On 4/13/07, Tim Pease <tim.pease / gmail.com> wrote:
> On 4/13/07, Robert Dober <robert.dober / gmail.com> wrote:
> > Hi list
> >
> > this is incredibly simple, but I just wanted to know what you think about it.
> >
> > I really often write the following code
> >
> > puts <whatever> if $DEBUG
> >
> > I guess you all do that to some extent, James just talked a newbie
> > into it recently ;)
> >
> > The first programmer's virtue of course makes me do some things like
> > def debug *args, &blk
> > return unless $DEBUG
> > <do something incredibly smart with the args ;)>
> > end
> > and sometimes on some of my machines I will do something like
> >
> > require 'ilmig/tools/debug'
> >
> > I feel that this might be so common place that a Kernel::debug or
> > whatever other suitable name might be a good idea.
> >
> > I am listening .... ;)
> >
>
> For medium to large programs having a global $DEBUG flag is going to
> create lots of "line noise" as all those debug messages go whipping
> by.
Tim the $DEBUG mechanism is quite primitive and other things are
needed for large scale development, no doubt.
My idea of the CR is orbiting around $DEBUG which is widely used in
quick hacks or small to medium scale development, but...
>
> I much prefer the fine grained control that the 'logging' and 'log4r'
> packages give you.
>
>
> require 'logging'
>
> class A
> def initialize
> @log = Logging::Logger[self]
> @log.debug "new object created '#{self.object_id}'"
> end
> end
>
> class B
> def initialize
> @log = Logging::Logger[self]
> @log.debug "new object created '#{self.object_id}'"
> end
> end
>
> Logging::Logger['A'].level = :warn
> Logging::Logger['B'].level = :debug
>
>
> It's a little more setup, but you have far greater control over what
> gets logged and what doesn't. The framework also takes care of
> timestamps, outputting class info, etc.
>
> And if you don't want all that complexity, there is always the core
> Logger class that comes with Ruby.
>
> Blessings,
> TwP
... I take one idea from your mail, with your kind permission ;)
Why not enhancing the semantics of $DEBUG at the same moment, I will elaborate
-----------------------------------------------------------------------------------
def Kernel.debug *args, &blk
return unless $DEBUG
begin
$DEBUG.puts args.join(" ") unless args.empty?
blk.call $DEBUG if blk
rescue
warn $DEBUG does not respond to the #puts message
end
end
now you can write code like
debug "OMG this should be deadcode, why I am here, I just kept that
code for sentimental reasons!!!!"
or
debug do
puts "whatever"
end
or
debug {
| stream |
stream.puts "@inst = #{@inst}"
}
or
debug do
$DEBUG.print "one"
end
of course the -d switch of ruby would just set $DEBUG to $stdout,
maybe a -l <stream>
switch could be introduced to set $DEBUG to a writeable IO object
representing <stream>
------------------------------------------------------------------------------------------------------
Now I realize I did not think about other debugging mechanisms, the
core idea is just to simplify what I think is a common and useful
idiom namely
puts "/...." if $DEBUG
I do not think that this will compete with more advanced debugging,
logging features, but why not enhance the $DEBUG switch as suggested
above.
Yeah and before I forget, thx for your input Tim.
Cheers
Robert
--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw