Práctica: Modificaciones a PerlSSH

Práctica: Modificaciones a `PerlSSH`

Puede encontrar una versión modificada que proporciona soluciones a algunas de estas cuestiones en GRID-Machine-0.07.tar.gz .

Modifique el módulo IPC::PerlSSH para que el tratamiento de las operaciones permitidas en el servidor se estructure según un hash similar a este:

  my %handler = (
    QUIT    => sub {  exit( 0 ) },
    EVAL    => \&revaluate,
    STORE   => \&rstore,
    CALL    => \&rcall,
    DUMP    => \&rdump,
    INSTALL => \&rinstall,
  );

  while( 1 ) {
     my ( $operation, @args ) = read_operation( $readfunc );

     my $handler = $handler{$operation};
     if (defined($handler)) {
       $handler->(@args);
       next;
     }

     send_operation( $writefunc, "DIED", "Unknown operation $operation\nARGS: @args" );
  }

¿Que relación existe entre una tabla de saltos y una aproximación OOP al problema de los condicionales en cascada? ¿Que solución es mejor?

¿Que ocurre en IPC::PerlSSH si en medio de la ejecución de una rutina remota se ejecuta un print?

Como se comenta en el apartado anterior el hecho de que los códigos ejecutados en un servicio EVAL son ejecutados en una subrutina (líneas 95 y 101) afecta al ámbito de una declaración ours:

 92     if( $operation eq "EVAL" ) {
 93        my $code = shift @args;
 94
 95        my $subref = eval "sub { $code }";
 96        if( $@ ) {
 97           send_operation( $writefunc, "DIED", "While compiling code: $@" );
 98           next;
 99        }
100
101        my @results = eval { $subref->( @args ) };
102        if( $@ ) {
103           send_operation( $writefunc, "DIED", "While running code: $@" );
104           next;
105        }
106
107        send_operation( $writefunc, "RETURNED", @results );
108        next;
109     }

¿Cómo puede solucionarse el problema de la ''modificación del ámbito''? ¿Es posible seguir declarando variables globales dentro de un eval? Comente la siguiente sesión con el depurador:

nereida:~/LEyapp> perl -wde 0

Loading DB routines from perl5db.pl version 1.28
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1):   0
  DB<1> x eval '{ use strict; our $x = 4 }'
0  4
  DB<2> x eval '{ use strict; print $x  }'
Variable "$x" is not imported at (eval 8)[(eval 7) line 1.
0  undef
  DB<3> x eval '{ use strict; our $x; print "$x\n"  }'
4
0  1

Dado que el ''programa'' principal que se ejecuta en la máquina remota se obtiene a partir de una cadena los mensajes de error en el servidor contienen un número de línea y un fichero poco explicativos. ¿Cómo hacer para hacer que el número de línea y el fichero que se informan seas mas exactos?

La depuración de un programa que se obtiene desde una cadena y que es evaluado es mas complicada que la de un programa guardado en un fichero. ¿Sabría explicar la causa? ¿Es posible guardar el código en módulos, comprobar su correcta compilación y enviarlos después? Consulte los módulos Module::Which y Module::ScanDeps:

nereida:~/src/perl/testing> perl -wde 0
main::(-e:1):   0
  DB<1> use Module::Which
  DB<2> $info = which('Module::Which', 'YAML')
  DB<3> x $info
0  HASH(0x858f0f0)
   'Module::Which' => HASH(0x85ab4cc)
      'base' => '/usr/local/share/perl/5.8.8'
      'path' => '/usr/local/share/perl/5.8.8/Module/Which.pm'
      'pm' => 'Module::Which'
      'version' => 0.0205
   'YAML' => HASH(0x883be60)
      'base' => '/usr/local/share/perl/5.8.8'
      'path' => '/usr/local/share/perl/5.8.8/YAML.pm'
      'pm' => 'YAML'
      'version' => 0.62

El módulo Module::ScanDeps permite el análisis de dependencias. Provee el ejecutable scandeps.pl:

nereida:~/src/perl/YappWithDefaultAction/examples> scandeps.pl Rule6.pm
'AutoLoader'           => '5.63',
'Cwd'                  => '3.18',
'File::Spec::Unix'     => '1.5',
'File::Spec'           => '3.18',
'Parse::Eyapp::YATW'   => 'undef',
'List::MoreUtils'      => '0.21',
'Parse::Eyapp::Base'   => 'undef',
'Parse::Eyapp::Node'   => 'undef',
'Parse::Eyapp::Driver' => '1.069577',

El módulo provee la función bind que provee una interfaz local a la máquina remota. ¿Que desventajas y ventajas le ve a este diseño de la API?
¿Que pasos habría que dar para dotar a IPC::PerlSSH de un servicio de llamada de procedimiento remota (RPC) que no estuviera limitado a argumentos de tipo ''cadena''? Esto es que se admitieran en el cliente Perl llamadas al servidor Perl con estructuras anidadas (vea los ejemplos examples/nested.pl y examples/nested2.pl en la distribución de GRID-Machine-0.07.tar.gz ?
Al ejecutar este fragmento de código:
```
pp2@nereida:~/src/perl/GRID_Machine/examples$ sed -ne '18,27p' nested.pl | cat -n
 1  $machine->sub(
 2    rmap => q{
 3      my $f = shift; # function to apply
 4      map { $f->($_) } @_;
 5    },
 6  );
 7
 8  my $cube = sub { $_[0]**3 };
 9  my @cubes = $machine->rmap($cube, 1..3)->Results;
10  { local $" = ','; print "(@cubes)\n"; }
```
se obtiene la salida:
```
pp2@nereida:~/src/perl/GRID_Machine/examples$ nested.pl
Linux orion 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686
(1,8,27)
```
Observe que la función pasada como parámetro sub { $_[0]**3 } es definida en la máquina local y llamada en la remota.
Obsérve el programa Makefile.PL en la distribución GRID-Machine-0.07.tar.gz . ¿Que hace la función MY::postamble?
Añada métodos put get a los objetos GRID::Machine que permita la copia de ficheros entre las dos máquinas. El método put permite transferir ficheros de la máquina local a la máquina remota. Por ejemplo:
```
$beo->put([ qw(file1 file2 file3) ]);
```
copiaría los ficheros file1, file2 y file3 en el directorio actuál en la máquina remota. Una llamada como:
```
$beo->put([ qw(file1 file2 file3) ], 'path');
```
copiaría los ficheros file1, file2 y file3 en el directorio path de la máquina remota. Una fuente de inspiración puede ser el código del módulo http://search.cpan.org/~ivan/Net-SCP/ .
Use File::Spec para escribir código independiente del sistema operativo.

Casiano Rodríguez León
2010-03-22