Gossamer Forum
Home : Products : Gossamer Links : Development, Plugins and Globals :

[suggestion] More Debug levels

Quote Reply
[suggestion] More Debug levels
Would be fine to have more flexibility of the debugging.

Currently the debugging has only 2 levels, and affects the whole script (Multi Level Debugging, MLD).
'debug_level' => '0', # can be set 0-2

Quote:
debug_level
This method returns the current debug level.
You may provide one argument which sets a new debug level.

0 means no debugging, 1 means basic debugging, 2 means heavy debugging.

If providing a new debug level, the old debug level is returned.


I would suggest a Functional Multi Level Debugging (FMLD) system, where the debugging of each function could be separately turned on-off.

The current 'debug_level' would be renamed to 'debug_level_general'. It would still control the debug level of the full LSQL script.

The 'debug_level_functions' would contain, a hash, where each key=value pairs controls debugging of a function.

The advantage of the new FMLD debug system, that while we can still have full debug control over the full script generally, but we can even just debug a function of the whole script without the need to have display all the sql queries and other currently unuseful options.

Example:
Code:
{
...
'debug_level_general' => '0', # current 'debug_level' option with 2 debug levels
'debug_level_functions' => {
"Plugins::Extended_link::mycode" => '2',
"Links::Build::site_html_category" => '1' }
...
}

In the example above, we will have displayed the debugging messages of the Plugins::Extended_link::mycode plugin function with debug level '2', and the debugging messages of Links::Build::site_html_category function with debug level '1'.
Only these debug texts will be displayed, nothing else, because the 'debug_level_general' is turned off.
Good idea, isn't?

If we want to turn on the general debugging, we just set 'debug_level_general' to '1', which will override the 'debug_level_functions' debugging, and all debug messages will be displayed.

The debug conditions could be coded as following:
- the debug level of functions from 'debug_level_functions', is assigned to the corresponding variable in the Links::init function.
- After Links::init, the variable levels of the example would be: $Plugins::Extended_link::mycode::DEBUG has debug level 2 and $Links::Build::site_html_category::DEBUG has debug level 1.
- debugging can be coded that way in the functions itself:
Code:
sub mycode {
print "The Extended_link debugging is turned on" if (
$Plugins::Extended_link::mycode::DEBUG or $CFG->{debug_level_general}
);
}

Of course $GT::Plugins::DEBUG could be still used to enable/disable plugin debugging generally.

Opinions, ideas are welcome.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Last edited by:

webmaster33: May 17, 2002, 10:06 AM
Quote Reply
Re: [webmaster33] [suggestion] More Debug levels In reply to
I think the current debugging system is extremely detailed and pinpoints most if not all errors.

I think adding debugging options for every function would be messy and confusing, not to mention all the changes that would need to be made when installing/uninstalling plugins and upgrades etc...

How are you going to turn on/off debugging for each function and keep control?...it doesnt seem practical.

Last edited by:

Paul: May 17, 2002, 9:45 AM
Quote Reply
Re: [webmaster33] [suggestion] More Debug levels In reply to
Another thing I was thinking...

debugging is for finding and fixing bugs. I don't understand why you'd want to "selectively" debug seeing as you never know where errors are coming from.

Why would you need so many debugging options?

Last edited by:

Paul: May 17, 2002, 10:15 AM
Quote Reply
Re: [Paul] [suggestion] More Debug levels In reply to
Quote:
How are you going to turn on/off debugging for each function and keep control?...
Paul, you may not read my post carefully. It is described in details.

If you turn off 'debug_level_general', then no debugging is turned on, right?
Now, we place the "Plugins::Extended_link::mycode" => '2' into 'debug_level_functions' hash, so debugging now is turned on just for the function Plugins::Extended_link::mycode, with debug level 2.

It is that easy.

So we are not forced to see, even the executed SQL queries, we just see the debugging info of our selected function.
Improving the debug system to FMLD, would be need a lot of small changes in the source code,
but these are small & easy changes and I think the easier debugging worths this extra work.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [Paul] [suggestion] More Debug levels In reply to
Sometimes 2 level debug is helpful, but sometimes selective debugging of some functions would be fine.
There are developing stages, when selective debugging can be helpful.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] [suggestion] More Debug levels In reply to
>>Paul, you may not read my post carefully. It is described in details. <<

Sure I did, but you only described how it would look in the config file.....that doesn't explain how it would be controlled from the admin panel and how Links SQL would keep track of every single function.

>>
So we are not forced to see, even the executed SQL queries, we just see the debugging info of our selected function.
<<

...and how do you know the error is not an SQL error or is not in a function that is currently turned "off".....you may have to turn debugging on for every function before you find the error which makes the whole idea pointless as you may as well have just turned on general debugging in the first place.

What you are suggesting is a major change for little gain. GT would have to go through every function altering the way debugging works.

Last edited by:

Paul: May 17, 2002, 10:31 AM
Quote Reply
Re: [Paul] [suggestion] More Debug levels In reply to
Quote:
What you are suggesting is a major change for little gain. GT would have to go through every function altering the way debugging works.

Not really. Debugging is one of the most important part of the developments. If that little gain can help somebody to find a bug, then it worths to do that debug system improvement.
As LSQL is getting bigger & difficulter, the debugging is getting also difficulter.
That selective debugging would help us to turn on when we want to debug just a few functions together.
I would not suggest it, if I would not need this selective debugging right now. I found it right now very useful, so my opinion is that worths implementing.

Finally to make clear, I would make it for myself, if I would not want to maintain upgrade compatibility. That's why I suggest it for the staff.

Have to go now, I will read replies, opinions tomorrow (14 hours later).

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] [suggestion] More Debug levels In reply to
>>
Debugging is one of the most important part of the developments.
<<

Definitately agree on that.

>>
As LSQL is getting bigger & difficulter, the debugging is getting also difficulter.
<<

Thats what I don't agree with. The current debugging hasn't failed me yet when I've used it (or has at least helped a staff member tell me what the error is).....it is detailed and accurate...infact more detailed than any other software I know of.

Anyway...who knows maybe GT will like your idea.

Last edited by:

Paul: May 17, 2002, 10:57 AM
Quote Reply
Re: [Paul] [suggestion] More Debug levels In reply to
Quote:
The current debugging hasn't failed me yet when I've used it (or has at least helped a staff member tell me what the error is).....it is detailed and accurate...infact more detailed than any other software I know of.
Paul, you are talking again about something other, than I wrote.
I did NOT tell you, that current debugging was failed, nor is wrong, nor it is unusable is any way, nor about how detailed is, nor how accurate is, nor compared to another software as you do.
I just wrote, I want it more flexible, and debugging is getting difficulter as the developments are improving LSQL.

Debugging is getting difficulter, as we have to browse through more & more debug info. Each new feature we add, would need some more debugging, and if we set a debug level 2, sometimes we get so much debugging info, that finding the info you wanted takes a lot time.

Current general debugging solution is very useful and really helpful, and detailed.

But there are some cases, like I had yesterday, when after I used general debugging, selective debugging would be fine:

- general debugging gives me too much details, or
- I've already located the place of the error, but still need some selective debugging, or
- just developing a plugin, and I don't need general debugging, just to debug the current plugin I'm working on.

In these cases, would be fine to have selective debugging, so I can turn off general debugging, and debug only those functions, I placed into the 'debug_level_functions' config option.

I'm convinced about usefulness of the selective debugging feature. Although, as you say we don't gain too much with this feature, and maybe we will not use so often as the general debugging, but when it is rarely required, you can thank God, that we have such useful selective debugging feature and you can save a lot time using it...
It is a feature, that would help us, developers, to be able to develop easier, and sometimes faster...

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...