RE: Problem to execute "sidecar" Perl scripts when compiling POE::Component::Resolver 0.912 with PAR

Hi Rocco,

thanks a lot (also for the refactoring improvement). Version 0.913 works great with PAR now :-).

At present only for the records: IMHO the PoCo::Generic alt_fork implementation might need a similar fix
[no actual need from my side though, but somebody may stumble on this in the future].

Cheers,
	Markus

-----Original Message-----
From: Rocco Caputo [mailto:[email protected]] 
Sent: Saturday, July 30, 2011 9:56 AM
To: POE Mailing List
Cc: Markus Jansen
Subject: Re: Problem to execute "sidecar" Perl scripts when compiling POE::Component::Resolver 0.912 with PAR

Thanks for the clarification, Markus.  I've applied a modified version of your patch as change 82af41c8ab2dd061acd7deb9979fa6cb5c4725ae.  You can review it online at https://github.com/rcaputo/poe-component-resolver

--
Rocco Caputo <[email protected]>

On Jul 29, 2011, at 05:01, Markus Jansen wrote:

> ... tiny correction of ^$X listed below, sorry for the typo ...
> /Markus
> 
> -----Original Message-----
> From: Markus Jansen [mailto:[email protected]]
> Sent: Friday, July 29, 2011 10:40 AM
> To: Rocco Caputo; POE Mailing List
> Subject: RE: Problem to execute "sidecar" Perl scripts when compiling 
> POE::Component::Resolver 0.912 with PAR
> 
> Hi Rocco,
> 
> thanks for coming back on this issue. Using the POE::Component::Resolver::Sidecar module is a good idea, though IMHO Module::ScanDeps should know that the module is needed via the use of "\&POE::Component::Resolver::Sidecar::main" for Windows.
> 
> The main problem is that while the [suboptimal] Windows solution would work for PAR, the standard [preferred] Unix solution does not for a number of reasons:
> - within PAR, 
> 	$^X  is set to "perl"
> 	@INC is set to [ "<par_unpack_path>/inc/lib", 
> "<par_unpack_path>/inc/", CODE(......), CODE(......) ]
> 
> - a "perl" executable does not exist inside the packed code (that is, at runtime under <par_unpack_path>)
> 	- instead, there is a "limited Perl interpreter"
> 	- one of the limits is that this interpreter cannot execute perl 
> scripts via -e
> 
> Each of the above effectively spoils the intended "$^X -I @INC -M...Sidecar -e '...Sidecar->main()'", i.e. the Sidecar execution via exec().
> 
> Due to the lack of -e support, one has to put
> 	use POE::Component::Resolver::Sidecar;
> 	POE::Component::Resolver::Sidecar->main();
> into some ...Sidecar.pl file, and get that called.
> 
> In the meantime, I have found that there are at least two ways to pack the above mini-script into a PAR executable (whether using the experimental --reuse switch or not is one of the details) and to get it called; hence, I would not like to dictate PAR users which of those ways to take, nor any naming conventions regarding the intermediate Sidecar.pl perl script.
> 
> As a result, supplying the possibility to specify $sidecar_program seems to me the only general and lightweight way forward.
> Perhaps the change should come with a comment that the intended use is for PAR and similar modules, and should be used by experts who think they know what they are doing :-).
> 
> Anyhow, my patch works great in production with the latest/greatest 2 PAR versions.
> 
> Best regards,
> 	Markus
> 
> 
> -----Original Message-----
> From: Rocco Caputo [mailto:[email protected]]
> Sent: Friday, July 29, 2011 6:54 AM
> To: POE Mailing List
> Cc: Markus Jansen
> Subject: Re: Problem to execute "sidecar" Perl scripts when compiling 
> POE::Component::Resolver 0.912 with PAR
> 
> Hi, Markus.
> 
> It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it.  Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects "use" statements in the source.
> 
> Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar?  A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here.
> 
> commit 638cd9e616a5b4ffbf413672784f41896de97430
> Author: Rocco Caputo <[email protected]>
> Date:   Fri Jul 29 00:44:00 2011 -0400
> 
>    Load the POE::Component::Resolver::Sidecar class.
> 
>    The presence of this module is requested on MSWin32.  Resolves
>    rt.cpan.org ticket 69172, reported by Gabor Szabo.
> 
> diff --git a/lib/POE/Component/Resolver.pm 
> b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644
> --- a/lib/POE/Component/Resolver.pm
> +++ b/lib/POE/Component/Resolver.pm
> @@ -9,6 +9,8 @@ use Time::HiRes qw(time);  use Socket 
> qw(unpack_sockaddr_in AF_INET AF_INET6);  use Socket::GetAddrInfo 
> qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV);
> 
> +use POE::Component::Resolver::Sidecar;
> +
> use Exporter;
> use base 'Exporter';
> our (@EXPORT_OK) = qw(AF_INET AF_INET6);
> 
> 
> --
> Rocco Caputo <[email protected]>
> 
> 
> On Jul 15, 2011, at 06:17, Markus Jansen wrote:
> 
>> Hi Rocco,
>> 
>> based on the excellent input I got so far from you and Steffen, I 
>> have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-).
>> 
>> The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed.
>> Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913.
>> 
>> Best regards,
>> 
>>        Markus
>