# RCR debug **URL:** \ **Category:** ruby-talk\ **Created:** [13 April 2007 13:26 UTC](https://rubytalk.org/t/rcr-debug/36915 "2007-04-13T13:26:43Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [13 April 2007 13:26 UTC](https://rubytalk.org/t/rcr-debug/36915/1 "2007-04-13T13:26:43Z")
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 \ 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   \ 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 .... 馃槈 Cheers Robert > **路路路** > > -- > You see things; and you say Why? > But I dream things that never were; and I say Why not? > -- George Bernard Shaw ---
**Author:** ![Tim\_Pease](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@Tim\_Pease](https://rubytalk.org/u/Tim_Pease)\ **Post date:** [13 April 2007 15:31 UTC](https://rubytalk.org/t/rcr-debug/36915/2 "2007-04-13T15:31:13Z")
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. 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 > **路路路** > > On 4/13/07, Robert Dober \ 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 \ 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 > >   \ > > 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 .... 馃槈 ---
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [13 April 2007 20:01 UTC](https://rubytalk.org/t/rcr-debug/36915/3 "2007-04-13T20:01:01Z")
> \> 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 \ 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 > \> \ > \> 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 > **路路路** > > On 4/13/07, Tim Pease \ wrote: > > > On 4/13/07, Robert Dober \ wrote: > > ----------------------------------------------------------------------------------- > 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 \ > switch could be introduced to set $DEBUG to a writeable IO object > representing \ > ------------------------------------------------------------------------------------------------------ > > 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 ---
**Author:** ![Tim\_Pease](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@Tim\_Pease](https://rubytalk.org/u/Tim_Pease)\ **Post date:** [14 April 2007 14:28 UTC](https://rubytalk.org/t/rcr-debug/36915/4 "2007-04-14T14:28:24Z")
A simple debug method seems like a great idea. But what happens when it ends up in Kernel and everyone starts using it? Now you'll get all the debug messages from your code and all the library code that you include. That's why I don't like the $DEBUG option. I know you want to put it into Kernel so everyone can use. But that's the whole problem -- everyone will start using it! And then it becomes not so useful. This is similar to making sure that your code runs -w clean (i.e. won't throw out warnings). The rails core is very bad about this -- lot's of warnings. Now you cannot find the warnings in your own code because all the rails warnings are cluttering things up. Same problem with a global $DEBUG flag. Just my $0.02 on the matter. Blessings, TwP PS Why not include this in the facets library? I think this would be a much more suitable place for such a creature. \<[http://facets.rubyforge.org/>](http://facets.rubyforge.org/>); > **路路路** > > On 4/13/07, Robert Dober \ wrote: > > > 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... ---
**Author:** ![Ara.T.Howard6](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@Ara.T.Howard6](https://rubytalk.org/u/Ara.T.Howard6)\ **Post date:** [14 April 2007 16:17 UTC](https://rubytalk.org/t/rcr-debug/36915/5 "2007-04-14T16:17:38Z")
alternatively    logger = Logger.new STDERR    logger.level = ENV['DEBUG\_ENV\_FOR\_MY\_CODE'] ? Logger::DEBUG : LOGGER::INFO    logger.debug{ 'now you have a debug method that can be turned on/off from the environment' } it's prety kiss... -a > **路路路** > > On Sat, 14 Apr 2007, Tim Pease wrote: > > > On 4/13/07, Robert Dober \ wrote: > > > > > 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... > > > > A simple debug method seems like a great idea. But what happens when > > it ends up in Kernel and everyone starts using it? Now you'll get all > > the debug messages from your code and all the library code that you > > include. That's why I don't like the $DEBUG option. > > > > I know you want to put it into Kernel so everyone can use. But that's > > the whole problem -- everyone will start using it! And then it > > becomes not so useful. > > > > This is similar to making sure that your code runs -w clean (i.e. > > won't throw out warnings). The rails core is very bad about this -- > > lot's of warnings. Now you cannot find the warnings in your own code > > because all the rails warnings are cluttering things up. > > > > Same problem with a global $DEBUG flag. > > > > Just my $0.02 on the matter. > > > > Blessings, > > TwP > > > > PS Why not include this in the facets library? I think this would be > > a much more suitable place for such a creature. > > > > \<[http://facets.rubyforge.org/>](http://facets.rubyforge.org/>); > > -- > be kind whenever possible... it is always possible. > - the dalai lama ---
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [14 April 2007 17:41 UTC](https://rubytalk.org/t/rcr-debug/36915/6 "2007-04-14T17:41:20Z")
Ara I guess you are right about the Kernel, a standard library module/class might be better, voici Logger. Funnily I think I really have not done enough research about Logger after Tim's input, well maybe because Tim just explained that he prefered Logger and that was not on my mind. Sorry Tim if I was not thoughtful enough. I feel that I just wanted to facilitate a common pattern, I had not though a second about if that common pattern was worth being facilitated... ... probably it is not. Thanks for your input, I guess I'll call it an RCR ;). This is a great ML, they think for you, someone to write a solution for this weeks Ruby Quiz for me ? :))) Cheers Robert > **路路路** > > On 4/14/07, ara.t.howard@noaa.gov \ wrote: > > > On Sat, 14 Apr 2007, Tim Pease wrote: > > > > \> On 4/13/07, Robert Dober \ wrote: > > \>\> 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... > > \> > > \> A simple debug method seems like a great idea. But what happens when > > \> it ends up in Kernel and everyone starts using it? Now you'll get all > > \> the debug messages from your code and all the library code that you > > \> include. That's why I don't like the $DEBUG option. > > \> > > \> I know you want to put it into Kernel so everyone can use. But that's > > \> the whole problem -- everyone will start using it! And then it > > \> becomes not so useful. > > \> > > \> This is similar to making sure that your code runs -w clean (i.e. > > \> won't throw out warnings). The rails core is very bad about this -- > > \> lot's of warnings. Now you cannot find the warnings in your own code > > \> because all the rails warnings are cluttering things up. > > \> > > \> Same problem with a global $DEBUG flag. > > \> > > \> Just my $0.02 on the matter. > > \> > > \> Blessings, > > \> TwP > > \> > > \> PS Why not include this in the facets library? I think this would be > > \> a much more suitable place for such a creature. > > \> > > \> \<[http://facets.rubyforge.org/>](http://facets.rubyforge.org/>); > > > > alternatively > > > >    logger = Logger.new STDERR > >    logger.level = ENV['DEBUG\_ENV\_FOR\_MY\_CODE'] ? Logger::DEBUG : LOGGER::INFO > > > >    logger.debug{ 'now you have a debug method that can be turned on/off from the environment' } > > > > it's prety kiss... > > > > -a > > -- > > be kind whenever possible... it is always possible. > > - the dalai lama > > -- > You see things; and you say Why? > But I dream things that never were; and I say Why not? > -- George Bernard Shaw