Hi all,
I’ve recently got around to reinstating some of my old Ruby apps after a
system upgrade, part of which involved an upgrade from 1.6 to 1.8pre3.
Some of the libraries used in these apps were written for 1.6, and now
they spew out loads of warnings. I seem to remember something about
warnings being on by default in a planned future version of Ruby, but I
didn’t think it was as soon as 1.8 - however, regardless of whether this
is the case or not, how do I turn them off? Remember that it’s not my
code, so I’m not about to go through and correct all the warnings. The
libraries still function correctly.
In message “Warnings?” on 03/07/29, Tim Bates tim@bates.id.au writes:
I’ve recently got around to reinstating some of my old Ruby apps after a
system upgrade, part of which involved an upgrade from 1.6 to 1.8pre3.
Some of the libraries used in these apps were written for 1.6, and now
they spew out loads of warnings. I seem to remember something about
warnings being on by default in a planned future version of Ruby, but I
didn’t think it was as soon as 1.8 - however, regardless of whether this
is the case or not, how do I turn them off? Remember that it’s not my
code, so I’m not about to go through and correct all the warnings. The
libraries still function correctly.
You’ve inspired me to add a way to stop all warnings. In the near
future release, -W0 stops all warnings.
How about a way to trap warnings similar to rescue Exception so we can trap and suppress certain expected warnings?
Thanks, Michael Davis
Yukihiro Matsumoto wrote:
···
Hi,
In message “Warnings?” > on 03/07/29, Tim Bates tim@bates.id.au writes:
I’ve recently got around to reinstating some of my old Ruby apps after a
system upgrade, part of which involved an upgrade from 1.6 to 1.8pre3.
Some of the libraries used in these apps were written for 1.6, and now
they spew out loads of warnings. I seem to remember something about
warnings being on by default in a planned future version of Ruby, but I
didn’t think it was as soon as 1.8 - however, regardless of whether this
is the case or not, how do I turn them off? Remember that it’s not my
code, so I’m not about to go through and correct all the warnings. The
libraries still function correctly.
You’ve inspired me to add a way to stop all warnings. In the near
future release, -W0 stops all warnings.
What can I do in the meantime? One of my curses-based apps is
practically unuseable, because the database-backed prints lots of
warnings every time it does anything. I’d like to have an interim
solution.
Tim Bates
···
On Wed, Jul 30, 2003 at 01:00:21AM +0900, Yukihiro Matsumoto wrote:
You’ve inspired me to add a way to stop all warnings. In the near
future release, -W0 stops all warnings.
How about a way to trap warnings similar to rescue Exception so we can trap and suppress certain expected warnings?
Since warning is a mere message, not exit like exceptions, it is more
difficult to catch. You can suppress warning messages by redirecting
$stderr temporarily (although it’s not thread safe).
On Tuesday 29 July 2003 04:12 pm, Tim Bates wrote:
On Wed, Jul 30, 2003 at 01:00:21AM +0900, Yukihiro Matsumoto wrote:
You’ve inspired me to add a way to stop all warnings. In the near
future release, -W0 stops all warnings.
What can I do in the meantime? One of my curses-based apps is
practically unuseable, because the database-backed prints lots of
warnings every time it does anything. I’d like to have an interim
solution.
On Wed, Jul 30, 2003 at 01:00:21AM +0900, Yukihiro Matsumoto wrote:
You’ve inspired me to add a way to stop all warnings. In the near
future release, -W0 stops all warnings.
What can I do in the meantime? One of my curses-based apps is
practically unuseable, because the database-backed prints lots of
warnings every time it does anything. I’d like to have an interim
solution.
I can appreciate the difficulty, however, I would rather not suppress all warnings and yet I have code that generates warnings that are okay. Will it be possible to turn off warnings and then turn them back on again at runtime? This would at least provide me an option to disable warning messages during methods that generate warnings.
How about a way to trap warnings similar to rescue Exception so we can trap and suppress certain expected warnings?
Since warning is a mere message, not exit like exceptions, it is more
difficult to catch. You can suppress warning messages by redirecting
$stderr temporarily (although it’s not thread safe).
“Yukihiro Matsumoto” matz@ruby-lang.org schrieb im Newsbeitrag
news:1059507455.553355.1938.nullmailer@picachu.netlab.jp…
Hi,
How about a way to trap warnings similar to rescue Exception so we can
trap and suppress certain expected warnings?
Since warning is a mere message, not exit like exceptions, it is more
difficult to catch. You can suppress warning messages by redirecting
$stderr temporarily (although it’s not thread safe).
The approach most reasonable is IMHO to provide a warning handler setting
mechanism similarly to the trace handler. Only I don’t know how much
runtime overhead that’d be. The handler block could receive something like
level, code, message, sender| and treat it appropriately. -W0, -W1 etc.
would then change the block’s filtering according to level.
irb(main):001:0> class WarningException < Exception; end
irb(main):002:0> module Kernel
irb(main):003:1> def warn(m)
irb(main):004:2> raise WarningException, m
irb(main):005:2> end
irb(main):006:1> end
irb(main):007:0> warn “Hello”
(irb):4:in warn': Hello (WarningException) from (irb):7:in irb_binding’
from C:/Apps/Ruby18/lib/ruby/1.8/irb/workspace.rb:52:in
`irb_binding’
from C:/Apps/Ruby18/lib/ruby/1.8/irb/workspace.rb:52
This, of course, depends on the module using the functionality. It
also won’t work on rb_warning or rb_warn, obviously.
-austin
···
On Wed, 30 Jul 2003 08:54:09 +0900, Michael Davis wrote:
I can appreciate the difficulty, however, I would rather not suppress all
warnings and yet I have code that generates warnings that are okay. Will
it be possible to turn off warnings and then turn them back on again at
runtime? This would at least provide me an option to disable warning
messages during methods that generate warnings.
When you say you have “code that generates warnings that are ok”, you
mean the warnings are safe to ignore, or code that generates warnings
that looks ok to you? And when you say “turn them back on again at
runtime”, do you mean a variable you can change programmatically, or a
function you can run that determines whether warnings go to the console
or not?
A typical unix way of dealing with output you don’t care about is
redirecting it to /dev/null, so you could create methods that reassign
$stderr to the default value or /dev/null depending on whether or not
you want to see them:
def warningsOn
$stderr.flush
$stderr = STDERR
end
def warningsOff
$stderr.flush
$stderr = File.open(‘/dev/null’, ‘w’)
end
(thinks why for the prototype)
Ben
···
On Tuesday, July 29, 2003, at 07:54 PM, Michael Davis wrote:
I can appreciate the difficulty, however, I would rather not suppress
all warnings and yet I have code that generates warnings that are
okay. Will it be possible to turn off warnings and then turn them
back on again at runtime? This would at least provide me an option to
disable warning messages during methods that generate warnings.
The approach most reasonable is IMHO to provide a warning handler setting
mechanism similarly to the trace handler. Only I don’t know how much
runtime overhead that’d be. The handler block could receive something like
level, code, message, sender| and treat it appropriately. -W0, -W1 etc.
would then change the block’s filtering according to level.
I proposed a think like this !
I’m not alone !
Oh, and a $VERBOSE as
