From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SHs/EY1ejl52FAAA0tVLHw (envelope-from ) for ; Wed, 08 Apr 2020 23:30:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GK39BY5ejl7mdwAA1q6Kng (envelope-from ) for ; Wed, 08 Apr 2020 23:30:22 +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 DF9D0945CB5 for ; Wed, 8 Apr 2020 23:30:19 +0000 (UTC) Received: from localhost ([::1]:41530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMK9B-00006W-9k for larch@yhetil.org; Wed, 08 Apr 2020 19:30:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57141) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMK8i-00006P-68 for emacs-orgmode@gnu.org; Wed, 08 Apr 2020 19:29:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMK8g-0007Ml-NW for emacs-orgmode@gnu.org; Wed, 08 Apr 2020 19:29:47 -0400 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:36714) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jMK8g-0007LV-Dy for emacs-orgmode@gnu.org; Wed, 08 Apr 2020 19:29:46 -0400 Received: by mail-wm1-x329.google.com with SMTP id d202so1990084wmd.1 for ; Wed, 08 Apr 2020 16:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=wIp+tABa0bBVgzDHoCeHXpAwm6YSwofjKnjpLwSuZxg=; b=JpXxHy4ZzoGFVTWTqijDPhVu8q5TeiaqCTGgUfV6dECkbx3gIGUai07cUOMoWfa/cc dXG+owXF7ER8/KufSzE81n5cu4kaXA/gz6kbddAqYKf/bCYIcXos29c1cP1983Ykgr1Y WtX2dd+bMiYNVF44YVio6jjUGQciZf/wACsYjiMaMGGdq2Xk4J8KIomf0Hfpz4TMb2RC zeyBrrqck4nTrVrr0hA5BkTYOp1dI7DgBj8ZqDqasNdTQypHLGLUbsJJkpkSX9Ma04tM LC2JplmR1sH31MF9yjknwiQU76tl2KvQTlvLWgz76q68O1mFW7c7k5mF301QYknobYh+ QqmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=wIp+tABa0bBVgzDHoCeHXpAwm6YSwofjKnjpLwSuZxg=; b=oXPeg+ePAS4W6khTx1YdB3sGs4ETJ1CErto7M61jc/dmglpmovKoRe7CYlOzWBSarZ Inqvyi+3/JAYbGVo4W7ZypYLC0ByxfY4Ec/5yxP6s65o0SHJJGlW/dfXiUA2SXmQz9JE xhPs0+y4eYRo5XOMDNRRtB4SlNj4BaReeSpvQxBcoJ04YhBSSbUEB2zQFJGWt3u7DMll c8fXKS/AFxmdswtKT0kCOuZdr+mrUOpErI+VWizyyIK75328vApVLe1HlnahWPXLK/3x /vbDg4Rkvmg6DgGlKSSqBzJGEbb9qzj2DCMNC7zmUGFPu1d9Fq9v3YR8fuBVefAIrDeD wzeA== X-Gm-Message-State: AGi0PuZOIEeZldmwuKIaEvuUbLPT33aW0JQaYU0wMDQISM5BDoS0QPUP 05VJbCCXKiAKV0wRtFgTxP+7iSSP X-Google-Smtp-Source: APiQypIed3davttP/Ck2+/oQaLq9fxXdxE3k5GTCB0h/WLTAwhhr4krvkjvZeuiwO/tHT8yW22cYvQ== X-Received: by 2002:a1c:bb08:: with SMTP id l8mr7567680wmf.168.1586388584402; Wed, 08 Apr 2020 16:29:44 -0700 (PDT) Received: from localhost (tor-exit-1.zbau.f3netze.de. [185.220.100.252]) by smtp.googlemail.com with ESMTPSA id v16sm1304760wml.30.2020.04.08.16.29.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2020 16:29:43 -0700 (PDT) From: akater To: emacs-orgmode@gnu.org Subject: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer Date: Wed, 08 Apr 2020 23:20:59 +0000 Message-ID: <87mu7lzhr8.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::329 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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=default; t=1586388620; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=wIp+tABa0bBVgzDHoCeHXpAwm6YSwofjKnjpLwSuZxg=; b=ej3icV++YMqr/p37dspMAt98CDDMTCoDgWEZYaiBtHUQBzRkMZKuVqTEIX5AtYVoTQL9RM zL/rxbvaBSQ1qK/pdW7UHrn24v3RSxb+m5pNq3SxguhXDgbuZLqDv4PkQd+MWGHPlHss08 tJgZLUaUNiOenAcRbfM0U93jMKTdwh0= ARC-Seal: i=1; s=default; d=yhetil.org; t=1586388620; a=rsa-sha256; cv=none; b=Uwkfg4PEBubmsi1Qnyl9drxPN33prYH7M41If1EosJfqV9/6NK389DmFlD0ZtYUn5WcqFv WNnh8QRDgLxhKwYo0n9P+POfls2ozI8xORyXMMMqxkQir8VmCOJPI3XqFBzObc54u6zmGN x7U/hInRtpQD1WF5HFKBfBeJI/7wnXo= ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JpXxHy4Z; dmarc=pass (policy=none) header.from=gmail.com; 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-Scanner: scn0 X-Spam-Score: -1.21 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JpXxHy4Z; dmarc=pass (policy=none) header.from=gmail.com; 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-Scan-Result: default: False [-1.21 / 13.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GENERIC_REPUTATION(0.00)[-0.58126879545106]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=1]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.31), country: US(-0.01), ip: 209.51.188.17(-0.58)]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_NEQ_ENVFROM(0.00)[nuclearspace@gmail.com,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[emacs-orgmode@gnu.org]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_SEVEN(0.00)[7]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: 82fdDP0k+Fyp * 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 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 :=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 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 =3Dob-lisp=3D 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. =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 sense = 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 #+end_trace #+begin_output wow #+end_output while simply hiding empty blocks, if any, for convenience. Note that currently, when =E2=80=9Coutput=E2=80=9D is specified, =E2=80=9Cv= alues=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?