From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitrii Korobeinikov Subject: [Proposal] Source Blocks with Post-Extensions Date: Mon, 22 Apr 2019 15:00:13 +0600 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000f65dd105871ab265" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:45348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIUok-0006aG-DK for emacs-orgmode@gnu.org; Mon, 22 Apr 2019 05:00:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIUoe-0005TK-Jq for emacs-orgmode@gnu.org; Mon, 22 Apr 2019 05:00:46 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:38674) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hIUoY-0005IS-VG for emacs-orgmode@gnu.org; Mon, 22 Apr 2019 05:00:40 -0400 Received: by mail-wr1-x429.google.com with SMTP id f14so14494367wrj.5 for ; Mon, 22 Apr 2019 02:00:26 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org --000000000000f65dd105871ab265 Content-Type: multipart/alternative; boundary="000000000000f65dcf05871ab263" --000000000000f65dcf05871ab263 Content-Type: text/plain; charset="UTF-8" For your convenience, I have attached this e-mail as an org-mode file. When I write several source blocks, which depend on one another, I tend to debug them one by one. So, I write this function and test it: #+NAME: square #+BEGIN_SRC python square = lambda x: x * x return square(5) #+END_SRC #+RESULTS: square : 25 After I see that the test is successful, I write this client function: #+BEGIN_SRC python :noweb yes <> return 5 + square(5) #+END_SRC #+RESULTS: : 25 And here, to get the correct result, I have to remove the ~return square(5)~ line in ~<>~. But I don't want to lose testing! So I find nothing better to do than to seperate the source block: #+NAME: square-1 #+BEGIN_SRC python square = lambda x: x * x #+END_SRC And, by the way, there was no error/warning that I have just redefined ~<>~, so, for the test-snippet below to work, I renamed it to ~<>~. I think the org-mode team is aware of it, but anyway: - [ ] no error checking of the description of a code block. #+NAME: square-1-tester #+BEGIN_SRC python :noweb yes <> return square(5) #+END_SRC #+RESULTS: square-1-tester : 25 - [ ] For every such source block used for testing purposes, you have to repeat the inclusion statement and part of the name, which is cumbersome. A fair solution is maybe to extend the block like this: #+NAME: square-1 #+BEGIN_SRC python square = lambda x: x * x #+END_SRC return square(5) #+END_SRC_TEST When I call this individually, the test part would run, but when I :noweb it in another block, the test part would be ommited. As an extension of this idea, it could be useful to have several test attachments like this, each producing its own result. Maybe, the TEST part could as well be ommited. Custom names are also an option: #+NAME: square-multiple #+BEGIN_SRC python square = lambda x: x * x #+END_SRC return square(5) #+END_SRC NAME: ext_1 return square(10) #+END_SRC NAME: ext_2 #+RESULTS: square-multiple-ext-1 : 25 #+RESULTS: square-multiple-ext-2 : 100 Overall, these techniques should reduce noise and increase usability. --000000000000f65dcf05871ab263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For your conve= nience, I have attached this e-mail as an org-mode file.
When I write several source blocks, which depend on one anothe= r, I tend to debug them one by one.

So, I write th= is function and test it:

#+NAME: square
= #+BEGIN_SRC python
=C2=A0 =C2=A0 square =3D lambda x: x * x
=
=C2=A0 =C2=A0 return square(5)
#+END_SRC

#+RESULTS: square
: 25

After I see= that the test is successful, I write this client function:

<= /div>
#+BEGIN_SRC python :noweb yes
=C2=A0 =C2=A0 <<squ= are>>
=C2=A0 =C2=A0 return 5 + square(5)
#+END_SR= C

#+RESULTS:
: 25

And here, to get the correct result, I have to remove the ~return square= (5)~ line in ~<<square>>~.
But I don't want to lo= se testing!
So I find nothing better to do than to seperate the s= ource block:

#+NAME: square-1
#+BEGIN_SR= C python
=C2=A0 =C2=A0 square =3D lambda x: x * x
#+END= _SRC

And, by the way, there was no error/warning t= hat I have just redefined ~<<square>>~,
so, for the t= est-snippet below to work, I renamed it to ~<<square-1>>~.
I think the org-mode team is aware of it, but anyway:

<= /div>
- [ ] no error checking of the description of a code block.
=

