When an instance variable is referred to before a value has been assigned to
it, it automatically gets the value nil and the warning you see is emitted.
The reason for the warning, I guess, is to help finding situations where you
make a mistake writing the name of the variable. For example, in the following
code
@var = 4
if @vra < 5
...
@vra in the second line should obviously have been @var. Without the varning,
it would have been easy to overlook this mistake (expecially if the variable
name was longer than only three characters). The warning helps spotting it.
To answer your question: the library should have set those variable to nil
before using them, if it wanted to avoid the warning (not necessarily in
initialize, just before the variables were used). Not doing so, however, is
perfectly correct, if you don't mind seeing the warnings. Personally, I don't
like them, so I always assign instance variables before using them.
I hope this helps
Stefano
···
On Tuesday 24 November 2009, Seebs wrote:
>Running some simple tests with Prawn, I am getting thousands of lines
>of warnings from Ruby 1.9.1:
>
>/usr/local/lib/ruby/gems/1.9.1/gems/prawn-layout-0.3.2/lib/prawn/table/cel
>l.rb:255: warning: instance variable @text_color not initialized
>
>There are hundreds of these, and they seem to come from a lot of usages
>like:
>
>e.text_color ||= @text_color
>
>or this kind of usage:
>
> def page_content
> @active_stamp_stream || @store[@page_content]
> end
>
>In the latter case, @store is apparently fine, it's just
> @active_stamp_screen which is uninitialized.
>
>Should I infer that the library should be setting these all to nil in its
>initialize()?
>
>-s
>
To answer your question: the library should have set those variable to nil
before using them, if it wanted to avoid the warning (not necessarily in
initialize, just before the variables were used). Not doing so, however, is
perfectly correct, if you don't mind seeing the warnings. Personally, I don't
like them, so I always assign instance variables before using them.
Thanks!
I hope this helps
It does. I guess I'm a bit confused, 'cuz on the one hand, Prawn looks
pretty nice, but on the other hand, getting thousands of lines of warnings
running a simple test program sorta worries me.
-s
···
On 2009-11-24, Stefano Crocco <stefano.crocco@alice.it> wrote:
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
As I said, there's nothing wrong with not initializing instance variables to
nil: it's a matter of preferences. It seems Prawn's author doesn't like to
initialize variables to nil (indeed, it looks a bit too C-like for ruby) and
doesn't mind some warnings.
If the warnings only annoy you, you should be able to disable them by not
passing the -w option to ruby. If instead you're worried that they can mean
there's something wrong, I think you don't need to. Most of the times,
warnings issued by ruby are harmless.
Stefano
···
On Tuesday 24 November 2009, Seebs wrote:
>On 2009-11-24, Stefano Crocco <stefano.crocco@alice.it> wrote:
>> To answer your question: the library should have set those variable to
>> nil before using them, if it wanted to avoid the warning (not
>> necessarily in initialize, just before the variables were used). Not
>> doing so, however, is perfectly correct, if you don't mind seeing the
>> warnings. Personally, I don't like them, so I always assign instance
>> variables before using them.
>
>Thanks!
>
>> I hope this helps
>
>It does. I guess I'm a bit confused, 'cuz on the one hand, Prawn looks
>pretty nice, but on the other hand, getting thousands of lines of warnings
>running a simple test program sorta worries me.
>
>-s
>
1. Actually, those warnings happen even without -w. (Unless there's
something non-obvious passing the -w to Ruby that I didn't think about.)
2. I actually really DO want -w warnings for my code. Is there a way to
do a require that suppresses warnings during parsing of the required code?
-s
···
On 2009-11-24, Stefano Crocco <stefano.crocco@alice.it> wrote:
If the warnings only annoy you, you should be able to disable them by not
passing the -w option to ruby. If instead you're worried that they can mean
there's something wrong, I think you don't need to. Most of the times,
warnings issued by ruby are harmless.
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
I never used Prawn, so I can't tell why it issues warnings even without the -w
option. However, you can control this setting from inside your code using the
$VERBOSE global variable. It is initially set by ruby to one of the following
values:
* true if the -w, -v or --verbose flags have been passed on the command line
* nil if the -W0 flag has been passed on the command line
* false if none of the above flags has been given
You can change it from inside your code to avoid warnings from Prawn:
#your code
...
old_verbose = $VERBOSE
$VERBOSE = nil #code which makes prawn issue warnings
...
$VERBOSE = old_verbose
Stefano
···
On Tuesday 24 November 2009, Seebs wrote:
>On 2009-11-24, Stefano Crocco <stefano.crocco@alice.it> wrote:
>> If the warnings only annoy you, you should be able to disable them by
>> not passing the -w option to ruby. If instead you're worried that they
>> can mean there's something wrong, I think you don't need to. Most of the
>> times, warnings issued by ruby are harmless.
>
>There's two issues.
>
>1. Actually, those warnings happen even without -w. (Unless there's
>something non-obvious passing the -w to Ruby that I didn't think about.)
>2. I actually really DO want -w warnings for my code. Is there a way to
>do a require that suppresses warnings during parsing of the required code?
>
>-s
>
On 2009-11-24, Stefano Crocco <stefano.crocco@alice.it> wrote:
If the warnings only annoy you, you should be able to disable them by not
passing the -w option to ruby. If instead you're worried that they can mean
there's something wrong, I think you don't need to. Most of the times,
warnings issued by ruby are harmless.
There's two issues.
1. Actually, those warnings happen even without -w. (Unless there's
something non-obvious passing the -w to Ruby that I didn't think about.)
So what I really want is a way to request that a particular chunk of code
have interpreter warnings disabled while running it, or to find out whether
the Prawn people would accept a patch to eliminate these.
-s
···
On 2009-11-24, Brian Candler <b.candler@pobox.com> wrote:
Yes - but note that these are run-time, not parse-time warnings.
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
I'm assuming I must have something I'm not thinking of (a makefile or
something) passing a -w that I'm not aware of.
-s
···
On 2009-11-24, Robert Klemme <shortcutter@googlemail.com> wrote:
This is not what I am seeing:
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
Nope! It turns out that I was using
ruby foo.rb
but "foo.rb" started with "#!/usr/local/bin/ruby -w", and apparently the
interpreter parses that even when ruby is invoked explicitly.
-s
···
On 2009-11-25, Robert Klemme <shortcutter@googlemail.com> wrote:
I'm assuming I must have something I'm not thinking of (a makefile or
something) passing a -w that I'm not aware of.
Or you used option -v:
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!