guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: add command line option to quiet compiler messages


From: Andy Wingo
Subject: Re: add command line option to quiet compiler messages
Date: Sat, 23 Jul 2016 12:29:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hi :)

On Wed 20 Jul 2016 08:41, Tobin Harding <address@hidden> writes:

> On Thu, Jul 14, 2016 at 12:01:10PM +0200, Andy Wingo wrote:
>> On Wed 13 Jul 2016 06:08, Tobin Harding <address@hidden> writes:
>> 
>> > While working on this I discovered that compile messages are output from 
>> > two
>> > separate places (load.c and boot-9.scm). Each file contains identical 
>> > strings
>> > for the messages. This goes against the rule of SPOT.
>> 
>> Sadly it has to be like this for now.  I do not have suggestions to fix
>> it; it's gnarly.
>
> Ok, Will forget about this. I would love to know why though, solely out of 
> interest.

Guile needs the ability to detect when files are out of date very early
in C, before any other Scheme file is loaded (compiled or not).  We need
to do it from Scheme too, as you see in this code.  The natural thing
would be to define primitives to emit the warnings in C and export them
to Scheme (or vice versa) but that means that the primitive would then
be in the default environment for everyone -- and we really don't want
to add things to the default environment at this point, it creates
maintenance hazards.  So copying strings is the lesser evil in a way.

>> Please resend without tabs, please.  Thanks :)
>
> I'm not sure about this one. I manually put spaces in front of each line as
> directed but it does not show up as a change in 'git diff'. Is the rest of the
> patch correct in regards to Guile project tab/space guidelines. (I couldn't 
> find
> any such guideline, is there some specific Emacs setup I should be using for
> Guile development?)

Hum, I see that our .dir-locals.el is currently:

  ((nil             . ((fill-column . 72)
                       (tab-width   .  8)))
   (c-mode          . ((c-file-style . "gnu")))
   (scheme-mode
    . ((indent-tabs-mode . nil)
       (eval . (put 'pass-if 'scheme-indent-function 1))
       (eval . (put 'pass-if-exception 'scheme-indent-function 2))
       (eval . (put 'pass-if-equal 'scheme-indent-function 2))
       (eval . (put 'with-test-prefix 'scheme-indent-function 1))
       (eval . (put 'with-code-coverage 'scheme-indent-function 1))
       (eval . (put 'with-statprof 'scheme-indent-function 1))))
   (emacs-lisp-mode . ((indent-tabs-mode . nil)))
   (texinfo-mode    . ((indent-tabs-mode . nil)
                       (fill-column . 72))))

But we are missing an (indent-tabs-mode . nil) in the c-mode part I
think.  That is the proper fix ;)  In my emacs I customized the default
indent-tabs-mode to nil globally; but that's a personal preference.

> I've changed it to;
>
>   --quiet        inhibit informational compiler output, e.g name of
>                  files being compiled
>
> Open to suggestions still. Unlike most programmers I find documenting
> my work harder than writing the code :)

Oh I entirely agree :)  FWIW I think this is a fine description of the
option.

>> > +           ((string=? arg "--quiet")
>> > +            (set! %quiet #t)
>> > +            (parse args out))
>> > +
>> 
>> Probably %quiet should be a parameter, and unless we plan on using it
>> for other purposes it should have a more specific name
>> (%verbose-auto-compilation-messages or so; no idea).
>
> Could you clarify please, a parameter to what?

See "Parameters" in the manual.  They are dynamically scoped
thread-local variables.

>> Or, you could always just (current-warning-port (%make-void-port "w"));
>> then the patch is super simple, no conditions needed.  That is what I
>> was originally thinking, but it has the disadvantage that you lose other
>> uses of the current warning port, but maybe that's an advantage too.
>
> Won't we loose compiler warnings then? I did not want to inhibit those.

Humm!  Good point.  But maybe some people want to silence those too?

As far as documentation goes, the right place is the doc/ref/ directory,
specifically doc/ref/guile-invoke.texi.

I will apply your patch as-is once we have docs, unless we can figure
out some more general "chattiness" or verbosity knob that makes sense
for other messages that Guile issues.  I suspect that the "real"
solution for user code is to use a logging module that suits the user's
needs, but for Guile we also have some needs that we should solve in a
simple way.  Could be that this patch is the one :)

Thanks for your patience in contributing!

Andy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]