🚀 go-pugleaf

a muchos les contestan lo mismo:  google es tu amigo


Miguel Farah ha escrito:

> Estoy trabajando en un programa en Perl. La primera mitad del código
> fuente consiste en muchas declaraciones de variables, como esto:
>
> $padre{"12"}="-23"; $madre{"12"}="-24"; $conyuges{"12"}=",";
> $hijos{"12"}=","; $sexo{"12"}="M"; $nombre{"12"}="Joaquín Bachelet
> Echeñique";
> $padre{"13"}="-25"; $madre{"13"}="-26"; $conyuges{"13"}=",";
> $hijos{"13"}=","; $sexo{"13"}="F"; $nombre{"13"}="Michelle Piñera
> Infante";
> $padre{"14"}="-27"; $madre{"14"}="-28"; $conyuges{"14"}=",";
> $hijos{"14"}=","; $sexo{"14"}="M"; $nombre{"14"}="Sebastián Lavín
> Jeria";
>
> que son generadas automáticamente por un segundo programa (también en
> Perl), que filtra los datos a partir de un archivo .GED entregado como
> input. La segunda mitad consiste en una serie de subrutinas que hacen
> cálculos y rastreos.
>
> Como la segunda mitad del código es esencialmente fija y la primera
> dependerá del archivo inicial y deberá regenerarse cada vez, lo más
> razonable es separar ambas partes en distintos archivos y luego unirlos
> con el equivalente al #include ... el problema es que no sé cuál es
> el
> equivalente en Perl (por otro lado, tengo un tercer programa, en PHP,
> que usa al primero, y para el cual sí tengo el problema resuelto:
> basta
> usar la sentencia include() ).
> 
> ¿Cómo lo hago? ¿Tendré que darme la p*ja de hacer un módulo?

claudio@webit.cl wrote:
> a muchos les contestan lo mismo:  google es tu amigo

Y el perldoc es un amigo más cercano... el problema es que a veces no
sabes por dónde buscar o de dónde agarrarte, especialmente cuando la
respuesta "obvia" (una sentencia "include" en Perl) no es la correcta.

Cito del charter:

"Este newsgroup se dedica a hablar, discutir y orientar sobre el
desarrollo de programas en los diversos lenguajes de programación
existentes. La idea principal es crear un ambiente provechoso en el
cual
usuarios puedan buscar respuestas a sus preguntas generales o
específicas con respecto a un lenguaje de programación, como COBOL,
C,
Pascal, Java, BASIC, SQL, PHP, etcétera."

[...]

"Se prohíbe el abuso desmedido de la buena voluntad :-)."

Discúlpame por utilizar el newsgroup correctamente.


Ah, por si alguien quedó metido, en comp.lang.perl.misc me
respondieron
al tiro:

do "archivo.pl";

Que, como se ve, no es inmediatamente obvio.

nahh.. disculpame tu...

solo lo decia, pq en menos de 5 minutos encontré la respuesta en
google.

claudio@webit.cl wrote:
> nahh.. disculpame tu...
>
> solo lo decia, pq en menos de 5 minutos encontré la respuesta en
> google.

Bien por ti. Yo no pude, y tampoco encontré la respuesta en el perldoc
(de hecho, estaba, pero no la pillé por no saber exactamente qué era
lo
que tenía que buscar).

Para esta clase de situaciones están los newsgroups, cachai?

(en todo caso, tú eres harto más bacán porque encontraste la
respuesta
en cinco minutos... mi pregunta en comp.lang.perl.misc tomó ONCE en
ser
respondida...)

Confundes las cosas...

A mi me tomó 5 minutos encontrar la respuesta, a partir del momento en
que lei tu pregunta y me metí a google a buscar.

Se demoraron 11 minutos en responderte a ti.. o sea desde que
publicaste el mensaje. Eso es realmente loable.

Desde ese punto de vista yo me demoré mas de un dia.

Y si se para que son los newsgroup, pero yo dije que buscaras en
google, debido a que era la mejor ayuda que podria prestar en este
caso.. google casi siempre me salva a mi, por que no a ti?

