-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
akater <nuclearsp...@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-----