unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: David Pirotte <david@altosw.be>
To: Mark H Weaver <mhw@netris.org>
Cc: 36677@debbugs.gnu.org, Robert Vollmert <rob@vllmrt.net>
Subject: bug#36677: [PATCH] Don't truncate backtraces
Date: Thu, 25 Jul 2019 13:27:57 -0300	[thread overview]
Message-ID: <20190725132757.60e2e1cb@capac> (raw)
In-Reply-To: <87lfwq52lv.fsf@netris.org>

[-- Attachment #1: Type: text/plain, Size: 5134 bytes --]

Hi Mark,

> You can see now that there are pressures coming from both directions
> on this issue. 

I always 'did see' that, my point is that enabling truncated printing
should be the default, and that we should be able to 'toggle' that to
full printing anytime ... for the repl, errors, and backtraces, The
'toggle' should be made so easy that we could bind it to, say, F8 or
another key, then hit it when needed ... not matter how easy is the
'toggle' mechanism though, the default should be, imo, to enable
truncated printing for he repl, errors, and backtraces.

Fwiw, I recently helped two quite advanced guilers, on #guile, one did
ask if he could 'truncate' and how, I pointed to the guile-cv
documentation, the other said: "I wish I new this was possible ...".

Currently, wrt to errors, it is very difficult, next to impossible, to
configure guile to enable truncated printing, and the above user, an
advanced guiler, answered, when I also pointed to a complete 'recipe',
in the guile-cv doc, '... thanks but I 'm gona get there ...' (or
something along the lines, I don't remember the exact words - it was
very clear though, that he was afraid to 'just' apply the recipe).

It seems, from Robert's email, that it is currently quite difficult, if
not impossible, to toggle bactraces to full printing.

> (1) Historically, the Guile has never truncated REPL output, and I'm
> concerned that changing the default behavior may violate longstanding
> user expectations.

'Historically' stands, imo, as an explanation, not as a justification
for a 'no change' ... we did change, and it did break user code, from
1.8 to 2.0 ... I don't think this change will break anything, but even
though, 2.2 -> 3.0 is 'an opportunity', should we agree of course ... 

>  I, for one, often ask for a moderately large data structure to be
> computed and printed at the REPL, and I normally want to see the
> whole thing.

You are an expert, you know it is possible, you know how ...

The persons I am 'targeting' to become guile-cv users are newbies,
although highly educated in their domain, they don't know what scheme
is, they don't even know the word 'Lisp', they don't understand I
have to configure Guile so they can use it ... and tell me, for the
very few I could 'sit next to' and configure for them, that they would
never ever do that themselves ... not even the 'simple' (simple for us),
repl config ...

Then as exposed above, even advanced guilers don't know, and when
informed 'how to', don't want to 'risk' lots of 'small changes' in
(ice-9 boot), which is understandable, I'm not 'jugging' ...

> (2) Some software may act as a front-end for the Guile REPL, sending
> commands to it and interpreting the output.  For example, I believe
> that Geiser does this.  I'm concerned that changing the default
> truncation behavior may cause problems here.

I use geiser, and never ever had a problem - but if I would I would
have talked to Jao, who's extremely responsive ... and he would have
solved the problem, but I never had a single problem: geiser only
interprets certain pattern, like guile-cv's output, to display images
in emacs ... so truncated print is not a problem at all for geier,
afaict at least.

> (3) I'm not confident that 'truncated-print' is fully robust for
> arbitrary data types.  I would need to make a careful audit of the
> code.

Again, imo, it explains, but does not stand as a justification for a
'no change': we could reuse the backtrace 'trunker', or make
truncaped-print robust, I never had a single truncated-print related
problem in years though, not a proof, but quite a good 'start' ...

> (4) The Guile REPL already provides a way to specify a custom printer,
> so there's nothing stopping you from installing 'truncated-print' as
> the REPL printer.

Imo, no matter how easy it is to change, the default should be to
enable truncated printing for the repl, erros and backtraces, then
indeed we should have 'dead easy' 'toggle' mechanism for those
'extremely rare' guilers who want (occasionally in my experience, I
sometimes do to of course) full print ...

> To be honest, the main reason I find lack of truncation painful
> sometimes is because Emacs does not cope well with extremely long
> lines, to put it mildly.  Honestly, that's a flaw in Emacs, and it
> seems like it would be better to fix Emacs than to work around it in
> Guile by omitting potentially useful information from error reports
> by default.

I strongly disagree with you: it is a guile and not an emacs problem.
But it also is impossible to work in a terminal, just try guile-cv,
it won't last minutes that you get totally crasy :) so to speak of
course, and wish truncated printing would be enable for the repl, erros
and backtraces, by default.

I should also add that typical image sizes that 'we' need to process
using gule-cv (or open-cv, imagej ...) are not small, made in average
of 20 millions+ pixels ... but you may try guile-cv even using small
images, in a terminal, it's not workable 'as is ...'

David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2019-07-25 16:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-15 20:29 bug#36677: [PATCH] Don't truncate backtraces Robert Vollmert
2019-07-17 17:57 ` Mark H Weaver
2019-07-17 18:11   ` Robert Vollmert
2019-07-21 15:35     ` Robert Vollmert
2019-07-21 22:59   ` David Pirotte
2019-07-22  0:33     ` Mark H Weaver
2019-07-25 16:27       ` David Pirotte [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190725132757.60e2e1cb@capac \
    --to=david@altosw.be \
    --cc=36677@debbugs.gnu.org \
    --cc=mhw@netris.org \
    --cc=rob@vllmrt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).