[Perl] FileHandles en Windows....

[Rodrigo Gallardo]

Alejandro G. Bedoya writes:
 > >Antes de continuar, te vuelvo a sugerir echarle un ojo a la funci=F3=
n tie de
 > >Perl (perldoc -f tie, o si est=E1s en Windows, debe estar dentro de=
 la
 > >p=E1gina de ayuda de perlfunc). Esto te permite hacer algo as=ED: (=
tomado de
 > >esa p=E1gina)
 >=20
 >     Si, ya hace mucho habia visto esa posibilidad, y la verdad no le=

 > entendi. Y por lo general si es complicado de explicar/entender, ent=
onces es
 > complicado de usar. Lo volvi a ver y sigo si entenderle("man perltie=
" est=E1
 > mas completo), muy seguramente porque se maneja como objeto y a mi
 > penosamente no se me da eso...

Ahi si no le atinaste. Precisamente son complicados de entender por
que son muy faciles de usar. La documentacion que estas leyendo es
para implementar uno mismo el acceso. Pero hay modulos que ya lo
hacen, por lo menos para casos como el que estamos tratando. Nadamas
le dices:

use AnyDBM_File;
tie %tu_hash, 'AnyDBM_File', 'un_archivo';

Y ya, a partir de ese momento, todo acceso a %tu_hash, no se da en
memoria, sino en el disco.


 >     Adem=E1s, por ahi mencionaron que se manejan como binarios, pues=
 no me
 > sirve entonces. Por lo que sale mas barato comprarle m=E1s memoria a=
 la compu
 > que usar     TIEs para mi caso. Tambien quien sabe como le hagas par=
a
 > relacionar una tabla con otra... como yo lo hago es f=E1cil gracias =
a perl:
 >=20
 > my %Usuarios=3D&GETNDBFILE1("usuarios.ndb");
 > my %Ordenes=3D&GETNDBFILE1("ordenes.ndb");
 > my $IDord=3D50;
 > print "La orden $IDord la hizo
 > $Usuarios{$Ordenes{$IDord}{'IDUSUARIO'}}{'NOMBRE'}.";

Le haces igual.


 >=20
 > Sin embargo, mi objetivo es hacer una nueva funcion con algo parecid=
o a:
 >=20
 > my %Usuarios=3D&GETNDBFILE2("select * from usuarios where estado=3D1=
 orderby
 > nombre");
 >=20
 >     Aqui seguirias usando los archivos NDB, pero los accesas tipo SQ=
L,
 > ahorrandote memoria ya que usarias el where, y luego ordenados con e=
l
 > orderby, todo lo que no hace mi funci=F3n actual. Aunque creo que es=
o ya lo
 > hace el DBI con archivos planos. El problema aqui es hacer el parser=
 SQL.
 > Eso me mantendr=E1 entretenido un buen rato. =3D)

=BFY para que trabajas si alguien ya lo hizo? Seguramente alguno de
DBD::RAM, DBD::SQLite o DBD::CSV hace lo que necesitas. Y si no, estan
cerca, as=ED que mejor contribuye a ellos, ahorrate trabajo, y coopera
con la comunidad. O si en tu proyecto no te permiten cooperar, por lo
menos ahorrate chamba.

 >=20
 > >Yo creo que se debe a la manera en que Unix y Windows manejan la
 > >memoria... Probablemente en Windows Perl tenga que estarle pidiendo=
 al
 > >kernel m=E1s y m=E1s pedazos de memoria, lo cual toma bastante tiem=
po (ya
 > >conoces la afici=F3n de Windows de 'thrashear' con la memoria virtu=
al). En
 > >los Unixes que conozco, el manejo de memoria es mucho m=E1s limpio =
y
 > >eficiente.
 >=20
 >     Pos quien sabe, yo creo que esta mal el PERL para Windows... deb=
eria de
 > matar el FileHandle con el close. Si fuera de Windows, se tardar=EDa=
 igual
 > aunque trasheara la memoria.
 > ...
 >  open(my $FileHandle,$_[0]) || die "$_[0]: $!";
 >  my @FileData =3D <$FileHandle>;   #Aqui esta la bronca...
 >  close($FileHandle);

No hab=EDa yo entendido bien. Por lo que veo, si tiene que ver con lo
que dice Gunner de la memoria. La bronca no es si se cierra el
FileHandle, es que lees todo el arvhivo a memoria. Cuando terminas de
procesarlo, perl no necesariamente libera la memoria que ocup=F3 para
los datos, de modo que, cuando lees el siguiente, necesita reservar
m=E1s memoria. Y luego m=E1s para el siguiente. Verifica que tus variab=
les
esten saliendo de contexto. Y que no estes usando 'closures'
escondidas por ah=ED, por que eso hace que las referencias no se
pierdan. No me acuerdo mero cual es la bronca de &funcion(), pero
quitale el &, por si las dudas.

--=20
Rodrigo
PGP key 1024D/ADC9BC28 2002-02-26 [expires 2004-02-26]
Fingerprint: 7C81 E60C 442E 8FBC D975  2F49 0199 8318 ADC9 BC28