🚀 go-pugleaf

On 2010-01-25, menth0l <menth0l@remove.this.o2.pl> wrote:
> Spotkałem się z pewnym problemem podczas uruchamiania skompilowanych 
> skryptów perla do postaci .exe za pomocą perlsvc. Wygląda to tak jakby 
> exec nie widział deklaracji importu modułów (choć sam skrypt działa 
> poprawnie). 

Bo tak faktycznie może być.

[...]
> Dodatkowo 
> dziwne jest to, że sprawa wydaje się losowa. W tym samym module importuje 
> także Class::Std, XML::TreePP oraz inne i nie ma z nimi problemu... Inne 
> moduły na które trafiłem a które sprawiły podobny problem (brak 
> widoczności importu) to Switch oraz TryCatch.
>
> Jak to ugryźć?

Dostarczać skrypt albo sportować program na język kompilowany.

> No i z czego wynika ta wybiórczość widoczności modułów?

Z konstrukcji wybranego kompilatora Perla. Jak sobie wyobrażasz że
miałby działać? Musi sparsować kod i zamienić go na postać wykonywalną.
A co zrobić z importami (use, require)? To samo. A jeśli coś jest
importowane za pomocą eval(), które kleiło stringi? Albo jakiejś innej
niestandardowej metody? Jak kompilator ma ocenić że ten moduł należy
dołączyć a tamtego nie?

-- 
Secunia non olet.
Stanislaw Klekot

Dnia 25-01-2010 o 19:30:09 menth0l <menth0l@remove.this.o2.pl> napisał(a):

> Spotkałem się z pewnym problemem podczas uruchamiania skompilowanych
> skryptów perla do postaci .exe za pomocą perlsvc. Wygląda to tak jakby
> exec nie widział deklaracji importu modułów (choć sam skrypt działa
> poprawnie).
>
> Problem pojawił się podczas próby definicji klasy abstrakcyjnej za pomocą
> modułu Class::Interface. Przykładowy kod:
>
> package ClassFoo;
> use Class::Interface;
> &abstract;
>
> sub foo;
> sub bar;
>
> oraz
>
> package ClassBar;
> use Class::Interface;
> &extends(ClassFoo);
>
> sub foo { print 'foo'; }
> sub bar { print 'bar'; }
>
> działa znakomicie w wersji skryptowej, tj. wymusza implementacje metod
> abstrakcyjnych. Tymczasem wersja skompilowana dochodząc do metody  
> abstract
> () rzuca błędem w stylu "Module ClassFoo doesn't use Class::Interface" co
> jest tyle dziwne, że deklaracja importu jest linijkę wyżej. Dodatkowo
> dziwne jest to, że sprawa wydaje się losowa. W tym samym module importuje
> także Class::Std, XML::TreePP oraz inne i nie ma z nimi problemu... Inne
> moduły na które trafiłem a które sprawiły podobny problem (brak
> widoczności importu) to Switch oraz TryCatch.
>
> Jak to ugryźć? No i z czego wynika ta wybiórczość widoczności modułów?

Z dokumentacji:


However, PerlSvc does not include modules that are mentioned in a  
variable. For example, in a script with the following line:
     require $module;

PerlSvc does not include the module identified by $module. To explicitly  
include this module, rebuild the PerlSvc using the --add list command-line  
switch, where list is a semicolon-delimited list of the modules you want  
to explicitly include.

Czyli perlsvc nie widzi tych wyoływanych przez zmienne.
A jakbyś zajrzał do Class::Interface i metody abstract, to tam masz

eval "use $caller";

Więc zgodnie z instrukcją spróbuj budować NTService używając --add (w tym  
'okienkowym' interfejsie do perlsvc i perapp możesz wyklikać potrzebne  
moduły)

Jak to nie zadziała, to z doświadczenia wiem, że łatwiej się diagnozuje  
takie problemy z kompilacją, próbując robić zwykłe egzeki - używając  
perlapp, a dopiero jak to działa, to budować usługi windowsowe używając  
perlsvc

Pozdrawiam
-- 
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas

> Wiec zgodnie z instrukcja sprobuj budowac NTService uzywajac --add (w tym  
> 'okienkowym' interfejsie do perlsvc i perapp mozesz wyklikac potrzebne  
> moduly)

Dzięki za odzew. Próbowałem kompilacji zarówno z parametrem:
--add Class::Interface
jak i:
-- add Class::Interface::

Niestety bez pozytywnych rezultatów. W dokumentacji oprócz opcji --add
nie znalazłem nic ciekawego więc rozumiem, że przysłowiowa dupa? Czy
może coś jeszcze da się zrobić?

--
pozdrawiam,
menth0l

Dnia 26-01-2010 o 09:15:19 menth0l <cementos@gmail.com> napisał(a):

>> Wiec zgodnie z instrukcja sprobuj budowac NTService uzywajac --add (w  
>> tym 'okienkowym' interfejsie do perlsvc i perapp mozesz wyklikac  
>> potrzebne moduly)
>
> Dzięki za odzew. Próbowałem kompilacji zarówno z parametrem:
> --add Class::Interface
> jak i:
> -- add Class::Interface::
>
> Niestety bez pozytywnych rezultatów. W dokumentacji oprócz opcji --add
> nie znalazłem nic ciekawego więc rozumiem, że przysłowiowa dupa? Czy
> może coś jeszcze da się zrobić?

A jesteś pewien, że to właśnie Class::Interface brakuje? IMO, to to akurat  
jest brane, tylko któryś z Twoich własnych pakietów nie...

Sprawdź, co tak naprawdę perlsvc próbuje wrzucić do egzeka - najepiej w GUI
(http://docs.activestate.com/pdk/8.1/index.html?page=PerlSvc.html%23perlsvc_name)
  - tam masz ładne drzewko, jeśli nie, to dodal do argumentów
--explain all

Tylko to straszną ilość informacji wywali, będziesz mieć trochę do  
analizy...

Być może, poza wskazaniem konkretnego modułu (czy przez --add, czy w  
drzewku w GUI), będziesz musiał podać ścieżkę do jego lokalizacji ,bo  
(szczególnie przy własnych modułach) nie leży w @INC (wtedy użyj --lib,  
lub okienka Module Search Patch w zakładce Main).

Uruchamiaj perlsvc w trybie verbose i patrz, co on Ci próbuje powiedzieć.

I jak już pisałem wcześniej - jak masz problemy z kompilacją, to ćwicz na  
perlapp, a nie perlsvc - kompilator i narzędzia do budowania mają  
identycznie działające, tyle, że perlsvc dodaje trochę "magii" związanej  
ze secyfiką usług windowsowych, co może utrudnić lokalizację problemu. Jak  
już pod perlappem się kompiluje i działa, to wtedy możesz popróbować  
zrobić NT Service - wtedy jak coś nie działa, to przynajmniej wiadomo  
bliżej, gdzie szukać ;-)

W ogóle za robienie usług to ja bym się nie zabierał, nie opanowawszy  
dobrze narowów podstawowego narzędzia do robienie ezeków - toto ma trochę  
pułapek...

Pozdrawiam
-- 
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas