GNU bug report logs - #16357
insufficient print abbreviation in error messages

Previous Next

To reply to this bug, email your comments to 16357 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: bug-guile <at> gnu.org
Subject: insufficient print abbreviation in error messages
Date: Sun, 5 Jan 2014 23:00:32 +0000

When guile is constructing error messages that display offending objects,
in version 2.0.9 it never abbreviates long or deep structures.  This can
easily lead to pathologically-long messages that take stupid amounts of
time and memory to construct and to display.  By contrast, guile-1.8
applies abbreviation at a reasonable level, and objects appearing in
stack traces have reasonable abbreviation on both versions.  Two very
mild examples:

$ guile-1.8 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons n v)))))"
Backtrace:
In current input:
   1: 0* [read {(1 2 3 4 5 6 7 8 9 ...)}]

<unnamed port>:1:1: In procedure read in expression (read (# 100 #)):
<unnamed port>:1:1: Wrong type argument in position 1 (expecting open input port): (1 2 3 4 5 6 7 8 9 10 ...)
$ guile-2.0 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons n v)))))"
Backtrace:
In ice-9/boot-9.scm:
 157: 7 [catch #t #<catch-closure d68400> ...]
In unknown file:
   ?: 6 [apply-smob/1 #<catch-closure d68400>]
In ice-9/boot-9.scm:
  63: 5 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 4 [eval # #]
In unknown file:
   ?: 3 [call-with-input-string "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons n v)))))" ...]
In ice-9/command-line.scm:
 180: 2 [#<procedure c83ac0 at ice-9/command-line.scm:175:6 (port)> #<input: string b495b0>]
In unknown file:
   ?: 1 [eval (read (let aaa (# #) (if # v #))) #<directory (guile-user) d5cc60>]
   ?: 0 [read (1 2 3 4 5 6 7 8 9 ...)]

ERROR: In procedure read:
ERROR: In procedure read: Wrong type argument in position 1 (expecting open input port): (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100)
$ guile-1.8 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v n)))))"
Backtrace:
In current input:
   1: 0* [read {(((# . 3) . 2) . 1)}]

<unnamed port>:1:1: In procedure read in expression (read (# 100 #)):
<unnamed port>:1:1: Wrong type argument in position 1 (expecting open input port): (((((((# . 7) . 6) . 5) . 4) . 3) . 2) . 1)
$ guile-2.0 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v n)))))"
Backtrace:
In ice-9/boot-9.scm:
 157: 7 [catch #t #<catch-closure 1c71400> ...]
In unknown file:
   ?: 6 [apply-smob/1 #<catch-closure 1c71400>]
In ice-9/boot-9.scm:
  63: 5 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 4 [eval # #]
In unknown file:
   ?: 3 [call-with-input-string "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v n)))))" ...]
In ice-9/command-line.scm:
 180: 2 [#<procedure 1c89da0 at ice-9/command-line.scm:175:6 (port)> #<input: string 1a505b0>]
In unknown file:
   ?: 1 [eval (read (let aaa (# #) (if # v #))) #<directory (guile-user) 1c65c60>]
   ?: 0 [read (((# . 3) . 2) . 1)]

ERROR: In procedure read:
ERROR: In procedure read: Wrong type argument in position 1 (expecting open input port): ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((() . 100) . 99) . 98) . 97) . 96) . 95) . 94) . 93) . 92) . 91) . 90) . 89) . 88) . 87) . 86) . 85) . 84) . 83) . 82) . 81) . 80) . 79) . 78) . 77) . 76) . 75) . 74) . 73) . 72) . 71) . 70) . 69) . 68) . 67) . 66) . 65) . 64) . 63) . 62) . 61) . 60) . 59) . 58) . 57) . 56) . 55) . 54) . 53) . 52) . 51) . 50) . 49) . 48) . 47) . 46) . 45) . 44) . 43) . 42) . 41) . 40) . 39) . 38) . 37) . 36) . 35) . 34) . 33) . 32) . 31) . 30) . 29) . 28) . 27) . 26) . 25) . 24) . 23) . 22) . 21) . 20) . 19) . 18) . 17) . 16) . 15) . 14) . 13) . 12) . 11) . 10) . 9) . 8) . 7) . 6) . 5) . 4) . 3) . 2) . 1)

Debian incarnation of this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734128

-zefram

Message #8 received at 16357 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: guile-devel <at> gnu.org
Cc: Zefram <zefram <at> fysh.org>, 16357 <at> debbugs.gnu.org
Subject: Re: bug#16357: insufficient print abbreviation in error messages
Date: Tue, 21 Jun 2016 14:17:30 +0200

