From: Mark H Weaver <mhw@netris.org>
To: ludo@gnu.org (Ludovic Courtès)
Cc: Andy Wingo <wingo@pobox.com>, guile-devel@gnu.org
Subject: Re: Discussion for %display-auto-compilation-messages (and --no-auto-compilation-messages option)
Date: Tue, 25 Mar 2014 23:19:02 -0400 [thread overview]
Message-ID: <871txpk5p5.fsf@yeeloong.lan> (raw)
In-Reply-To: <8761n1k7s7.fsf@yeeloong.lan> (Mark H. Weaver's message of "Tue, 25 Mar 2014 22:34:00 -0400")
Mark H Weaver <mhw@netris.org> writes:
> For example, I recently discovered that REPL Servers weren't redirecting
> the warning port to the socket, so warnings about expressions typed on a
> REPL server were being sent to the main program's stderr. I fixed this
> in 5e74217c7cf07ad474cdce1a01e049492e7ef1b7, but if we add another port
> parameter I'll have to fix that in at least two places now: server.scm
> and coop-server.scm.
>
> I wonder if external code needs to sometimes do this as well. How will
> they cope with a periodically-expanding set of port parameters, while
> retaining compatible with older versions of guile that lack some of
> them? Should we add a 'parameterize-all-stdout-like-ports' macro?
It occurs to me that one possibility would be to allow some of these
parameters to effectively mirror the value of some other parameter.
For example, the 'current-notification-port' parameter could mirror the
'current-warning-port' parameter by default, which could in turn mirror
the 'current-error-port' parameter by default.
One way to implement this would be to make the corresponding fluid be a
thunk that returns a port, instead of the port itself. The converter
could accept either a port or a parameter, and convert each of these to
a suitable thunk. Finally, we'd make custom 'current-warning-port' and
'current-error-port' procedures that would handling calling the thunk.
Of course, this extra complexity would make these parameters inherently
more expensive, so it would only be appropriate for these special
seldom-used port parameters. However, for these cases it might be a
worthwhile extension. In one commit we could fix a number of possible
bugs (similar to the one fixed by 5e74217) that might well exist in
external code.
What do you think?
Mark
next prev parent reply other threads:[~2014-03-26 3:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-01 22:08 Discussion for %display-auto-compilation-messages (and --no-auto-compilation-messages option) Sjoerd van Leent
2014-03-02 21:13 ` Ludovic Courtès
2014-03-03 15:17 ` Sjoerd van Leent
2014-03-25 20:58 ` Andy Wingo
2014-03-25 21:20 ` Ludovic Courtès
2014-03-26 2:34 ` Mark H Weaver
2014-03-26 3:19 ` Mark H Weaver [this message]
2014-03-26 8:18 ` Andy Wingo
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=871txpk5p5.fsf@yeeloong.lan \
--to=mhw@netris.org \
--cc=guile-devel@gnu.org \
--cc=ludo@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).