Newsgroup: it.comp.lang.perl
Titolo: Il fantasma.

Ho sentito dire che esisterebbe da qualche parte  un compilatore per gli script  Perl. 
C'è qualche fondamento di realta in questa cosa o è frutto di pura fantasia?  
-- 
Qui si usa Linux.
http://www.puppylinux.org
http://digilander.libero.it/puppylinuxitalia/
07/11/2009 ore 22:21:57

 C'ï¿œ qualche fondamento di realta in questa cosa o ï¿œ frutto di pura fantasia?  
Bisogna vedere cosa intendi per /compilatore/.
Se ti aspetti qualcosa che trasformi l'intero programma in un eseguibile 
binario nativo che possa funzionare senza l'interprete perl, ï¿œ frutto di 
pura fantasia, almeno attualmente (in passato dei tentativi sono stati 
fatti, ma il loro sviluppo ï¿œ cessato).
Esistono delle applicazioni che generano un eseguibile, che perï¿œ ï¿œ 
soltanto un bundle dell'applicazione e degli eventuali moduli da essa 
utilizzati (e puï¿œ includere l'interprete perl stesso).
Quando viene lanciato, l'eseguibile si limita poi a scompattare i 
sorgenti e ad eseguire l'applicazione tramite perl.
PerlApp e PAR funzionano cosï¿œ.

 C'ï¿œ qualche fondamento di realta in questa cosa o ï¿œ frutto di pura fantasia?  
http://search.cpan.org/~nwclark/perl-5.8.9/utils/perlcc.PL
"The code generated in this way is not guaranteed to work. The whole 
codegen suite (perlcc included) should be considered *very* 
experimental. Use for production purposes is strongly discouraged."

 
http://search.cpan.org/~nwclark/perl-5.8.9/utils/perlcc.PL
Quando parlavo di /sviluppo cessato/ mi riferivo proprio a perlcc: la 
sua ultima versione ï¿œ del 2003 e in perl 5.10 non viene piï¿œ neanche incluso.
 > "The code generated in this way is not guaranteed to work. The whole
 > codegen suite (perlcc included) should be considered *very*
 > experimental. Use for production purposes is strongly discouraged."
Ottima precisazione ;-)

 PerlApp e PAR funzionano così.
Li lasciamo a più tardi.
Stamattina il problema è questo:
-----------------------
#!/usr/bin/perl
$b=-A "/root/nomefile";
open "mn","| Xdialog --title 'Accesso a file' --msgbox '$b' 00 00";
close "mn";
-----------------------
Esce un numero decimale che dovrebbe indicare il tempo trascorso
dall' ultimo accesso a /root/nomefile ma che non riesco a tradurre 
in ore minuti e secondi. How to?
Grazie mille.
-- 
Qui si usa Linux.
http://www.puppylinux.org
http://digilander.libero.it/puppylinuxitalia/
10/11/2009 ore 10:55:42

 Grazie mille.
Mi sembra che avessi giï¿œ risposto ad una domanda simile qui sul ng in 
passato...
Questa ï¿œ una soluzione che fa uso di Date::Calc, altrimenti per una 
soluzione con i calcoli a manella, ti rimando al mio vecchio messaggio.
---
use strict;
use warnings;
use File::stat;
use Date::Calc qw(Delta_DHMS Time_to_Date);
my $filename = '/path/to/file.txt';
printf
qq[Sono trascorsi %s giorni, %s ore, %s minuti e %s secondi dall'ultimo 
accesso al file $filename],
Delta_DHMS( Time_to_Date( stat($filename)->atime ), Time_to_Date(time) )
---
Sono trascorsi 411 giorni, 19 ore, 57 minuti e 30 secondi dall'ultimo 
accesso al file /path/to/file.txt

 Bisogna vedere cosa intendi per /compilatore/.
Non c'entra con la domanda iniziale, ma anche l'interprete perl in 
realtï¿œ compila il codice sorgente, vero? Utilizza una sorta di bytecode?
E.

?manu* wrote:

Sï¿œ e sï¿œ, anche se a rigore quello che viene prodotto dal compilatore 
perl non ï¿œ bytecode(*) ma un /parse tree/, che viene poi passato allo 
/esecutore/ (o virtual machine), che lo esegue.
Ove necessario, la fase di esecuzione viene sospesa per richiamare di 
nuovo la fase di compilazione (su specifiche porzioni di codice, in 
seguito a eval, do, require...), e poi viene ripresa.
Quindi, nel caso generale, la fase di compilazione e quella di 
esecuzione di un programma Perl, possono alternarsi l'una all'altra fino 
alla terminazione del programma (invece nei casi piï¿œ semplici c'ï¿œ la 
compilazione di tutto il codice all'inizio e poi l'esecuzione senza 
interruzioni fino alla terminazione).
(*)
Il bytecode puï¿œ essere prodotto dai cosiddetti compiler-backend come 
B::Bytecode.

 /esecutore/ (o virtual machine), che lo esegue.
