Skip Menu |

This queue is for tickets about the XML-Rabbit CPAN distribution.

Report information
The Basics
Id: 81753
Status: resolved
Worked: 3 hours (180 min)
Priority: 0/
Queue: XML-Rabbit

Owner: ROBINS [...]
Requestors: arfreitas [...]

Bug Information
Severity: Unimportant
Broken in: 0.2.1
Fixed in: (no value)

Download (untitled) / with headers
text/plain 4.3k
Greetings, First of all, thanks for creating XML::Rabbit! The distribution is really a HUGE help providing directly XML mapping to plain objects using Moose. I'm creating this ticket as "Unimportant" not because I think it is not import, but because the error may be due a dependency of Data::Visitor::Callback. I'm really not sure if it is a feature or a bug, but it's making much more difficult to debugging code when using XML::Rabbit. I attached files to help to reproduce the error: a XML file and a Perl script that just reads the file and tries to get some values from the objects created. The tarball has the objects packages. This is what I got after starting debugging: c:\Temp>perl -d cpan.xml Loading DB routines from version 1.37 Editor support available. Enter h or 'h h' for help, or 'perldoc perldebug' for more help. main::( my $file = shift; DB<1> n main::( my $mon_conf = Siebel::Monitor::Config->new( file => $file ); DB<1> main::( print join( "\n", main::( $mon_conf->gateway, $mon_conf->enterprise, $mon_conf->srvrmgrPath ), main::( "\n"; DB<1> spbrsiegw01 sbl_crm_prd C:\Siebel\8.1\Client_1\BIN main::( print Dumper( $mon_conf->servers ), "\n"; DB<1> Data::Visitor::Callback::callback(C:/Perl/site/lib/Data/Visitor/ 248: my ( $self, $name, $data, @args ) = @_; 100 levels deep in subroutine calls! DB<1> After the message "100 levels deep in subroutine calls!", the debug goes into the guts of Data::Visitor::Callback and goes over a lot of steps. Even if I try to go directly to a previous set break point, it does not work. It is not a bug, but is messy. Here is more detail on the environment that I'm using here: Windows 7 Enterprise Service Pack 1 c:\Temp>perl -V Set up gcc environment - 3.4.5 (mingw-vista special r3) Summary of my perl5 (revision 5 version 16 subversion 1) configuration: Platform: osname=MSWin32, osvers=5.2, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='C:\Perl\site\bin\gcc.exe', ccflags ='-DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T -DHASATTRIBUTE -fno-strict-aliasing -mms-bitfields', optimize='-O2', cppflags='-DWIN32' ccversion='', gccversion='3.4.5 (mingw-vista special r3)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='C:\Perl\site\bin\g++.exe', ldflags ='-L"C:\Perl\lib\CORE"' libpth=\lib libs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt perllibs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl516.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -L"C:\Perl\lib\CORE"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1601 [296175] Built under MSWin32 Compiled at Aug 30 2012 20:08:55 @INC: C:/Perl/site/lib C:/Perl/lib .
Subject: Siebel.tar
Download Siebel.tar
application/octet-stream 6k

Message body not shown because it is not plain text.

text/x-perl 580b
use warnings; use strict; use Data::Dumper; use lib '.'; use Siebel::Monitor::Config; my $file = shift; my $mon_conf = Siebel::Monitor::Config->new( file => $file ); print join( "\n", $mon_conf->gateway, $mon_conf->enterprise, $mon_conf->srvrmgrPath ), "\n"; print Dumper( $mon_conf->servers ), "\n"; print ref($mon_conf->servers()), "\n"; #foreach my $server ( @{ $mon_conf->servers } ) { # # foreach my $component ( @{ $server->components } ) { # # print join( "\n", $component->name, $component->OKStatus ), "\n"; # # } # #}
Subject: cpan.xml
Download cpan.xml
text/xml 12.9k

Message body is not shown because it is too large.

Subject: What Data::Visitor::Callback is used for in XML::Rabbit
Download (untitled) / with headers
text/plain 1.1k
If you look at line 137 of lib/XML/Rabbit/Trait/ you can see that I use it to figure out which classes are specified in a Moose type-constraint. If you have an easier way of figuring out that I'd be more than willing to use something else than Data::Visitor::Callback (D::V::C for now) to solve this challenge. In fact, D::V::C has some issues with hash seed randomization on perl 5.17.6, which I documented in a failing test to the author of D::V::C. You can see it here: The challenge is that we need to traverse the data structures of the type-constraint to figure out what classes are used. To just do string testing is prone to issues as it would cause problems when a bare string in a TC is NOT a class, as identified by Moose. If the Moose TC system had a way to tell us this without having to use D::V::C then I would of course use that in a jiffy. One obvious way to improve on this would be to use an iteration-based approach instead of recursion which is used in D::V::C. But that would be just about the same as reimplementing D::V::C, and I'd like to avoid that. Suggestions?
Download (untitled) / with headers
text/plain 343b
I've gotten rid of Data::Visitor::Callback, and the type constraint class resolution should now be much simpler. chromatic contributed a fix that I improved. You can find it here: I've released 0.3.0 to CPAN just now which should solve the problem.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to