Re: [O] [Proposal] Source Blocks with Post-Extensions

Well Ken, you improved my workflow right there, I am going to add the :prologue trick to my shell properties header and get the test error output in the results block. Thank you right back! On Fri, Jul 26, 2019 at 10:18 AM Ken Mankoff wrote: > > On 2019-07-26 at 08:58 -04, Martin Alsinet >

Re: [O] [Proposal] Source Blocks with Post-Extensions

On 2019-07-26 at 08:58 -04, Martin Alsinet wrote... > I usually have a shell buffer nearby and go there to inspect the > failed tests when I get no output. The problem is that shell blocks do > not capture stderr. John Kitchin wrote a blog post >

Re: [O] [Proposal] Source Blocks with Post-Extensions

Ken, I usually have a shell buffer nearby and go there to inspect the failed tests when I get no output. The problem is that shell blocks do not capture stderr. John Kitchin wrote a blog post about

Re: [O] [Proposal] Source Blocks with Post-Extensions

Hi Martin, On 2019-06-26 at 18:09 -04, Martin Alsinet wrote... > I use a different approach, where I tangle the source into files in > modules and then I import those modules from other blocks. This allows > me to organize my document with different sections for the code and > its tests, which

Re: [O] [Proposal] Source Blocks with Post-Extensions

Dear Martin, Your approach to test cases is quite valuable for more structured projects and for automation. For something that's either quick or w/out much architectural certainty to it, I would still prefer the handy one-liners. Nonetheless, thanks for the example! Best, Dmitrii. чт, 27 июн.

Re: [O] [Proposal] Source Blocks with Post-Extensions

Dmitrii, I use a different approach, where I tangle the source into files in modules and then I import those modules from other blocks. This allows me to organize my document with different sections for the code and its tests, which then get exported into their corresponding files. * Square

Re: [O] [Proposal] Source Blocks with Post-Extensions

Sorry for not answering these two days. You are right, that's an option. But I just don't think that's the best possible one - for usability. Introducing this would imply architectural decisions, so it might not be immediately clear if it's right or not. Especially that the improvement might not

Re: [O] [Proposal] Source Blocks with Post-Extensions

YMMV, but personally, I think the real problem here is combining your tests with your definition. i.e. square = lambda x: x * x is your real code block while the return line is really just part of testing/debugging and should not be in your definition block. Tests are very important, but I find

Re: [O] [Proposal] Source Blocks with Post-Extensions

> On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov wrote: > > Thank you! > That's a handy technique and it does help. > As I understand, there's no way to extend that to multiple lines? AFAICS, no there is no way to split the :epilogue arg to multiple lines. Of course, you can always

Re: [O] [Proposal] Source Blocks with Post-Extensions

Thank you! That's a handy technique and it does help. As I understand, there's no way to extend that to multiple lines? One-liners for tests are enough sometimes, but not always. For those cases, it is cumbersome to split as well. пн, 22 апр. 2019 г. в 22:51, Berry, Charles : > It looks like you

Re: [O] [Proposal] Source Blocks with Post-Extensions

It looks like you want the :epilogue header argument. See inline. > On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov wrote: > > 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 >

[O] [Proposal] Source Blocks with Post-Extensions

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)