claudio@webit.cl wrote:
> Confundes las cosas...
>
> A mi me tomó 5 minutos encontrar la respuesta, a partir del momento en
> que lei tu pregunta y me metí a google a buscar.
>
> Se demoraron 11 minutos en responderte a ti.. o sea desde que
> publicaste el mensaje. Eso es realmente loable.
>
> Desde ese punto de vista yo me demoré mas de un dia.
>
> Y si se para que son los newsgroup, pero yo dije que buscaras en
> google, debido a que era la mejor ayuda que podria prestar en este
> caso.. google casi siempre me salva a mi, por que no a ti?

Porque yo busqué y no pude encontrar la respuesta.

Y tú te fuiste en mala, porque dijiste simplemente "AAG" y no:

]do "archivo.pl;"
]
]AAG para la próxima.

o algo por el estilo.


P.S.: honra el followup.

Miguel Farah wrote:

> Estoy trabajando en un programa en Perl. La primera mitad del código
> fuente consiste en muchas declaraciones de variables, como esto:
>
> $padre{"12"}="-23"; $madre{"12"}="-24"; $conyuges{"12"}=",";

[... equivalente de #include...]

Esa es una curiosa manera de escribir todos esos datos. Por que no
mejor

%padre = ( 12 => -23, ... );
%madre = ( 12 => -24, ... ); ?

El `do "archivo.pl"' que ya descubriste funciona bien, pero si tus
varios hashes son medianamente grandes, puedes considerar usar el
modulo "Storable". Como siempre, perldoc Storable te cuenta los
detalles.

Salu2,
W.

Waldo wrote:
> Miguel Farah wrote:
>
> > Estoy trabajando en un programa en Perl. La primera mitad del código
> > fuente consiste en muchas declaraciones de variables, como esto:
> >
> > $padre{"12"}="-23"; $madre{"12"}="-24"; $conyuges{"12"}=",";
>
> [... equivalente de #include...]
>
> Esa es una curiosa manera de escribir todos esos datos. Por que no
> mejor
>
> %padre = ( 12 => -23, ... );
> %madre = ( 12 => -24, ... ); ?

Porque voy leyendo un archivo GEDCOM, segmento por segmento, que dice
cosas como esto:

0 @I63@ INDI
1 NAME Juan /Soto/
1 SEX M
1 CHAN
2 DATE 19 JUN 2006
1 BIRT
2 DATE 19 MAR 1942
2 PLAC Santiago, Chile
1 BAPM
2 PLAC Santiago, Chile
1 OCCU vago empedernido
1 NATI chilena
1 RELI pastafariano
1 FAMS @F12@
1 FAMC @F41@

Este primer bloque indica los datos de una persona (nombre, sexo,
etcétera) y la(s) familia(s) en la(s) que es cónyuge y la en que es
hijo.

Luego, un segundo segmento dice cosas como esto otro:

0 @F91@ FAM
1 HUSB @I356@
1 WIFE @I357@
1 CHIL @I358@
1 CHIL @I359@
1 CHIL @I360@
1 CHIL @I157@
1 CHIL @I361@
1 CHIL @I362@
1 CHIL @I363@
1 CHIL @I364@
1 CHIL @I365@

Aquí se define una familia, indicando los códigos del marido, mujer e
hijos.

Por esto, parte de las asignaciones son más fáciles de hacer si vas
línea por línea (las de hijos, en particular:
[$hijos{"356"}.="358,";]).
Como además almaceno los datos de hijos y cónyuges como strings que
contienen una lista interna (",13,14,15,16,"), prefiero manejar TODOS
los códigos de individuos de la misma manera, para evitar
complicaciones
con las conversiones posteriores [onda if "23" eq ("".$individuo) , con
$invididuo==63 ].

Como dice el viejo dicho, TMTOWTDI. :-)



> El `do "archivo.pl"' que ya descubriste funciona bien, pero si tus
> varios hashes son medianamente grandes, puedes considerar usar el
> modulo "Storable". Como siempre, perldoc Storable te cuenta los
> detalles.

No tenía idea. Gracias por el dato.

Miguel Farah wrote:

> Porque voy leyendo un archivo GEDCOM, segmento por segmento, que dice
> cosas como esto:
[...]

No has dicho de que taman~o es el archivo, pero igual puedes hacer lo
mismo que haces, salvo que en vez de imprimir cada item cuando lo lees,
imprimes la tabla total al final. Me parece bastante mas limpio y te
queda como lo que sugeria antes. Eso si, si las tablas tienen centenas
de miles de elementos, puede ser un problema :-)

