Re^4: sprintf is printing unexepected output

I really didn't know that. In my experiences (which are far from sophisticated), I don't remember a single time I regreted to use Data::Dump. Probably I haven't reached the edges that you mentioned. Given the zero size of the bug queue of the module and the general quality of modules by Gisle Aas, I thought it was quite a robust module. Maybe such examples of intolerance by Data:Dump should be transformed into bugs, so they get a chance of being fixed.

But it may be possible as well that things changed since the last time you gave a chance to Data::Dump. For instance, in the Changes file, we read:

   Release 1.05

   Improved track scalar references; dump() ended up
   recursing forever on some cyclic structures.

On the other hand, the usage we were telling about was as a debugging aid. If it fails, you can backup to Data::Dumper's ugly output without serious consequences.

Comment on Re^4: sprintf is printing unexepected output

Replies are listed 'Best First'.
Re^5: sprintf is printing unexepected output by ysth (Canon) on Dec 31, 2006 at 01:34 UTC
Ugly output? What do you mean?	[reply]
Re^6: sprintf is printing unexepected output by jettero (Monsignor) on Dec 31, 2006 at 03:41 UTC
I was curious enough to try it... `# perl -MData::Dump=dump -e '$h = {lol=>2}; $h->{lol2} = $h; print dum +p($h), "\n"' do { my $a = { lol => 2, lol2 => 'fix' }; $a->{lol2} = $a; $a; }` [download] That really is pretty slick looking compared to Data::Dumper. I'm not going to switch or anything, but you can't deny the output looks cooler. Less efficient maybe, but cooler... -Paul	[reply] [d/l]
Re^6: sprintf is printing unexepected output by ferreira (Chaplain) on Jan 02, 2007 at 11:04 UTC
I meant you have those ugly `$VARn` variables by default and possibly a series of statements as output which may not be used like this: `$var = [% dumper_output %];` [download]	[reply] [d/l] [select]