#+NAME: square-1-tester
#+BEGIN_SRC python :n= oweb yes
=C2=A0 <<square-1>>
=C2=A0 return = square(5)
#+END_SRC

#+RESULTS: square-1-= tester
: 25

- [ ] For every such source = block used for testing purposes, you have to repeat the inclusion statement= and part of the name, which is cumbersome.

A fair= solution is maybe to extend the block like this:

= #+NAME: square-1
#+BEGIN_SRC python
=C2=A0 square =3D l= ambda x: x * x
#+END_SRC
=C2=A0 return square(5)
<= div>#+END_SRC_TEST

When I call this individually, = the test part would run, but when I :noweb it in another block, the test pa= rt would be ommited.

As an extension of this idea,= it could be useful to have several test attachments like this, each produc= ing its own result. Maybe, the TEST part could as well be ommited. Custom n= ames are also an option:

#+NAME: square-multiple
#+BEGIN_SRC python
=C2=A0 square =3D lambda x: x * x
#+END_SRC
=C2=A0 return square(5)
#+END_SRC NAME= : ext_1=C2=A0
=C2=A0 return square(10)
#+END_SRC NAME: = ext_2=C2=A0

#+RESULTS: square-multiple-ext-1
=
: 25

#+RESULTS: square-multiple-ext-2
: 100

Overall, these techniques should reduce n= oise and increase usability.

