Tracy: the standalone version of Nette Debugger

Notice: This thread is very old.
David Grudl
Nette Core | 8229
+
0
-

After five years of development, here is a really standalone version of tool you know very well as:

  • Laděnka
  • Nette Debug
  • Nette Debugger
  • Nette Diagnostics

And now it is called Tracy.

Currently, Tracy has the same API as Nette\Diagnostics (only namespace was changed). But I think this is chance to take a step in the development and find much better API. Any ideas?

echo
Member | 134
+
0
-

David Grudl wrote:

And now it is called Tracy.

Currently, Tracy has the same API as Nette\Diagnostics (only namespace was changed). But I think this is chance to take a step in the development and find much better API. Any ideas?

Wouldn't it be better then if Nette was using Tracy rather than Nette\Diagnostics as there would be no duplicities when updating either source (Nette master/Tracy master)? In my opinion both should be identical. Or not?

MartinitCZ
Member | 580
+
0
-

I think that echo has right.

This is not good idea. One app in two different namespaces.

Majkl578
Moderator | 1364
+
0
-

Nette itself should require/suggest Tracy in composer.json and remove Nette\Diagnostics.

Filip Procházka
Moderator | 4668
+
0
-

I agree, It can be added to dev and Nette could have BC aliases in itself.

MartinitCZ
Member | 580
+
0
-

@**Filip Procházka**: But I think that if replace Nette\Diagnostic with Tracy (over composer) will be in 2.1 … you can skip alliases

Filip Procházka
Moderator | 4668
+
0
-

Better BC = happier users.

MartinitCZ
Member | 580
+
0
-

@**Filip Procházka**: That sounds like a good idea ;)

Milo
Nette Core | 1283
+
0
-

This is not an idea to API change, but idea for manual libs loading.

Tracy.php // loader + shortcuts
Tracy.no-shortcuts.php // loader

I have never met with naming conflict pesonally, I use only Tracy ;-), but it seems to me as a nice harmless way to disable shortcuts.

Milo
Nette Core | 1283
+
0
-

And add one more shortcut:

function bdump($var)
{
	Tracy\Debugger::barDump(func_get_args());
}
David Grudl
Nette Core | 8229
+
0
-

Tracy should be compatible with Composer autoloading, so there should be something like Tracy\Shortcuts::init().

Milo
Nette Core | 1283
+
0
-

To the API change topic… I would appreciate these changes.

  1. Convert static classes to singletons. For Dumper and Debugger at least. In my code is often Debugger::log($e), in better cases $this->logger->log($e) where:
class ErrorLogger {
	public function log(...) {
		Tracy\Debugger::log(...);
	}
}
  1. Provide mechanism to object dumping. E.g. Dumper::forObject('Milo\Class', function($dumper) {...}).
  2. Provide mechanism to easiest Dumper or Debugger configuration. This is my often usage:
Tracy\Debugger::enable(...);
Tracy\Debugger::$strictMode = TRUE;
Tracy\Debugger::$maxDepth = 1e5;
// and configure Dumper::COLLAPSE_COUNT is very hard

// Fluent may be helpful
Tracy\Debugger::configure()->enable(TRUE)->email(...)->getDumper()->maxDepth(10);
  1. Somehow remember which object/class members should stay collapsed or expanded. Or mark them as non-dumpable. It is very useful for big structures where is a little bit annoying still clicking after every dump. I have no concrete idea how to do it. Perhaps over JavaScript and cookie
this.collapsed['Milo\Class::member'] = TRUE;
  1. Provide interface to logging on non-stdout. Useful during XML-RPC debugging where FireBug does not exists. I have a SqliteDebugger where I fill dumps and by AJAX dumping them into browser. Somehow easy redirect whole BlueScreen/dumps html would be great.
  2. Possibility to continue after Warning/Notice in strictMode, just like PHP itself.

These are things which I find useful to have. I'm sure that some of issues can be solved in other way I proposed, it is just idea.

enumag
Member | 2118
+
0
-

Somehow remember which object/class members should stay collapsed or expanded. Or mark them as non-dumpable. It is very useful for big structures where is a little bit annoying still clicking after every dump. I have no concrete idea how to do it. Perhaps over JavaScript and cookie

Marking as non-dumpable would be good. I often get very large dumps because some large structures are dumped on multiple levels of the backtrace. The bluescreen rendering then takes VERY long time and the structures that caused it were pretty much useless for finding the error. I'd be glad to get rid of them.