bug#16357: insufficient print abbreviation in error messages

bug#16357: insufficient print abbreviation in error messages

[Andy Wingo]

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@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

bug#16357: insufficient print abbreviation in error messages

[Zefram]

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

Re: bug#16357: insufficient print abbreviation in error messages

[Andy Wingo]

On Tue 21 Jun 2016 14:38, Zefram <zefram@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

Re: bug#16357: insufficient print abbreviation in error messages

[Mark H Weaver]

Andy Wingo <wingo@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

bug#16357: insufficient print abbreviation in error messages

[Andy Wingo]

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

> Andy Wingo <wingo@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

bug#16357: insufficient print abbreviation in error messages

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:

> On Thu 23 Jun 2016 18:57, Mark H Weaver <mhw@netris.org> writes:
>
>> Andy Wingo <wingo@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