Not really sure what to do here.

Ideally we could just use ~@y in the format messages.  However we can't
rely on having a full format loaded up, only simple-format.  We could
lazily load the full format when needed, but I don't know if we should
train users that the full `format' is always around.

We could define well-known parameters for specifying that we should
truncate the output of a `write' procedure, and have pair / vector /
bytevectors use that parameter when needed.  Perhaps that's the thing?

Or, we could use print states.  But print states are not so great and
ideally we would remove them eventually.

Thoughts?

Andy

On Mon 06 Jan 2014 00:00, Zefram <zefram <at> fysh.org> writes:

> When guile is constructing error messages that display offending objects,
> in version 2.0.9 it never abbreviates long or deep structures.  This can
> easily lead to pathologically-long messages that take stupid amounts of
> time and memory to construct and to display.  By contrast, guile-1.8
> applies abbreviation at a reasonable level, and objects appearing in
> stack traces have reasonable abbreviation on both versions.  Two very
> mild examples:
>
> $ guile-1.8 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons n v)))))"
> Backtrace:
> In current input:
>    1: 0* [read {(1 2 3 4 5 6 7 8 9 ...)}]
>
> <unnamed port>:1:1: In procedure read in expression (read (# 100 #)):
> <unnamed port>:1:1: Wrong type argument in position 1 (expecting open input port): (1 2 3 4 5 6 7 8 9 10 ...)
> $ guile-2.0 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons n v)))))"
> Backtrace:
> In ice-9/boot-9.scm:
>  157: 7 [catch #t #<catch-closure d68400> ...]
> In unknown file:
>    ?: 6 [apply-smob/1 #<catch-closure d68400>]
> In ice-9/boot-9.scm:
>   63: 5 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
>  432: 4 [eval # #]
> In unknown file:
>    ?: 3 [call-with-input-string "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons n v)))))" ...]
> In ice-9/command-line.scm:
>  180: 2 [#<procedure c83ac0 at ice-9/command-line.scm:175:6 (port)> #<input: string b495b0>]
> In unknown file:
>    ?: 1 [eval (read (let aaa (# #) (if # v #))) #<directory (guile-user) d5cc60>]
>    ?: 0 [read (1 2 3 4 5 6 7 8 9 ...)]
>
> ERROR: In procedure read:
> ERROR: In procedure read: Wrong type argument in position 1 (expecting open input port): (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100)
> $ guile-1.8 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v n)))))"
> Backtrace:
> In current input:
>    1: 0* [read {(((# . 3) . 2) . 1)}]
>
> <unnamed port>:1:1: In procedure read in expression (read (# 100 #)):
> <unnamed port>:1:1: Wrong type argument in position 1 (expecting open input port): (((((((# . 7) . 6) . 5) . 4) . 3) . 2) . 1)
> $ guile-2.0 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v n)))))"
> Backtrace:
> In ice-9/boot-9.scm:
>  157: 7 [catch #t #<catch-closure 1c71400> ...]
> In unknown file:
>    ?: 6 [apply-smob/1 #<catch-closure 1c71400>]
> In ice-9/boot-9.scm:
>   63: 5 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
>  432: 4 [eval # #]
> In unknown file:
>    ?: 3 [call-with-input-string "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v n)))))" ...]
> In ice-9/command-line.scm:
>  180: 2 [#<procedure 1c89da0 at ice-9/command-line.scm:175:6 (port)> #<input: string 1a505b0>]
> In unknown file:
>    ?: 1 [eval (read (let aaa (# #) (if # v #))) #<directory (guile-user) 1c65c60>]
>    ?: 0 [read (((# . 3) . 2) . 1)]
>
> ERROR: In procedure read:
> ERROR: In procedure read: Wrong type argument in position 1 (expecting open input port): ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((() . 100) . 99) . 98) . 97) . 96) . 95) . 94) . 93) . 92) . 91) . 90) . 89) . 88) . 87) . 86) . 85) . 84) . 83) . 82) . 81) . 80) . 79) . 78) . 77) . 76) . 75) . 74) . 73) . 72) . 71) . 70) . 69) . 68) . 67) . 66) . 65) . 64) . 63) . 62) . 61) . 60) . 59) . 58) . 57) . 56) . 55) . 54) . 53) . 52) . 51) . 50) . 49) . 48) . 47) . 46) . 45) . 44) . 43) . 42) . 41) . 40) . 39) . 38) . 37) . 36) . 35) . 34) . 33) . 32) . 31) . 30) . 29) . 28) . 27) . 26) . 25) . 24) . 23) . 22) . 21) . 20) . 19) . 18) . 17) . 16) . 15) . 14) . 13) . 12) . 11) . 10) . 9) . 8) . 7) . 6) . 5) . 4) . 3) . 2) . 1)
>
> Debian incarnation of this bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734128
>
> -zefram

