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
>
