Tracy: the standalone version of Nette Debugger
- David Grudl
- Nette Core | 8218
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
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
I think that echo has right.
This is not good idea. One app in two different namespaces.
- Filip Procházka
- Moderator | 4668
I agree, It can be added to dev and Nette could have BC aliases in itself.
- MartinitCZ
- Member | 580
@**Filip Procházka**: But I think that if replace Nette\Diagnostic with Tracy (over composer) will be in 2.1 … you can skip alliases
- David Grudl
- Nette Core | 8218
Tracy should be compatible with Composer autoloading, so there should be
something like Tracy\Shortcuts::init()
.
- Milo
- Nette Core | 1283
To the API change topic… I would appreciate these changes.
- 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(...);
}
}
- Provide mechanism to object dumping. E.g.
Dumper::forObject('Milo\Class', function($dumper) {...})
. - 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);
- 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;
- 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. - 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
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.