Ok, ti ringrazio. Approfitto a chiedere ancora. Ma i files compilati 
dove vengono memorizzati? Perchï¿œ immagino che la compilazione non 
avvenga ad ogni esecuzione.
E.

?manu* wrote:

Invece ï¿œ proprio quello che avviene ;-)
Almeno nella maggior parte dei casi.
Volendo ï¿œ possibile generare bytecode su file e poi eseguire tale file 
(anzi, addirittura di default perl quando deve caricare un modulo ne 
cerca prima la versione compilata (.pmc) e, solo se non la trova, cerca 
poi la versione /sorgente/ (.pm)).
Ma in genere non lo si fa, perchï¿œ il guadagno velocistico non ï¿œ 
particolarmente rilevante (peraltro il bytecode generato non ï¿œ portabile).
Quello che si fa invece, quando si vuole evitare di ricompilare ogni 
volta un programma, ï¿œ utilizzare un cosiddetto /ambiente persistente/, 
ovvero un ambiente che non soltanto mantiene in memoria il programma 
compilato, ma lo mantiene addirittura /in esecuzione/ (in pratica 
all'interno di un loop in attesa della chiamata).
Questi ambienti in molti casi offrono invece degli incrementi 
prestazionali ragguardevoli.
Tra di essi ci sono PPerl, mod_perl, FastCGI ed altri.

 Tra di essi ci sono PPerl, mod_perl, FastCGI ed altri.
Ah ecco. Siccome il mio codice gira su un webserver, ï¿œ probabile che sia 
quest'ultimo a mantenere una cache del codice compilato. Perchï¿œ nel mio 
caso ï¿œ palese che la prima esecuzione dopo una modifica ci mette molto 
piï¿œ tempo delle successive...
Inoltre sto usando il Template Toolkit (forse me lo avevi suggerito 
proprio tu?). Mi pare di aver letto da qualche parte che anche i 
templates vengono precompilati per velocizzare l'esecuzione.
Ti chiedo questo perchï¿œ il sito che sto aggiustando non ï¿œ proprio una 
scheggia nel rispondere... e vorrei cercare di capire dov'ï¿œ il problema.
E.

?manu* wrote:

Allora, la questione ï¿œ un po' piï¿œ complessa (ma non troppo ;-)
La persistenza della web application e la precompilazione dei template 
TT sono due cose del tutto distinte. Inoltre la prima va attivata 
esplicitamente, altrimenti non ce l'hai; il caching dei template invece 
ï¿œ automatico (in memoria), ma puoi comunque migliorarlo.
Partiamo dai template TT (sï¿œ, te l'avevo suggerito io TT ;-)
Qui fortunatamente la cosa ï¿œ molto semplice.
Come dicevo, i template compilati vengono automaticamente cachati in 
memoria (forse ï¿œ questo che velocizza la tua applicazione dopo il primo 
accesso), ma di default vengono rigenerati (alla richiesta successiva) 
se sono piï¿œ vecchi di 1 secondo.
Per aumentarne il tempo di vita, basta istanziare l'oggetto TT con il 
seguente parametro (tra gli altri):
my $template = Template->new({
     STAT_TTL => 3600,  # In secondi
});
ma ovviamente fallo solo in produzione, non durante lo sviluppo.
Opzionalmente con questi ulteriori parametri:
my $template = Template->new({
     COMPILE_DIR => '/tmp/ttc', # Dir. dove metterï¿œ i template compilati.
     COMPILE_EXT => '.ttc'      # Estensione template compilati.
});
avrai la compilazione dei template su disco, in maniera completamente 
automatica e trasparente. Finito.
---
Per la persistenza della web application ï¿œ un po' piï¿œ complicato, nï¿œ 
sono in grado di darti indicazioni precise, non sapendo nulla della tua 
applicazione e nemmeno del web server che stai usando.
Assumendo che si tratti di un'applicazione che usa CGI.pm e che gira su 
Apache 2.x, la soluzione piï¿œ semplice ï¿œ probabilmente ModPerl::Registry, 
che (una volta installato ovviamente) si attiva semplicemente 
configurando Apache come spiegato qui:
http://search.cpan.org/~pgollucci/mod_perl-2.0.3/docs/api/ModPerl/Registry.pod
La tua applicazione non richiederï¿œ modifiche, perï¿œ per funzionare in un 
ambiente persistente deve essere scritta /bene/, ovvero deve 
inizializzare (o finalizzare) tutte le variabili globali (se vi sono), 
usare appropriatamente (o non usare per niente) i blocchi BEGIN, non 
avere cicli nei reference e una serie di altre cosette che ogni 
programma ben scritto dovrebbe rispettare.
In assenza di questa disciplina, una volta attivata la persistenza, si 
potrebbe avere un comportamento diverso del programma e/o dei memory-leak.
Detto questo, magari il collo di bottiglia ï¿œ da tutt'altra parte (ad es. 
nell'eventuale DBMS di back-end).
In effetti ï¿œ strano che la tua applicazione sia lenta: non dovrebbe 
esserlo, anche senza persistenza (a meno che non faccia cose veramente 
complesse e/o giri su hardware limitato).
Dovresti fare un po' di profiling per isolare i colli di bottiglia:
http://search.cpan.org/dist/Devel-NYTProf/
P.S.
Anche tu avresti dovuto aprire un nuovo thread ;-)
Ciao!

 se sono piï¿œ vecchi di 1 secondo.
Scusa, sono stato impreciso: non ï¿œ che i template compilati vengano 
rigenerati sempre: avviene solo se ci sono state variazioni ai template 
/sorgente/.
Mentre il controllo sulle variazioni viene fatto sempre (trascorso un 
secondo).
Ed ï¿œ questa elaborazione che si puï¿œ limitare, giocando sul parametro 
STAT_TTL.

 STAT_TTL.
Ma questo avviene anche tra chiamate successive la mio CGI? Perchï¿œ 
tipicamente ad ogni esecuzione del CGI il template viene utilizzato una 
volta sola, quindi per me ï¿œ inutile una cache in memoria. A meno che il 
mod_perl non sia in grado di mantenere questa informazione tra una 
chiamata e l'altra, questo ancora non l'ho capito bene.
La possibilitï¿œ di cache-are i template su disco mi sembra molto 
interessante. Proverï¿œ ad applicarla quando il codice sarï¿œ piï¿œ assestato.
A proposito, come faccio a valutare i tempi di esecuzione di un CGI?
E.

 interessante. Prover� ad applicarla quando il codice sar� pi� assestato.
Si puo`, sempre con Template:
<
http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template.pm#Cachi
ng_and_Compiling_Options>
La direttiva che ti interessa e` COMPILE_DIR
s.
-- 
Stefano Rodighiero      |  
http://www.stefanorodighiero.net
mailto:
lar...@perl.it
   |  Italian Perl Mongers: 
http://www.perl.it

 A proposito, come faccio a valutare i tempi di esecuzione di un CGI?
Ancora non ci hai detto se sei su Apache o no :-)
Tirando pertanto ancora a indovinare: leggi bene quest'articolo:
http://perl.apache.org/docs/1.0/guide/performance.html
in particolare questo capitolo:
http://perl.apache.org/docs/1.0/guide/performance.html#Benchmarking_Applications
Inoltre puoi testare la tua applicazione anche dalla command line ed 
utilizzare quindi facilmente Devel::NYTProf o altro tool di profiling 
per Perl:
http://search.cpan.org/~lds/CGI.pm-3.48/lib/CGI.pm#DEBUGGING
(*) Poi ci sono delle politiche di refresh dei processi (in base al 
numero di richieste servite ecc.) che anch'esse sono customizzabili, ma 
fanno parte del fine-tuning diciamo.

