Forum: Ruby is -w really useful?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Wybo D. (Guest)
on 2006-03-27 15:29
(Received via mailing list)
I would like to use the -w commandline option always, but any useful
output is always obscured by message from the standard libraries:

For example:

/usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/if/grande.rb:404:
warning: useless use of > in void context
/usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/if/grande.rb:580:
warning: useless use of < in void context
/usr/local/lib/ruby/1.8/tk.rb:2313: warning: redefine encoding=
/usr/local/lib/ruby/1.8/tk.rb:2316: warning: redefine encoding
/usr/local/lib/ruby/1.8/tk/font.rb:718: warning: instance variable
@compoundfont not initialized
/usr/local/lib/ruby/1.8/tk/font.rb:671: warning: instance variable
@compoundfont not initialized
/usr/local/lib/ruby/1.8/tk/font.rb:718: warning: instance variable
@compoundfont not initialized
/usr/local/lib/ruby/1.8/tk/font.rb:671: warning: instance variable
@compoundfont not initialized
/usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/rl/uri.rb:78:
warning: method redefined; discarding old base=
/usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/cp.rb:209: warning:
useless use of < in void context
/usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/cp.rb:309: warning:
useless use of > in void context

Should such messages not be banned?
James G. (Guest)
on 2006-03-27 18:01
(Received via mailing list)
On Mar 27, 2006, at 5:29 AM, Wybo D. wrote:

> I would like to use the -w commandline option always, but any
> useful output is always obscured by message from the standard
> libraries:

[snip warnings]

Just to be clear, Rio is not a standard library (though TK is).

> Should such messages not be banned?

I do agree that standard libraries should not trigger warnings.

James Edward G. II
Justin C. (Guest)
on 2006-03-28 01:07
(Received via mailing list)
Wybo D. wrote:
> /usr/local/lib/ruby/1.8/tk.rb:2316: warning: redefine encoding
> /usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/cp.rb:209:
> warning: useless use of < in void context
> /usr/local/lib/ruby/gems/1.8/gems/rio-0.3.7/lib/rio/cp.rb:309:
> warning: useless use of > in void context
>
> Should such messages not be banned?
>

Some warnings are really just informational. For example, redefining a
method isn't 'wrong,' and it can be how your program is supposed to
function. Or having an uninitialized instance variable might not matter
- after all, I don't think there is a difference between that and
setting it to nil.

However, it could be dangerous or unintentional, so you get a warning.
As with all debugging output, you have to filter through it sometimes.

-Justin
Wybo D. (Guest)
on 2006-03-28 01:55
(Received via mailing list)
On Tue, 28 Mar 2006, Justin C. wrote:

>
> Some warnings are really just informational. For example, redefining a method
> isn't 'wrong,' and it can be how your program is supposed to function. Or
> having an uninitialized instance variable might not matter - after all, I
> don't think there is a difference between that and setting it to nil.
>
> However, it could be dangerous or unintentional, so you get a warning. As
> with all debugging output, you have to filter through it sometimes.

Sure, that's all true, and I want to see such messages to warn myself
for
possibly bad programming habits.
But when I see lots of such message emerge from libraries that I didn't
write myself, I'll easily miss the ones that really matter to me and can
be influenced by me.
Robert D. (Guest)
on 2006-03-28 12:58
(Received via mailing list)
On 3/27/06, Wybo D. <removed_email_address@domain.invalid> wrote:
> >> [messages skipped]
> > don't think there is a difference between that and setting it to nil.
>
> --
> Wybo
>
> Wouldn't it be nice to have a perl/ada style

pragma :warnings_on
pragma :warnings_off
or
pragma :warnings, level

at a dynamic base.

Now for a given (standard) library we could just say

e.g.
module MyModule
   pragma :warnings 0
end

Just a thaught

Robert


--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
Wybo D. (Guest)
on 2006-03-29 02:17
(Received via mailing list)
On Tue, 28 Mar 2006, Robert D. wrote:

> Wouldn't it be nice to have a perl/ada style
>
> pragma :warnings_on
> pragma :warnings_off
> or
> pragma :warnings, level
>
> at a dynamic base.

Well, you can already say: $VERBOSE = true or $VERBOSE = false.
Isn't that the same?
Andrew J. (Guest)
on 2006-03-29 02:44
(Received via mailing list)
On Wed, 29 Mar 2006 07:17:10 +0900, Wybo D. 
<removed_email_address@domain.invalid>
wrote:
>
> Well, you can already say: $VERBOSE = true or $VERBOSE = false.
> Isn't that the same?

Actually, $VERBOSE can take on three semantic values: nil, false, true.
Further, behaviour can differ slightly if -W0, -W1, -W2 (ie, nil, false,
true (and -w == -W2) are set from the command line as opposed to setting
$VERBOSE in the script (parse-time vs runtime). This means that doing
something akin to:

  module Kernel
    def no_warn
      begin
        verbose = $VERBOSE
        $VERBOSE = nil
        yield
        ensure
        $VERBOSE = verbose
      end
    end
  end

  no_warn do
    puts (0..5)
  end

doesn't quench the warning, but -W0 does. Strangely, changing that
block to:

  no_warn do
    puts "foo"
    puts (0..5)
  end

results in yet different warning behaviours.

At any rate, a catchable warning system might be a good idea and
encourage people to wrap 'warnable' code in blocks that don't emit
particular warnings -- so something like:

  no_warn :method_redefined do
    # (meta)code that redefines methods
  end

would explicitly turn off the method redefinition warning (presumably we
are doing that on purpose here), but still emit any other warnings the
code might generate.

Just a thought.

andrew
This topic is locked and can not be replied to.