[...]
> Por esto, parte de las asignaciones son más fáciles de hacer si vas
> línea por línea (las de hijos, en particular:
> [$hijos{"356"}.="358,";]).

Los puedes hacer linea por linea, pero nada (excepto taman~o) te obliga
a _imprimirlos_ linea por linea, no?

> con las conversiones posteriores [onda if "23" eq ("".$individuo) , con
> $invididuo==63 ].

Alguna razon por la que haces algo como "23" eq ("".$individuo) ? En
Perl no es necesario "convertir" numeros a strings. Los numeros tienen
siempre doble personalidad. Puedes hacer "23" eq $individuo, o 23 ==
$individuo sin mas. (Internamente, un numero en Perl parte su vida como
numero (guardado como int, o long, o lo que sea) pero adquiere una
representacion como string automaticamente, cuando se necesita, y ambas
conviven siempre. Cuando una de las dos cambia, la otra se invalida.
Como consecuencia, un simple entero puede ocupar varias decenas de
bytes internamente y en general es buena idea no hacer cosas como "23"
eq $individuo, para evitar crear la otra representacion).

> Como dice el viejo dicho, TMTOWTDI. :-)

Me perdi. No conozco el dicho.

Salud2,
W.

Waldo wrote:
> Miguel Farah wrote:
>
> > Porque voy leyendo un archivo GEDCOM, segmento por segmento, que dice
> > cosas como esto:
> [...]
>
> No has dicho de que taman~o es el archivo, pero igual puedes hacer lo
> mismo que haces, salvo que en vez de imprimir cada item cuando lo lees,
> imprimes la tabla total al final. Me parece bastante mas limpio y te
> queda como lo que sugeria antes. Eso si, si las tablas tienen centenas
> de miles de elementos, puede ser un problema :-)

Lo pensé por el lado de "leo el dato, lo imprimo y me olvido de él".
Es
más sencillo de manejar, y no tiene tanta importancia que sea más o
menos limpio, pues se trata de datos generados en forma automática,
que
no se supone que deban ser leídos por un humano. Y si después hay que
hacer alguna clase de debugging, basta con hacer un print entremedio.
IMHO.

El archivo GEDCOM que yo manejo tiene 418 individuos y 106 familias,
que
no es mucho. He visto otros que tienen 4000+ individuos...


> [...]
> > Por esto, parte de las asignaciones son más fáciles de hacer si vas
> > línea por línea (las de hijos, en particular:
> > [$hijos{"356"}.="358,";]).
>
> Los puedes hacer linea por linea, pero nada (excepto taman~o) te obliga
> a _imprimirlos_ linea por linea, no?

No, nada me obliga.

> > con las conversiones posteriores [onda if "23" eq ("".$individuo) , con
> > $invididuo==63 ].
>
> Alguna razon por la que haces algo como "23" eq ("".$individuo) ? En

No, no lo hago. Es precisamente lo que evito. :-)

> Perl no es necesario "convertir" numeros a strings. Los numeros tienen

Lo sé. Lo que pasa es que no me gusta ese tratamiento (siempre he
preferido tipos de datos fuertes).


> siempre doble personalidad. Puedes hacer "23" eq $individuo, o 23 ==
> $individuo sin mas. (Internamente, un numero en Perl parte su vida como
> numero (guardado como int, o long, o lo que sea) pero adquiere una
> representacion como string automaticamente, cuando se necesita, y ambas
> conviven siempre. Cuando una de las dos cambia, la otra se invalida.
> Como consecuencia, un simple entero puede ocupar varias decenas de
> bytes internamente y en general es buena idea no hacer cosas como "23"
> eq $individuo, para evitar crear la otra representacion).
>
> > Como dice el viejo dicho, TMTOWTDI. :-)
>
> Me perdi. No conozco el dicho.

"There's More Than One Way To Do It."

Miguel Farah wrote:

> > Alguna razon por la que haces algo como "23" eq ("".$individuo) ? En
>
> No, no lo hago. Es precisamente lo que evito. :-)

Ok, el punto era que aun si tienes que usar strings, puedes hacer
simplemente 23 eq $individuo (el "23" y el "".$individuo son
superfluos).

> > > Como dice el viejo dicho, TMTOWTDI. :-)
> >
> > Me perdi. No conozco el dicho.
>
> "There's More Than One Way To Do It."

Ah, por supuesto. Como es que se me fue??

Salu2,
W.