Servicio Comun de Informatica Grafica

C A P I T U L O 7 Librerías de Procedimientos

Como ya se adelantó en el capítulo anterior, los procedimientos pueden estar en el mismo fichero o en uno distinto. De estar en distintos ficheros, podrán estar en el directorio del programa principal o en otro cualquiera. Tiene que haber un mecanismo que informe al intérprete de Tcl dónde localizar cada procedimiento cuando necesita interpretarlo.

El comando unknown

Tcl puede realizar todo esto gracias al comando unknow. Cada vez que el intérprete localiza un comando que le es desconocido, llama al comando unknown con el nombre del comando desconocido. De aquí se deduce que el comando unknown no es un comando a utilizar por el programador, sino por el intérprete. La localización de la librería es devuelta por el comando info library.

El fichero tclindex

El fichero tclindex es el archivo que permite al intérprete conocer en qué fichero se encuentra cada procedimiento dentro de un directorio, en el caso de que no todos los procedimientos estén en el mismo fichero que el programa principal. Por ello, cada directorio que contenga ficheros, que a su vez contengan procedimientos, tendrá su propio fichero tclindex.

Este fichero no se crea de forma manual, sino que es generado por el propio intérprete, pero es misión del programador hacer que este lo genere. esto se puede hacer desde el intérprete de Tcl (tclsh80) o desde el de Tk (wish80).

- Desde tclsh80: En una ventana de DOS, y situados en el directorio dónde se desea crear el fichero tclindex, se invoca el intérprete escribiendo:

c:\tcl\lib\ejemplo> c:\tcl\bin\tclsh76

El intérprete responderá con su promt (%).




%

Y se escribirá lo siguiente:




% auto_mkindex c:/tcl/lib/ejemplo
%

Y ya se podrá salir del intérprete, pues el fichero ya está generado.




% exit
c:\tcl\lib\ejemplo>

Es importante darse cuenta del sentido de las barras inclinadas, que en DOS es "\", y en Tcl es "/", y de que las rutas o path en otro caso pueden ser distintas.

- Desde wish80: Una vez ejecutada la consola, es posible desplazarse en ella por los directorios con el comando cd y cd ..(los dos puntos deben de estar separados de cd, al estilo UNIX), y ver lo que hay en cada directorio con el comando glob *.

De esta forma se desplazará hasta el directorio en cuestión, teniendo en cuenta que la consola siempre se inicia

en directorio /tcl/bin, ya que es donde se encuentra el intérprete.

Una vez en el directorio se escribirá la ruta hasta el directorio deseado:

% auto_mkindex c:/tcl/lib/ejemplo

y el fichero quedará creado. Es importante acordarse de actualizar estos ficheros cuando el nombre de alguno de

los procedimientos de los que en ellos se hace mención sea modificado, o cambiado de directorio o de fichero.

Es importante hacer notar que en caso de escribir este fichero de forma manual, el intérprete no lo reconocerá como tal, y no funcionará.

La variable auto_path

Con el fin de que el comando unknown sepa en qué directorios debe buscar los procedimientos cuando se encuentra con algún comando que no reconoce, se usa la variable auto_path. Esta variable es una lista cuyos elementos son, los nombres de todos los posibles directorios donde debe buscar los procedimientos. Esta variable se declara al comienzo del programa principal.

lappend auto_path c:/tcl/lib/ejemplo c:/tcl/lib/ejemplo/imagenes

Esto es correcto, pero presenta el problema de que cada vez que el programa sea guardado en un directorio diferente, esta variable deberá ser modificada. Para evitar esto, bastará con introducir al comienzo del programa unas líneas de código que obtienen de forma automática, cuál es el nombre del directorio donde se está ejecutando el programa. Estas líneas son:

# Calcula el nombre del directorio actual.

set script_name [file tail [info script]]

if { [lsearch -exact [array names env] ENTPATH]==-1 } {

set ENT_PATH [file dirname [info script]]

} else {

set ENT_PATH $env(ENTPATH)

}

Donde ENT_PATH es una variable que guardará el nombre del directorio actual, pudiéndose llamar así o de cualquier otra forma.

Ahora la carga de la variable auto_parh será:

lappend auto_path $ENT_PATH $ENT_PATH/images

Como curiosidad decir que aunque en la consola pueda ejecutarse el comando de UNIX pwd, que nos da el path actual, no es posible sustituir el código del ejemplo anterior por una instrucción como esta:

% set ENT_PATH [pwd]

ya que independientemente de dónde esté situada la aplicación, siempre devolverá el path del intérprete.

Carga de Ficheros

Durante la ejecución del programa puede ser necesario la carga de ficheros que contengan procedimientos o inicializaciones de variables que se desea guardar en un fichero a parte. En estos casos, se utilizará el comando source.

source $APP_PATH/config.tcl

En este caso se estaría cargando en el programa un fichero que probablemente contenga variables de configuración y que se encuentra en el mismo directorio que el programa principal.

Hay que tener en cuenta, que si en lugar de contener el fichero procedimientos contiene comandos Tc, estos se ejecutarán. Pero si únicamente contiene procedimientos, serán leídos y cargados en memoria, pudiendo ser ejecutados posteriormente, que es lo que realmente interesa durante la carga de una aplicación.

De cargarse procedimientos de esta manera, podrán ser usados en el programa aunque no hayan sido declarados en el fichero tclindex.

Esto hace que pudan ser utilizadas dos formas diferentes de cargar procedimienros en memoria. Una es la vista hasta ahora, mediante un fichero tclindex, que tiene la ventaja de que sólo se cargarán en memoria aquellos procedimientos que realmente se utilizan, pero el inconveniente de tener que actualizarlo cada vez que se añada un nuevo procedimiento en el directorio o se cambie el nombre de alguno de los ya existentes.

la segunda manera de hacer esto mismo, consiste en poner al inicio del fichero principal de la aplicación una serie de comandos source que cargen todos los ficheros del programa. La ventaja es que no es necesario un tclindex, con todos los problemas que acarrea; la desventaja consiste en que se cargarán todos los procedimientos en memoria, se vayan o no a utilizar.

En estos momentos, Sun MicroSystems, empresa que desarrolla Tcl/Tk, se inclina por la segunda estrategia.