* Summary I have a patch that allows to put trace output and error output into corresponding Org buffer. Current behaviour with outputs being splitted so that they go to different buffers (Org buffer, REPL), is arbitrary and inconvenient. The patch ensures backwards compatibility. I thus believe merging the patch would be a clear improvement. I use the proposed features daily (trace, mostly). Note however that the patch can't be merged right away; see [[Caveats]]. Contents of output streams not specified in =:results= is always emitted to REPL buffer. * Examples I'll give here some examples of what's possible with the patch applied that is not possible currently. ** Output of ~time~ #+begin_src lisp :results trace (time 0) #+end_src #+RESULTS: : Evaluation took: : 0.000 seconds of real time : 0.000004 seconds of total run time (0.000004 user, 0.000000 system) : 100.00% CPU : 420 processor cycles : 0 bytes consed : ** Traces #+begin_src lisp :results trace :wrap example lisp (defun memq (item list) (or (eq item (car list)) (memq item (cdr list)))) (trace memq) (memq 'e '(a b c d e f)) #+end_src #+RESULTS: #+begin_example lisp 0: (MEMQ E (B C D E F)) 1: (MEMQ E (C D E F)) 2: (MEMQ E (D E F)) 3: (MEMQ E (E F)) 3: MEMQ returned T 2: MEMQ returned T 1: MEMQ returned T 0: MEMQ returned T #+end_example ** Ignored errors #+begin_src lisp :results errors :wrap example lisp (ignore-errors (/ 1 0)) #+end_src #+RESULTS: #+begin_example lisp ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/")) ; (/ 1 0) ; ; caught STYLE-WARNING: ; Lisp error during constant folding: ; arithmetic error DIVISION-BY-ZERO signalled ; Operation was (/ 1 0). ; ; compilation unit finished ; caught 1 STYLE-WARNING condition #+end_example ** A combo #+begin_src lisp :results errors trace output :wrap example lisp (progn (time 0) (ignore-errors (/ 1 0)) (princ "wow")) #+end_src #+RESULTS: #+begin_example lisp ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/")) ; (/ 1 0) ; ; caught STYLE-WARNING: ; Lisp error during constant folding: ; arithmetic error DIVISION-BY-ZERO signalled ; Operation was (/ 1 0). ; ; compilation unit finished ; caught 1 STYLE-WARNING condition Evaluation took: 0.000 seconds of real time 0.000004 seconds of total run time (0.000004 user, 0.000000 system) 100.00% CPU 420 processor cycles 0 bytes consed wow #+end_example * Caveats This improvement requires a change in SLIME code. One of SLIME maintaners agreed to merge it but SLIME and Org would need to synchronise their updates, and I'm not sure how to approach this. Corresponding patch to SLIME changes the interface of ~swank:eval-and-grab-output~. As implemented, ~swank:eval-and-grab-output~ makes its users choose between values and output by means of ~car~ and ~cadr~; preserving the compatibility by extending the current behaviour would make its users refer to various outputs by their positions which is a very bad idea. I employed alist instead. However, merging will break =ob-lisp= completely for those who use vcs Org but a stable SLIME. The change to SLIME may also affect ~org-babel-execute:clojure~ but I have no idea why Clojure would use SLIME and whether it actually does use it. Anyway, I will be able to provide a patch for it that would ensure backwards compatibility. * Some Details ** Syntax At least one function needs to be changed, namely ~org-babel-execute:lisp~. We preserve the current behaviour, i.e. =:results output= behaves as it used to. Preserving compatibility requires patching ~org-babel-result-cond~ so that it does not try to vectorise output from =:result trace=, =:result errors=. We could avoid this by requiring the =output= parameter all the time, so that user would have to write something like =:results trace output= or =:results output trace standard=. While the former is neat, the latter is not. Also, the notion “error output stream” makes sense not only for Common Lisp. Thus, adding =trace= and =errors= exceptional cases to ~org-babel-result-cond~ looks acceptable to me. ** (suggestion) Multi-block return Overall, I believe it would be best to embrace full potential of Org features and implement multi-block results as default for Common Lisp evaluation in Org, like in the following example: #+begin_src lisp (progn (time 0) (ignore-errors (/ 1 0)) (princ "wow") t) #+end_src #+RESULTS: #+begin_values lisp T #+end_values #+begin_errors lisp ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/")) ; (/ 1 0) ; ; caught STYLE-WARNING: ; Lisp error during constant folding: ; arithmetic error DIVISION-BY-ZERO signalled ; Operation was (/ 1 0). ; ; compilation unit finished ; caught 1 STYLE-WARNING condition #+end_errors #+begin_trace lisp Evaluation took: 0.000 seconds of real time 0.000003 seconds of total run time (0.000003 user, 0.000000 system) 100.00% CPU 476 processor cycles 0 bytes consed #+end_trace #+begin_output wow #+end_output while simply hiding empty blocks, if any, for convenience. Note that currently, when “output” is specified, “values” is simply lost, and vice versa. Implementing multi-block results would fix this shortcoming too. However, I did not try to implement this yet. * Conclusion How do we sync with SLIME if you're OK with this? How do we treat the case of vcs Org + stable SLIME?
Hi, akater <nuclearspace@gmail.com> writes: > I have a patch that allows to put trace output and error output into > corresponding Org buffer. Can you share the patch (as an attachment)? Does it add a functionality just for one ob-* library or for babel evaluation in general? > Current behaviour with outputs being splitted > so that they go to different buffers (Org buffer, REPL), is arbitrary > and inconvenient. The patch ensures backwards compatibility. I thus > believe merging the patch would be a clear improvement. I use the > proposed features daily (trace, mostly). Note however that the patch > can't be merged right away; see [[Caveats]]. Can the patch be made so that the ob-* library is still compatible with previous versions of slime? If the patch is just for one babel library and completely depends on a version of slime that does not exist yet, perhaps it is a good idea to publish your modified version of that library, test the proposed feature with your users and see what can be added to Org's core later on? Don't hesitate to send an update on this. Thanks, -- Bastien
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 akater <nuclearspace@gmail.com> writes: > * Summary > I have a patch that allows to put trace output and error output into > corresponding Org buffer. Current behaviour with outputs being splitted > so that they go to different buffers (Org buffer, REPL), is arbitrary > and inconvenient. The patch ensures backwards compatibility. I thus > believe merging the patch would be a clear improvement. I use the > proposed features daily (trace, mostly). Note however that the patch > can't be merged right away; see [[Caveats]]. > > Contents of output streams not specified in =:results= is always emitted > to REPL buffer. > > * Examples > I'll give here some examples of what's possible with the patch applied > that is not possible currently. > > ** Output of ~time~ > #+begin_src lisp :results trace > (time 0) > #+end_src > > #+RESULTS: > : Evaluation took: > : 0.000 seconds of real time > : 0.000004 seconds of total run time (0.000004 user, 0.000000 system) > : 100.00% CPU > : 420 processor cycles > : 0 bytes consed > : > > ** Traces > #+begin_src lisp :results trace :wrap example lisp > (defun memq (item list) (or (eq item (car list)) (memq item (cdr list)))) > (trace memq) > (memq 'e '(a b c d e f)) > #+end_src > > #+RESULTS: > #+begin_example lisp > 0: (MEMQ E (B C D E F)) > 1: (MEMQ E (C D E F)) > 2: (MEMQ E (D E F)) > 3: (MEMQ E (E F)) > 3: MEMQ returned T > 2: MEMQ returned T > 1: MEMQ returned T > 0: MEMQ returned T > #+end_example > > ** Ignored errors > #+begin_src lisp :results errors :wrap example lisp > (ignore-errors (/ 1 0)) > #+end_src > > #+RESULTS: > #+begin_example lisp > ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/")) > ; (/ 1 0) > ; > ; caught STYLE-WARNING: > ; Lisp error during constant folding: > ; arithmetic error DIVISION-BY-ZERO signalled > ; Operation was (/ 1 0). > ; > ; compilation unit finished > ; caught 1 STYLE-WARNING condition > #+end_example > > ** A combo > #+begin_src lisp :results errors trace output :wrap example lisp > (progn (time 0) (ignore-errors (/ 1 0)) (princ "wow")) > #+end_src > > #+RESULTS: > #+begin_example lisp > ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/")) > ; (/ 1 0) > ; > ; caught STYLE-WARNING: > ; Lisp error during constant folding: > ; arithmetic error DIVISION-BY-ZERO signalled > ; Operation was (/ 1 0). > ; > ; compilation unit finished > ; caught 1 STYLE-WARNING condition > > Evaluation took: > 0.000 seconds of real time > 0.000004 seconds of total run time (0.000004 user, 0.000000 system) > 100.00% CPU > 420 processor cycles > 0 bytes consed > > > wow > #+end_example This looks really a great feature!!! > > * Caveats > This improvement requires a change in SLIME code. One of SLIME > maintaners agreed to merge it but SLIME and Org would need to > synchronise their updates, and I'm not sure how to approach this. > > Corresponding patch to SLIME changes the interface of > ~swank:eval-and-grab-output~. As implemented, > ~swank:eval-and-grab-output~ makes its users choose between values and > output by means of ~car~ and ~cadr~; preserving the compatibility by > extending the current behaviour would make its users refer to various > outputs by their positions which is a very bad idea. I employed alist > instead. However, merging will break =ob-lisp= completely for those who > use vcs Org but a stable SLIME. > > The change to SLIME may also affect ~org-babel-execute:clojure~ but I > have no idea why Clojure would use SLIME and whether it actually does > use it. Anyway, I will be able to provide a patch for it that would > ensure backwards compatibility. > > * Some Details > ** Syntax > At least one function needs to be changed, namely > ~org-babel-execute:lisp~. > > We preserve the current behaviour, i.e. =:results output= behaves as it > used to. Preserving compatibility requires patching > ~org-babel-result-cond~ so that it does not try to vectorise output from > =:result trace=, =:result errors=. > > We could avoid this by requiring the =output= parameter all the time, so > that user would have to write something like =:results trace output= or > =:results output trace standard=. While the former is neat, the latter > is not. Also, the notion “error output stream” makes sense not only for > Common Lisp. Thus, adding =trace= and =errors= exceptional cases to > ~org-babel-result-cond~ looks acceptable to me. > > ** (suggestion) Multi-block return > Overall, I believe it would be best to embrace full potential of Org > features and implement multi-block results as default for Common Lisp > evaluation in Org, like in the following example: > > #+begin_src lisp > (progn (time 0) (ignore-errors (/ 1 0)) (princ "wow") t) > #+end_src > > #+RESULTS: > #+begin_values lisp > T > #+end_values > #+begin_errors lisp > ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/")) > ; (/ 1 0) > ; > ; caught STYLE-WARNING: > ; Lisp error during constant folding: > ; arithmetic error DIVISION-BY-ZERO signalled > ; Operation was (/ 1 0). > ; > ; compilation unit finished > ; caught 1 STYLE-WARNING condition > #+end_errors > #+begin_trace lisp > Evaluation took: > 0.000 seconds of real time > 0.000003 seconds of total run time (0.000003 user, 0.000000 system) > 100.00% CPU > 476 processor cycles > 0 bytes consed > > > #+end_trace > #+begin_output > wow > #+end_output > I have some considering. Multi-block return might will cause other options hard to handle the result block. For example ~:cache~, ~:results replace~, and use result as source block input data. WDYT? > while simply hiding empty blocks, if any, for convenience. > > Note that currently, when “output” is specified, “values” is simply > lost, and vice versa. Implementing multi-block results would fix this > shortcoming too. > > However, I did not try to implement this yet. > > * Conclusion > How do we sync with SLIME if you're OK with this? How do we treat the > case of vcs Org + stable SLIME? Might on Org Mode side, add an function to detect SLIME output, or SLIME version to make sure ~:results trace~ is usable. If not, warn user to update SLIME. WDYT? - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -----BEGIN PGP SIGNATURE----- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7LD5oUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsOfywgApWgakIbbyqXschl80ynG/4feY+CN dE2M+65SG3PKwO41DpfAo85n8JKSRqODYPzxRZSWU6nX1su/q7+e3sxkXN/WEIHW Di47Xbq5G9OgBT+Hs9lK5sGHrvL2c7RfPnXi8WNhyPriMrRBQc35n4ZG6OyVpnOG Q3o+RZdcDN3Jyxpp1w0iPzpfx0m6Qh7NGdfg9Gqb+uuKgCH+Nqixy/Oy/yYxdvwZ wLgZWqdwu4kV7LUNEf/nqLmQm2K74v5N9+Ysa1ChaQFpfBADbXIDCyZhV2Qqw0QJ 6FnmL0xM1Ajs9yvPe0ilb6UV1bvGCkCMcLPQ9lcr7qs4xju49SpFH0q45Q== =Ug7d -----END PGP SIGNATURE-----
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --] stardiviner <numbchild@gmail.com> writes: > I have some considering. Multi-block return might will cause other options hard > to handle the result block. For example ~:cache~, ~:results replace~, and use result > as source block input data. WDYT? Probably. I'm not a user of either :cache or :results replace but multi-block return, if implemented, will likely require some non-trivial work to be incorporated smoothly. Returning just a single block by default will keep it safe for general users. But I do find it suspicious when some output is produced and yet not submitted into the buffer where evaluation results are supposed to go. And Org seems to be able to handle this very neatly. >> while simply hiding empty blocks, if any, for convenience. >> >> Note that currently, when “output” is specified, “values” is simply >> lost, and vice versa. Implementing multi-block results would fix this >> shortcoming too. >> >> However, I did not try to implement this yet. >> >> * Conclusion >> How do we sync with SLIME if you're OK with this? How do we treat the >> case of vcs Org + stable SLIME? > > Might on Org Mode side, add an function to detect SLIME output, or SLIME version > to make sure ~:results trace~ is usable. If not, warn user to update SLIME. WDYT? For now, I just delayed activation of the feature in Org until a certain future SLIME version. In my SLIME patch, it's handled more subtly, using supplied-p optional argument, a check that can be dropped once Org 9.3 becomes unsupported. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 800 bytes --]