From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id wHgsLLsPy156GQAA0tVLHw (envelope-from ) for ; Mon, 25 May 2020 00:22:19 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id SJsDKLsPy17tJwAAbx9fmQ (envelope-from ) for ; Mon, 25 May 2020 00:22:19 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CB5B79403EC for ; Mon, 25 May 2020 00:22:18 +0000 (UTC) Received: from localhost ([::1]:54460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jd0si-0004fJ-Li for larch@yhetil.org; Sun, 24 May 2020 20:22:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32860) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jd0sN-0004fA-5L for emacs-orgmode@gnu.org; Sun, 24 May 2020 20:21:55 -0400 Received: from [183.249.132.153] (port=1968 helo=localhost) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jd0sL-0006iU-UB for emacs-orgmode@gnu.org; Sun, 24 May 2020 20:21:54 -0400 Received: by localhost (Postfix, from userid 1000) id AC5F2241A15; Mon, 25 May 2020 08:21:46 +0800 (HKT) References: <87mu7lzhr8.fsf@gmail.com> User-agent: mu4e 1.4; emacs 28.0.50 From: stardiviner To: akater Subject: Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer In-reply-to: <87mu7lzhr8.fsf@gmail.com> Date: Mon, 25 May 2020 08:21:46 +0800 Message-ID: <87zh9wg8yt.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 183.249.132.153 (deferred) Received-SPF: softfail client-ip=183.249.132.153; envelope-from=numbchild@gmail.com; helo=localhost X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/24 20:12:11 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: 53 X-Spam_score: 5.3 X-Spam_bar: +++++ X-Spam_report: (5.3 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FSL_HELO_NON_FQDN_1=0.001, HELO_LOCALHOST=3.828, NML_ADSP_CUSTOM_MED=0.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: reject X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: numbchild@gmail.com Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.91 X-TUID: L9l33UbSjNCt =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 akater 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 =3D:results=3D is always emit= ted > 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 > :=20=20=20 > > ** 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) > ;=20 > ; caught STYLE-WARNING: > ; Lisp error during constant folding: > ; arithmetic error DIVISION-BY-ZERO signalled > ; Operation was (/ 1 0). > ;=20 > ; 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) > ;=20 > ; caught STYLE-WARNING: > ; Lisp error during constant folding: > ; arithmetic error DIVISION-BY-ZERO signalled > ; Operation was (/ 1 0). > ;=20 > ; 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 >=20=20=20 > > 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 =3Dob-lisp=3D completely for those w= ho > 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. =3D:results output=3D behaves as = it > used to. Preserving compatibility requires patching > ~org-babel-result-cond~ so that it does not try to vectorise output from > =3D:result trace=3D, =3D:result errors=3D. > > We could avoid this by requiring the =3Doutput=3D parameter all the time,= so > that user would have to write something like =3D:results trace output=3D = or > =3D:results output trace standard=3D. While the former is neat, the latter > is not. Also, the notion =E2=80=9Cerror output stream=E2=80=9D makes sens= e not only for > Common Lisp. Thus, adding =3Dtrace=3D and =3Derrors=3D 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) > ;=20 > ; caught STYLE-WARNING: > ; Lisp error during constant folding: > ; arithmetic error DIVISION-BY-ZERO signalled > ; Operation was (/ 1 0). > ;=20 > ; 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 >=20=20=20 > > #+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 u= se result as source block input data. WDYT? > while simply hiding empty blocks, if any, for convenience. > > Note that currently, when =E2=80=9Coutput=E2=80=9D is specified, =E2=80= =9Cvalues=E2=80=9D 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 ve= rsion to make sure ~:results trace~ is usable. If not, warn user to update SLIME.= WDYT? =2D --=20 [ 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 =20=20=20=20=20=20 =2D----BEGIN PGP SIGNATURE----- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7LD5oUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsOfywgApWgakIbbyqXschl80ynG/4feY+CN dE2M+65SG3PKwO41DpfAo85n8JKSRqODYPzxRZSWU6nX1su/q7+e3sxkXN/WEIHW Di47Xbq5G9OgBT+Hs9lK5sGHrvL2c7RfPnXi8WNhyPriMrRBQc35n4ZG6OyVpnOG Q3o+RZdcDN3Jyxpp1w0iPzpfx0m6Qh7NGdfg9Gqb+uuKgCH+Nqixy/Oy/yYxdvwZ wLgZWqdwu4kV7LUNEf/nqLmQm2K74v5N9+Ysa1ChaQFpfBADbXIDCyZhV2Qqw0QJ 6FnmL0xM1Ajs9yvPe0ilb6UV1bvGCkCMcLPQ9lcr7qs4xju49SpFH0q45Q=3D=3D =3DUg7d =2D----END PGP SIGNATURE-----