Il Tue, 10 Nov 2009 12:48:34 GMT
Emanuele Zeppieri <ema...@tiscali.itsnip_here.invalid> ha scritto:
|
|
|
|Questa è una soluzione che fa uso di Date::Calc, altrimenti per una 
|soluzione con i calcoli a manella, ti rimando al mio vecchio messaggio.
|
|---
|
|use strict;
|use warnings;
|
|use File::stat;
|use Date::Calc qw(Delta_DHMS Time_to_Date);
|
|my $filename = '/path/to/file.txt';
|
|printf
|qq[Sono trascorsi %s giorni, %s ore, %s minuti e %s secondi
dall'ultimo |accesso al file $filename\n],
|Delta_DHMS( Time_to_Date( stat($filename)->atime ),
Time_to_Date(time) ) |
|---
|
|Aridaje co' 'sta shell! :-)
Sul terminale funziona, ma non riesco a mettere il risultato in una
variabile per poterlo usare con Xdialog o altro.
------------------------------
$a=`qq[Sono trascorsi %s giorni, %s ore, %s minuti e %s secondi
dall'ultimo |accesso al file $filename\n],
|Delta_DHMS( Time_to_Date( stat($filename)->atime ),
Time_to_Date(time) )`  i doppi apici a quanto pare qui non bastano. 
------------------------------
Per completare il quadro: non ho nemmeno idea di come ripescare
dal server il tuo vecchio thread sull' argomento. 
Saluti.
-- 
Qui si usa Linux.
http://www.puppylinux.org
http://digilander.libero.it/puppylinuxitalia/
14/11/2009 ore 10:58:56

 dal server il tuo vecchio thread sull' argomento. 
Google Groups e un po' di pazienza:
http://groups.google.gp/group/it.comp.lang.perl/browse_thread/thread/79f925d265359e2e