From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 06:05:43 2020 Received: (at submit) by debbugs.gnu.org; 10 Mar 2020 10:05:43 +0000 Received: from localhost ([127.0.0.1]:51908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBblf-000775-BQ for submit@debbugs.gnu.org; Tue, 10 Mar 2020 06:05:43 -0400 Received: from lists.gnu.org ([209.51.188.17]:44586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBble-00076y-ER for submit@debbugs.gnu.org; Tue, 10 Mar 2020 06:05:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58965) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBbld-00007Y-7V for bug-guile@gnu.org; Tue, 10 Mar 2020 06:05:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBblb-0006oE-S5 for bug-guile@gnu.org; Tue, 10 Mar 2020 06:05:41 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:59179 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jBblb-0006mS-ND for bug-guile@gnu.org; Tue, 10 Mar 2020 06:05:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583834738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=KVWpN5IDlPdoV1YAdTqqX6AoSEvz6G/aqARRo0f+mnc=; b=Dp0Vs0PNxTyhaCIHRp5iGX/6BXvGY0QDOR+W1YpUdTAVn8N2AjT42VNzZrh3rBBKG2cpTi 66VXPQewX7RSbBwXt4CBckEQGUBiqrtY8QWIewyZ3jFcU7jYrFt6vrkXIVSsbcpnHIphup DO6aZWKE7LkWIgpE7AqqcoZLiEPo4OI= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-ikAqQfO8McmmaQYPsgNxYg-1; Tue, 10 Mar 2020 06:05:36 -0400 X-MC-Unique: ikAqQfO8McmmaQYPsgNxYg-1 Received: by mail-il1-f200.google.com with SMTP id g79so6044467ild.7 for ; Tue, 10 Mar 2020 03:05:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KVWpN5IDlPdoV1YAdTqqX6AoSEvz6G/aqARRo0f+mnc=; b=SrM2qqywchO0HlCMt3L/dCrKfd4RBUZ3bOsMhKARpXpuDKZZc3LmIBP7E8E4nBciXy ovqRwhC5MQh+RPFdQdbp4sfBhj2U2OmujPMFnePYmaMVbl0JOXAAoOwqWNhRtNM0bIFm EtGu2Vis9KhHTkgvzARqbq9y0us8TYcdNfd9k9Loi+Ux+Rf0uvjr+shCWhRR2TNvlZzm jYFlRW8v2enSjOaZ6vY+0VJsJtLj4+6u5Xq0qvqrH4Z29ubgU8Ribz0WN7vvRAPPcNkR E5h8AYansiDnGH7bO9XtWLmU8beX/nwfGb5lNY5TDiX5tmB6WLDe77PO/OTYdHTNcIYL 9jpg== X-Gm-Message-State: ANhLgQ1Qixp+OdBPYFk5IRFDJrWFNX8yLzzw2q8QmwIwc0RflW5qyqhv z5qyT1bAR5UgLI2gNcRGhPagw7jd0BZWUkFOnGj75wNanA00fSVtxdyfdcari/XiAkQQEtUTi1q o12m6FnUTKgUzFapGV4+zqR2OkQ== X-Received: by 2002:a05:6e02:c94:: with SMTP id b20mr18670375ile.282.1583834735761; Tue, 10 Mar 2020 03:05:35 -0700 (PDT) X-Google-Smtp-Source: ADFU+vviKIeNrryMWyK6u+WpxSBkAlAVJ0s5xmH1LVTzeLQfUdJbcfJPozDzFS5rRSnzMDDJP5nWsmCNCNd8Ybp/8HI= X-Received: by 2002:a05:6e02:c94:: with SMTP id b20mr18670359ile.282.1583834735497; Tue, 10 Mar 2020 03:05:35 -0700 (PDT) MIME-Version: 1.0 From: Jan Synacek Date: Tue, 10 Mar 2020 11:05:24 +0100 Message-ID: Subject: Backtraces can contain very long strings To: bug-guile@gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000caea5c05a07d42fe" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.120 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) --000000000000caea5c05a07d42fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have the following backtrace: Backtrace: In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 8 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 7 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 6 (_ #(#(#))) In ice-9/boot-9.scm: 2806:4 5 (save-module-excursion _) 4351:12 4 (_) In /home/jsynacek/./git.scm: 72:0 3 (_) 61:16 2 (change-spec _ _ "66.33" _ #) 48:12 1 (change-release "# We ship a .pc file but don't want t=E2=80= =A6" =E2=80=A6) In unknown file: 0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil=E2=80= =A6" =E2=80=A6) ERROR: In procedure make-regexp: Wrong type (expecting exact integer): " " While this is probably not considered an error, I guess it might be better to ellipsize strings in errors such is mine that are over a certain length long. The important part of the backtrace was scrolled away and I got confused about the string, as I thought it was part of the output and started wondering why (display ...) keeps the escaped newlines in the string. If this is not considered a bug, please, at least consider it an RFE. --=20 Jan Synacek Software Engineer, Red Hat --000000000000caea5c05a07d42fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have the following backtrace:

Backtrace:
In ice-9/= boot-9.scm:
=C2=A0 1736:10 =C2=A09 (with-exception-handler _ _ #:unwind?= _ # _)
In unknown file:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08 (= apply-smob/0 #<thunk 651b40>)
In ice-9/boot-9.scm:
=C2=A0 =C2= =A0 718:2 =C2=A07 (call-with-prompt _ _ #<procedure default-prompt-handl= e=E2=80=A6>)
In ice-9/eval.scm:
=C2=A0 =C2=A0 619:8 =C2=A06 (_ #(#= (#<directory (guile-user) 74cf00>)))
In ice-9/boot-9.scm:
=C2= =A0 =C2=A02806:4 =C2=A05 (save-module-excursion _)
=C2=A0 4351:12 =C2=A0= 4 (_)
In /home/jsynacek/./git.scm:
=C2=A0 =C2=A0 =C2=A072:0 =C2=A03 (= _)
=C2=A0 =C2=A0 61:16 =C2=A02 (change-spec _ _ "66.33" _ #<= ;output: file 1>)
=C2=A0 =C2=A0 48:12 =C2=A01 (change-release "#= We ship a .pc file but don't want t=E2=80=A6" =E2=80=A6)
In un= known file:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 (make-regexp &quo= t;^Release:(\\s*).*$" "# We ship a .pc fil=E2=80=A6" =E2=80= =A6)

ERROR: In procedure make-regexp:
Wrong type (expecting exact i= nteger): "
<HERE COMES A LOOOONG STRING WHICH IS ABOUT 193000 CHAR= ACTERS WIDE>
"

While this is probably not considered an err= or, I guess it might be better to ellipsize strings in errors such is mine = that are over a certain length long. The important part of the backtrace wa= s scrolled away and I got confused about the string, as I thought it was pa= rt of the output and started wondering why (display ...) keeps the escaped = newlines in the string.

If this is not considered = a bug, please, at least consider it an RFE.

--
Jan S= ynacek
Software Engineer, Red Hat
--000000000000caea5c05a07d42fe-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 07:47:25 2020 Received: (at submit) by debbugs.gnu.org; 10 Mar 2020 11:47:25 +0000 Received: from localhost ([127.0.0.1]:51951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBdM5-0003KJ-7N for submit@debbugs.gnu.org; Tue, 10 Mar 2020 07:47:25 -0400 Received: from lists.gnu.org ([209.51.188.17]:40245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBdM3-0003KB-3B for submit@debbugs.gnu.org; Tue, 10 Mar 2020 07:47:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44416) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBdM1-0007B9-Do for bug-guile@gnu.org; Tue, 10 Mar 2020 07:47:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_NONE, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBdM0-0002aC-0B for bug-guile@gnu.org; Tue, 10 Mar 2020 07:47:21 -0400 Received: from mail.tuxteam.de ([5.199.139.25]:47384) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jBdLz-00025W-FX for bug-guile@gnu.org; Tue, 10 Mar 2020 07:47:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:Date; bh=V8asfJVW8yQtC4VlBgzIebE+6aiHaxDTzRDggJ8WI+I=; b=REBCIJFeJlW+7hJelO5Ak/A4bZo+oZ/nrLZ3s24kTdHMnbb2yvVbEFcy6LqB+bh6H9HHt/u3QaOM3UXT8DYzLE9eqLDNckl9ws4kSoq+lO06GGkJ3p9WXn2fkEZh+O8mHBmfvGjEgFadcP71iJLYN3uiH8XzylLNdWNnmtDtznH2AI39oQo5C25ifszhmoBg6Bg2NGHDIOFlYrhk2ErVVUvHD2O6pPagYhUsR1CXSPgyPtPcxMg8KJZVGT3OXJX3AoOLScwospB0DDfl5FfcfnZwCwLxhu0y5fQSE03cElDjx/UWZ0nsPQ0I+rdpxQ5SQB6hayCxyi088J4UkfKeqQ==; Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1jBdLr-0002o2-Nl for bug-guile@gnu.org; Tue, 10 Mar 2020 12:47:11 +0100 Date: Tue, 10 Mar 2020 12:47:11 +0100 To: bug-guile@gnu.org Subject: Re: bug#40008: Backtraces can contain very long strings Message-ID: <20200310114711.GA10381@tuxteam.de> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) From: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 5.199.139.25 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote: > I have the following backtrace: >=20 > Backtrace: > In ice-9/boot-9.scm: > 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) > In unknown file: > 8 (apply-smob/0 #) > In ice-9/boot-9.scm: > 718:2 7 (call-with-prompt _ _ #) > In ice-9/eval.scm: > 619:8 6 (_ #(#(#))) > In ice-9/boot-9.scm: > 2806:4 5 (save-module-excursion _) > 4351:12 4 (_) > In /home/jsynacek/./git.scm: > 72:0 3 (_) > 61:16 2 (change-spec _ _ "66.33" _ #) > 48:12 1 (change-release "# We ship a .pc file but don't want t=E2=80= =A6" =E2=80=A6) > In unknown file: > 0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil=E2=80= =A6" =E2=80=A6) >=20 > ERROR: In procedure make-regexp: > Wrong type (expecting exact integer): " > > " >=20 > While this is probably not considered an error, I guess it might be better > to ellipsize strings in errors such is mine that are over a certain length > long. The important part of the backtrace was scrolled away and I got > confused about the string, as I thought it was part of the output and > started wondering why (display ...) keeps the escaped newlines in the > string. Some want it, some want it not. I remember a couple of discussions in guile-user and guile-devel about this topic. Have you tried setting debug options `width' and/or `depth' (cf. procedure `debug-options')? (my current defaults are 79 columns/20 rows, this is Guile 3.0). > If this is not considered a bug, please, at least consider it an RFE. I guess one could argue about the current defaults, but it'll be difficult to find values making all people happy all the time. Cheers -- t --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAl5nfj8ACgkQBcgs9XrR2kbW5QCeMAOZw7IjHI4ZSzT4J2/Z/19s aU8AnA2yq/0OqStuGCMQRnZh3f1mVSfe =YJZ3 -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 11 07:13:43 2020 Received: (at 40008) by debbugs.gnu.org; 11 Mar 2020 11:13:43 +0000 Received: from localhost ([127.0.0.1]:53672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBzJ0-0007ub-S6 for submit@debbugs.gnu.org; Wed, 11 Mar 2020 07:13:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBzIy-0007uM-P9 for 40008@debbugs.gnu.org; Wed, 11 Mar 2020 07:13:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jBzIt-0004um-Ch; Wed, 11 Mar 2020 07:13:35 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=37822 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jBzIr-0006ih-JG; Wed, 11 Mar 2020 07:13:34 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Subject: Re: bug#40008: Backtraces can contain very long strings References: <20200310114711.GA10381@tuxteam.de> Date: Wed, 11 Mar 2020 12:13:32 +0100 In-Reply-To: <20200310114711.GA10381@tuxteam.de> (tomas@tuxteam.de's message of "Tue, 10 Mar 2020 12:47:11 +0100") Message-ID: <875zfbm9er.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40008 Cc: 40008@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi, skribis: > On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote: >> I have the following backtrace: >>=20 >> Backtrace: >> In ice-9/boot-9.scm: >> 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) >> In unknown file: >> 8 (apply-smob/0 #) >> In ice-9/boot-9.scm: >> 718:2 7 (call-with-prompt _ _ #) >> In ice-9/eval.scm: >> 619:8 6 (_ #(#(#))) >> In ice-9/boot-9.scm: >> 2806:4 5 (save-module-excursion _) >> 4351:12 4 (_) >> In /home/jsynacek/./git.scm: >> 72:0 3 (_) >> 61:16 2 (change-spec _ _ "66.33" _ #) >> 48:12 1 (change-release "# We ship a .pc file but don't want t=E2= =80=A6" =E2=80=A6) >> In unknown file: >> 0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil=E2= =80=A6" =E2=80=A6) >>=20 >> ERROR: In procedure make-regexp: >> Wrong type (expecting exact integer): " >> >> " >>=20 >> While this is probably not considered an error, I guess it might be bett= er >> to ellipsize strings in errors such is mine that are over a certain leng= th >> long. The important part of the backtrace was scrolled away and I got >> confused about the string, as I thought it was part of the output and >> started wondering why (display ...) keeps the escaped newlines in the >> string. > > Some want it, some want it not. I remember a couple of discussions > in guile-user and guile-devel about this topic. > > Have you tried setting debug options `width' and/or `depth' (cf. procedure > `debug-options')? > > (my current defaults are 79 columns/20 rows, this is Guile 3.0). The backtrace itself is ellipsized, but the value displayed in the exception (the long string above) is not. I would rather not ellipsize anything in the exception itself. Thoughts? Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 11 08:39:21 2020 Received: (at 40008) by debbugs.gnu.org; 11 Mar 2020 12:39:21 +0000 Received: from localhost ([127.0.0.1]:53740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jC0ds-0003Ve-Rw for submit@debbugs.gnu.org; Wed, 11 Mar 2020 08:39:21 -0400 Received: from mail-vs1-f42.google.com ([209.85.217.42]:39655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jC0dq-0003VQ-K8 for 40008@debbugs.gnu.org; Wed, 11 Mar 2020 08:39:19 -0400 Received: by mail-vs1-f42.google.com with SMTP id a19so1188549vsp.6 for <40008@debbugs.gnu.org>; Wed, 11 Mar 2020 05:39:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Vp2e7ajiIwNdKi+DC9uMlAmdm2DzL6iQkdZ4XN5vt7o=; b=sST60f8RrjmnSfZuQZRNjgU5g4qrjHRIpgKOkeYtHCfK8JZcoQg/AS3V3o8YIgZ+xU q4VzEaNSt/LpVyE6Kqc1BgsfzpHeefs+PTyVhgtnSUsnvu7qpfcsBgv/cU/MYakbooug oNz4jJiDx/3nlxPMwopqLjZlqHF/6KDAlsYSoVP1s1LeYO/P/hQnZAVhfwRAYpYcjUKW Hwti+QBtef/DIJx8C9xRZr50okhDJoYVigFgO7HNFsVUmTVXsJNTZiSXZaYgvByFNRum I5GqlfoIMQ0cQBaq1mpXwwGEZndwgLt5wmvlcF8elkMXJAFv3w1hVHlcm16bE6mJhjCc s1Xw== X-Gm-Message-State: ANhLgQ1NHsICZ+CJ0SFSWK3YB7qUr4qjkbDQItklkz3TisYiwZXV1xOs AuW3Cv427pG4YfVAsb3Rx21mQ9DpoXTN73WQxvQ= X-Google-Smtp-Source: ADFU+vs9DdgRWShGBwJfYmVOTGgvd4Pf2eG4Cyjbpv/5XZWPRuqrEtwpL2xvQqFxqKHbdGGSDtrJoBvgM+yZKz1XiA8= X-Received: by 2002:a67:c50d:: with SMTP id e13mr1865145vsk.118.1583930353038; Wed, 11 Mar 2020 05:39:13 -0700 (PDT) MIME-Version: 1.0 References: <20200310114711.GA10381@tuxteam.de> <875zfbm9er.fsf@gnu.org> In-Reply-To: <875zfbm9er.fsf@gnu.org> From: Mikael Djurfeldt Date: Wed, 11 Mar 2020 13:39:01 +0100 Message-ID: Subject: Re: bug#40008: Backtraces can contain very long strings To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: multipart/alternative; boundary="0000000000000ab82505a09386e7" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 40008 Cc: 40008@debbugs.gnu.org, Mikael Djurfeldt , tomas@tuxteam.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mikael@djurfeldt.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --0000000000000ab82505a09386e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 11, 2020 at 12:14 PM Ludovic Court=C3=A8s wrote: > Hi, > > skribis: > > > On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote: > >> I have the following backtrace: > >> > >> Backtrace: > >> In ice-9/boot-9.scm: > >> 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) > >> In unknown file: > >> 8 (apply-smob/0 #) > >> In ice-9/boot-9.scm: > >> 718:2 7 (call-with-prompt _ _ #) > >> In ice-9/eval.scm: > >> 619:8 6 (_ #(#(#))) > >> In ice-9/boot-9.scm: > >> 2806:4 5 (save-module-excursion _) > >> 4351:12 4 (_) > >> In /home/jsynacek/./git.scm: > >> 72:0 3 (_) > >> 61:16 2 (change-spec _ _ "66.33" _ #) > >> 48:12 1 (change-release "# We ship a .pc file but don't want t=E2= =80=A6" =E2=80=A6) > >> In unknown file: > >> 0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil=E2= =80=A6" =E2=80=A6) > >> > >> ERROR: In procedure make-regexp: > >> Wrong type (expecting exact integer): " > >> > >> " > >> > >> While this is probably not considered an error, I guess it might be > better > >> to ellipsize strings in errors such is mine that are over a certain > length > >> long. The important part of the backtrace was scrolled away and I got > >> confused about the string, as I thought it was part of the output and > >> started wondering why (display ...) keeps the escaped newlines in the > >> string. > > > > Some want it, some want it not. I remember a couple of discussions > > in guile-user and guile-devel about this topic. > > > > Have you tried setting debug options `width' and/or `depth' (cf. > procedure > > `debug-options')? > > > > (my current defaults are 79 columns/20 rows, this is Guile 3.0). > > The backtrace itself is ellipsized, but the value displayed in the > exception (the long string above) is not. > > I would rather not ellipsize anything in the exception itself. > > Thoughts? > It would be nice if this was configurable. As Tomas pointed out this kind of thing can be a matter of taste. Also, if debugging some specific problem involving large strings it might be convenient to switch on for anyone. There could be a debug-option (see (debug-options '?)) `exception-width' (similar to `width' but for errors and exceptions). But how is the debug-options interface regarded nowadays? Is it going to be deprecated? I notice that the `width' option doesn't seem to have an effect anymore. Looking into backtrace.c and (system repl debug) the width nowadays rather seems to be controlled by the terminal width only. Best regards, Mikael --0000000000000ab82505a09386e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 11, 2020 at 12:14 PM Ludovic = Court=C3=A8s <ludo@gnu.org> wrote= :
Hi,

<tomas@tuxteam.de<= /a>> skribis:

> On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
>> I have the following backtrace:
>>
>> Backtrace:
>> In ice-9/boot-9.scm:
>>=C2=A0 =C2=A01736:10=C2=A0 9 (with-exception-handler _ _ #:unwind? = _ # _)
>> In unknown file:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8 (apply-smob/0 #<thun= k 651b40>)
>> In ice-9/boot-9.scm:
>>=C2=A0 =C2=A0 =C2=A0718:2=C2=A0 7 (call-with-prompt _ _ #<proced= ure default-prompt-handle=E2=80=A6>)
>> In ice-9/eval.scm:
>>=C2=A0 =C2=A0 =C2=A0619:8=C2=A0 6 (_ #(#(#<directory (guile-user= ) 74cf00>)))
>> In ice-9/boot-9.scm:
>>=C2=A0 =C2=A0 2806:4=C2=A0 5 (save-module-excursion _)
>>=C2=A0 =C2=A04351:12=C2=A0 4 (_)
>> In /home/jsynacek/./git.scm:
>>=C2=A0 =C2=A0 =C2=A0 72:0=C2=A0 3 (_)
>>=C2=A0 =C2=A0 =C2=A061:16=C2=A0 2 (change-spec _ _ "66.33"= ; _ #<output: file 1>)
>>=C2=A0 =C2=A0 =C2=A048:12=C2=A0 1 (change-release "# We ship a= .pc file but don't want t=E2=80=A6" =E2=80=A6)
>> In unknown file:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 (make-regexp "^Rel= ease:(\\s*).*$" "# We ship a .pc fil=E2=80=A6" =E2=80=A6) >>
>> ERROR: In procedure make-regexp:
>> Wrong type (expecting exact integer): "
>> <HERE COMES A LOOOONG STRING WHICH IS ABOUT 193000 CHARACTERS W= IDE>
>> "
>>
>> While this is probably not considered an error, I guess it might b= e better
>> to ellipsize strings in errors such is mine that are over a certai= n length
>> long. The important part of the backtrace was scrolled away and I = got
>> confused about the string, as I thought it was part of the output = and
>> started wondering why (display ...) keeps the escaped newlines in = the
>> string.
>
> Some want it, some want it not. I remember a couple of discussions
> in guile-user and guile-devel about this topic.
>
> Have you tried setting debug options `width' and/or `depth' (c= f. procedure
> `debug-options')?
>
> (my current defaults are 79 columns/20 rows, this is Guile 3.0).

The backtrace itself is ellipsized, but the value displayed in the
exception (the long string above) is not.

I would rather not ellipsize anything in the exception itself.

Thoughts?



=
But how is the debug-options interface regarded nowadays? Is it going = to be deprecated? I notice that the `width' option doesn't seem to = have an effect anymore. Looking into backtrace.c and (system repl debug) th= e width nowadays rather seems to be controlled by the terminal width only.<= /div>

Best regards,
Mikael
--0000000000000ab82505a09386e7--