unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Daniel Llorens <daniel.llorens@bluewin.ch>
To: David Pirotte <david@altosw.be>
Cc: Andy Wingo <wingo@pobox.com>, guile-user@gnu.org, guile-devel@gnu.org
Subject: Re: GNU Guile 2.1.7 released (beta)
Date: Tue, 28 Feb 2017 02:49:51 +0100	[thread overview]
Message-ID: <F7A3D39F-1D0F-453F-95C4-0F366A274B1B@bluewin.ch> (raw)
In-Reply-To: <20170227210444.681b8e02@capac>


On 28 Feb 2017, at 01:04, David Pirotte <david@altosw.be> wrote:

> Hi Andy,
> 
>> So!  Release blockers.
>> ...
> 
> Not a blocker, at all, but I was thinking to this, wrt manipulating (very) large
> vectors, arrays, lists ...
> 
> -]	repl - truncated-print
> 
> Right now I edit the installed (system repl common), and wrote a tip in Guile-CV's
> manual so users can do that as well:  less then optimal :).  It would be nice to
> provide an option, so users could set it 'just like that', in the repl, or as a
> global config in their .guile (I did see lloda does that in his for arrays, but it's
> not an obvious option to set, it is a 'sophisticated' little piece of code (for an
> end-user at least)).

I think this is the minimum for .guile:

(import (system repl common) (ice-9 format))
(repl-default-option-set! 'print (lambda (repl val) (format #t "~200@y" val)))

That doesn't seem so bad. For the current repl you can do:

(repl-option-set! (car (fluid-ref *repl-stack*)) 'print (lambda (repl val) (format #t "~200@y" val)))

We could have shortcuts, something like:

; not in current Guile
(repl-default-print-truncate! 200)
(repl-print-truncate! (current-repl) 200)

What do you think?

I'm guilty of finding these things by googling mailing lists and browsing the Guile source... repl-default-option-set! is documented, but repl-option-set!/ref isn't. There seems to be a chunk of text missing here:

https://www.gnu.org/software/guile/manual/html_node/System-Commands.html

There's one thing that I realized recently, that something like #1:5(a b c d e) or #@0:5(a b c d e) is actually valid read syntax, although #:5(a b c d e) is invalid, not sure if it should be. (Of course the truncated-print output doesn't *have* to be readable.) So it may be a good idea to print truncated arrays/vectors/etc that way, maybe even by default.

> -]	error(s) while manipulating (very) large vectors or arrays
> 
> Unlike the above, it appears there is currently no way to have error (the procedure)
> and raised exceptions in general, to use truncated-print, it would be cool to 'link'
> the above option so error reports use it as well.

Agreed, this is a serious issue for me. Unfortunately the current API lets the error reporter decide how to print the arguments using a format string (cf scm_error) so you have to work around that.

The hack I posted recently to guile-devel was buggy, so I'll repeat it here without the bug. It needs this patch:

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=6118d9dd0cc7733ca71c6b803a942a15f463663a

and this code in .guile:

; Truncate output on exceptions. Requires exception-format to be used in ice-9/boot.scm.
; FIXME doesn't handle e.g. "x~~~s" -> "x~~~@y"
(define (rewrite-fmt fmt)
  (let loop ((f "") (b 0))
    (let ((next (string-contains-ci fmt "~s" b)))
      (if next
        (loop
         (if (or (zero? next) (not (char=? #\~ (string-ref fmt (- next 1)))))
           (string-append f (substring fmt b next) "~200@y")
           f)
         (+ next 2))
        (string-append f (substring fmt b))))))

(define (truncate-format port fmt . args)
  (apply format port (rewrite-fmt fmt) args))
(set! exception-format truncate-format)

This can't work in general, since the call to scm_error may decide to use ~a instead of ~s, etc. I'd limit further what can go into that format string.

But I would welcome a proper solution.

Regards

	—lloda




  reply	other threads:[~2017-02-28  1:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-18 10:31 GNU Guile 2.1.7 released (beta) Andy Wingo
2017-02-23 18:54 ` Andy Wingo
2017-02-23 20:04   ` Mike Gran
2017-02-23 21:06     ` Andy Wingo
2017-03-01 13:01       ` Thien-Thi Nguyen
2017-03-01 17:36         ` Andy Wingo
2017-03-02  5:50           ` Thien-Thi Nguyen
2017-02-24  0:52     ` Break-when [was GNU Guile 2.1.7 released (beta)] Matt Wette
2017-02-24 14:02   ` GNU Guile 2.1.7 released (beta) Andy Wingo
2017-02-24 17:46   ` Arne Babenhauserheide
2017-02-26 17:57     ` Andy Wingo
2017-02-27 19:32       ` Mike Gran
2017-02-27 20:30         ` Andy Wingo
2017-02-27 23:00       ` Thomas Morley
2017-02-28  8:31         ` Andy Wingo
2017-02-28  9:38           ` David Kastrup
2017-02-28 14:03             ` Andy Wingo
2017-03-05 16:54           ` Thomas Morley
2017-03-01 18:04       ` Arne Babenhauserheide
2017-02-28  0:04   ` David Pirotte
2017-02-28  1:49     ` Daniel Llorens [this message]
2017-03-02 20:54       ` David Pirotte

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=F7A3D39F-1D0F-453F-95C4-0F366A274B1B@bluewin.ch \
    --to=daniel.llorens@bluewin.ch \
    --cc=david@altosw.be \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=wingo@pobox.com \
    /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).