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

People
Owner: ROBINS [...] cpan.org
Requestors: arfreitas [...] cpan.org
Cc:
AdminCc:

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



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 rabbit.pl cpan.xml Loading DB routines from perl5db.pl version 1.37 Editor support available. Enter h or 'h h' for help, or 'perldoc perldebug' for more help. main::(rabbit.pl:7): my $file = shift; DB<1> n main::(rabbit.pl:9): my $mon_conf = Siebel::Monitor::Config->new( file => $file ); DB<1> main::(rabbit.pl:11): print join( "\n", main::(rabbit.pl:12): $mon_conf->gateway, $mon_conf->enterprise, $mon_conf->srvrmgrPath ), main::(rabbit.pl:13): "\n"; DB<1> spbrsiegw01 sbl_crm_prd C:\Siebel\8.1\Client_1\BIN main::(rabbit.pl:15): print Dumper( $mon_conf->servers ), "\n"; DB<1> Data::Visitor::Callback::callback(C:/Perl/site/lib/Data/Visitor/Callback.pm:248): 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.

Subject: rabbit.pl
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

Message body is not shown because it is too large.

Subject: What Data::Visitor::Callback is used for in XML::Rabbit
If you look at line 137 of lib/XML/Rabbit/Trait/XPath.pm 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: https://github.com/nothingmuch/data-visitor/pull/2 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?
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: https://github.com/robinsmidsrod/XML-Rabbit/commit/7fcaf2fa0a18231e1336cc64bd0937feea92b86e I've released 0.3.0 to CPAN just now which should solve the problem.