--000000000000f65dcf05871ab263-- --000000000000f65dd105871ab265 Content-Type: application/octet-stream; name="org-test-suite.org" Content-Disposition: attachment; filename="org-test-suite.org" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jus4mk3o0 IytUSVRMRTogW1Byb3Bvc2FsXSBTb3VyY2UgQmxvY2tzIHdpdGggUG9zdC1FeHRlbnNpb25zCiMr QVVUSE9SOiBEbWl0cmlpIEtvcm9iZWluaWtvdgojK0VNQUlMOiBkaW0xMjEya0BnbWFpbC5jb20K CldoZW4gSSB3cml0ZSBzZXZlcmFsIHNvdXJjZSBibG9ja3MsIHdoaWNoIGRlcGVuZCBvbiBvbmUg YW5vdGhlciwgSSB0ZW5kIHRvIGRlYnVnIHRoZW0gb25lIGJ5IG9uZS4KClNvLCBJIHdyaXRlIHRo aXMgZnVuY3Rpb24gYW5kIHRlc3QgaXQ6CgojK05BTUU6IHNxdWFyZQojK0JFR0lOX1NSQyBweXRo b24KICAgIHNxdWFyZSA9IGxhbWJkYSB4OiB4ICogeAogICAgcmV0dXJuIHNxdWFyZSg1KQojK0VO RF9TUkMKCiMrUkVTVUxUUzogc3F1YXJlCjogMjUKCkFmdGVyIEkgc2VlIHRoYXQgdGhlIHRlc3Qg aXMgc3VjY2Vzc2Z1bCwgSSB3cml0ZSB0aGlzIGNsaWVudCBmdW5jdGlvbjoKCiMrQkVHSU5fU1JD IHB5dGhvbiA6bm93ZWIgeWVzCiAgICA8PHNxdWFyZT4+CiAgICByZXR1cm4gNSArIHNxdWFyZSg1 KQojK0VORF9TUkMKCiMrUkVTVUxUUzoKOiAyNQoKQW5kIGhlcmUsIHRvIGdldCB0aGUgY29ycmVj dCByZXN1bHQsIEkgaGF2ZSB0byByZW1vdmUgdGhlIH5yZXR1cm4gc3F1YXJlKDUpfiBsaW5lIGlu IH48PHNxdWFyZT4+fi4KQnV0IEkgZG9uJ3Qgd2FudCB0byBsb3NlIHRlc3RpbmchClNvIEkgZmlu ZCBub3RoaW5nIGJldHRlciB0byBkbyB0aGFuIHRvIHNlcGVyYXRlIHRoZSBzb3VyY2UgYmxvY2s6 CgojK05BTUU6IHNxdWFyZS0xCiMrQkVHSU5fU1JDIHB5dGhvbgogICAgc3F1YXJlID0gbGFtYmRh IHg6IHggKiB4CiMrRU5EX1NSQwoKQW5kLCBieSB0aGUgd2F5LCB0aGVyZSB3YXMgbm8gZXJyb3Iv d2FybmluZyB0aGF0IEkgaGF2ZSBqdXN0IHJlZGVmaW5lZCB+PDxzcXVhcmU+Pn4sCnNvLCBmb3Ig dGhlIHRlc3Qtc25pcHBldCBiZWxvdyB0byB3b3JrLCBJIHJlbmFtZWQgaXQgdG8gfjw8c3F1YXJl LTE+Pn4uCkkgdGhpbmsgdGhlIG9yZy1tb2RlIHRlYW0gaXMgYXdhcmUgb2YgaXQsIGJ1dCBhbnl3 YXk6CgotIFsgXSBubyBlcnJvciBjaGVja2luZyBvZiB0aGUgZGVzY3JpcHRpb24gb2YgYSBjb2Rl IGJsb2NrLgoKIytOQU1FOiBzcXVhcmUtMS10ZXN0ZXIKIytCRUdJTl9TUkMgcHl0aG9uIDpub3dl YiB5ZXMKICA8PHNxdWFyZS0xPj4KICByZXR1cm4gc3F1YXJlKDUpCiMrRU5EX1NSQwoKIytSRVNV TFRTOiBzcXVhcmUtMS10ZXN0ZXIKOiAyNQoKLSBbIF0gRm9yIGV2ZXJ5IHN1Y2ggc291cmNlIGJs b2NrIHVzZWQgZm9yIHRlc3RpbmcgcHVycG9zZXMsIHlvdSBoYXZlIHRvIHJlcGVhdCB0aGUgaW5j bHVzaW9uIHN0YXRlbWVudCBhbmQgcGFydCBvZiB0aGUgbmFtZSwgd2hpY2ggaXMgY3VtYmVyc29t ZS4KCkEgZmFpciBzb2x1dGlvbiBpcyBtYXliZSBleHRlbmQgdGhlIGJsb2NrIGxpa2UgdGhpczoK CiMrTkFNRTogc3F1YXJlLTEKIytCRUdJTl9TUkMgcHl0aG9uCiAgc3F1YXJlID0gbGFtYmRhIHg6 IHggKiB4CiMrRU5EX1NSQwogIHJldHVybiBzcXVhcmUoNSkKIytFTkRfU1JDX1RFU1QKCldoZW4g SSBjYWxsIHRoaXMgaW5kaXZpZHVhbGx5LCB0aGUgdGVzdCBwYXJ0IHdvdWxkIHJ1biwgYnV0IHdo ZW4gSSA6bm93ZWIgaXQgaW4gYW5vdGhlciBibG9jaywgdGhlIHRlc3QgcGFydCB3b3VsZCBiZSBv bW1pdGVkLgoKQXMgYW4gZXh0ZW5zaW9uIG9mIHRoaXMgaWRlYSwgaXQgY291bGQgYmUgdXNlZnVs IHRvIGhhdmUgc2V2ZXJhbCB0ZXN0IGF0dGFjaG1lbnRzIGxpa2UgdGhpcywgZWFjaCBwcm9kdWNp bmcgaXRzIG93biByZXN1bHQuIE1heWJlLCB0aGUgVEVTVCBwYXJ0IGNvdWxkIGFzIHdlbGwgYmUg b21taXRlZC4gQ3VzdG9tIG5hbWVzIGFyZSBhbHNvIGFuIG9wdGlvbjoKCiMrTkFNRTogc3F1YXJl LW11bHRpcGxlCiMrQkVHSU5fU1JDIHB5dGhvbgogIHNxdWFyZSA9IGxhbWJkYSB4OiB4ICogeAoj K0VORF9TUkMKICByZXR1cm4gc3F1YXJlKDUpCiMrRU5EX1NSQyBOQU1FOiBleHRfMSAKICByZXR1 cm4gc3F1YXJlKDEwKQojK0VORF9TUkMgTkFNRTogZXh0XzIgCgojK1JFU1VMVFM6IHNxdWFyZS1t dWx0aXBsZS1leHQtMQo6IDI1CgojK1JFU1VMVFM6IHNxdWFyZS1tdWx0aXBsZS1leHQtMgo6IDEw MAoKT3ZlcmFsbCwgdGhlc2UgdGVjaG5pcXVlcyBzaG91bGQgcmVkdWNlIG5vaXNlIGFuZCBpbmNy ZWFzZSB1c2FiaWxpdHkuCg== --000000000000f65dd105871ab265--