* bug#16357: insufficient print abbreviation in error messages [not found] <20140105230032.GB30283@fysh.org> @ 2016-06-21 12:17 ` Andy Wingo 2016-06-21 12:38 ` Zefram 2016-06-23 16:57 ` Mark H Weaver 0 siblings, 2 replies; 6+ messages in thread From: Andy Wingo @ 2016-06-21 12:17 UTC (permalink / raw) To: guile-devel; +Cc: Zefram, 16357 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#16357: insufficient print abbreviation in error messages 2016-06-21 12:17 ` bug#16357: insufficient print abbreviation in error messages Andy Wingo @ 2016-06-21 12:38 ` Zefram 2016-06-21 15:10 ` Andy Wingo 2016-06-23 16:57 ` Mark H Weaver 1 sibling, 1 reply; 6+ messages in thread From: Zefram @ 2016-06-21 12:38 UTC (permalink / raw) To: guile-devel, 16357 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug#16357: insufficient print abbreviation in error messages 2016-06-21 12:38 ` Zefram @ 2016-06-21 15:10 ` Andy Wingo 0 siblings, 0 replies; 6+ messages in thread From: Andy Wingo @ 2016-06-21 15:10 UTC (permalink / raw) To: Zefram; +Cc: 16357, guile-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug#16357: insufficient print abbreviation in error messages 2016-06-21 12:17 ` bug#16357: insufficient print abbreviation in error messages Andy Wingo 2016-06-21 12:38 ` Zefram @ 2016-06-23 16:57 ` Mark H Weaver 2016-06-23 17:59 ` Andy Wingo 1 sibling, 1 reply; 6+ messages in thread From: Mark H Weaver @ 2016-06-23 16:57 UTC (permalink / raw) To: Andy Wingo; +Cc: Zefram, 16357, guile-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#16357: insufficient print abbreviation in error messages 2016-06-23 16:57 ` Mark H Weaver @ 2016-06-23 17:59 ` Andy Wingo 2016-06-26 1:05 ` Mark H Weaver 0 siblings, 1 reply; 6+ messages in thread From: Andy Wingo @ 2016-06-23 17:59 UTC (permalink / raw) To: Mark H Weaver; +Cc: Zefram, 16357, guile-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#16357: insufficient print abbreviation in error messages 2016-06-23 17:59 ` Andy Wingo @ 2016-06-26 1:05 ` Mark H Weaver 0 siblings, 0 replies; 6+ messages in thread From: Mark H Weaver @ 2016-06-26 1:05 UTC (permalink / raw) To: Andy Wingo; +Cc: Zefram, 16357, guile-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-06-26 1:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20140105230032.GB30283@fysh.org> 2016-06-21 12:17 ` bug#16357: insufficient print abbreviation in error messages Andy Wingo 2016-06-21 12:38 ` Zefram 2016-06-21 15:10 ` Andy Wingo 2016-06-23 16:57 ` Mark H Weaver 2016-06-23 17:59 ` Andy Wingo 2016-06-26 1:05 ` Mark H Weaver
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).