Message #11 received at 16357 <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: guile-devel <at> gnu.org, 16357 <at> debbugs.gnu.org
Subject: Re: bug#16357: insufficient print abbreviation in error messages
Date: Tue, 21 Jun 2016 13:38:40 +0100

Andy Wingo wrote:
>Thoughts?

How was this managed in Guile 1.8?

It seems that you need the truncated-print mechanism to be always
available internally, but this doesn't require that it be always visible
to the user.  You can still require the full libraries to be loaded for
the user to get access.

Lazy loading sounds like a bad idea.  Error handling is a bad place to
attempt something that complex and failure-prone.

-zefram

Message #14 received at 16357 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Zefram <zefram <at> fysh.org>
Cc: 16357 <at> debbugs.gnu.org, guile-devel <at> gnu.org
Subject: Re: bug#16357: insufficient print abbreviation in error messages
Date: Tue, 21 Jun 2016 17:10:13 +0200

On Tue 21 Jun 2016 14:38, Zefram <zefram <at> fysh.org> writes:

> Andy Wingo wrote:
>>Thoughts?
>
> How was this managed in Guile 1.8?

The printers and the backtrace handling was quite different, but it used
"print states".

> It seems that you need the truncated-print mechanism to be always
> available internally, but this doesn't require that it be always visible
> to the user.  You can still require the full libraries to be loaded for
> the user to get access.
>
> Lazy loading sounds like a bad idea.  Error handling is a bad place to
> attempt something that complex and failure-prone.

That's what we do for backtrace printing in 2.2, for what it's worth.
It's a tradeoff between memory size, good errors, maintainability,
startup time, safety, duplication... the global optimimum corresponds to
no per-axis optimimum :/

Andy

Message #17 received at 16357 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: Zefram <zefram <at> fysh.org>, 16357 <at> debbugs.gnu.org, guile-devel <at> gnu.org
Subject: Re: bug#16357: insufficient print abbreviation in error messages
Date: Thu, 23 Jun 2016 12:57:17 -0400

Andy Wingo <wingo <at> pobox.com> writes:
> Or, we could use print states.  But print states are not so great and
> ideally we would remove them eventually.

We will need print states, or something like them, to support writing
cyclic data structures as required by R7RS.

     Mark

Message #20 received at 16357 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Zefram <zefram <at> fysh.org>, 16357 <at> debbugs.gnu.org, guile-devel <at> gnu.org
Subject: Re: bug#16357: insufficient print abbreviation in error messages
Date: Thu, 23 Jun 2016 19:59:10 +0200

On Thu 23 Jun 2016 18:57, Mark H Weaver <mhw <at> netris.org> writes:

> Andy Wingo <wingo <at> pobox.com> writes:
>> Or, we could use print states.  But print states are not so great and
>> ideally we would remove them eventually.
>
> We will need print states, or something like them, to support writing
> cyclic data structures as required by R7RS.

I was thinking parameters would be sufficient.  Dunno.  WDYT about that?

Andy

Message #23 received at 16357 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: Zefram <zefram <at> fysh.org>, 16357 <at> debbugs.gnu.org, guile-devel <at> gnu.org
Subject: Re: bug#16357: insufficient print abbreviation in error messages
Date: Sat, 25 Jun 2016 21:05:36 -0400

Andy Wingo <wingo <at> pobox.com> writes:

> On Thu 23 Jun 2016 18:57, Mark H Weaver <mhw <at> netris.org> writes:
>
>> Andy Wingo <wingo <at> pobox.com> writes:
>>> Or, we could use print states.  But print states are not so great and
>>> ideally we would remove them eventually.
>>
>> We will need print states, or something like them, to support writing
>> cyclic data structures as required by R7RS.
>
> I was thinking parameters would be sufficient.  Dunno.  WDYT about that?

Parameters would propagate to places where we don't want them to
propagate.  For example, if in the course of running a custom printer,
some internal procedure prints something to a different port, e.g. to a
string port, then the parameter would still take effect.

      Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.