MKDEBUG produces non-commented output

[GoogleCodeExporter]

MKDEBUG=1 should never print a line that doesn't have a # in front of it. 
mk-table-checksum violates this rule.

Is there a way to make the _d() subroutine common code?

Original issue reported on code.google.com by baron.schwartz on 2 Nov 2008 at 7:42

[GoogleCodeExporter]

_d() in some cases may also die if it is given an undef value.  It should print 
out
"undef" in this case.

Original comment by baron.schwartz on 28 Nov 2008 at 4:26

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Target these for release end of January 2009.

Original comment by baron.schwartz on 4 Jan 2009 at 5:04

• Added labels: Milestone-2009_01

[GoogleCodeExporter]

I don't think there's an easy way to make _d() common code because if we make a
Debug.pm common module, then every other common module will need to require it 
but
that will cause a problem because if common/LogParser.pm requires Debug.pm by 
doing:
require 'Debug.pm'
Then when LogParser.pm is copied into mk-log-parser, Debug.pm will no longer 
exist
(require will look in the current dir). So we would need to copy Debug.pm into 
the
LogParser package namespace inside mk-log-parser. But that's a lot of work for 
little
payoff. Furthermore, it breaks the idea that the modules are truly modular: 
none of
them require any other module internally (but, of course, many require other 
modules
externally--the various args like q, v, etc.).

We could make modules that want to debug require a d arg (to new() or 
whatever), but
again this seems like a lot of work for little payoff because there'd be a huge 
list
of places in all the scripts where we'd have to add this extra d=>$debug arg.

Since the modules and _d() don't change often, and _d() is really simple, I 
think
it's best if I just go through them all and fix _d() where it's broken.

Original comment by dan...@percona.com on 9 Jan 2009 at 7:13

• Changed state: Started

[GoogleCodeExporter]

I will, however, make a _d.pl scriptlette so that it can be tested. Then, when 
we're
happy with it, I will edit all the modules and scripts and just :r this 
scriptlette
into place.

Original comment by dan...@percona.com on 9 Jan 2009 at 7:18

[GoogleCodeExporter]

r2794 has the _d.pl scriptlette and _d.t to test it.

Original comment by dan...@percona.com on 9 Jan 2009 at 8:15

[GoogleCodeExporter]

All common modules are updated as of r2801.
The main scripts remain to be done.

Original comment by dan...@percona.com on 11 Jan 2009 at 12:16

[GoogleCodeExporter]

Done as of r2822.  All scripts and common modules have the common/_d.pl.

Now the question is: do we want to update-modules on all the scripts?

Original comment by dan...@percona.com on 16 Jan 2009 at 8:29

[GoogleCodeExporter]

I'm going to say yes because I've already done a number of scripts in order to 
do
issue 140. So what's a few more? Plus, as long as their tests still pass, we 
should
ok. That, and I don't recall us doing any serious changes to any of the common
modules, so nothing should blow up. Let's see...

Original comment by dan...@percona.com on 17 Jan 2009 at 9:19

[GoogleCodeExporter]

Done as of r2845 and earlier revs. Nothing blew up; the scripts still pass 
their tests.

Original comment by dan...@percona.com on 17 Jan 2009 at 10:40

• Changed state: Fixed