[Roma.pm] perl scripting

Flavio Poletti polettix at gmail.com
Tue Mar 22 04:56:12 PDT 2011


Ciao,

    di sicuro un approccio modulare è quello da preferire. Non credo di
capire benissimo i problemi che stai ponendo:

* gestione delle variabili sintattiche
* inizializzazione delle variabili
* gestione degli argomenti

Puoi fare un esempio più preciso dei tre tipi di problemi? In particolare,
il terzo problema non mi sembra "reale", ci sono dei modi per impostare lo
stack dell'interprete perl in modo che la chiamata alla funzione "veda" dei
parametri in ingresso dentro @_ come se fosse stata chiamata da un'altra sub
perl.

Ciao,

    Flavio.


2011/3/21 Leo Cacciari <leo.cacciari at gmail.com>

> Il 03/21/2011 07:40 PM, Flavio Poletti ha scritto:
> > Ciao Leo,
> >
> >     se capisco bene (ma è molto probabile che non sia così!) tu stai
> > realizzando un sistema che al suo interno deve dare la possibilità di
> > inserire delle estensioni scritte in Perl.
> >
> Esattamente :)
> > Parlando di compilazione, ecc. immagino che il sistema sia scritto in
> > C o C++ o altro linguaggio che alla fine genera un eseguibile di
> > qualche tipo, nel quale viene anche inclusa la libreria
> C++
> > libperlxxx del caso che gestisce l'interprete perl. Nel tuo flusso di
> > programma ci sarà ad un certo punto (o in vari punti) una chiamata
> > verso un gestore che si occupa di caricare le estensioni e di
> > eseguirle sui dati di interesse
> L'idea era di avere un interprete perl embedded i comandi a quel punto
> possono ridursi a "load" e "run", più eventualmente un sistema di
> scheduling come suggerito da Fabio.
>
>
> >
> > Stiamo parlando di questo?
> >
>
> Come vedi sì :)
>
> Quando parlo di "compilazione" intendo la compilazione Perl. In altre
> parole: se inizializzo un interprete ogni volta che eseguo uno script lo
> script stesso deve essere analizzato e compilato in bytecode ogni volta
> (senza contare l'overhead dovuto all'inizializzazione stessa
> dell'interprete!). L'alternativa è inizializzare un interprete al primo
> caricamento di uno script ed usarlo per tutti gli script successivamente
> caricati.
>
> Questo secondo approccio, però, pone due problemi. Il primo è quello di
> evitare collisioni di nomi in script diversi. Il secondo è quello di
> avere un unico entry point per eseguire uno script dopo averlo caricato.
> Stavo pensando di trasformare lo script
>
> #!/usr/bin/perl -w
> # script foo/bar/foobar.pl
>
> use vars qw($a);
>
> sub foo() {
> }
>
> sub bar() {
>
> }
>
> $a = 42;
> $b = foo($a);
>
> # etc...
>
> in qualcosa come
>
> package Foo::Bar::Foobar;
>
> use vars qw($a);
>
> sub foo() {
> }
>
> sub bar() {
>
> }
>
>
> sub main() {
>  $a = 42;
>  $b = foo($a);
>   # etc
> }
>
> cosicché, per eseguire lo script basta invocare Foo::Bar::Foobar::main
>
> Ovviamente ci sono molti problemi in questo approccio, tra quelli che mi
> saltano immediatamente agli occhi sono la gestione delle variabili
> sintattiche, l'inizializzazione delle variabili che andrebbe ripetuta ad
> ogni esecuzione dello script e infine la gestione degli argomenti dello
> script...
>
> > Ciao,
> >
> >     Flavio.
> >
> >
> >
>
> --
> Leo Cacciari
> Aliae nationes servitutem pati possunt populi romani est propria libertas
>
> _______________________________________________
> Roma mailing list
> Roma at pm.org
> http://mail.pm.org/mailman/listinfo/roma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/roma/attachments/20110322/df1602ec/attachment.html>


More information about the Roma mailing list