On Fri, Jul 11, 2025 at 11:26:19AM +0200, Patrice Dumas wrote:
> On Fri, Jul 11, 2025 at 12:45:05AM +0100, Gavin Smith wrote:
> > As Texinfo tree elements are now blessed into the Texinfo::TreeElement
> > class, this class is output by Data::Dumper when used by
> > Texinfo::Common::debug_print_tree. I use this fairly often when developing
> > and/or debugging. Sample output:
> >
> > The "bless" function calls with the "Texinfo::TreeElement" arguments
> > are new. I couldn't find a way to eliminate the usages of "bless"
> > by Data::Dumper.
>
> There is the $Data::Dumper::Toaster function in Data::Dumper that could
> be used to do something for each blessed object, maybe copy it without
> blessing?
It is $Data::Dumper::Freezer that does something before it is
dumped. Copying the hash doesn't work (it is the original hash
that needs to be unblessed). I could unbless it using the (not installed
by default) Data::Structure::Util module, but then I ran into
problems with type checks in Texinfo::Common::debug_print_element,
Texinfo::Convert::Texinfo::_convert_to_texinfo and possibly elsewhere.
So then I would have to iterate over the tree and rebless every element.
> > The only way I can think of is to post-process the
> > output with regular expressions.
>
> Another possibility could be to have a global variable/function to turn
> on/off blessing of elements (with an XS override such that the same is
> done for elements created from C) that would need to be called if
> TreeElement are used, which is likely to be never... I can do that if
> this is considered to be a good idea. If the elements are not blessed,
> the Texinfo::TreeElement::new function would be a noop.
Probably not worth the trouble just for this function. I can work around
the problem with regex.
> > Maybe this is not a big problem, as I can use
> > Texinfo::ManipulateTree::tree_print_details instead (this is the function
> > used by the test suite, which uses a different, more concise format,
> > albeit one I'm less familiar with):
>
> I personnally prefer this format by far, and only use it, and I found
> the Data::Dumper output to be unreadable for debugging anything a bit
> complex even before having bless.
I got very familiar with this format when writing the XS parser as I
was comparing the results from the XS and pure Perl parser.
> Another advantage (and the original
> reason to do it) is that it can be used to debug C code too, and both
> output should be similar (not necessarily exactly the same, maybe, when
> the types in C are more precise than in Perl, I haven't checked), which
> can be very handy when one or the other gives a better/good result.
I'm sure I'll learn to interpret this soon.
> > *@node C1 {@asis{} 2}
> > |INFO
> > |spaces_before_argument:
> > |{spaces_before_argument: }
> > |EXTRA
> > |is_target:{1}
> > |node_number:{10}
> > |normalized:{-2}
> > *arguments_line C1
> > *line_arg C2
> > |INFO
> > |spaces_after_argument:
> > |{spaces_after_argument:\n}
> > *@asis C1
> > *brace_container
> > { 2}
> >
> >
> > Incidentally, it is a lot of typing to use Texinfo::Common::debug_print_tree
> > or Texinfo::ManipulateTree::tree_print_details when you are trying to debug
> > the program. I remember that many years ago, print_tree was exported by
> > default by Texinfo::Common. I found the following ChangeLog entry from
> > 2022 (I thought it was older):
> >
> > 2022-09-14 Patrice Dumas <pertu...@free.fr>
> >
> > * tp/Texinfo/Common.pm: more consistent export ok. Do not
> > export print_tree. Rename print_tree() as debug_print_tree().
> > Rename add_preamble_before_content as _add_preamble_before_content.
> > Remove _collect_references, unused and doing something strange.
> >
> > Although it may make sense from the perspective of abstraction and
> > encapsulation, it doesn't make sense from the sense of making it easy
> > to develop the program, in my opinion. So I think we should consider
> > exporting a few basic functions by default, so we can again simply write
> > "warn print_tree($element);" rather than
> > "warn Texinfo::ManipulateTree::tree_print_details($element);".
>
> Do it, no problem, but please add a comment explaining why.
Ok, thanks.
