Warning: instance variable @foo not initialized

S

Seebs

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/cell.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
 
S

Stefano Crocco

|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
|

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
 
S

Seebs

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
 
S

Stefano Crocco

|> 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
|

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
 
S

Seebs

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
 
B

Brian Candler

Seebs said:
Is there a way
to
do a require that suppresses warnings during parsing of the required
code?

Yes - but note that these are run-time, not parse-time warnings.

def quietly
ov = $VERBOSE
$VERBOSE = nil
yield
ensure
$VERBOSE = ov
end

quietly { p @foo }
 
S

Stefano Crocco

|> 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
|

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
 
R

Robert Klemme

2009/11/24 Seebs said:
There's two issues.

1. =A0Actually, those warnings happen even without -w. =A0(Unless there's
something non-obvious passing the -w to Ruby that I didn't think about.)

This is not what I am seeing:

$ allruby -e 'p @foo'
CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin]
nil
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-cygwin]
nil
$ allruby -we 'p @foo'
CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin]
-e:1: warning: instance variable @foo not initialized
nil
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-cygwin]
-e:1: warning: instance variable @foo not initialized
nil
$
2. =A0I actually really DO want -w warnings for my code. =A0Is there a wa= y to
do a require that suppresses warnings during parsing of the required code=
?

You can use -W to have a bit more control over verbosity.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
S

Seebs

Yes - but note that these are run-time, not parse-time warnings.

D'oh. Spot the forgetful C programmer.

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
 
R

Robert Klemme

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:

-v print version number, then turn on verbose mode

Kind regards

robert
 
S

Seebs

Or you used option -v:

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
 
B

Brian Candler

Seebs said:
D'oh. Spot the forgetful C programmer.

So what I really want is a way to request that a particular chunk of
code
have interpreter warnings disabled while running it

That's what I already posted:

quietly do
.. any code you like, e.g. build a document using prawn
end
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,236
Members
46,822
Latest member
israfaceZa

Latest Threads

Top