Programación Bizarra

250 caracteres

2011-07-04T18:08:00.003-03:00

Las Interrupciones en los Procesadores 80x86

2011-03-09T15:31:00.001-03:00

1. Origen de las interrupciones.

En las computadoras con procesadores 80x86 las interrupciones pueden ser originadas por la CPU (las excepciones), “disparando” el pin INTR (interrupciones enmascarables) o el NMI (interrupciones no enmascarables), o por las instrucciones INT 3, INT n, INTO o BOUND (interrupciones por software).

1.1. Excepciones.

Como ya se ha dicho, se nombra de esta manera a las interrupciones originadas por la CPU. INTEL las clasifica, según la dirección de retorno de la rutina o proceso que atiende la interrupción, de la siguiente manera:

Faults: la dirección de retorno es la de la instrucción que se ejecutaba cuando se originó la excepción. Esta excepción permite solucionar el problema y volver a ejecutar dicha instrucción.
Traps: la dirección de retorno es la de la instrucción que le sigue a la que se ejecutaba cuando se originó la excepción. Son usadas exclusivamente para propósito de depuración, como por ejemplo colocar un “breakpoint”.
Aborts: a veces no es posible determinar la dirección de retorno, por lo tanto tampoco es posible continuar con el programa luego de una excepción de esta clase. Son causadas por fallas graves, como errores en el hardware o entradas erróneas en las tablas del sistema.

Algunas excepciones generan un “error code” que proporcionan información sobre estas.

Vector	Mnemonico	Decripción	Tipo	Error code
0	#DE	Divide error	Fault	No
1	#DB	Debug	Fault/Trap	No
2	-	NMI interrupt	Interrupción	No
3	#BP	Breakpoint	Trap	No
4	#OF	Overflow	Trap	No
5	#BR	Range exceeded	Fault	No
6	#UD	Invalid opcode	Fault	No
7	#NM	No math coprocessor	Fault	No
8	#DF	Doble fault	Abort	Si
9	-	Coprocesor segment overrun	Fault	No
10	#TS	Invalid TSS	Fault	Si
11	#NP	Segment not present	Fault	Si
12	#SS	Stack-segment fault	Fault	Si
13	#GP	General protection	Fault	Si
14	#PF	Page fault	Fault	Si
15	-	(Intel reserved)	-	No
16	#MF	Math fault	Fault	No
17	#AC	Alignment check	Fault	Si
18	#MC	Machine check	Abort	No
19	#XF	Streaming SIMD extensions	Fault	No
20-31	-	(Intel reserved)	-	No
32-255	-	User defined	Interrupción	No

1.2. Interrupciones externas.

En las PCs de IBM la CPU tiene conectado un controlador de interrupciones programable 8259 al pin INTR. Los distintos dispositivos se conectan a este chip (por las IRQ) y le solicitan que interrumpa al procesador cuando lo requieran. Este chip no solo debe interrumpir al procesador, sino que también debe indicarle cuál es el vector asociado al dispositivo (se hablará de los vectores luego) que solicitó la interrupción.

A partir de las ATs las PCs comenzaron a venir con dos 8259 conectados en cascada, permitiendo conectar hasta 15 dispositivos.

Estas interrupciones se pueden enmascarar indiscriminadamente desde el procesador, poniendo el flag IF en 0, o selectivamente desde el 8259.

Otra forma de generar interrupciones desde el exterior de la CPU es disparando por el pin NMI, esto ocurre cuando hay una falla de hardware, por ejemplo problemas con la memoria. En este caso el vector es 2 y no es posible enmascarar estas interrupciones.

1.3. Interrupciones por software.

Es posible generar interrupciones con el vector deseado mediante la instrucción INT n. Esto es útil para implementar “breakpoints” y “system calls”. Las system calls son un conjunto de rutinas y procesos que ofrece el sistema operativo a los programadores de aplicaciones para que tengan acceso restringido a los recursos del sistema.

Linux implementa las “system calls” en el vector 0x80, por lo tanto para invocarlas hay que hacerlo con la instrucción INT 0x80.

Anexo 1.A. El controlador de interrupciones 8259.

1.A.1 La interface de interrupción con el 80x86.

Los procesadores 80x86 poseen sólo una línea de entrada sobre la cual pueden recibir una señal de interrupción. El 8259 PIC – Programmable Interrupt Controller (Controlador de Interrupciones Programable) administra las múltiples interrupciones de los múltiples dispositivos, para entregarle las solicitudes al procesador 80x86 de a una. Para esto se lo coloca entre el microprocesador 80x86 y los dispositivos.

Conexión entre los dispositivos y el 80x86 a través del 8259 PIC

1.A.2 El 8259 PIC (Programmable Interrupt Controller)

El 8259 PIC controla las interrupciones por hardware, permite acoplarse con otros 8259 en cascada soportando hasta 64 niveles de interrupción. La mayoría de las PC sólo tienen 2 de estos alojados en alguna dirección. Uno maneja los IRQ del 0 al 7 y el otro del 8 al 15, dando en total 15 líneas individuales de IRQ.

El PIC nos permite enmascarar IRQs individuales, esto significa que esas solicitudes no podrán llegar al procesador. Cómo hay 2 PICs alojados en diferentes direcciones, debemos determinar cual PIC necesitamos usar. El primer PIC, localizado en la dirección base 0x20h controla los IRQ 0 a IRQ 7. El segundo PIC está localizado en la dirección base 0xA0h, y controla las IRQs del 8 al 15. El formato de bits de la Operation Control Word 1 (OCW1 es la instrucción para enmascarar o desenmascarar las solicitudes) es el siguiente:

PIC maestro			PIC esclavo
Bit	Disable IRQ	Función	Bit	Disable IRQ	Función
7	IRQ7	Puerto Paralelo	7	IRQ15	Reservado.
6	IRQ6	Disco Flexible	6	IRQ14	Disco Rígido.
5	IRQ5	Reservado/Tarjeta de sonido	5	IRQ13	Coprocesador matemático.
4	IRQ4	Puerto serie	4	IRQ12	PS/2 Mouse
3	IRQ3	Puerto serie	3	IRQ11	Reservado.
2	IRQ2	PIC2	2	IRQ10	Reservado.
1	IRQ1	Teclado	1	IRQ9	Redirección del IRQ2
0	IRQ0	Timer del sistema	0	IRQ8	Reloj en tiempo real.
Asignaciones típicas de IRQ y su correspondiente bit para enmascarar o desenmascarar las solicitudes.

Como se ve en la tabla y en la siguiente figura, el IRQ2 está conectado al PIC 2, así, si se enmascara este IRQ, se deshabilitarán las IRQ 8 a la 15.

Conexión en cascada entre 2 PICs

1.A.3 Las Operaciones del PIC

La programación del 8259 consiste de dos acciones básicas:

Primero habilitamos o deshabilitamos cada fuente de interrupción independientemente escribiendo un valor en el registro de máscara de interrupción (IMR). El IMR es un registro del 8259 ubicado en el puerto 21h para el PIC maestro y ubicado en A1h para el PIC esclavo. Cada bit del IMR corresponde a una fuente, si el bit es 0, entonces su correspondiente interrupción esta habilitada. Si el bit del IMR es 1, entonces la fuente de interrupción se deshabilitada (se enmascara) y no puede generar interrupción.

La definición para cada uno de los bits del IMR es la siguiente: el bit 0 corresponde a la IRQ0, el bit 1 a la IRQ1 y así sucesivamente con todos los bits. Por ejemplo, si queremos deshabilitar las interrupciones de todos los dispositivos excepto el teclado. Esto pudiera lograrse con las siguientes instrucciones:

mov al, 0FDh

out 21h, al

O en el lenguaje C, pero manteniendo los valores anteriores del puerto 21h:

outportb(0x21,(inportb(0x21) & 0xFD);

La segunda acción programando el 8259 tiene que ver con indicarle el final de la rutina de servicio a interrupción. Esto se logra enviando al registro de comando del 8259, el comando de fin de interrupción (EOI), representado por 20h. Coincidentemente, a este registro se accede vía el puerto 20h para el PIC maestro y vía A0h para el PIC esclavo, de tal manera que la señal de fin interrupción se envía mandando el comando EOI, como se ejemplifica en las siguientes instrucciones:

mov al, 20h

mov 20h, al

Diagrama de Bloques del 8259 PIC

Como se puede ver en la figura anterior, las 8 líneas individuales de Interrupt Request, primero pasan por el Interrupt Mask Register (IMR), para ver si han sido enmascaradas o no. Si están enmascaradas, entonces no serán procesadas hasta nuevo aviso. Por otro lado, si no están enmascaradas, estas registrarán sus solicitudes en el Interrupt Request Register (IRR).

El IRR mantendrá todas las solicitudes IRQs hasta que hayan sido tratadas apropiadamente. Si es necesario, este registro podrá ser leído colocando correctamente bits en la Operation Control World 3. El Priority Resolver, simplemente selecciona el IRQ con mayor prioridad. Aunque la más alta prioridad dentro de cada 8259 es la IRQ0 para el maestro e IRQ8 para el esclavo, la conexión a través de IRQ2 causa que IRQ8-IRQ15 sean las siguientes peticiones de prioridad más alta después de IRQ1. Así, el orden de prioridad por omisión para las peticiones de interrupción es IRQ0, IRQ1, IRQ8-IRQ15, IRQ3-IRQ7.

Una vez que el PIC ha determinado cual IRQ procesar, se lo debe decir al procesador, así llamará a la ISR de forma automática. Este proceso es realizado enviando una señal INT al procesador, es decir, es usada la línea INT del procesador. El procesador entonces terminará el proceso de la instrucción actual y reconocerá la solicitud INT con un pulso INTA (Interrupt Acknowledge).

Luego de recibir la señal INTA proveniente del procesador, la IRQ que el PIC está actualmente procesando es almacenada en el In-Service Register (ISR), el cual, como su nombre lo indica, muestra que IRQ está actualmente siendo servida.

Otro pulso INTA será enviado por el procesador, para decirle al PIC que coloque un puntero de 8 bits en el bus de datos, correspondiente al número de IRQ. Si una IRQ atendida por el PIC2 requiere el servicio, entonces el PIC2 enviará el puntero. El procesador maestro PIC1, seleccionará al PIC2 para que envíe el puntero, colocando la identificación de esclavo (Slave ID) del PIC2 en la linea de la cascada, el cual tiene un ancho de tres cables (CAS0, CAS1, CAS2) entre los PICs.

Los cinco (5) bits más significantes del puntero es colocado usando el Initialization Command Word 2 (ICW2). Este será 00001 para el PIC 1 y 01110 para el PIC2. Los 3 bits menos significantes serán enviados para indicar el número de IRQ que pide atención. Por ejemplo, Si el IRQ solicita atención, entonces, el puntero de 8 bits estará formado por 00001 en los 5 bits más significativos y 011 (IR3) para los bits menos significativos. Juntando esto quedará 00001011 o 0x0B, el cual es el vector de interrupciones del IRQ 3 (como se puede ver en la tabla de asignaciones típicas de IRQ mostrada anteriormente en este TP).

El mismo principio se aplica al PIC2. Si el IRQ 10 requiere un servicio, entonces será enviado el byte 01110010, el cual representa la interrupción 72h. Como la IRQ10 está en el PIC2, los 3 bits menos significativos usados serán 010.

Una vez que la ISR ha hecho todo lo necesario, enviará una End of Interrupt (EOI) hacia el PIC, el cual vuelve a poner en uso al In-Service Register. Si la solicitud proviene del PIC2, entonces, las señales EOIs se deberán enviar a ambos PICs. Luego el PIC determinará la próxima interrupción en prioridad y se repite el mismo proceso. Si no hay solicitudes de interrupción presentes, el PIC esperará por la próxima solicitud antes de interrumpir el procesador.

1.A.4 Redireccionamiento de las IRQ2/IRQ9

La IRQ 2 del PIC maestro se usa para conectar a otro PIC como esclavo, no permitiendo que otro dispositivo sea conectado a esta IRQ y la IRQ2 se desvía hacia la IRQ9 (en el segundo controlador). Un dispositivo de hardware usando la IRQ2, instalaría su ISR en INT 0x0A. Por lo tanto será usada una rutina ISR en INT 71h, la cual enviará una EOI al PIC2 y luego llamará a la ISR en INT 0x0A. Parte del código en assembler de la ISR para la IRQ9 sería como el siguiente:

MOV AL,20

OUT A0,AL ; envía EOI al PIC2

INT 0A ; llama a la ISR para la IRQ2

IRET

La rutina sólo envía una EOI al PIC2, como se espera que se ejecute una rutina ISR escrita para la IRQ2, esta se encargará de enviar una EOI al PIC1. Como el PIC2 es inicializado como esclavo sobre la IRQ2, cualquier solicitud usando el PIC2 no llamará a la rutina ISR para la IRQ2. El puntero de 8 bits provendrá del PIC2.

Anexo 1.B. Interrupciones en sistemas con más de un procesador.

1.B.1 SISTEMAS SMP

El sistema SMP – Symmetrical multiprocessing agrega unos pocos requerimientos al manejo de interrupciones al hardware y software respecto al sistema “normal” de UP – UniProcessing. Obtener ventajas del paralelismo requiere sincronización., por ejemplo sólo una CPU debe controlar una interrupción de una cierta interrupción de hardware. En segundo lugar, es necesario un mecanismo eficiente para pasar mensajes entre las CPUs, para planificar tareas entre las CPUs y para diferentes propósitos de sincronización.

1.B.2 APIC

Para permitir que se distribuyan completamente el control entre CPUs en un sistema SMP, Intel ha desarrollado I/O APIC (Advanced Programmable Interrupt Controller), el cuál remplaza el 8259A Programmable Interrupt Controller de los sistemas UP.

Un APICs local posee registros de 32-bits, un clock interno, un dispositivo temporizador (timer), y dos líneas de IRQ adicionales reservadas para interrupciones locales. Las interrupciones locales son usadas típicamente para reiniciar el sistema.

Las I/O APIC consisten en un conjunto de IRQs, una tabla de redirección de interrupciones de 24 entradas, registros programables y una unidad de mensajes para enviar y recibir mensajes APIC sobre el bus ICC (Interrupt Controler Communication). Cada entrada en la tabla de redirección pueden ser programadas individualmente para indicar el vector de interrupciones y la prioridad, la CPU destino y cómo se selecciona la CPU. La tabla es usada para trasladar un mensaje de cualquier IRQ externa mediante una señal a una o más unidades APIC locales vía el bus ICC.

Las solicitudes de interrupción pueden ser distribuidas a las CPUs de dos maneras diferentes: Modo Fijo (Fixed Mode) o Modo de Prioridad más baja (Lowest-Priority Mode). Un rasgo importante en el APIC es que permite a las CPUs generar interrupciones entre los procesadores (interprocessor interrupts - IPIs). La CPU puede almacenar el vector de interrupciones y el identificador de los objetivos de la APIC local en el registro ICR – Interrupt Local Register de su propia APIC. Entonces un mensaje es enviado por el bus ICC a la APIC local del objetivo, la cuál entonces provoca la interrupción correspondiente a su CPU.

Hay soporte para múltiples I/O APICs en el kernel 2.4.18-10.

2. Tratamiento de las interrupciones

2.1 Interrupt descriptor table (IDT).

Se trata de un arreglo de hasta 256 elementos (pueden ser menos) de 8 bytes cada uno. Los programadores de un sistema operativo pueden decidir ubicarlo en cualquier lugar de la memoria física, luego cargarán el registro “IDTR” con su dirección y la cantidad de bytes que ocupa menos 1. La instrucción para hacer esto es “LIDT”, pero solo puede ser ejecutada por los procesos o procedimientos que tienen el máximo privilegio.

Si el vector hace referencia a una entrada más allá del límite de la tabla, la excepción “general-protection exception” es generada.

Relación entre el registro IDTR y la IDT.

2.2 Formas de atender a las interrupciones.

Los procesadores 80386 o superiores proporcionan dos formas básicas de atender a una interrupción dependiendo de su correspondiente entrada en la IDT, una interrupt-gate o trap-gate, o una task-gate. La diferencia es que de la primera forma no se produce un “context switch”.

Los siguientes campos forman parte de una interrupt-gate o trap-gate:

Segment selector: indica en qué segmento de memoria se encuentra la rutina que atiende a la interrupción.
Offset: indica en que posición del segmento está la primera instrucción de la rutina.
DPL: indica cuál debe ser el privilegio para acceder a la rutina. Este campo no es tenido en cuenta por el procesador cuando la interrupción es generada por hardware (ya sea interna o externa), sin embargo cuando la interrupción es generada por la instrucción “INT” es importante.
P: indica si el segmento al que apunta el campo “Segment selector” es válido. Si está en 0 y se produce la interrupción, se generará una excepción.
D: Indica si “la gate” apunta a código de 32 bits o 16 bits.

Las estructuras de la interrupt-gate y de la trap-gate.

Cuando una interrupción ocurre y en la entrada de la IDT hay una iterrupt-gate o trap-gate el procesador guarda en la pila los flags, la dirección de la instrucción que se iba a ejecutar (determinada por los registros CS y EIP) y el código de error (si existe), en ese orden. Luego salta al procedimiento que atenderá la interrupción. Si se trata de una interrupt-gate las interrupciones se deshabilitarán automáticamente, se obtendría el mismo efecto si se pusiera una trap-gate y luego se invocara a la instrucción “CLI” (clear interrupt flag) al comienzo de la rutina que atiende la interrupción. Es responsabilidad de la persona que programó esta rutina preservar el estado de todos los registros. Al finalizar se deberá volver al procedimiento que se estaba ejecutando, mediante la instrucción “IRET” (esta instrucción es similar a “RET”, con la única diferencia que también restaurará los flags).

La pila antes y luego de que se produzca una interrupción atendida por una interrupt-gate o trap-gate.

Si en la entrada hay una task-gate la interrupción será atendida por otro proceso, entonces se produce un context switch. En este caso el procesador realiza las siguientes tareas:

Todos los registros de la CPU que contienen información que le corresponde al proceso en ejecución son salvados automáticamente.
La información necesaria para que el procesador sepa hacia qué proceso volver cuando termine de atender la interrupción es almacenada.
El flag “NT” (nested task) se pone en 1 para indicar que hay una anidación de procesos (información que será necesaria para la intrucción “IRET”).
El proceso en ejecución toma el estado de “BUSY” (ocupado), significa que no podrá continuar hasta que termine el que atiende a la interrupción.
Los registros son cargados con la información que le corresponde al nuevo proceso y comienza la ejecución.

Al terminar se deberá volver con la instrucción “IRET”, que producirá un context switch al verificar que el flag “NT” está en 1.

Los siguientes campos forman parte de una task-gate:

Segment selector: indica el segmento que contiene información acerca del proceso.
DPL: indica cuál debe ser el privilegio para hacer un context switch hacia el proceso. Este campo no es tenido en cuenta por el procesador cuando la interrupción es generada por hardware (ya sea interna o externa), sin embargo cuando la interrupción es generada por la instrucción “INT” es importante.
P: indica si el segmento al que apunta el campo “Segment selector” es válido. Si está en 0 y se produce la interrupción, se generará una excepción.

La estructura de la task-gate.

Las ventajas que ofrece atender una interrupción con otro proceso son que todos los registros son salvados automáticamente y que la rutina puede ser aislada otorgándole un espacio de direcciones lógicas distinto. Por otro lado la cantidad de información que el procesador guarda automáticamente en el context switch hace que pueda ser una opción mucho más lenta que la interrupt-gate o trap-gate.

2.3 Inicializando la IDT

Antes de que el Kernel habilite una interrupción, debe cargar la dirección inicial de la IDT en el registro idtr e inicializar todas las entradas de la tabla. Linux usa las interrupts gates para controlar interrupciones y las trap gates para controlar excepciones. Linux no usa task gates.

Interrupt Gate: Todos los controladores de interrupciones.

System Gate: 4 controladores de excepciones (3,4,5 y el vector 128)

Trap Gate: Todos los controladores de excepciones excepto el 4.

Insertar los gates en la IDT

set_intr_gate(n, addr)

Inserta una interrupt gate, el campo DPL (Descriptor Privilege Level = 0), entonces no puede ser accedido por programas en modo usuario.

set_system_gate(n, addr)

Inserta una system gate, el campo DPL = 3, esto significa que pueden ser accedidas por programas en modo usuario. Por ejemplo, en Linux, el vector 128 accedido por una system call iniciada por una INT 0x80. La INT3, INTO, BOUND y la INT 0x80 pueden ser accedidas por procesos en modo usuario.

set_trap_gate(n, addr)

Inserta una trap gate, DPL = 0. Son usadas para activar las rutinas de atención a excepciones.

Estas funciones insertan el gate descriptor en la n-ésima entrada de la IDT. El parámetro addr identifica el desplazamiento (offset) del segmento en el código del Kernel, el cual es la dirección base de la rutina de atención. Ejemplo

set_system_gate(0x80, &system_call); (en sched.c y traps.c)

Anexo 2.A. Interrupciones en Linux.

2.A.1 Linux System Calls

Se invocan ejecutando int $0x80, quiere decir que:

El número de vector de excepciones programadas es el 128.

La CPU cambia al modo kernel y ejecuta la función del kernel.

El proceso llamado pasa el número de system call (syscall number) identificando al system call en el registro eax (en los procesadores Intel).
El controlador syscall es responsable de:

Guardar los registros en la pila en modo kernel.
Invocar a la rutina de servicio de la syscall.
Salir llamando ret_from_sys_call().

La tabla para enviar system calls:

Asocia un número de syscall con la rutina de servicio correspondiente,
Almacenada en el arrar sys_call_table tiene NR_syscall entradas (256 máximo, el linux 2.4.18 tiene 237).
El n-ésimo registro contiene la dirección de la rutina de servicio de la syscall n.

2.A.2 Iniciando las System Calls

Cuando el sistema bootea, es llamada la función arch/i386/kernel/traps.c:trap_init(), esta coloca la entrada correspondiente al vector 0x80 (tipo 15, DPL 3) en la IDT (set_system_gate(0x80, &system_call);), apuntando a la dirección de la system_call en arch/i386/kernel/entry.S.

Cuando una aplicación en espacio de usuario hace una system call, los argumentos son pasados vía registro y la aplicación ejecuta la instrucción ‘int 0x80’. Esto causa una trap, se pasa a modo kernel, y el procesador salta a la system_call apuntada en entry.S.

2.A.3 System Calls Estáticas

Una de las características más importantes de Unix es la clara distinción entre el “espacio del kernel” y el “espacio del usuario”. Linux ofrece a los procesos que corren en el espacio del usuario un conjunto de interfaces para interactuar con dispositivos hardware como la CPU, discos, impresoras, etc. El sistema Linux implementa la mayoría de las interfaces entre procesos en modo usuario y dispositivos hardware con las llamadas System Calls emitidas al kernel. Una de las últimas versiones del Kernel de Linux (versión 2.4.18) tiene 237 system calls. Las system calls pueden ser llamadas también System Request o syscall.

En general, se supone que proceso no posee acceso al kernel. No puede acceder a la memoria del kernel y no puede llamar a funciones del kernel. El hardware de la CPU hace esto posible (esta forma de control se llama “modo protegido”).

Las System calls son una excepción a esta regla. Un proceso llena registros con los valores apropiados y entonces, llama a una instrucción especial que salta a una dirección definida en el Kernel. En las CPUs de Intel, esto es posible por la llamada interrupt 0x80. El hardware sabe que una vez que se salta a esta dirección, no se está corriendo en el restringido modo de usuario.

Para indicar al kernel el número de la system call, debe almacenarse dicho número en el registro EAX. Antes de cambiar al modo kernel, el procesador debe guardar todos los registros y derivarle la ejecución a la función del kernel apropiada, antes debe verificar que EAX no esté fuera de rango. El archivo uniste.h contiene los números de las system calls.

2.A.4 Bottom Halves

Bottom halves son la forma en que Linux retrasa el procesamiento. Se usan en los controladores de interrupciones. En un controlador de interrupciones, no se procesan otras interrupciones o eventos de ninguna clase mientras este se está ejecutando (las interrupciones son deshabilitadas), Si se quiere poder atender otras interrupciones mientras el controlador se está ejecutando y dejar el resto de la manipulación para más tarde (porque consume mucho tiempo), pero antes que el retorno al espacio de usuario, se debe crear una bottom half. A una Bottom Half también se la conoce como softirq.

Uno de los principales problemas con el manejo de las interrupciones es como realizar largas tareas dentro de un controlador de interrupciones. A veces, se necesita hacer un trabajo considerable como respuesta a una interrupción de un dispositivo, pero un controlador de interrupciones debe terminar rápidamente y no mantener bloqueadas las interrupciones por mucho tiempo. Estas dos necesidades (mucho trabajo y velocidad) entran en conflicto mutuamente.

La solución a este problema es dejar para el controlador de interrupciones lo inmediatamente necesario, usualmente leer algo del hardware o enviar algo al hardware, y entonces programar el control de nueva información para más tarde (en la “bottom half”) y retornar del controlador. El Kernel garantiza entonces que llamará a la bottom half tan pronto como sea posible, antes que se retorne a modo usuario, y cuando hace esto, todo lo permitido a los módulos del kernel estará permitido ahora.

Así los controladores de interrupciones están divididos en dos partes: una top y una bottom half (mitad de arriba y mitad de abajo). La top half es el verdadero controlador de interrupciones: a veces solo le dice al kernel que ejecute la bottom half, y sale. El kernel garantiza que la top half nunca reentrará. Si llega otra interrupción, será encolada hasta que la top half termine. Como la top half deshabilita las interrupciones, debe ser rápida.

La bottom half correrá antes que otra interrupción sea procesada, o su tiempo se haya terminado. Las interrupciones no son deshabilitadas mientras una bottom half está corriendo, entonces estas pueden hacer trabajos “lentos”.

2.A.5 Implementación

Puede haber hasta 32 controladores bottom half diferentes; bh_base es un vector de punteros a cada una de las rutinas bottom half del kernel; bh_active y bh_mask tienen los bits colocados (activados) de acuerdo a que controladores han sido instalados y cuales están activos. Si el bit N de bh_mask está colocado, entonces el N-ésimo elemento de bh_base contiene la dirección de la rutina bottom half. Si el bit N de bh_active está colocado, entonces la N-ésima rutina bottom half debe ser llamada tan pronto como el planificador crea razonable. Estos índices son definidos estáticamente, la rutina bottom half del timer posee la priridad más alta (índice 0), la rutina bottom half de la consola es la próxima en prioridad (índice 1), etc.

Algunas de las rutinas bottom half del kernel son específicas del dispositivo, pero otras son más genéricas. Por ejemplo, el controlador del TIMER es marcado como activo cada vez que el timer del sistema interrumpe y es usado para manejar los mecanismos de cola del temporizador del kernel.

Cada vez que un controlador de dispositivos, o alguna otra parte del kernel, necesita planificar trabajo para ser hecho después, este añade trabajo a la cola del sistema apropiada, por ejemplo a la cola del timer, y entonces le indica al kernel que alguna rutina bottom half necesitar ser hecha. Esto lo hace colocando el bit apropiado en bh_active. El bit 8 es colocado si el controlador ha encolado algo en la cola inmediata y desea que se ejecute y se procese el controlador bottom half inmediato. La máscara de bits bh_active es verificada al final de cada system call, justo antes que el control sea devuelto al proceso llamador. Si hay algún bit colocado, las rutinas bottom half activas son llamadas. Primero se verifica el bit 0, luego el bit 1, y así hasta el bit 31.

Cada vez que una rutina de la bottom half es llamada el bit en bh_active es borrado. Así, cada activación sólo causa una ejecución. bh_active es transitorio; sólo tiene significado entre llamadas al planificador (scheduler) y es una forma de no llamar rutinas bottom half cuando no tienen trabajo que hacer.

Las Bottom halves que están esperando serán ejecutadas sólo cuando uno de los siguientes eventos ocurre:

El kernel finaliza la atención de una excepción.
El kernel finaliza la atención de una system call.
El kernel finaliza la atención de una interrupción.
El kernel ejecuta la función schedule() para seleccionar un nuevo proceso.

2.A.6 Ejemplo

El kernel necesita un sistema de sincronización para: mantener la cuenta de la hora y fecha para ser usada por ejemplo por gettimeofday(), y mantener el temporizador que notifica al kernel o a un programa de usuario que un intervalo de tiempo ha terminado.

Cada interrupción del timer: Actualiza los “momentos” (jiffies); Actualiza la hora y fecha; Determina cuanto tiempo un proceso se ha estado ejecutando y lo precede su porción de tiempo ha terminado; Actualiza las estadísticas de los recursos usados; Invoca funciones para intervalos de tiempo terminados.

Cuando una señal sobre la IRQ 0 es generada, se invoca timer_interrupt(), deshabilitando las interrupciones (la flag SA_INTERRUPT es activada para indicarlo). Finalmente do_timer() es ejecutada. Simplemente incrementa los “momentos” y asigna otras tareas a los controladores bottom half. Las bottom half actualizan la fecha y hora, estadísticas, ejecuta sus funciones antes que su intervalo de tiempo finalice e invoca schedule() si es necesario, para replanificar procesos.

do_timer() corre con las interrupciones deshabilitadas, y debe ser ejecutado lo más rápidamente posible. Esta simplemente actualiza un valor fundamental mientras que delega otras actividades a dos bottom halves.

La timer_bh() asociada con la bottom half TIMER_BH invoca la update_times() y run_timer_list().

La función update_times() invocada por la bottom half TIMER_BH actualiza xtime deshabilitando las interrupciones.

Cada vez que algún código quiere planificar una bottom half para que sea ejecutada, este llama a mark_bh. En la vieja implementación de BH, mark_bh colocaba un bit en la máscara, permitiendo a la correspondiente rutina bottom half ser encontrada rápidamente en tiempo de ejecución. En los kernel modernos, esta sólo llama traklet_schedule para planificar la rutina de bottom half para la ejecución.

División entre espacios de usuario y de kernel.

Un ejemplo de uso para las Bottom half es en las interfaces de red: una Top Half obtiene el paquete de datos y la top half la procesa.

2.A.7 Interrupciones de Software

La diferencia entre software interrupts y bottom halves es que las bottom halves son estrictamente serializadas (2 bottom halves no pueden ser ejecutadas al mismo tiempo), las software interrupt no es serializada, así se da la posibilidad de correr 2 mismas interrupciones en 2CPUs, en este caso una software interrupt puede ser reentrante.

2.A.8 Tasklet

Es un mecanismo similar a las bottom half, construidas sobre las software interrupts pero serializadas. 2 CPU pueden ejecutar 2 tasklets al mismo tiempo, pero esas tasklet deben ser diferentes.

2.A.9 LINUX 2.4 Bottom Half

Las Bottom half continúan en Linux 2.4, pero son construidas sobre las tasklets. No pueden correr al mismo tiempo en diferentes CPU, esto degrada el rendimiento significativamente de sistemas multiprocesadores.

2.A.10 Colas de Tareas

Las colas de tareas pueden ser pensadas como extensiones dinámicas de las viejas bottom halves.

2.A.11 Beneficios de usar Bottom Halves

Las Bottom halves son el mecanismo más viejo para diferir la ejecución de tareas al kernel y están disponibles desde el Linux 1.x.
La existencia de las bottom halves es muy importante para realizar responsabilidades del kernel atendiendo interrupciones de múltiples dispositivos rápidamente.
Los controladores de dispositivos y otras partes del kernel de linux pueden encolar el trabajo por hacer.

Anexo 2.B. Programa de ejemplo.

Es un programa muy sencillo que muestra cómo se construye la IDT, cómo se inicializan los 8259 y cómo se hacen las rutinas para atender a las interrupciones. Lo único que hace es esperar que pasen 20 segundos aproximadamente o que el usuario presione la tecla ESC. Consta de funciones escritas en C y en assembler y está hecho para correr en modo real (aunque luego pase a modo protegido), por eso es conveniente enlazarlo para DOS.

Archivo: ejprog.asm

GLOBAL _read_cr0, _write_cr0, _lgdt, _lidt, _update_cs, _enable, _disable, \

_timer_isr, _kbd_isr

EXTERN _timer_handler, _kbd_handler

SEGMENT _TEXT PUBLIC CLASS=CODE USE16

_read_cr0: ; devuelve el contenido del registro cr0

mov eax, cr0

mov edx, eax

shr edx, 16

retn ; dx:ax es contienen los datos que se devuelven

_write_cr0: ; carga el registro cr0 con el parámetro

push bp

mov bp, sp

mov eax, [ss:bp+4]

mov cr0, eax

pop bp

retn

_lgdt: ; carga el registro GDTR con el parámetro

push bp

mov bp, sp

push bx

mov bx, [ss:bp+4]

lgdt [ds:bx]

pop bx

pop bp

retn

_lidt: ; carga el registro IDTR con el parámetro

push bp

mov bp, sp

push bx

mov bx, [ss:bp+4]

lidt [ds:bx]

pop bx

pop bp

retn

_update_cs: ; carga el registro CS con el parámetro

push bp

mov bp, sp

mov ax, [ss:bp+4]

push ax

push word .1

retf

.1:

pop bp

retn

_enable: ; pone en 1 el flag IF

sti

retn

_disable: ; pone en 0 el flag IF

cli

retn

_timer_isr:

pushad ; salva todos los registros de uso general

call _timer_handler ; llama a timer_handler()

popad ; restaura todos los registros de uso general

iretd

_kbd_isr:

pushad ; salva todos los registros de uso general

call _kbd_handler ; llama a kbd_handler()

popad ; restaura todos los registros de uso general

iretd

Archivo: ejprog.c

#include <stdio.h>

extern unsigned long read_cr0();

extern void write_cr0(unsigned long);

extern void lgdt(struct GDTR*);

extern void lidt(struct IDTR*);

extern void update_cs(unsigned int);

extern void enable();

extern void disable();

extern interrupt timer_isr();

extern interrupt kbd_isr();

typedef unsigned char byte;

typedef unsigned int word;

typedef unsigned long dword;

/******************************************************************************/

/* Aquí se construye la GDT. Esta tabla define los segmentos en modo protegi- */

/* do. No se darán más detalles en este trabajo, sin embargo es posible en- */

/* contrar más información al respecto en los manuales de INTEL. */

/******************************************************************************/

#define ACS_CODE 0x9A

#define ACS_DATA 0x92

#define ACS_STACK 0x92

struct DESCR_SEG {

word limite,

base_l;

byte base_m,

acceso,

atributos,

base_h;

} gdt[4] = { 0 };

struct GDTR {

word limite;

dword base;

} gdtr;

void setup_GDT_entry (struct DESCR_SEG *item,

dword base, dword limite, byte acceso) {

item->limite = limite;

item->base_l = base;

item->base_m = base >> 16;

item->acceso = acceso;

}

void setup_GDT() {

setup_GDT_entry (&gdt[1], ((dword)_CS)<<4, 0xFFFF, ACS_CODE);

setup_GDT_entry (&gdt[2], ((dword)_DS)<<4, 0xFFFF, ACS_DATA);

setup_GDT_entry (&gdt[3], ((dword)_SS)<<4, 0xFFFF, ACS_STACK);

gdtr.base = ((dword) _DS)<<4;

gdtr.base += (word) gdt;

gdtr.limite = sizeof(gdt)-1;

lgdt(&gdtr);

}

/******************************************************************************/

/* Puertos */

#define PORT_8259M 0x20

#define PORT_8259S 0xA0

#define PORT_KBD_A 0x60

/* Palabras para los 8259 */

#define ICW1 0x11

#define ICW3M 0x04

#define ICW3S 0x02

#define ICW4 0x01

#define EOI 0x20

#define INT_GATE_CONFIG 0x8E00

#define CODE_SEG_SEL 0x08

/* Estructura de la interrupt-gates. */

struct int_gate {

word offset_l,

segmento,

config,

offset_h;

};

/* Estructura del registro IDTR. */

struct IDTR {

word limite;

dword base;

};

struct int_gate idt[0x22] = { 0 }; /* IDT */

struct IDTR idtr; /* IDTR */

byte old_IRQ_maskM, old_IRQ_maskS;

volatile byte scancode=0;

unsigned int ticks=0;

/* Función llamada por timer_isr(). */

void timer_handler() {

/* El BIOS ha configurado el timer para que envie interrupciones a una */

/* frecuencia de 18,2 Hz, por lo tanto en 20 segundos habra 364 inte- */

/* rrupciones aproximadamente. */

if (ticks++ == 364) scancode = 0x81;

outportb (PORT_8259M, EOI);

}

/* Función llamada por kbd_isr(). */

void kbd_handler() {

/* Leyendo el código de tecla. */

scancode = inportb (PORT_KBD_A);

outportb (PORT_8259M, EOI);

}

void setup_IDT() {

/* Cargando en la IDT las interrupt-gates para el timer y el teclado. */

idt[0x20].offset_l = (word) &timer_isr;

idt[0x20].segmento = CODE_SEG_SEL;

idt[0x20].config = INT_GATE_CONFIG;

idt[0x21].offset_l = (word) &kbd_isr;

idt[0x21].segmento = CODE_SEG_SEL;

idt[0x21].config = INT_GATE_CONFIG;

/* Cargando el registro IDTR. */

idtr.base = ((dword) _DS)<<4;

idtr.base += (word) idt;

idtr.limite = sizeof(idt)-1;

lidt(&idtr);

}

void setup_PIC (byte vector_maestro, byte vector_esclavo) {

outportb (PORT_8259M, ICW1); /* comienza la inicialización del 8259 */

outportb (PORT_8259S, ICW1);

outportb (PORT_8259M+1,vector_maestro); /* vector base para el maestro */

outportb (PORT_8259S+1,vector_esclavo); /* vector base para el esclavo */

outportb (PORT_8259M+1,ICW3M);

outportb (PORT_8259S+1,ICW3S);

outportb (PORT_8259M+1,ICW4);

outportb (PORT_8259S+1,ICW4);

}

int main() {

word old_CS, old_DS, old_SS;

printf("Programa de ejemplo: \"Atendiendo interrupciones\".\n\n");

printf("Para salir presione ESC o espere 20 segundos.");

/* Construyendo la GDT. */

setup_GDT();

/* Enmascarando las interrupciones (flag IF = 0). */

disable();

/* Construyendo la IDT. */

setup_IDT();

/* Salvando las máscaras IRQ. */

old_IRQ_maskM = inportb (PORT_8259M+1);

old_IRQ_maskS = inportb (PORT_8259S+1);

/* Inicializando el PIC para que los vectores de las IRQ vayan desde el */

/* 0x20 hasta el 0x2F. */

setup_PIC (0x20, 0x28);

/* Enmascarando todas las interrupciones excepto las del timer y las del */

/* teclado. */

outportb (PORT_8259M+1, 0xFC);

outportb (PORT_8259S+1, 0xFF);

/* Salvando el contenido de los registros de segmento. */

old_CS = _CS;

old_DS = _DS;

old_SS = _SS;

/* Pasando a modo protegido. */

write_cr0 (read_cr0() | 1L);

/* Cargando los registros de segmento con los valores para el modo pro- */

/* tegido. */

update_cs (0x08);

_ES = _DS = 0x10;

_SS = 0x18;

/* IF = 1 */

enable();

/* Esperando por ESC. */

while (scancode!=0x81) {}

/* IF = 0 */

disable();

/* Volviendo a modo real. */

write_cr0 (read_cr0() & 0xFFFFFFFEL);

/* Restaurando los registro de segmento. */

update_cs (old_CS);

_ES = _DS = old_DS;

_SS = old_SS;

/* Restaurando el IDTR. */

idtr.base = 0;

idtr.limite = 0x3FF;

lidt (&idtr);

/* Inicializando el PIC como estaba antes. */

setup_PIC (0x08, 0x70);

/* Restaurando las máscaras IRQ. */

outportb (PORT_8259M+1, old_IRQ_maskM);

outportb (PORT_8259S+1, old_IRQ_maskS);

/* IF = 1 */

enable();

return 0;

}

REFERENCIAS

Intel Architecture Software Developer’s Manual Volume 1
Intel Architecture Software Developer’s Manual Volume 3
webster.csu.cr.edu
www.beyondlogic.org
www.cources.ece.uiuc.edu/ece291/lecture/spring2003

apuntes de Computer Engineering II, Dr. Zbigniew Kalbarczyk, University of Illinois at Urbana- Champaign

wiki.cs.uiuc.edu/cs427
my.execpc.com/~greezer/osd/intr.
Linux Interrupts: The Basic Concepts, Mika J. Järvenpää, University of Helsinki, Department of Computer Science
The Linux Kernel, Boston University: Signals and Interrupts.
rdtb1.suwon.ac.kr

Real-Time & Multimedia Database Lab., The University of Suwon, Choi,Sook-Young

Guide to 80x86 assembly, Gavin Estey, 1995

La "reventa" del software

2010-11-22T17:51:00.004-03:00

Es un pensamiento por ahí al que se llega facilmente, pero se me vino a la cabeza en estos últimos días. Quizás nuevamente, porque ya se me habría aparecido en algún otro momento.

El software se convierte en un negocio interesante si se consigue desarrollar un vez y vender mil. Y esto no debe tomarse tan literalmente, porque a veces, aunque no vendamos un producto mil veces, podemos reutilizar las ideas (fragmentos de código, si se desea ser más concreto) en otro desarrollo, con lo que estaríamos revendiendo también.

Desarrollar software es altamente costoso, requiere un gran esfuerzo en aprender tecnologías, entender problemas, desarrollar conceptos, etc, etc, etc. Desarrollar para utilizar o vender pocas veces sencillamente no vale el esfuezo.

Este concepto no es solamente posible en el software, sino en toda "industria" intelectual, como bien saben los malos columnistas de los diarios berretas. Por ejemplo en el arte vemos a los creadores aplicar sus conceptos y repetirse, repetirse y repetirse, hasta que ya no puedan robar más y tengan que sentarse a crear algo nuevo.

El punto es que el "desarrollar una vez y vender mil" no sólo es una buena idea, sino que es la única viable para que este negocio funcione.

Es verdad que por ahí estoy descubriendo la pólvora en el siglo XXI, o por ahí ya reutilizaba y revendía pero no me había puesto a darme cuenta... ¡bueno che, soy algo lento!

Aquí les dejo un interesante artículo sobre la trampa de la reutilización del software:

http://techdistrict.kirkk.com/2009/07/08/reuse-is-the-dream-dead/

Bandera en ASCII

2010-06-19T17:51:00.001-03:00


   o
 <___>
  | |______    Argentina
  | |######)        200 años!!!
  | |#####(_________
  | |######|########)
  | |######|#######(_______________ 
  | |      |########|##############|
  | |      |########|##############|
  | |      |      __|##############|
  | |      |     /&&|##############|
  | |      |     \&&|              |
  | |######|      ^^|\             |
  | |######|########|/             |
  | |######|########|              |
  | |######|########|##############|
  | |~~~~~~|########|##############|
  | |      '~~~~~~~~|##############|
  | |               |##############|
  | |               '~~~~~~~~~~~~~~'
  | |
  | |

What the Hex?

2010-06-16T14:10:00.003-03:00

¡Adiviná el color!

No sé lo que quiero bajar, pero lo quiero ya

2010-06-11T15:13:00.004-03:00

Fuente: No te vayas, estúpida

Un signo de los tiempos, en este caso un signo de cómo andarán los niveles de ansiedad humana, es que los sitios de descargas en Internet, para no cobrarte, te amenazan con... 90 segundos de espera. Tremendo. Si pagás es ya, sin demora. Si no pagás, tenés que esperar... un minuto y medio. Ugh. Solo ciertos monjes zen (los más avanzados) logran superar esto y por tanto no estarían suscriptos a Rapidshare y seguirían bajando con semejantes demoras, allá en sus confortables chozas del Himalaya.

Sí, está bien, ahí dice que, además, lo que gratismente baja en media hora, garpando baja en tres minutos. ¿Y? Es media hora, andá a mirar ese pavo a las trufas que tenés al horno que no se te pase, y cuando volvés ya lo tenés igual, Dios mío, qué carajo nos pasa?

Bases de datos, passwords, seguridad y otras yerbas

2010-04-01T18:38:00.003-03:00

Fuente: Angel Freire Diario de un Programador

Mar 24, 2010

Hoy por la madrugada paso algo bastante fuerte: hackearon geelbe.com

Para los que no lo saben geelbe es un “club privado de compras”, un modelo distinto a sitios como Mercado Libre o De Remate donde cualquiera puede participar. La idea es lograr tener una red de confianza entre la gente que participa ya que solamente se entra por invitación.

Al margen de como funciona el sitio, esta madrugada se publico en Internet una lista de usuarios con su respectivo password. ¿Como es esto posible? Facil, los passwords estaban guardados en la base de datos en texto plano.

Existen varias formas en las que uno puede elegir guardar el password de sus usuarios en la base de datos, a saber: en texto plano, encriptadas, encriptadas con salt. Cada una tiene sus pro y sus contras, y de hecho dependiendo del tipo de aplicación que estemos desarrollando existen leyes al respecto.

Texto plano

Guardar las claves en texto plano es lo mas simple. Uno tiene registro del password de cada usuario y cuando este intenta ingresar al sistema se compara el password que nos provee contra el que tenemos en la base de datos, si es igual, lo dejamos pasar, si no es igual, impedimos que acceda.

Encriptada

Cuando uno encripta passwords utiliza algún tipo de hash, esto es, un algoritmo que da por resultado una cadena de texto que no se puede revertir al dato que se ingreso originalmente (el password).

Ejemplos de estos algoritmos son md5 y sha1, los mas utilizados en las aplicaciones WEB por cierto.

Encriptada con salt

Para entender la encriptacion con salt primero hay que ver una gran falencia en la encriptacion a secas: Si uno asume que su aplicación puede, por alguna falla de seguridad, llegar a dejar expuesta la base de datos, y por consiguiente tener acceso a los passwords encriptados, estos pueden llegar a ser revertidos.

¿Pero como? Si recién dije que se utilizan algoritmos por los cuales no se puede llegar al password partiendo del resultado del algoritmo, bien, existen lo que se conoce como rainbow tables, que son listas de los passwords ya encriptados y su correspondiente password en texto plano. De esta forma cuando uno tiene un password encriptado, puede ir a una rainbow table pre generada con millones de passwords y ver si lo encuentra ahí, de ser así, tiene la versión en texto plano del mismo. Obviamente también existe la “fuerza bruta”, esto es, teniendo el hash empezar a probar encriptar todas las combinaciones de letras, números, etc hasta llegar a algún hash que coincida, y ahí obtenemos el password original (o también se puede utilizar una lista de los passwords mas comunes para probar).

¿Como evitamos que alguien venga y compruebe los passwords guardados en la base de datos contra una rainbow table y obtenga el password original? Bueno, podemos, en lugar de guardar el hash del password, agregarle una pequeña cadena de texto “random” al password original, y después guardarnos el hash resultante de encriptar eso y también guardarnos la cadena. Esta es la practica mas extendida hoy en día y frameworks como Django ya lo hacen desde el vamos, también el cookbook de Ruby on Rails nos recomienda hacerlo. Es mucho menos probable que existan rainbow con el password mas una cadena al azar de que si existen rainbow tables con el password solamente.

Viendo estas tres opciones tenemos que decir que el caso de Geelbe coincida con el primero, ellos no encriptan los passwords guardados en la base de datos lo cual no seria problema si nadie pudiera acceder a la base de datos.

Puedo asumir que como quien tuvo acceso a los passwords los publico en la web, que no accedio al servidor, ya que su intencion era la de hacer algun daño a la imagen de Geelbe y de haber tenido acceso al servidor seguramente hubiera defaceado (ie: cambiado la pagina por algo tipo “hackeado por pepito”) y no solamente publicado los passwords. Seguramente el acceso se dio por algún SQL Injection como el que Patricio descubrió hace unas semanas en Infobae.

Otro detalle a tener en cuenta, y esta practica no esta tan extendida, es la elección del algoritmo para encriptar/hashear los passwords. Si bien las practicas comunes nos dicen que usemos md5 y sha1, lo cierto es que esos algoritmos no fueron diseñados para esa tarea, son efectivos, si, pero tienen un problema: son rápidos.

¿Que tiene de malo que sean rápidos? Cuando uno controla a un usuario que accede a su sitio por lo general guarda una cookie que. Esta cookie guarda solamente un identificador de sesión el cual en el servidor terminamos asociando con el usuario, esto quiere decir que solamente la primer ves que accede el usuario al sitio se comprueba su password. Así que no necesitamos que sea rápido. ¿Donde si es útil la velocidad del algoritmo de hasheo? Cuando uno trata de hacer brute force. Si vos tenes un hash y queres ir probando todas las palabras posibles contra ese hash, y cada intento te toma milésimas de segundo, vas a llegar mucho mas rápido a destino que si te toma 1 segundo cada intento. Es por eso que es recomendable utilizar algún algoritmo como bcrypt que si están diseñados para guardar passwords de usuarios (¡Es lento apropósito!).

Si la aplicación por otro lado tiene que manejar datos como tarjetas de crédito y cobros (PayPal, Google checkout, etc), recomiendo leer las guiás de PCI y los blogs de la gente que desarrolla los estándares de seguridad para ese tipo de aplicaciones (por suerte hasta ahora no me toco desarrollar ninguna así de critica).

Una nota al margen del objetivo del post (concientizar del sano storage de passwords): La gente de Geelbe esta haciendo un laburo groso, un SQL Injection no es un bug tan raro y el error grave que tuvieron (tener los passwords en pseudo texto plano) es corregible 100%, no seamos botones y pasemos la lista de usuarios afectados y sus passwords por ahí.

¿No sabe qué nombre ponerle a sus clases?

2010-03-22T15:52:00.003-03:00

Los verdaderos programadores

2010-03-15T18:42:00.000-03:00

Iterando strings en Java

2010-03-11T01:26:00.006-03:00

CharacterIterator it = new StringCharacterIterator("abcd");

for (char ch=it.first(); ch != CharacterIterator.DONE; ch=it.next())
...

O sea, Iterator tiene como subclase a CharacterIterator, pero a su vez CharacterIterator tiene como subclase a StringCharacterIterator. Glorioso, 130 caracteres de pura m...agia que hacen cosas tan dificiles como... ¿iterar sobre una cadena?

En otros lenguajes

C

for (char *c = string; *c != NULL; c++)
/* hacer algo con *c */

Python

for c in string:
# hacer algo con c

Los lenguajes de verdad vs Java

2010-02-16T01:42:00.004-03:00

(Por el regreso de Brainfuck)

def load():
 global a
 a = {}
 with open("mapa") as f:
     for i, l in enumerate(f):
         for j, c in enumerate(l):
             a[(j,i)] = c

load()

for k, v in a.iteritems():
 print k, "=", v

Acababa de escribir estas líneas en Python, lenguaje que no acostumbro a utilizar en mi trabajo habitual donde casi todo se hace con Java, para abrir un archivo de texto, leer los caracteres y colocarlos en un diccionario.

Mientras, recordaba cómo se hacía para abrir un archivo de texto en Java y leerlo, y encontraba por ahí:

import java.io.*;

public class ReadWriteTextFile {

/**
* Fetch the entire contents of a text file, and return it in a String.
* This style of implementation does not throw Exceptions to the caller.
*
* @param aFile is a file which already exists and can be read.
*/
static public String getContents(File aFile) {
//...checks on aFile are elided
    StringBuilder contents = new StringBuilder();

try {
  //use buffering, reading one line at a time
      //FileReader always assumes default encoding is OK!
      BufferedReader input =  new BufferedReader(new FileReader(aFile));
  try {
    String line = null; //not declared within while loop
        /*
    * readLine is a bit quirky :
    * it returns the content of a line MINUS the newline.
    * it returns null only for the END of the stream.
    * it returns an empty String if two newlines appear in a row.
    */
    while (( line = input.readLine()) != null){
      contents.append(line);
      contents.append(System.getProperty("line.separator"));
    }
  }
  finally {
    input.close();
  }
}
catch (IOException ex){
  ex.printStackTrace();
}

return contents.toString();
}

/**
* Change the contents of text file in its entirety, overwriting any
* existing text.
*
* This style of implementation throws all exceptions to the caller.
*
* @param aFile is an existing file which can be written to.
* @throws IllegalArgumentException if param does not comply.
* @throws FileNotFoundException if the file does not exist.
* @throws IOException if problem encountered during write.
*/
static public void setContents(File aFile, String aContents)
                             throws FileNotFoundException, IOException {
if (aFile == null) {
  throw new IllegalArgumentException("File should not be null.");
}
if (!aFile.exists()) {
  throw new FileNotFoundException ("File does not exist: " + aFile);
}
if (!aFile.isFile()) {
  throw new IllegalArgumentException("Should not be a directory: " + aFile);
}
if (!aFile.canWrite()) {
  throw new IllegalArgumentException("File cannot be written: " + aFile);
}

//use buffering
    Writer output = new BufferedWriter(new FileWriter(aFile));
try {
  //FileWriter always assumes default encoding is OK!
      output.write( aContents );
}
finally {
  output.close();
}
}

/** Simple test harness.   */
public static void main (String... aArguments) throws IOException {
File testFile = new File("C:\\Temp\\blah.txt");
System.out.println("Original file contents: " + getContents(testFile));
setContents(testFile, "The content of this file has been overwritten...");
System.out.println("New file contents: " + getContents(testFile));
}
}

Mi equipo de programadores

2010-02-12T15:45:00.001-03:00

La tierra de c++

2009-12-28T16:35:00.002-03:00

Porqué importa el software terminado

2009-12-11T08:00:00.000-03:00

Fuente: Dos Ideas

Escrito por Leonardo De Seta

Domingo 06 de Diciembre de 2009 13:38

Es bien sabido que en Scrum es muy importante tener software que funcione al final de cada sprint. Pero... ¿por qué? Joe Little comparte 4 buenas razones por las cuales tenemos que enfocarnos en tener software que funciona, siempre.

Las malas noticias no mejoran con el tiempo. Dicho de otra manera, es más barato arreglar un bug ahora que arreglarlo más tarde. O la arquitectura, o el diseño. Tiene que estar terminado.
Lo reconozco cuando lo veo. Los usuarios no pueden dar feedback sin algo concreto que mirar. Por lo que "terminado" también significa eso. Tiene que ser los suficientemente concreto para permitir el feedback (y si, a menudo eso son más malas noticias, antes).
No está terminado hasta que está terminado. Y vaya si habremos vivido esta pesadilla. Sólo si está terminado vamos a tener una idea de nuestro progreso real. Y de ahí podremos saber cuándo haremos la entrega.
No construir sobre una mala base. No queremos construir software nuevo por encima de software con errores. Si cambiamos algo abajo, la casa entera se nos podría caer. Nuevamente, ningún bug debe escapar al sprint.

Seguramente a ustedes se les ocurren más motivos por los cuales debemos tener software funcionando, siempre.

Estos son algunos de los motivos por los cuales la Definición de Terminado es un artefacto esencial dentro de Scrum.

Traducido de Why working software is important, por Joe Little.

Fusionando secuencias ordenedas con Python

2009-12-08T23:38:00.006-03:00

Este artículo explica la receta “Iterator Merge” (Iterador Fusión) escrita por Raymond Hettinger.

El objetivo de la misma es devolver una secuencia ordenada de ítems,
fusionando secuencias previamente ordenadas.

El algoritmo hace uso del módulo estándard heapq, el cual implementa una versión particular del algoritmo de cola de prioridad. A continuación se muestra el código completo de la receta y luego su explicación:

import heapq

def imerge(*iterables):
   '''Merge multiple sorted inputs into a single sorted output.

   Equivalent to:  sorted(itertools.chain(*iterables))

   >>> list(imerge([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
   [0, 1, 2, 3, 4, 5, 5, 7, 8, 10, 15, 20, 25]

   '''
   heappop, siftup, _StopIteration = heapq.heappop, heapq._siftup, StopIteration
  
   h = []
   h_append = h.append
   for it in map(iter, iterables):
       try:
           next = it.next
           h_append([next(), next])
       except _StopIteration:
           pass
   heapq.heapify(h)

   while 1:
       try:
           while 1:
               v, next = s = h[0]      # raises IndexError when h is empty
               yield v
               s[0] = next()           # raises StopIteration when exhausted
               siftup(h, 0)            # restore heap condition
       except _StopIteration:
           heappop(h)                  # remove empty iterator
       except IndexError:
           return

Línea 12: Se asignan atributos y nombres globales a variables locales, lo que acelera el acceso en la implementación estándard de Python (CPython)

Líneas 14 a 21: Se genera una lista con los primeros ítems y la función que devuelve el siguiente para cada una de las secuencias. La lista tendrá tantos ítems como secuencias se hayan pasado a la función.

Línea 22: Se transforma la lista en un montículo (heap) dejándola preparada para realizar las operaciones de la cola de prioridad.

Líneas 24 a 34: Se obtiene el primer item en la cola, se devuelve su valor y se reemplaza con el siguiente de la secuencia a la que pertenece el ítem devuelto (luego se recalculan las posiciones con siftup). En caso que no haya siguiente en esa secuencia, se elimina de la cola (heappop). La cola va quedando con el ítem y la función que devuelve el siguiente para las secuencias que no se agotaron. El algoritmo termina cuando la cola queda vacía.

Usos del algoritmo

El algoritmo es eficiente en la utilización de memoria, necesita mantener el menor ítem de cada secuencia y uno más al momento de reemplazarlo por el siguiente, lo que lo hace ideal para fusionar varios archivos con muchos ítems como para cargarlos todos en memoria, por ejemplo para fusionar varios archivos de logs ordenados por fecha.

El módulo heapq está disponible desde la versión de Python 2.3. A partir de la versión 2.6, Python incluye la función merge directamente en el módulo heapq, que hace lo mismo que la función imerge aquí presentada.

Referencias

Tabla periódica de Perl 6

2009-12-04T03:08:00.000-03:00

Dilbert: GUI button

2009-12-01T02:51:00.000-03:00

Traducción:

- ¿Por qué agregaste este botón a la interfaz?
- Porque usted me lo pedió.
- ¿Por qué pediría eso?
- Siempre sugiere cambios aleatorios para crear la ilusión de "valor agregado".
- Quita el botón.
- Sólo está en su copia.

Firefox es un panda

2009-11-13T14:46:00.005-03:00

Fuente: tintafantasma

Desde que salió este estupendo navegador, los usuarios que lo usan ha ido creciendo por monton, sin embargo pocos son los que conocen lo que realmente es un firefox. La mayoria de las personas lo llaman (en nuestra lengua) como “zorro de fuego”, “zorro incandesente”, etc; gracias al logo del Firefox visto a “simple vista”, sin embargo, ¿es realmente un zorro lo que vemos en ese logo?

Según Stateinslandzoo.org, Wellingtonzoo.com y CreativeBits, firefox es el nombre que se le da en chino al panda rojo.

The Chinese name for red panda is hunho or firefox, due to their colour and similar size to a fox.

En Wikipedia (ingles) también se afirma.

Si vemos bien al firefox (panda rojo), podemos ver que hay un gran parecido con el logo del navegador firefox…

Vs.

Fijense, ambos tienen un color similar, ambos tienen una orejitas puntiagudas, cola larga, nariz negrita, incluso fijense en la redondez de las patitas en ambos casos.
Ahora habrá que llamarlo…panda de fuego o panda rojo.

Post editado:
Y bueno tampoco nos hemos dado cuenta de las FAQ’s del mismo Firefox….

What’s a Firefox?

A “Firefox” is another name for the red panda.

Ver FAQ’s de Firefox

Saludos
The Ghost

El tutorial más corto sobre Autoconf y Automake

2009-11-11T08:00:00.000-03:00

Traducción del artículo de Paolo Bonzini (2 de Noviembre del 2009).

El problema con autotools es que se usa para cosas complicadas, y los programadores copian y pegan cosas complicadas aún cuando deben hacer algo simple. El 99% de los programadores sólo necesita acceder a los archivos .pc y generar sencillos Makefiles. De la parte de la portabilidad se encarga glib, sdl, etc.

Se puede usar los siguientes archivos autotools, de sólo 9 líneas, para comenzar desde allí y agregar más cosas luego (incluyendo libtool).

configure.ac:

AC_INIT([package], [version])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_CONFIG_SRCDIR([configure.ac])
AC_CONFIG_HEADERS([config.h])     # no es realmente necesario
AC_PROG_CC                        # o AC_PROG_CXX
AC_CONFIG_FILES([Makefile])
AC_OUTPUT

Makefile.am:

bin_PROGRAMS = hello
hello_SOURCES = hello.c

Suficiente para ejecutar:

$ autoreconf -fvi
$ ./configure
$ make

Para cada paquete que se necesite, se debe agregar:

PKG_CHECK_MODULES([cairo], [cairo])
PKG_CHECK_MODULES([fontconfig], [fontconfig])

AM_CFLAGS = $(cairo_CFLAGS) $(fontconfig_CFLAGS)
LIBS += $(cairo_LIBS) $(fontconfig_LIBS)

respectivamente en configure.ac (luego de AC_PROG_CC) y Makefile.am.

El juego más fácil del mundo

2009-11-09T08:00:00.001-03:00

Hace unas semanas escribí sobre el juego más difícil del mundo. Para los que se frustraron intentando pasar algún nivel, acá les traigo otro para saciar la sed de revancha...

Java Hashing

2009-11-07T16:27:00.001-03:00

Fuente: Dos Ideas

Escrito por Leonardo De Seta

Martes 27 de Octubre de 2009 10:22

Todos los objetos en Java tiene dos métodos muy importantes: el método hashCode() y el método equals(). Estos métodos están diseñados para ser sobreescritos de acuerdo a su contrato general.

En este artículo veremos porqué y cómo sobreescribir el método hashCode() que cumpla con el contrato para los HashCode.

El contrato de un HashCode

El contrato del hashCode() dice:

"Si dos objetos son iguales usando equals(), entonces la invocación a hashCode() de ambos objetos debe retornar el mismo valor"

Entonces, la pregunta que surge es: ¿es necesario que siempre se cumpla esa oración?

Consideremos una clase que tiene una implementación correcta del método equals(), ¿qué pasaría si no obedecemos el contrato anterior?

Para responder a esa pregunta, vamos a tener que considerar dos situaciones:

Objetos que son iguales, pero retornan diferentes hashCodes
Objetos que no son iguales, pero retornan el mismo hashCode

Objetos que son iguales, pero retornan diferentes hashCodes

¿Qué pasaría si dos objetos son iguales (invocando equals()) pero retornan diferentes hashCodes? El código se ejecutará a la perfección. Nunca vamos a encontrar problemas... hasta que se nos ocurra almacenar a nuestro objeto dentro de una colección como un HashSet o un HashMap. Cuando hagamos esto, nos vamos a encontrar con problemas raros durante la ejecución.

Primero tenemos que comprender cómo funcionan las clases del tipo HashSet y HashMap. Estas clases de colecciones dependen de que los objetos que son agregados cumplan con el contrato del hashCode. Vamos a obtener resultados impredecibles en tiempo de ejecución si no obedecemos el contrato y queremos almacenar estos objetos en la colección.

Veamos por ejemplo el HashMap. Cuando guardamos valores en un HashMap, estos valores en realidad se almacenan dentro de "baldes". Cada uno de estos baldes tiene asignado un número que lo identifica. Cuando agregamos un valor al HashMap, almacena el dato en uno de esos baldes. El balde que se usa depende del hashCode que devuelva el objeto a ser almacenado. Por ejemplo, si el método hashCode() del objeto retorna 49, entonces se almacena en el balde 49 dentro del HashMap.

Más tarde, cuando verifiquemos si la colección contiene al elemento invocando el método contains(elemento), el HashMap primero obtiene el hashCode de ese "elemento". Luego buscará el balde que corresponde a ese hashCode. Si el balde está vacio, significa que el HashMap no contiene al elemento y devuelve false.

Si hay un objeto o más dentro del balde, entonces se compara al "elemento" con todos los elementos en ese balde usando el método equals().

Objetos que no son iguales, pero retornan el mismo hashCode

El contrato del hashCode no dice nada sobre este caso. Por lo tanto, objetos distintos pueden devolver el mismo hashCode, pero las colecciones como los HashMap van a ser más ineficientes si se almacenan objetos diferentes con el mismo valor de hashCode.

¿Por qué almacenar en baldes?

Se utiliza este mecanismo de "baldes" por un tema de eficiencia. Pueden imaginarse que si todos los objetos que se agregan a un HashMap se almacenaran en una única lista grande, entonces tendríamos que comparar la entrada con todos los objetos de la lista para dterminar si un elemento en particular está contenido en el Map. Como se usan baldes, sólo se comparan los elementos del balde específico, y en general cada balde sólo almacena una pequeña cantidad de elementos en el HashMap.

Sobreescribir el método hashCode()

Puede resultar complejo escribir un buen método de hashCode() para una clase nueva.

Retornar un valor fijo (es una mala idea...)

Podemos implementar un método de hashCode() que devuelva un valor fijo, como por ejemplo:


//no hagan esto, genera mal rendimiento
@Override
public int hashCode() {
return 1;
}

Este método satisface todos los requerimientos y es "legal" de acuerdo al contrato del hashCode, pero no va a resultar muy eficiente. Si se usa este método, todos los objetos se almacenarán dentro del mismo balde (el correspondiente al "1"), y cuando querramos comprobar si un objeto específico está dentro de la colección, entonces siempre se tendrá que verificar el contenido completa de dicha colección.

Por otro lado, si sobreescribimos el método hashCode() y rompemos el contrato ("dos objetos iguales con equals deben devolver el mismo hashCode"), entonces cuando se invoque el método contains() podría devolver false para un elemento que se encuentra dentro de la colección, pero en un balde diferente.

Método de Effective Java

Joshua Bloch en su libro Effective Java nos brinda una buena guía para generar un valor de hashCode():

Guardar alguna constante con un valor distinto al cero; por ejemplo 17, en una variable int llamada result.
Para cada campo significativo f en el objeto (es decir, cada campo que se tiene en cuenta al ejecutar un equals()), hacer lo siguiente:
1. Calcular un int de hashCode para el campo:
  1. Si esl campo es un booleano, calcular c = (f ? 1 : 0)
  2. Si el campo es un byte, char, short o int, calcular c = (int) f
  3. Si el campo es un long, calcular c = (int) (f ^ (f >>> 32))
  4. Si el campo es un float, calcular c = Float.floatToIntBits(f)
  5. Si el campo es un double, calcular long l = Double.doubleToLongBits(f); c = (int) (l ^ (l >>> 32));
  6. Si el campo es una referencia a un objeto, calcular c = f.hashCode()
  7. Si el campo es un array, tratar a cada elemento por separado. Es decir, calcular el hashCode de cada elemento significativo usando las reglas anteriores.
2. Combinar el hashCode calculado c en el paso 2.1 en un resultado como sigue: result = 37 * result + c;
Retornar result
Mirar al hashCode() resultante y asegurarse que instancias iguales tengan el mismo hashCode.

Veamos un ejemplo de este algoritmo:


public class HashTest {
 private String campo1;
 private short  campo2;

 //resto de la clase...

 @Override
 public int hashCode() {
      int result = 17;
      result = 37*result + campo1.hashCode();
      result = 37*result + (int)campo2;
      return result;
 }
}

Como vemos elegimos la constante 37. La idea es ejegir un número que sea un número primo. Podemos elegir cualquier número primo. Al usar un número primo los objetos se distribuirán mejor en los baldes. Pueden aprender más sobre este algoritmo y la distribución que genera buscando en Internet.

Apache HashCodeBuilder

Como estamos aprendiendo, no es siempre facil retornar un buen valor de hashCode. Por suerte existen clases que nos pueden ayudar.

El paquete org.apache.commons.lang.builder de Jakarta-Commons contiene la clase HashCodeBuilder que está diseñada para ayudarnos a implementar el método hashCode(). Muchos desarrolladores luchan por escribir sus hashCode cuando existe esta clase que nos simplifica el proceso.

Así es como quedaría la clase de prueba anterior usando la clase HashCodeBuilder:


public class HashTest {
 private String campo1;
 private short  campo2;

 //resto de la clase...

 @Override
 public int hashCode() {
      return new HashCodeBuilder(83, 7)
           .append(campo1)
           .append(campo2)
           .toHashCode();
 }
}

Noten que los dos números del constructor del HashCodeBuilder son dos números impares distintos a cero - estos números ayuda a evitar la colisión de valores de hashCode en otros objetos.

Si se necesita, se puede invocar al hashCode() de la superclase usando appendSuper(int).

Resulta muy facil escribir el método hashCode() usando la clase Apache HashCodeBuilder.

Objetos mutables como clave

Como consejo general, deberíamos usar objetos inmutables como clave en una colección. El hashCode funciona mejor cuando se calcula con datos inmutables. Si usamos objetos mutables como clave y estos objetos cambian su estado de manera que el hashcode también cambia, entonces el objeto almacenado quedará ubicado en un balde incorrecto dentro de la colección.

La cosa más importante a consdierar cuando se implementa el hashCode() es que, sin importar cuándo se invoca a este método, tiene que producir el mismo valor para un objeto en particular cada vez que se invoca. Si tenemos un escenario en donde el objeto produce un valor de hashCode() cuando se invoca al put() del HashMap y luego produce otro valor durante un get(), en ese caso no podremos recuperar este objeto. Por lo tanto, si nuestro hashCode() depende de datos mutables en el objeto, cambiar estos datos con seguridad producirán una nueva clave al generar un hashCode() diferente.

Veamos el siguiente ejemplo:


public class Empleado {

 private String nombre;
 private int edad;

 public Empleado() { 
 }

 public Empleado(String nombre, int edad) {
      this.nombre = nombre;
      this.edad = edad;
 }

 public String getNombre() {
      return nombre;
 }

 public void setNombre(String nombre) {
      this.nombre= nombre;
 }

 public int getEdad() {
      return edad;
 }

 public void setEdad(int edad) {
      this.edad = edad;
 }

 @Override
 public boolean equals(Object obj) {
      if (obj instanceof Empleado) {
           Empleado emp = (Empleado)obj;
           return (emp.nombre.equals(nombre) && emp.edad == edad);
      }
      return false;
 }

 @Override
 public int hashCode() {
      return nombre.length() + edad;
 }

 public static void main(String[] args) {   
      Empleado e = new Empleado("muhammad", 24);
      Map map = new HashMap();
      map.put(e, "Muhammad Ali Khojaye");                

      // encuentra el resultado
      System.out.println(map.get(e));

      e.nombre = "abid";

      // el map devolverá null porque no lo encuentra
      System.out.println(map.get(e));

      // otra vez devolverá null
      System.out.println(map.get(new Empleado("muhammad", 24)));
 }
}

Vemos en el ejemplo anterior que obtenemos algunos resultados extraños. Después de cambiar el campo nombre, el cálculo del hashCode() devuelve un nuevo número y apuntará a un nuevo balde, por lo que el contains() devolverá false.

Podemos arreglar esta situación usando alguna de estas alternativas:

El hashcode es mejor calcularlo con datos inmutables; por lo tanto, asegurarnos que sólo usaremos objetos inmutables como claves de una colección.
Implementar el hashCode() usando la primer técnica: devolver un valor constante. En este caso tenemos que ser conscientes que estamos quitando todas las ventajas del mecanismo de baldes de las colecciones.
Si necesitamos incluiir campos mutables en el método de hashCode(), entonces podemos calcular y almacenar el valor del hash cuando se crea el objeto, y cada vez que se actualiza alguno de los campos mutables, primero debemos quitarlo de la colección y luego agregarlo nuevamente una vez hecho el cambio.

Traducido de Java Hashing, publicado en DZone.

awk continúa pateando traseros

2009-11-04T08:13:00.003-03:00

En comp.programming alguién envió un interesante programa de perl para imprimir sólo la primera aparición de cada línea (o sea, eliminar líneas repetidas) de un archivo preservando el orden de las mismas (o sea, no teniendo que ordenar el archivo previamente).

Recordemos que la mayoría de las veces esta tarea se realiza con el comando de Unix "uniq", que requiere que se ordene el archivo previamente con el comando "sort".

La línea es:

perl -ne 'print $_ unless $seen{$_}++'

Muy bueno. Sin embargo alguién respondió con la siguiente línea de awk:

awk '!o[$0]++'

¡¡¡IN-CRE-í-BLE!!!

Gadgets en abowman.com

2009-11-02T07:00:00.001-03:00

El programador Adam Bowman ofrece gadgets muy locos para decorar blogs, entre otras cosas, en este sitio.

Tcl/Tk, un lenguaje con actitud de rock

2009-10-29T07:00:00.001-03:00

Sin dudas el más grande invento desde los pañales descartables. Tcl/Tk es un lenguaje interpretado 100% libre creado por el profesor John K. Ousterhout en la universidad de California, que permite escribir scripts y programas de mayor complejidad con interfaces gráficas, sockets, bases de datos y decenas de extensiones para hacer de todo muy fácilmente.

Tcl/Tk se encuentra disponible para casi todas las plataformas, desde Linux hasta Windorch, pasando por Mac. Para programar en Tcl/Tk no hace falta ninguna herramienta especial, ni IDE. Sólo crear un archivo de texto nuevo, escribir nuestro código, y listo, si tenemos instalado el interprete ya se puede ejecutar.

Probablemente hay muchas razones por las que Tcl/Tk es popular, pero quiero nombrar algunas de las que dice en el propio sitio:

Desarrollo Rápido: la razón más importante por la cual la gente usa Tcl es que consigue realizar su trabajo más rápido. En muchos casos, usted puede implementar aplicaciones 5-10x más rápido con Tcl que con otros lenguajes, especialmente si la aplicación utiliza interfaces gráficas, manejo de "strings", estructuras dinámicas de datos, sockets o requiere integración.
Interfaces Gráficas: con Tk, Tcl ofrece facilidades para la creación de interfaces gráficas que son increíblemente simples pero muy potentes.
Multiplataforma: Tcl/Tk se ejecuta en Windows, Macintosh, y casi todas las plataformas Unix que se pueda imaginar. Proporciona API de alto nivel que le permite escribir código que funciona de la misma - en todas partes -, mientras que en Tcl/Tk se preocupa por respetar las diferencias de plataforma, como el aspecto y comportamiento nativo para el GUI.
Fácil de aprender: Tcl es un lenguaje muy simple. Los programadores experimentados pueden aprender Tcl y producir su primera aplicación interesante en tan sólo unas pocas horas o días. Los programadores casuales también puede aprender Tcl rápidamente.
Madurez: Tcl/Tk ha estado bajo continuo y activo desarrollo y uso por un gran grupo de expertos desde la década de 1990.
Deploy o Despliegue: los lenguajes dinámicos a menudo hacen más difícil la implementación, porque usted necesita obtener tanto el intérprete del lenguaje, las bibliotecas y la aplicación en cada máquina donde se ejecutará. Tcl/Tk ofrece soluciones muy interesantes para empaquetar todo esto en un único archivo ejecutable de poco más de 1MB.
Abundancia de bibliotecas: decenas de bibliotecas maduras, para hacer muchas cosas.
La comunidad: otra de las razones atractivas para el uso de Tcl es la gran comunidad de usuarios y desarrolladores que posee. La wiki es una fuente inagotable de recursos. También cuenta con un numeroso y solidario grupo de hackers, comp.lang.tcl, al que se puede recurrir cuando uno no encuentra soluciones.
¡Es Software Libre!

Como contra podría mencionar que hay muy pocos recursos en español, por lo que exige que conozcamos inglés básico.

Para mostrar la eficacia del lenguaje, copio de la wiki esta calculadora:

y el código de menos de 50 líneas:

¿Por dónde comenzar?

En la wiki hay varios recursos y enlaces a tutoriales. Me pareció que http://www.bin-co.com/tcl/tutorial/contents.php estaba más o menos bien. Aunque es en inglés, casi no se encuentran recursos en español para este lenguaje.

¿Dónde consigo Tcl/Tk?

Si está usando GNU/Linux, probablemente esté instalado o se encuentra en el repositorio de su distribución. Si está usando windorch, puede descargar ActiveTcl.

En este sitio he publicado un par de programitas hechos en Tcl/Tk, por lo que se pueden ver las entradas marcadas con dicha etiqueta.

Los lenguajes más populares

2009-10-27T07:28:00.000-03:00

El sitio http://langpop.com/ recopila datos acerca de los lenguajes de programación más populares.

Presentación de Log4j

2009-10-24T17:24:00.001-03:00

Log4j 1.2.15 Short Manual

View more presentations from Emmerson Miranda.

Construye tu propia tira cómica online

2009-10-24T17:03:00.002-03:00

Fuente: Oloblogger

Seguro que alguna vez hemos dejado de publicar un buen chiste que se nos pasó por la cabeza, simplemente porque no somos muy mañosos para el dibujo.

Esto se ha acabado porque hay muchas páginas que ofrecen herramientas para crear tu propia tira, así que el que no lo haga a partir de ahora es porque no le da la gana.

Monkey Dyne nos ofrece una forma muy sencilla de combinar personajes y texto. Aunque muy limitado, para diálogos de dos personajes resulta suficiente. Estos ya están diseñados y sólo hay que elegir cual ponemos a la izquierda y cual a la derecha. Admite hasta un bocadillo por personaje para cada una de las tres viñetas posibles.

En Witty Comics ya tenemos 48 personajes distintos y 60 fondos para elegir. Posibilidad de cambiar el bocadillo según sea un texto normal, pensamiento, grito o susurro. Personajes dibujados tipo años 70 y otros basados en animales. Previsualización directa.

Strip Generator tiene unos personajes mezcla de la Familia Adams y las Supernenas, pero permite mayor flexibilidad a la hora de crear y colocar los personajes. Con un catálogo aceptable de personajes, objetos y bocadillos, también permite cambiar los tamaños, rotar y la superposición de elementos.

Pixton tiene personajes muy simples prediseñados, que podemos personalizar algo más que en los anteriores casos: tamaño, cabello, color... e incluso cambiar la postura. La escena también es modificable y se pueden añadir objetos.

MakeBeliefsComix. Prácticamente todos los elementos son personalizables. Algo más flexible en cuanto al número de viñetas porque se puede elegir entre 2 y 4. Quince personajes a elegir con variaciones en cuanto a posición y expresión. También incluye la posibilidad de rotar, cambiar tamaño y posicionar libremente.

Pikistrips, aporta una variante que es la de subir las imágenes que quieras. Prácticamente me ha parecido un laboratorio de fotomontaje, pero adaptado al comic. Un montón de parámetros personalizables similares a los de los programas de edición de imágenes, bastantes modelos predefinidos de maquetado de viñetas y los bocadillos, que no podían faltar.

Bitstrips es el más completito, pero en consecuencia, el más complicado. Creo que no es recomendable para un trabajo esporádico, pero es el mejor si vas a hacer tiras con cierta frecuencia. Permite personalizar todos los rasgos de los personajes, así como su complexión, postura o vestimenta. Aunque tienes suficientes prediseñados para poder empezar, puedes crear tus propios personajes y guardarlos en tu librería personal. Muchos fondos, muchos objetos, muchos formatos de tira.

En casi todos los procesos de creación se dispone de un editor básico y de otro avanzado para poder recrearse un poco más.

La tabla periódica de las fuentes

2009-10-17T17:56:00.006-03:00

¿Por qué en GNU/Linux no hay virus?

2009-10-11T19:52:00.003-03:00

El último post de Steal This Software, de donde también tomé la foto, me llevó a copiar esto de una FAQ de Debian:

Los virus son la pesadilla de los administradores, cada mes aparecen mas de 30 mil y es un hecho que las actualizaciones mensuales de los antivirus no los incluyen a todos. Para los usuarios no expertos también son una molestia, los antivirus pueden hacer que una computadora pierda hasta el 30% de su veocidad. Cada año cientos de millones de dólares se pierden en horas/hombre (y horas/mujer ;-) ) por los virus en todo el mundo.

Para que un programa sea considerado como un virus debe cumplir dos requisitos:

1) Que se copie a sí mismo
2) Que se propague de manera "natural" entre los sistemas

Los gusanos son programas que aprovechan un exploit (error en el código de un programa) para infiltrarse en un sistema. Los troyanos son gusanos que abren un puerto trasero para permitir que una persona ajena entre al sistema. La diferencia principal entre los virus y los gusanos radica en que los virus se propagan sólos por la red, mientras que alguien (un hacker) debe realizar acciones especificas para implantar un gusano. Por cada máquina atacada por un gusano existen miles (quizás millones) de equipos infectados por virus. En GNU/Linux hay gusanos y troyanos, pero no virus.

Con frecuencia he escuchado la opinion de "expertos" que argumentan que en Linux no hay virus porque hay pocos equipos con este sistema operativo, pero que en cuanto se vuelva más popular los virus aparecerán. Obviando el hecho de que Unix/Linux poseen el 40% del mercado de servidores, esta opinión revela las pobres expectativas que Microsoft le ha impuesto al usuario común, pues según éste, es normal que todos los sistemas operativos sean afectados por los virus. Pero en realidad, solo Windows padece de los virus. No todo es culpa de Microsoft, no ha sido fácil llevar a un sistema operativo tan deficiente como Windows95 al exigente mundo de los servidores: en busca de un buen desempeño, se ha debido de pagar un precio en la seguridad de Windows XP y Windows 2003, quizás un precio demasiado alto.

El hecho, sin embargo, es que en Linux no hay ni habrá virus, (la verdad es que en ningún sistema operativo deberían de existir los virus), la razón radica en la gestión de memoria y la asignacion de permisos por omisión, los cuales hacen imposible que un programa no autorizado se ejecute y propague. Varias consultoras reportan que los servidores mas atacados en Internet son los basados en Linux, y la gran mayoria sale victorioso de la prueba. Sin embargo, esto no significa que este sistema operativo sea invulnerable: los programas y el mismo kernel poseen fallas que al ser explotadas permiten que, en casos extremos, un extraño tome control del equipo. La mejor manera de prepararse para un ataque es siendo uno mismo un hacker, escaneando los puerto de nuestro server, inyectando SQL en nuestras paginas web y tratando de ejecutar codigo malicioso. Lo más importante es frecuentar sitios que informen sobre fallos de seguridad, como linuxtoday.com y buscar actualizaciones para nuestro sistema cada siete dias. Existen muchas soluciones que automatizan este proceso.

El juego de la vida de Conway

2009-10-09T00:25:00.005-03:00

Se trata de un sencillo juego matemático que publicó el británico Conway en 1970.

Desde un punto de vista teórico (que excede la temática de este blog), es interesante porque es equivalente a una máquina universal de Turing, es decir, todo lo que se puede computar algorítmicamente se puede computar en el juego de la vida.

Se trata de un tablero con un número infinito de casilleros. Cada casillero se denomina "célula", y puede estar viva (color negro) o muerta (color blanco), según se quiera antes de comenzar la partida.

Una vez armado el tablero se da comienzo. El estado del tablero evoluciona a lo largo de unidades de tiempo discretas (se podría decir que por turnos). El estado de todas las células se tiene en cuenta para calcular el estado de las mismas al turno siguiente. Todas las células se actualizan simultáneamente.

Las transiciones dependen del número de células vecinas vivas:

Una célula muerta con exactamente 3 células vecinas vivas "nace" (al turno siguiente estará viva).
Una célula viva con 2 ó 3 células vecinas vivas sigue viva, en otro caso muere o permanece muerta (por "soledad" o "superpoblación").

¡Hermoso!

Hay un poco más de información en wikipedia, junto a varios enlaces de implementaciones del juego en varios lenguajes y plataformas. Pero me gustó esta hecha en Javascript.

Por último no descarto que me programe yo mismo uno en java o javascript algún día de estos.

El problema con la planificación

2009-10-06T23:40:00.001-03:00

Fuente: Dos Ideas

Escrito por Leonardo De Seta

Martes 06 de Octubre de 2009 09:47

Creo que estoy teniendo bastante éxito con mi carrera. Pero si hubiera sido mejor con la planificación, no hubiera logrado ni la mitad de las cosas que logré! De hecho, algunas cosas ni siquiera las hubiera comenzado...

Hay cosas que se pueden planificar, y otras que no. El problema es que la mayoría de las organizaciones esperan tener un plan. Y esperan cumplirlo sin importar lo que ocurra. Y esto no es realista.

Al hacer una planificación detallada se está presuponiendo que se sabe a donde se quiere ir, y que no vamos a influenciarnos por lo que ocurra en el camino - o al menos, no sin tener que hacer una gran re-planificación. En mi experiencia, esto provoca que los líderes de proyecto tengan una visión restringida.

No me malinterpreten - no estoy sugiriendo que se embarquen en un proyecto que no tenga una visión clara y robusta. Y no estoy sugiriendo que se embarquen en un proyecto en donde no tienen idea de lo que hay que lograr, y si es tiene objetivos razonables (aunque si desafiante) con los recursos disponibles. Y definitívamente es una buena idea armarse de un plan de alto nivel que tenga hitos; pero es un mapa de ruta de alto nivel en vez de un plan detallado.

Yo vengo de un entorno de desarrollo tradicional, y soy consciente que todo eso suena bastante loco. Y admito que se necesita cierto nivel de madurez y experiencia para reconocer que no se puede planificar en detalle por adelantado si queremos mantener la flexibilidad, como así lo exigen los requerimientos reales, riesgos, problemas, prioridades y oportunidades que van apareciendo a medida que construimos el software.

La mayoría de las organizaciones no están listas para aceptar esta idea tan radical - la idea de aceptar que no sabemos a donde estamos yendo (al menos, no con certeza), y que no sabemos cuál va a ser el retorno de la inversión, o cuándo ocurrirá. Entonces, como mínimo, es esencial contar con una visión clara y un plan de alto nivel. Sean cuidadosos de no entrar en detalles.

En vez de un plan detallado, prefiero una visión fuerte, una estrategia, metas, y un mapa de ruta (un plan de alto nivel). Las tácticas para lograr esto, por ejemplo las características precisas y todas las tareas a entregar, pueden variar en el camino y es mejor no planificarlas por adelantado. Esto le permite al equipo descubrir los detalles cuando están en una mejor posición para hacerlo, y les permite cambiar la dirección rápidamente en respuesta a las circunstancias cambiantes.

Y, cuando lo pensamos un poco, es el significado de ágil...

Café Instantáneo

2009-09-30T08:41:00.002-03:00

Café Instantáneo es la idea de utilizar scripts bastante sencillos para generar código. Surge de una necesidad personal de aumentar la productividad en el desarrollo de un par de sistemas web con Java.

Es más fácil copiar y pegar código conocido que escribirlo.

Esta necesidad se me presentó hace relativamente poco tiempo, por lo que actualmente sólo he desarrollado unas pocas horas (para ser generoso) en esta dirección. Sólo hice este script Tcl/Tk de pocas líneas para generar fuentes a partir de plantillas.

Habrá más café instantáneo en algún futuro.

Cómo NO hacer programas

2009-09-23T19:39:00.001-03:00

200610 - Antipatrones de Software

View more documents from Javier Gonzalez Sanchez.

El juego más difícil del mundo

2009-09-21T17:45:00.003-03:00

Es impozible!!! Muy difícil!!!

Unix, el sistema operativo "hackeable"

2009-09-20T04:29:00.002-03:00

Es indudable que Unix (en sus distintas implementaciones y clones) es el sistema operativo favorito de los hackers. Y cuando digo hackers no me refiero a los que se dedican a la seguridad informática, ya que esos son crackers, sino a los que estudian y practican la programación de computadoras por placer.

La principal razón de usar Unix es que este sistema operativo ofrece un ambiente muy propicio para la programación "casual".

A diferencia de otros sistemas, como MS windorch, Unix no establece una estricta barrera entre usuario y desarrollador. En windorch se da esta barrera porque el sistema no ofrece recursos para hacer programas o scripts ad hoc, como por ejemplo un buen interprete de comandos y un potente sistema de scripting. De hecho, windorch ni siquiera viene con un editor de texto decente en el que se pueda escribir una miserable línea de código.

La programación en windorch requiere de adquirir algún pesado y costoso entorno de desarrollo integrado, como .NET. Muy apto para uso profesional, pero muy poco adaptado para las necesidades del desarrollador casual.

Esta barrera molesta deja en claro que el sistema está pensado para que el usuario NO programe. Surge de una concepción de que el software es elaborado en un engorroso proyecto planificado y en un entorno más bien profesional, pero no a través de la escritura de pequeños programas o scripts por parte de los usuarios.

Algo muy distinto pasa en el mundo del Unix, donde el sistema sí viene con muchos recursos para programar modestas soluciones a medida. Se podría decir que Unix es un sistema "hackeable" ya que ofrece buenos editores de texto, con potentes interpretes de comandos y potentes sistemas de scripting. Sólo basta con abrir un archivo nuevo, y comenzar a escribir código y listo, ya estamos programando. En Unix casi que decir usuario es decir también programador.

El día internacional del software libre

2009-09-20T03:35:00.003-03:00

Software Freedom Day (SFD) es una celebración anual del software libre. SFD busca no sólo celebrar las virtudes del software libre, sino que además promocionar su uso.

SFD fue creado en el 2004 y se celebró el 28 de Agosto. Desde entonces ha crecido en popularidad. En el 2008 más de 500 agrupaciones en 90 países lo festejaron.

Desde el 2006 se decidió que se realizara el tercer sábado de cada Septiembre: 15 de Septiembre del 2007, 20 de Septiembre del 2008, 19 de Septiembre del 2009, etc.

La velocidad mata

2009-09-16T14:50:00.001-03:00

Fuente: Dos Ideas
Escrito por Leonardo De Seta

Miércoles 16 de Septiembre de 2009 09:30

Sos un programador. Eso signifca que tenés una presión tremenda por trabajar rápido. Hay fechas que cumplir. Hay bugs que arreglar antes de la gran demo. Hay calendarios productivos a los que llegar. Y tu trabajo depende de cuán rápido vayas y qué tan confiable seas para cumplir las planificaciones. Y esto significa que tenés que tomar atajos, compromisos, ser rápido y desprolijo.

Que estupidez.

Si, me escucharon. ¡Que estupidez! No existe el "rápido y desprolijo" en el software. La desprolijidad significa lentitud. La desprolijdad es la muerte.

El código malo hace que todos sean lentos. Vos lo sabes. Yo lo sé. Alguna vez, todos nos vimos retrasados por mal código. Nos volvimos lentos con mal código que escribimos hace un mes, hace dos semanas, incluso ayer. En el software hay una cosa seguro: si escribimos código malo, vamos a ir lento. Y si el código es muy malo, es probable que directamente nos detengamos.

La única forma de ir rápido es trabajar bien.

Y esto es simple sentido común. Podría citar frase tras frase al respecto. Cualquier cosa que vale la pena hacer, vale la pena hacerla bien. Un lugar para cada cosa, y cada cosa en su lugar. Lento y constante ganan la carrera. Y así, y así. Tenemos siglos de sabiduría que nos dicen que apurarse es mala idea. Y sin embargo, cuando la fecha se acerca...

La habilidad de los profesionales es su capacidad para tener intención. Los profesionales no se apuran. Los profesionales comprenden el valor de la prolijidad y la disciplina. Los profesionales no escriben mal código - nunca.

Equipo tras equipo caen en la tentación de apresurar las cosas en su código. Equipo tras equipo usaron largas horas de sobreesfuerzo en un intento de llegar con su producto al mercado. Y equipo tras equipo destruyeron los proyectos en el intento. Los equipos que empiezan a empiezan a apresurarse y hacer milagros, a menudo terminan arrastrándose en lentitud después de unos meses. Su código está tan mezclado, tan confuso, tan acoplado, que nadie puede hacer un cambio sin romper otro ocho módulos. Nadie puede tocar un módulo sin tener que tocar otros veinte. Y cada cambio introduce un nuevo efecto secundario impredecible, junto con más bugs. Las estimaciones se estiran de días a meses. El equipo se paraliza en una lentitud mortal. Los gerentes se vuelven locos, y los desarrolladores comienzan a buscar trabajos nuevos.

¿Y qué pueden hacer los líderes? Pueden gritar y gritar sobre que "hay que ir más rápido". Pueden apresurar más las fechas, para causar una sensación de urgencia. Pero al final, lo único que resulta es contratar más programadores. E incluso esto no funciona siempre, porque las nuevas personas van a terminar agregando más problemas por encima del problema viejo. En poco tiempo, el equipo volvió a estar lento, en una marcha continua e inexorable hacia la Productividad Cero.

¿Y quien es el responsable del desastre? Los programadores. Vos. Yo. Nos apresuramos. Hicimos lio. No mantuvimos la prolijidad. No actuamos profesionalmente.

Si queremos ser profesionales, si amamos esta profesión, entonces no debemos apresurarnos. Debemos mantener prolijo al código. Tan prolijo que casi no necesite comentarios.

Traducido de Speed kills, por Uncle Bob.

I wish I were the moon

2009-09-16T00:57:00.005-03:00

Extraño juego creado por el innovador desarrollador argentino independiente Daniel Benmergui inspirado en el cuento "La distancia de la Luna" del escritor italiano (nacido en Cuba) Italo Calvino. Consiste en encontrar los posibles finales de un triángulo amoroso entre dos enamorados y la luna.

Lo sorprendente es el modo de juego, que imita tomar una "fotografía" con el mouse y arrastrarla para interactuar con los distintos elementos de la pantalla. Casi no se utiliza texto para comunicarse con el usuario, se trata de apelar a la intuición del jugador, lo cual ayuda a establecer un vínculo emocional.

Los gráficos "retro" pixelados de bajísima resolución son increíbles. Le dan una estética muy bella ante los nostálgicos que vivieron algo de la historia de los videojuegos. Por otro parte intentan apartarse del hiperrealismo que, posibilitado por los recursos tecnológicos, nos propone un gran grupo de desarrolladores en estos tiempos.

Además el juego le rinde culto a la sencillez. Probando una vez más que lo simple es mejor... Una verdadera obra de arte.

Puede jugar aquí.

Ejemplo de GUI Bizarra...

2009-09-16T00:32:00.000-03:00

La siguiente captura de pantalla pertenece a un software de CMR bastante popular entre las compañías de telecomunicaciones. Pueden observar este cuadro de diálogo al finalizar el alta un cliente ADSL. Juro que no hay ningún tipo de edición sobre la imagen.

Podría argumentarse que esta interfaz no es bizarra, sólo estúpida... pero prefiero no hacer mucho ruido al respecto.

Sobre el IQ

2009-09-15T12:26:00.003-03:00

Fuente: Steal This Software

Hace rato que tenia ganas de escribir sobre esto. Cuantas veces uno ha oído "tal persona tiene tanto de IQ" o "determinado personaje posee un coeficiente intelectual de X"
Ahora, alguna vez uno se planteó qué es un IQ??
Según wikipedia el IQ es un resultado de un test:

El cociente intelectual o coeficiente intelectual,[1] abreviado CI (en inglés IQ) es un número que resulta de la realización de un test estandarizado para medir las habilidades cognitivas de una persona, "inteligencia", en relación con su grupo de edad.

La primera vez que me enteré de la existencia de esto (tendría unos 15 años) me pareció interesante, anque simplista voy a reconocer. Simplista para ser algo que "define" la inteligencia. O sea, vendría a ser, X individuo hace un test que consiste en N numero de preguntas (de logica, reconocimiento de series, patrones) y dependendiendo de como le vaya, es cuan inteligente es esa persona. Muy chato para mi gusto. Sin envargo realicé varios tests por curiosidad. No recuerdo los resultados (seguramente me salió que estoy en la media) pero lo que si recuerdo es que, siendo distintos los tests, hacer el primero me fue mas dificil que el segundo. Esto es, el hacer el primero me "entrenó" de alguna forma. Hizo que hacer el segundo fuera más sencillo, además de que sabía que esperar (a pesar de que los tests no eran iguales) me había mostrado una forma encarar ciertos problemas. Entonces, hice algunos más y noté que era como si justamente fuera un entrenamiento, practicar el tipo de ejercicios hacía que los posteriores costaran un poco menos.

De todo esto se desprende mi conclusión. Los tests de IQ dan un número a la habilidad/experiencia de una persona para resolver un tipo de problema. La inteligencia no es algo "medible" y mucho menos por completar unas series de cuadraditos o de números. Estos tests sólo dividen, y estancan. Le dicen a alguien "vos sos la media" como que no hubiera más remedio.

No me hubiera atrevido a publicar esta entradad (hubiera considerado que estos son disparates míos) si no fuera por un comentario que leí en un libro de Paenza (de las serie "matematica, estás ahí?") donde él mismo opinaba algo similar a mi.

Frase del día

2009-09-15T11:56:00.001-03:00

"Copiar de una fuente es plagiar, copiar de dos o más es investigar."

A Una Década Del Ultimo Sueño de Sega

2009-09-13T21:57:00.009-03:00

El pasado miércoles no fue un día cualquiera para los aficionados a los consolas de videojuegos (en especial para los que llevan más de 20 años arrastrándose por este mundo). Concretamente, se cumplieron diez años desde aquél memorable 9/9/99, fecha elegida por la filial norteamericana de Sega para el lanzamiento de la esperada Dreamcast en occidente, la que sería luego conocida como la mejor y la última consola de videojuegos de dicha compañía.

Si tuvieron la suerte de poseer una de estas maravillas (o al menos de haberla probado en casa de algún amigo / enemigo algo más afortunado), saben de lo que estoy hablando. Juegos como Soul Calibur (considerado por muchos como el mejor juego de lucha de la historia), Sonic Adventure, Virtua Tennis, Shenmue (maravilla técnica si las hubo), Power Stone, Skies Of Arkadia y Dead Or Alive 2 representaban los desarrollos cumbre en juegos de aquél entonces.

Sega venía de tiempos muy complicados: el rotundo fracaso de la Saturn (consola de 32bit que compartió su generación con Playstation y N64) y del Sega32X (una suerte de "upgrade" para la megaexitosa Genesis/Mega Drive) dejaron en bastantes apuros económicos a la compañía nipona, que no podía darse el lujo de fracasar nuevamente. El proyecto que devolvería los laureles a Sega se conocería inicialmente como Katana, y mediante una acertada jugada se lanzaría casi un año antes que sus competidores (la Playstation 2 de Sony, la Nintendo GameCube y el Xbox de Microsoft).

Algunas de las características técnicas más destacables de la Dreamcast eran su procesador de video (PowerVR2 de Nec); los VMU (una suerte de memory card con esteroides); el modem de 56k integrado (esta consola prácticamente inventó el juego online para este tipo de plataformas); y la posibilidad de utilizar un cable D-Sub para conectarlo a un monitor VGA o HDTV (mejorando notablemente la calidad de imagen).

El sistema de almacenamiento era el bizarro "GD-ROM", de manofactura propietaria, capaz de almacenar hasta 1GB de información. Una decisión bastante desacertada, por cierto, motivada principalmente por un intento para evitar la piratería. Por supuesto, dicho propósito no fue conseguido: los siempre hábiles piratas lograron hacer "rippings" en CD-ROMs convencionales, con algunos trucos realtivamente sencillos como eliminación de videos y resampleo de audio. Un lectora de DVD externa fue anunciada, pero lamentablemente no llegó a dar a luz.

En fin, una máquina que en teoría lo tenía casi todo como para llevarse al mundo por delante. Y eso era lo que parecía ocurrir en principio: durante su lanzamiento, el producto se agotó rápidamente, y al poco tiempo Sega se vió en dificultades para poder cumplir con la alta demanda de Dreamcast que el mercado exigía. Los primeros juegos fueron de un éxito notable, y en general eran una mezcla de conceptos relativamente nuevos (como Sonic Adventure o Shenmue) con clásicos arcades de Sega (como Daytona Usa, Crazy Taxi y Virtua Fighter). Los títulos deportivos de la línea Sega Sports son particularmente recordados (entre ellos el mítico Virtua Tennis).

¿Que ocurrió luego? Bueno, eso es motivo de divergente discusión, pero en general se coincide en lo siguiente: Sega no pudo destinar el dinero suficiente que un buen plan de Marketing requería, ni logró convencer a la suficiente cantidad de desarrolladores terceros de que publicaran en su consola (es particularmente llamativo el caso de Electronics Arts, que abiertamente le dió la espalda a Dreamcast. Pueden leer más acerca de esto en la referencias). Como resultado, la casa del erizo azul ya no poseía la solvencia financiera para seguir fabricando Dreamcast y sostenerla en el mercado. La ventaja inicial que había logrado sacarle a sus competidores se había esfumado, y Playstation 2 (a la que Sony estaba promocionando sin reparar en gastos de ningún tipo) comenzaba a apoderarse del mercado.

Marzo del 2001 fue el final del camino. Sega decidió centrar su antención en el desarrollo de software, abandonando el hardware definitivamente. Durante algún tiempo más, no obstante, siguieron saliendo considerables juegos nuevos, totalizando una biblioteca de bastante maś de 600 títulos. Asimismo, creció el círculo de desarrollos "homebrew" alrededor de esta consola (incluso hubo una versión del sistema GNU/Linux Debian preparada para correr en Dreamcast).

Sintetizando, Dreamcast no logró devolverle a Sega el lugar que en el pasado había alcanzado con éxitos como el Master System y el Sega Genesis, pero indudablemente no puede considerársele un fracaso. Fue un rotundo suceso comercial que, aunque breve, batió varias marcas. Dreamcast innovó en varios aspectos (como el del juego online), y definió nuevos estándares de calidad para los desarrollos de las generaciones siguientes (Soul Calibur sigue viéndose maś que bien hoy día, incluso pese a sus años). Y principalmente, brindó muchas horas de sano entretenimiento a incontables usuarios. Entre ellos se encuentra quién escribe estas líneas, en un intento de brindarle un humilde homenaje a tan formidable pieza de hardware, de una época muy destacable dentro de la historia de los videojuegos.

Referencias

Entrada en Wikipedia
http://en.wikipedia.org/wiki/Dreamcast

Artículo conmemorativo en Gamasutra, con interesantes entrevistas a los involucrados en la producción de la consola
http://www.gamasutra.com/view/feature/4128/the_rise_and_fall_of_the_dreamcast.php?

No se recomienda borrar datos

2009-09-10T14:33:00.002-03:00

Fuente: Dos Ideas

Escrito por Leonardo De Seta

Miércoles 09 de Septiembre de 2009 17:43

En las bases de datos, la eliminación lógica es aquella que ocurre al activar una marca de "eliminado" al registro, mientras que la eliminación física consiste en eliminar realmente el registro de la base. ¿Cuál estrategia es mejor?

Quienes aplican el borrado lógica sugieren agregar una columna "eliminado" a la tabla, y dejar los datos intactos. Una fila se considera borrada si la columna "eliminado" contiene un "true". Este enfoque es simple, facil de entender, rápido para implemente y explicar, pero a menudo se implementa mal. El problema es que, en general, eliminar una fila o entidad no es un evento simple. No sólo afecta a los datos del modelo, sino también a la forma del modelo. Es por esto que existen las claves foráneas, para asegurarnos de no terminar con Items de Factura sin una Factura padre. Y este es el más sencillo de los ejemplos...

Cuando hay que lidiar con las bajas lógicas, es facil terminar en situaciones de corrupción de datos. Por ejemplo, el campo "última órden" del Cliente (una optimización que nadie se acordó) podría terminar apuntando a una Orden con baja lógica.

Entonces, si un desarrollador tiene que borrar un registro de la base, y las bajas lógicas parecen desrecomendadas, queda la opción de las bajas físicas. Para preservar la integridad de datos, deberemos eliminar la fila en cuestión y todas las filas relacionadas en cascada. Pero en el mundo real la cascada no es posible.

Supongamos que el departamento de marketing decide eliminar un producto del catálogo. ¿Deberían desaparecer también todas las órdenes que contienen ese producto? Y si continuamos la cascada, ¿deberíamos borrar todas las peticiones para esas órdenes también? Y siguiendo, ¿deberíamos rearmar el resumen financiero de la empresa?

Obviamente, no.

El problema viene por la interpretación del "eliminar". En el ejemplo anterior, cuando marketing dice "eliminar", se refiere a discontinuar un producto. No queremos vender más este producto. Queremos quitarlo del inventario, y no hacer más pedidos a nuestro proveedor. El producto no debería aprecer más cuando nuestros clientes hacen una búsqueda en el sitio, pero la gente del almacen va a tener que seguir gestionando este producto en el interín. Por supuesto, es mucho más facil decir "eliminar el producto" que explicar todo esto.

Entonces, tenemos varias interpretaciones del "eliminar" para los usuarios:

Las órdenes de compra no se borran: se cancelan. De hecho, también podría haber cargos extra por cancelar una órden tarde.
Los empleados no se borran: renuncian, se jubilan o se los despide. También es probable que haya que gestionar una compensación.
Los puestos no se borran: se cubren (cuando entra un candidato).
y así...

En todos los casos, debemos enfocarnos en la tarea que el usuario desea realizar, en vez de en acciones técnicas sobre la base de datos.

En vez de enfocarnos en una columna "eliminado", lo mejor es usar un campo que contenga el estado del dato: activo, discontinuado, cancelado, obsoleto, etc. Estos campos de estado le permiten al usuario mirar los datos históricos y tomar decisiones.

La eliminacion física de datos puede tener consecuencias negativas más allá de romper la integridad. Tenemos que tener mucho cuidado cuando intentamos una eliminación física. Y como regla general, no borremos nada.

Basado en Deleting data is not a recommended practice.

Programación Talabartera Volumen 1

2009-09-09T14:50:00.003-03:00

Hoy: Cómo verificar que una variable sea un entero en BASH...

(tomado de por ahí)

1)


if [ $VARIABLE -eq $VARIABLE 2> /dev/null ]; then
 echo "integer"
else
 echo "not integer"
fi


echo "${VAR}" | grep "[^0-9]" > /dev/null >&1
if [ "$?" -eq "0" ]; then
 echo string
else
 echo integer
fi


if [ $VARIABLE -ge 0 2>/dev/null ]; then


echo "${VAR}" | grep -v -- "^-\?[0-9]\+$" > /dev/null >&1
if [ "$?" -eq "0" ]; then
  echo string
else
  echo integer
fi


if (($x)); then
 echo "true"
else
 echo "false"
fi


if (($x)) 2>/dev/null; then
 echo "true"
else
 echo "false"
fi


if echo $VAR | grep -Eq '^[+-]?[0-9]+$'
then
 echo integer
else
 echo non integer
fi

Recreo: el diccionario del Eclipse

2009-09-08T12:04:00.003-03:00

Hoy...

más de cerca...

La felicidad del usuario según la funcionalidad del software

2009-09-07T15:30:00.003-03:00

Anda dando vueltas por ahí...

Consejos para Entrevistar Usuarios

2009-08-01T17:51:00.001-03:00

Copyright (c) 2009 Héctor Francisco Hernández <hectorfh@gmail.com>.

La copia exacta y la distribución de copias exactas de esta página son
permitidas mundialmente en cualquier medio, provisto que esta nota se
mantenga.

Mis andanzas por el mundo de la informática y la computación son de variopintas naturalezas. Estos consejos surgen de mi experiencia en el último proyecto en el que he estado involucrado. De la necesidad de hacer análisis y relevamiento y de tener que entrevistar a los futuros usuarios del nuevo sistema.
Dada mi relativamente corta trayectoria como desarrollador, era la primera vez que me encontraba haciendo este tipo de trabajo.
Afortunadamente las entrevistas fueron exitosas y muy fructíferas, ya que me aportaron valiosísima información, que no estaba disponible de otra forma, para completar mi análisis. Y además he aprendido algunas cosas que aquí les dejo.

Sobre el Planeamiento

Tenga un plan: Lo primero y lo fundamental en una entrevista es tener un plan bien claro acerca de qué información se quiere obtener y de qué manera se va a obtener. En función de ello se deben seleccionar las preguntas cuidadosamente. Recuerde que la mayor parte de la entrevista consiste en su planeamiento y búsqueda de las preguntas adecuadas. Es ahí donde debe invertir el tiempo.
Pregunte eficazmente: Las preguntas no deben ser abiertas por demás, deben ser precisas y eficaces. De este modo, si es posible trate de hacer preguntas que admitan una cantidad de respuestas acotadas. En ese caso podría hasta leerle las posibles respuestas al usuario. Por ejemplo, si desea saber qué funciones del sistema actual el usuario utiliza, no le pregunte "¿Qué funciones del sistema actual utiliza?", en vez de eso pregúntele "¿Cuáles de las siguientes funciones del sistema actual utiliza?" y proceda a leerle las funciones. Esto le ayudará al usuario a no olvidarse de ninguna y a usted a obtener una respuesta previsible y manejable.
Pregunte sobre lo que el usuario sabe: No haga preguntas cuya respuesta el usuario desconoce, o que no es obligación que conozca. Recuerde que el usuario sabe perfectamente cómo se hace el trabajo que le toca realizar porque así se lo indicaron, pero difícilmente conozca cómo se podría mejorar o de qué otra manera se podría realizar. El usuario no ha pensado en ello porque por lo general no es su trabajo. En cambio, es buena idea que usted, que es analista, sí lo piense. Recuerde que es el médico el que hace el diagnóstico y establece el tratamiento, no el paciente.
Lo bueno, si breve, dos veces bueno: Trate de que la entrevista sea lo más breve posible. Hay dos razones para hacer esto, la primera es que a medida que el tiempo pasa, las ganas y la concentración de usted y el entrevistado van disminuyendo y las cosas se van volviendo más difíciles. La segunda es por una cuestión de respeto hacia el entrevistado que gentilmente y sin obligación le está cediendo su tiempo.

Durante la Entrevista

Dirija la charla: Durante la entrevista usted debe dirigir la charla en todo momento, de lo contrario le dará la oportunidad al entrevistado de hacerlo y se podría entrar en divagaciones sobre asuntos irrelevantes. Esto no le será difícil si ha planeado correctamente. De este modo usted hablará como quien conoce acerca de lo que está preguntando y sabe exactamente lo que quiere. Por lo que el entrevistado no pensará que es un improvisado que está perdiendo el tiempo y se lo está haciendo perder a él también.
Escuche: Escuche atentamente al usuario, con la menor cantidad de prejuicios posibles, y evite dar por sabidas las respuestas
de antemano. Muchas veces el usuario suele dar respuestas distintas a
las que esperamos. También evite emitir juicios personales, que casi nunca vienen al caso.
Escriba durante la entrevista: Escriba lo que el usuario le va contando, es lo que debe hacer si no tiene una memoria privilegiada o poco ocupada en donde pueda grabar todo. Personalmente, y por una saturación (o limitación) mental, suelo olvidar lo que no he anotado.
Haga amigos: Aproveche la entrevista para cultivar o consolidar relaciones, es su
oportunidad para "caer bien" y para que lo tengan presente. Los usuarios
juegan un papel fundamental en el desarrollo de los sistemas y en el
éxito o fracaso de sus proyectos, por lo que parte de su trabajo
consiste en "hacer sociales". Desarrolle sus aptitudes en comunicación,
son de vital importancia y de gran valor.
Sea agradecido: Es buena idea ir por la vida sonriendo y agradeciendo a Dios, pero en este caso particular recuerde que el entrevistado no tiene la obligación de colaborar con
usted. No es él quién lo necesita, sino es usted quien lo necesita a
él. Por lo que debe estar sumamente agradecido por el tiempo y la
atención que le brinda y estará moralmente en deuda. También recuerde
que esto
es un ida y vuelta y que es buena idea devolver las atenciones.

Luego de la Entrevista

Luego de la entrevista es muy importante que documente las respuestas del usuario y la información obtenida. La razones para ello son a) no olvidar las respuestas, b) poder compartirlas y además c) nos servirá para cuando tengamos que rendir cuentas acerca de nuestro trabajo.

¿Qué es el Software?

2009-06-15T22:47:00.005-03:00

Copyright (c) 2009 Héctor Francisco Hernández <hectorfh@gmail.com>.

La copia exacta y la distribución de copias exactas de esta página son permitidas mundialmente en cualquier medio, provisto que esta nota se mantenga.

Dice un importante libro de ingeniería de software:

Muchas personas asocian el término software con los programas de computadora. De hecho, ésta es una visión muy restrictiva. El software no son sólo programas, sino todos los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta. Por lo general, un sistema de software consiste de diversos programas independientes, archivos de configuración que se utilizan para ejecutar estos programas, un sistema de documentación que describe la estructura del sistema, la documentación para el usuario que explica cómo utilizar el sistema y, en cuanto a los productos de software, sitios Web que permitan a los usuarios descargar la información de productos recientes.

Claro está que asociar el término "software" con los programas de computadoras es una visión restrictiva. Sin embargo, la visión del autor acerca del término también lo es. El punto es que en ningún momento se ha incluído a las personas como parte de un sistema "software", ni a los usuarios, ni a los desarrolladores, ni a los implementadores. ¿Acaso no lo son?

En mi opinión, el "software" es poco más que conocimiento. Construir un sistema consiste en generar conocimiento, parte de este conocimiento se plasma en el código fuente de los programas, otra en la documentación, pero gran parte se encuentra en el cerebro de los desarrolladores y de los usuarios. Es mencionado como "conocimiento tácito", a diferencia del otro que se llama "conocimiento explícito". Mucho de este conocimiento tácito no es posible codificarlo (convertirlo en conocimiento explícito) ni transferirlo. ¿Acaso no es este conocimiento parte del sistema?

Poseer una visión u otra cambiará las decisiones que tomemos a la hora de gestionar proyectos software. Si no consideramos a las personas como parte de él, probablemente creamos que sea posible dejar ir a un desarrollador, por ejemplo, sin perder un pedazo del sistema. Debemos prever antes de comenzar el proyecto que una parte importante de los resultados obtenidos será el conocimiento logrado por la gente que participe de él. Este conocimiento es también patrimonio de la organización (se conoce como capital intelectual) y debe ser gestionado, sería inocente ignorarlo y no actuar en consecuencia.

Resumiendo mi idea, creo que el software no se trata de programas de computadora, de manuales de usuario o de diagramas UML, sino de conocimiento. Esas son sólo algunas de las formas en las que el conocimiento puede presentarse, pero existen otras más complejas. No reconocerlas podría conducir a tomar malas decisiones.

Referencias

Artículo de la Wikipedia acerca de la Gestión del Conocimiento

Libro "Ingeniería del Software" de Ian Sommerville

Herramientas Libres para OLAP: Mondrian y JPivot

2009-04-05T19:35:00.037-03:00

Presentación de Mondrian y JPivot, dos herramientas libres para OLAP en Java

Copyright (c) 2009 Héctor Francisco Hernández <hectorfh@gmail.com>.
Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, Versión 1.3 o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia se encuentra en http://www.gnu.org/copyleft/fdl.html.

I. ¿Qué es OLAP?

OLAP suele ser el primer paso en el campo de la inteligencia de negocio (Business Intelligence) en toda organización.

Repasemos brevemente el concepto de sistema transaccional con el fin de introducir OLAP.

En informática, los sistemas transaccionales son aquellos que están hechos para registrar y soportar las transacciones de negocio, por ejemplo operaciones empresariales como la venta, la compra, la adquisición de créditos, el pago, entre otras.

Se suele llamar a esta clase de uso de sistemas informáticos OLTP, "On Line Transaction Processing".

Estos sistemas deben estar preparados para soportar un gran número de usuarios en línea y distintos tipos de operaciones de manera concurrente. Y suelen tener la característica de que la interacción entre el usuario y el sistema es relativamente corta: menos de un segundo en muchos casos. La operación de negocio se llevará a cabo completamente a través de varias interacciones cortas que exigirán una respuesta inmediata. Además deben proveer datos actualizados hasta la última transacción; deben estar disponibles de forma continua; deben ser rápidos; y deben brindar la protección e integridad de los datos.

Sin embargo el universo informático dentro de una organización no termina en las aplicaciones OLTP. Existen otras aplicaciones, generalmente destinadas a soportar la toma de decisiones, que consisten en analizar una gran cantidad de datos para generar informes de negocio de ventas, mercadotecnia, informes de dirección y áreas similares.

Esta aplicación de sistemas informáticos se suele denominar OLAP, "On Line Analytical Processing".

OLAP (online analytical processing o procesamiento analítico en línea) es un término acuñado por EF Codd & Associates, que publicó un libro blanco en 1993, encargado por Arbor Software (en la actualidad Hyperion Solutions), titulado "Prestación de OLAP (Procesamiento Analítico On-Line) para análisis de usuario: Un mandato de las TI".

"En Línea" implica que aún cuando grandes cantidades de datos están involucradas en las consultas, el sistema debe responder lo suficientemente rápido como para permitir ser usado de manera interactiva.

Hay que remarcar que Codd cobró para escribir este libro blanco de apoyo a Essbase (producto comercial de Arbor). El documento de Codd fue visto como propaganda parcial.

Estos sistemas recolectan y procesan información registrada por los sistemas transaccionales de la organización y ponen los resultados a disposición del usuario a través de reportes que se generan de manera instantanea. Estos datos son utilizados generalmente para tomar decisiones y por lo general no necesitan estar actualizados al día de la fecha. Por ejemplo, el usuario requiere un informe de ventas del último cuatrimestre, o se precisa una comparación de los gastos en los últimos años.

La siguiente captura de pantalla muestra un reporte OLAP clásico.

(Reporte OLAP generado con JPivot)

Bases de datos OLAP

Aunque existen muchas herramientas de generación de informes que operan sobre las bases de datos de los sistemas transaccionales, suelen ser lentas.

Los diseños de estas bases de datos están pensados para realizar altas, bajas y modificaciones de la forma más óptima, teniendo un mínimo grado de redundancia de información posible. Esto significa que se tiende a la normalización.

Sin embargo la normalización puede hacer lentas las consultas complejas, ya que al estar la información distribuida en muchas tablas es necesario calcular productos cartesianos complejos (en sql "inner join", "outer join", el operador coma) y en gran cantidad. Este tipo de operaciones es de los más costosos para el motor de base de datos.

Cuando las consultas implican cruzar varias tablas de decenas o cientos de miles de registros, el sistema no responde satisfactoriamente. Además de tardar varios minutos en presentar la información, se consumen recursos haciendo más lento y degradando el servicio prestado por el sistema a los otros usuarios en línea.

La solución adoptada consiste es extraer, tranformar y cargar (ETL: Extract, Transform and Load) los datos a una base exclusiva para OLAP. Si bien las bases de datos relacionales, u orientadas a objetos en los sistemas más recientes, son las utilizadas comunmente en las aplicaciones OLTP, en el mundo OLAP las bases de datos impuestas son las multidimensionales.

Conceptualmente, una base de datos multidimensional utiliza la idea de "cubos". Un cubo posee N dimensiones y en él están registrados "hechos" de un determinado tipo. Los hechos podrían ser, por ejemplo, desde las ventas realizadas por una empresa (según estudios la utilización de OLAP para el analisis de ventas es la aplicación más popular) hasta los defectos que reportan los usuarios de un sistema informático, según cuál fuese la finalidad de la aplicación.

Cada "hecho" tiene asociado un elemento de cada dimensión definida para el cubo. Por ejemplo, si el cubo registra ventas, cada venta tiene asociado un lugar geográfico (dimensión geográfica), el día en el que ocurrió (dimensión temporal), el producto que se vendió (dimensión de tipo), etc.

Además el "hecho" tiene valores asociados, por ejemplo el importe por el cual se realizó la venta o la cantidad de unidades vendidas.

Poseyendo estos tres elementos, a saber, un tipo de hecho, un conjunto de dimensiones y un conjunto de valores, queda conformado un cubo capaz de responder preguntas como cuántas ventas de determinado artículo se realizaron en el mes de febrero, o cuál es el producto más vendido del trimestre pasado en la ciudad de Córdoba.

Para consultar estos datos al cubo se necesita una herramienta fundamental. Así como existen lenguajes de consultas en los otros paradigmas de bases de datos (SQL, HQL), para las bases multidimensionales el lenguaje es MDX: MultiDimensional eXpressions.

MDX fue presentado como parte de la especificación OLE DB for OLAP (ODBO) en 1997 por Microsoft, con Mosha Pasumansky siendo uno de los arquitectos del lenguaje. Luego de la especificación siguió el lanzamiento comercial de Microsoft OLAP Services 7.0 en 1998 y más tarde Microsoft Analysis Services. La última versión de la especificación OLE DB for OLAP (ODBO) fue publicada por Microsoft en 1999.

Aunque no es un estándar, sino más bien una especificación propietaria de Microsoft, ha sido adoptada por una amplia gama de compañías en diversos productos, entre los que se incluyen Applix, Microstrategy, SAS, SAP, Whitelight, NCR, Panorama Software, Proclarity, AppSource, Cognos, Business Objects, Brio Technology, Crystal Reports, Microsoft Excel, Microsoft Reporting Services, etc.

Un ejemplo de consulta MDX es la siguiente:


SELECT
 { [Measures].[Importe] } ON COLUMNS,
 { [Tiempo].[2002], [Tiempo].[2003] } ON ROWS
FROM Ventas
WHERE ( [Sucursal].[Zona Oeste].[Tablada] )

Esta consulta obtiene como resultado un reporte OLAP, de un aspecto similar a la captura de pantalla mostrada más arriba, con los totales de las ventas realizadas por una sucursal llamada "Tablada" de una cadena de mercados mostrando los años 2002 y 2003 en el eje vertical. No tienen mucha importancia por el momento los detalles de qué es lo que se consigue con la consulta, sólo qué aspecto tiene el lenguaje MDX. Nótese una fuerte inspiración en el lenguaje SQL, el "select-from-where".

II. Herramientas Libres para OLAP: Mondrian y JPivot

Existe más de una solución OLAP en el mercado. Entre las herramientas disponibles se incluyen motores para implementar bases de datos multidimensionales nativas (solución MOLAP) o para emularlas sobre una implementación relacional (solución ROLAP), diseñadores de cubos, navegadores, generadores de reportes, graficadores, programas para realizar la extracción, transformación y carga de datos (ETL) desde bases transaccionales.

La mayoría de estas herramientas son privativas y requieren de la adquisición de una licencia para poder usarlas. Sin embargo ya comienzan a haber productos libres y de calidad aceptable que podemos utilizar en un entorno de producción. Entre estos hablaremos de dos para JEE que se pueden descargar de la internet: Mondrian, un motor ROLAP, y JPivot un explorador OLAP web basado en Mondrian que muestra la información en tablas interactivas que el usuario puede navegar.

Mondrian

La última versión de Mondrian y su documentación se encuentra en http://mondrian.pentaho.org/.

De una manera similar a un ORM (por ejemplo Hibernate en Java), que permite emular una base de datos orientada a objetos a partir de una relacional, Mondrian nos permite emular una base multidimensional. Permitiéndonos así realizar consultas en lenguaje MDX, pensando en términos de cubos, hechos, dimensiones y valores en lugar de tablas, registros y campos.

Mondrian está compuesto por un conjunto de archivos "jar", que proveen una API inspirada en JDBC pero diseñada para trabajar con una base multidimensional. El sistema necesita que escribamos en un archivo "xml" cómo se corresponden los elementos de esta base con la base relacional.

La base relacional debe ser diseñada cuidadosamente de modo que sobre ella se pueda hacer el mapeo. Las estructuras comunmente usadas son tres:

Una única tabla para el cubo donde existe un registro por cada hecho (por ejemplo, un registro por cada venta). El registro tendrá un código único, un campo o más por cada dimensión y un campo por cada valor del hecho (un campo con el importe de la venta, otro con la cantidad de artículos vendidos, etc.).

Una estructura de estrella. Con una tabla central de hechos donde está el código único del mismo y los valores correspondientes, y varias tablas periféricas, una por cada dimensión. Los registros de la tabla central se relacionan con los registros de las tablas periféricas de un modo "muchos a uno", por lo tanto la tabla central posee además una clave foránea por dimensión.
Una estructura de copo de nieve. No muy alejada de la estrella, pero busca quitar relaciones de la tabla central para ahorrar espacio.

Para mostrar un ejemplo de mapeo, supongamos un cubo llamado "Ventas" que posee todas las ventas de una pequeña cadena de mercados. Este cubo tendrá tres dimensiones: "Rubro", "Sucursal" y "Tiempo", y también un valor, el "Importe" de la venta. Previamente crearíamos una base de datos en algún servidor que tenga conectividad con JDBC, por ejemplo MySQL. Nuestra arquitectura será la típica estrella, con la tabla de hechos "venta" y una tabla adicional por cada dimensión.

Así las sentencias que crearán la base serán las siguientes:


create database olapmercado;
create table venta (id integer primary key, rubro_id integer,

        sucursal_id integer, tiempo_id integer, importe double);
create table rubro (id integer primary key, nombre char(20));
create table sucursal (id integer primary key, nombre char(20));
create table tiempo (id integer primary key, anio integer, mes integer);

Estas tablas deben ser llenadas. Probablemente queramos hacerlo con datos que se encuentran en algún otro sistema. Por eso debemos crear un script o programita que extraiga, transforme y cargue los datos (ETL), y que lo haga periodicamente, por ejemplo todas las semanas o todos los meses.

Para mapear el cubo con la tabla, creamos un archivo llamado "olapmercado.xml" con el siguiente contenido:

<?xml version="1.0"?>
<Schema name="olapmercado">
  <Dimension name="Rubro">
    <Hierarchy hasAll="true" allMemberName="Todos"

        primaryKey="id">
      <Table name="rubro"/>
      <Level name="Rubro" column="nombre"/>
    </Hierarchy>
  </Dimension>

  <Dimension name="Sucursal">
    <Hierarchy hasAll="true" allMemberName="Todas"

        primaryKey="id">
      <Table name="sucursal"/>
      <Level name="Sucursal" column="nombre"/>
    </Hierarchy>
  </Dimension>

  <Dimension name="Tiempo">
    <Hierarchy hasAll="true" allMemberName="Total"

        primaryKey="id">
      <Table name="tiempo"/>
      <Level name="Anio" column="anio"/>
      <Level name="Mes" column="mes"/>
    </Hierarchy>
  </Dimension>

  <Cube name="Ventas">
    <Table name="venta"/>

    <DimensionUsage name="Rubro" source="Rubro"

        foreignKey="rubro_id"/>
    <DimensionUsage name="Sucursal" source="Sucursal"

        foreignKey="sucursal_id"/>
    <DimensionUsage name="Tiempo" source="Tiempo"

        foreignKey="tiempo_id"/>

    <Measure name="Importe" column="importe"

        aggregator="sum" formatString="#,##0.00"/>
  </Cube>
</Schema>

Una vez hecho esto, ya estamos en condiciones de poder utilizar la API de Mondrian, basada en JDBC, para conectarnos a la base, ejecutar consultas MDX y obtener resultados.

Esta API tiene un aspecto similar al siguiente:


Connection connection = DriverManager.getConnection(
  "Provider=mondrian;" +
  "Jdbc=jdbc:mysql://localhost/olapmercado?" +

  "user=root&password=root1;" +
  "Catalog=olapmercado.xml;",
  null,
  false);

String mdxString = "select {(Sucursal, Rubro)} on rows, " +
  "{Tiempo} on columns from Ventas";

Query query = connection.parseQuery(mdxString);

Result result = connection.execute(query);

int[] coord = {0, 0};
Cell cell = result.getCell(coord);

etc...

Pero no diré más sobre el asunto. No es preciso utilizar esta API habiendo navegadores OLAP como JPivot que pueden ejecutar la consulta y mostrar los datos en pantalla sin necesidad de programar nada.

JPivot

La aplicación de Mondrian por sí misma parece estar destinada a la programación en un bajo nivel. Debemos ejecutar varios métodos de Java para establecer la conexión con la base, ejecutar la consulta y obtener los resultados, para después programar cientos de líneas según lo que necesitemos: mostrarlos en pantalla, pasarlos a alguna hoja de cálculo, imprimirlos o hacer algún gráfico.

Afortunadamente existen componentes y programas conocidos como "clientes OLAP", que trabajan con Mondrian, cuyo objetivo es proporcionar una interfaz ("front" en inglés) "prefabricada" donde, con sólo introducir la consulta MDX, se puede obtener los datos en una tabla navegable, imprimirlos, graficarlos y hasta exportarlos a una hoja de cálculo. Entre estos programas se encuentra JRubik, una aplicación de escritorio programada con Swing, y JPivot, que está implementada como un conjunto de tags JSP (tecnología web), por lo que es altamente configurable y se integra bien con nuestras aplicaciones web.

JPivot se puede descargar de la página del proyecto en SourceForge, http://jpivot.sourceforge.net/. La distribución binaria incluye el archivo ".war" listo para ser colocado en algún servidor JEE y funcionar.

Por defecto, en la distribución ya vienen algunas consultas hechas a modo de ejemplo. Se encuentran dentro de los archivos ".jsp" en el directorio "WEB-INF/queries". En los mismos archivos se puede ver cómo se configura la cadena de conexión con la base de datos. Y en el mismo directorio se halla un archivo ".xml" de mapeo para el Mondrian (recuérdese que JPivot utiliza Mondrian y que ya viene con los ".jar" incluídos).

Los pasos para tener JPivot andando son pocos, aunque pueden llevar algunas horitas la primera vez. Primero, descargar algún servidor web como Tomcat e instalar el ".war". Segundo, armar el archivo de mapeo para el Mondrian. El paso cero habría sido tener una base de datos ya armada. Tercero, armar los archivos con las consultas MDX y la cadena de conexión (en lugar de utilizar una cadena de conexión, también es posible especificar un "datasource"), para ello tomar como base los ejemplos que vienen. Si todo va bien ya tendrémos el navegador OLAP funcionando.

Luego JPivot se puede modificar según nuestras necesidades. Es fácil cambiar el aspecto de la interfaz del navegador.

Suponiendo el ejemplo de más arriba, del cubo "Ventas" de la cadena de mercados, con el mismo archivo de mapeo, veamos algunas capturas de pantallas:

select {(Sucursal, Rubro)} on rows, {Tiempo} on columns from Ventas
select {Sucursal} on rows, {Rubro} on columns from Ventas
select {(Rubro, Sucursal)} on rows, {Tiempo} on columns from Ventas

Hasta aquí Mondrian y JPivot, dos herramientas para OLAP libres. Si le ha interesado le sugiero que continue leyendo la documentación de Mondrian y JPivot en sus respectivos sitios y que se anime a experimentar instalando JPivot.

III. Referencias

Wikipedia
http://wikipedia.org/

estadistico.com
http://www.estadistico.com/

SearchOracle.com
http://searchoracle.com/

Mondrian
http://mondrian.pentaho.org/

JPivot
http://jpivot.sourceforge.net/

Presentación del sed

2009-03-24T02:38:00.028-03:00

Tutorial, Guía o Simplemente Introducción al Comando Sed de Unix

Copyright (c) 2009 Héctor Francisco Hernández <hectorfh@gmail.com>.

Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, Versión 1.3 o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia se encuentra en http://www.gnu.org/copyleft/fdl.html.

1. Introducción

La herramienta de Unix "sed" ("stream editor" o "editor de flujo") es, junto con "awk" (y sin
contar a Perl, la panacea, en la contienda), la más poderosa en lo que
a procesamiento de texto plano se refiere.

Al igual que el editor "ed", del cual toma todos sus comandos, permite escribir pequeños scripts de edición de texto en un
particular lenguaje:


# el comando "i" inserta texto en la línea
# que se le indique
sed '7i hola mundo' zaraza.txt

# el comando "d" borra líneas
sed '1d' zaraza.txt

# el comando "s" sustituye texto utilizando
# expresiones regulares si se desea
sed '1,$s/palavra/palabra/g' zaraza.txt

Sin embargo, su característica distintiva es la habilidad de procesar
texto proveniente desde la entrada estándar. La que lo convierte en una
herramienta ideal para construir filtros y utilizarlos en nuestros scripts
Bourne, Korn, tcsh, bash, o lo que fuere.

2. Uso Básico

Las instrucciones que entiende "sed" están compuestas primero por el
número o rango de líneas sobre el cual se realizará la transformación y
luego por la acción a realizar. Omitir el número o rango de líneas
implicará que la acción se ejecute sobre la totalidad de las mismas.

De este modo si, por ejemplo, disponemos del siguiente listado obtenido por el
comando "ps":


 PID   TTY TIME     CMD
6245 pts/1 00:00:00 bash
6246 pts/1 00:00:00 ps

Y para procesar el listado queremos suprimir los títulos,
podríamos eliminar la primera línea con la instrucción
"1d". Por lo tanto nuestro comando en el shell sería
"ps | sed '1d'" y obtendríamos:


6245 pts/1 00:00:00 bash
6246 pts/1 00:00:00 ps

Los rangos de líneas son de la forma "n,m" que significa
"desde la línea n inclusive hasta la línea m".
Pudiendo "m" ser el símbolo especial "$" que
indica el final del archivo.

Así, por ejemplo, si quisiéramos, como generalmente ocurre,
obtener desde la línea 74 hasta la 83 de un archivo de texto denominado
"xxx" podríamos hacerlo con la instrucción
"74,83p" así:

sed -n '74,83p' xxx

En este ejemplo debo hacer notar el parámetro "-n". Por
defecto "sed" imprime todo a la salida estándar, sólo
que "-n" modifica este comportamiento para que no lo haga. Por lo
tanto, si no usáramos el parámetro "-n"
obtendríamos todo el archivo "xxx" con las
líneas desde la 74 hasta la 83 duplicadas, ya que la instrucción
"p" volvería a imprimirlas.

No sólo es posible indicar un número de línea o un rango numérico,
también es posible indicar una expresión regular o un rango de
expresiones regulares.

Cuando queremos que la acción se ejecute sobre las líneas que
coincidan con una expresión determinada, debemos escribirla delante del
comando entre barras:

# imprime sólo las líneas que tengan la
# palabra "proc", lo mismo que haría el
# comando "grep proc"
sed -n '/proc/p'

# borra lo que se encuentre entre
# "#ifdef __WIN32__" y "#endif"
sed '/#ifdef __WIN32__/,/#endif/d'

De este modo, por ejemplo, si disponemos del siguiente listado arrojado por
"ls":

total 888
-rw-r--r--  1 usuario1 users   2737 2003-04-01 04:36 LICENSE.txt
-rw-r--r--  1 usuario1 users   3639 2003-04-01 04:36 README.txt
drwxr-xr-x  4 usuario1 users   4096 2007-09-08 21:52 build
drwxr-xr-x  2 usuario1 users   4096 2007-09-08 21:52 convert
drwxr-xr-x  5 usuario1 users   4096 2007-09-08 21:52 docs
drwxr-xr-x 12 usuario1 users   4096 2007-09-08 21:52 examples
drwxr-xr-x  3 usuario1 users   4096 2003-04-01 04:35 src
drwxr-xr-x 12 usuario1 users   4096 2003-04-01 04:36 test
-rw-r--r--  1 usuario1 users 351405 2003-04-01 04:36 velocity-1.3.1.jar
-rw-r--r--  1 usuario1 users 510105 2003-04-01 04:36 velocity-dep-1.3.1.jar
drwxr-xr-x  5 usuario1 users   4096 2007-09-08 21:52 xdocs

Y queremos obtener un listado sólo de los directorios (las filas que
comienzan con la letra "d"). Podríamos utilizar el sed para
borrar las entradas que no comienzan con esa letra:
"ls -l | sed '/^d/!d'":

drwxr-xr-x  4 usuario1 users 4096 2007-09-08 21:52 build
drwxr-xr-x  2 usuario1 users 4096 2007-09-08 21:52 convert
drwxr-xr-x  5 usuario1 users 4096 2007-09-08 21:52 docs
drwxr-xr-x 12 usuario1 users 4096 2007-09-08 21:52 examples
drwxr-xr-x  3 usuario1 users 4096 2003-04-01 04:35 src
drwxr-xr-x 12 usuario1 users 4096 2003-04-01 04:36 test
drwxr-xr-x  5 usuario1 users 4096 2007-09-08 21:52 xdocs

Note que el símbolo de exclamación "!" detrás
de la expresión regular niega la condición. Esto debería
leerse como "borre todas las líneas que no comiencen con la letra
d".

Otra forma de obtener el mismo resultado es imprimiendo sólo
las líneas que comienzan con la letra "d":

ls -l | sed -n '/^d/p'

Explicar las expresiones regulares va más allá de los
límites de este artículo, pero el carácter "^"
significa "comienzo de línea", por lo tanto "^d"
hace referencia a las líneas que poseen una "d" seguida de
su comienzo.

3. Lo Más Importante: El Comando "s"

El comando "s" sustituye expresiones regulares en la línea actual.
Este comando por sí sólo sería justificación para
la existencia del sed.

El modo de uso de este comando es "s/patrón/reemplazo/flags". Donde
"patrón" es la expresión regular que debe sustituirse por
"reemplazo" y los flags son modificadores opcionales que indican, por ejemplo,
si la búsqueda debe discriminar entre mayúsculas y
minúsculas o no.

Siguiendo mi uso de explicar con ejemplos, suponga que posee un texto donde
las palabras podrían estar separadas por más de un espacio:

Aquí   me pongo a   cantar
al  compás de    la vigüela,
que al hombre  que lo desvela
una   pena     estrordinaria,
como la ave solitaria
con    el cantar se   consuela.

Sin embargo usted necesita, por alguna extraña razón que ahora no
se me ocurre, que estén separadas por exactamente un único
espacio. Podría sustituir el patrón "uno o más espacios"
por un único espacio. El comando sería:

sed 's/ \+/ /g'

El "\+" luego de un carácter significa una o más ocurrencias de
ese carácter (se recomienda leer sobre expresiones regulares en general).
La letra "g" al final es un flag que hace que se sustituyan todos los patrones
encontrados en cada línea. Sin él sólo se
sustituirá la primera ocurrencia en cada renglón del texto.

El resultado:

Aquí me pongo a cantar
al compás de la vigüela,
que al hombre que lo desvela
una pena estrordinaria,
como la ave solitaria
con el cantar se consuela.

Y así también es posible hacer referencia al "patrón" o a
"subpatrones" en el "reemplazo" mediante los carácteres especiales
"\&" y "\1", "\2", "\3"... "\n" respectivamente. Por ejemplo, suponga que
posee la siguiente lista en la que cada elemento es de la forma
"archivo@direcorio":

libhardware.a@dosbox-0.70/src/hardware
Makefile.in@dosbox-0.70/src/libs
video.h@dosbox-0.70/include
README.video@dosbox-0.70/docs
Makefile@dosbox-0.70/visualc_net

Luego de aplicarle a la lista "sed 's_$.*$@$.*$_\2/\1_'", obtenemos:

dosbox-0.70/src/hardware/libhardware.a
dosbox-0.70/src/libs/Makefile.in
dosbox-0.70/include/video.h
dosbox-0.70/docs/README.video
dosbox-0.70/visualc_net/Makefile

Esto significa que "\1" hace referencia al subpatrón que se encuentra
entre los primeros paréntesis y que "\2" hace referencia al
subpatrón entre los segundos paréntesis. Fíjese
también que en lugar de separar los parámetros del comando con
una barra "/" lo hice con "_". Esto es porque sed nos permite utilizar cualquier
carácter como separador y se dará cuenta automáticamente
de cuál estamos usando.

Aunque el ejemplo que acabo de enseñar parece estúpido,
créame que es real y que para un trabajo me ha tocado hacer un script
que leía una lista con esa estructura.

4. Procesando Varias Líneas por Vez

Hasta el momento en todos los ejemplos que mostré se leía una
línea, se chequeaba una condición y se realizaba una
operación. Y así cada operación involucraba una
única línea.

Existen, sin embargo, circunstancias en las que es necesario operar sobre
más de una línea por vez. Observe el siguiente archivo:

Registro: 1
Nombre: Anibal
Telefono: 621-229

Registro: 2
Nombre: Hector
Telefono: 562-245

Registro: 3
Nombre: Pablo
Telefono: 622-354

Alguien ha decidido guardar una lista de personas con sus números
de teléfonos en un extraño formato, utilizando cuatro
líneas por registro.
Nuestra tarea es poner la información en una manera más
conveniente para su procesamiento:

1;Anibal;621-229
2;Hector;562-245
3;Pablo;622-354

Claro está que sería imposible
solucionar este problema leyendo de a una línea a la vez. Sería
bueno poder trabajar leyendo de a un registro (cuatro líneas) por
iteración.

Este tipo de problemas se resuelve con el comando "N", que fuerza
la lectura
de la siguiente línea en la iteración actual.

Al comenzar la iteración, sed trae la línea al buffer.
Internamente el valor del buffer sería:

buffer = "Registro: 1"

Luego de ejecutar la instrucción "N", que lee la
línea siguiente y la concatena en el buffer, quedaría:

buffer = "Registro: 1\nNombre: Anibal"

Observe que "\n" significa "nueva línea"
(el carácter ASCII número 10).

Como vemos, nos vamos aproximando a la solución. Basta con leer
dos líneas más y ya tenemos el registro completo.
Y luego de hacerlo debemos reemplazar el retorno de carro "\n"
por ";" con "s/\n/;/g", para así llegar a:

buffer = "Registro: 1;Nombre: Anibal;Telefono: 621-229;"

Ahora resta quitar lo que molesta, las palabras
"Registro: ", "Nombre: ", "Telefono: " y el
punto y coma de más al final.

Para lograrlo utilizaremos una super sustitución con expresiones
regulares:

"s/^Registro: \(.*\);Nombre: \(.*\);Telefono: \(.*\);$/\1;\2;\3/"

buffer = "1;Anibal;621-229"

Ahora podríamos poner todo junto.
Suponiendo que los datos originales estaban en el archivo "agenda",
nuestro comando quedaría:

sed 'N;N;N;s/\n/;/g;s/^Registro: \(.*\);Nombre: \(.*\);Telefono: \(.*\);$/\1;\2;\3/' agenda

Ilegible, ¿verdad? Si así lo considera, puede hacerlo en dos
pasos invocando dos veces al sed.

5. Programación en Sed

En la documentación del sed de GNU, el capítulo que explica esto dice
"Comandos para gurúes del sed ... En la mayoría de los casos, el uso de
estos comandos indican que probablemente sea mejor programar en awk o Perl".
La razón por la cual enseño estos comandos es para mostrar el límite de la herramienta.

A pesar de no tener variables ni poseer forma de controlar el flujo de
ejecución más que con etiquetas, un comando para "GOTO" y otro
para "GOTO" condicional, sed es un lenguaje "Turing-completo". Esto es que
tiene un poder computacional equivalente a la máquina universal de
Turing. Por eso circula un mito nerd de que en algún lugar de la web
se puede descargar los fuentes de un sokoban, un arkanoid y algún otro
juego clásico implementado en sed.

Los comandos para hacer un "GOTO" incondicional y condicional son "b" y "t"
respectivamente. Las etiquetas se definen con el comando ":". Además
sed posee un buffer denominado "hold space" que provee un espacio adicional para
almacenar datos sobre el cual podremos guardar y recuperar lo que pongamos con
los comandos h, H, g, G, x. Refiéranse a la documentación del sed
los interesados, pues no tengo interés en explicar sobre este asunto.

Imaginese que sin variables, sin estructuras de control y sin operadores
aritméticos entre otras cosas,
la programación en sed no es más que otro aburrido juego de
ingenio para simios. Por este motivo será que finalizaré este
capítulo copiándole un script del tutorial "Sed - An Introduction and
Tutorial" de Bruce Barnett que ilustra algo de esto y dejaré el tema
allí mismo.

Lo que hace el ejemplo es guardar los párrafos en el "hold buffer" a
medida que los va leyendo. Si el párrafo posee el patrón pasado
por parámetro al script lo imprime.

#!/bin/sh
sed -n '
# Si es una línea vacía, finaliza el párrafo.
# Por lo tanto se debe analizar. Se hace un "GOTO" a "para".
/^$/ b para
# Si la línea no está vacía, se agrega al "hold buffer".
H
# Al final del archivo se analiza el último párrafo.
# "GOTO" a "para".
$ b para
# Se hace un "GOTO" al final del script.
b
# La etiqueta "para". Sección donde se analiza el párrafo.
:para
# Se recupera el párrafo completo.
x
# Se busca el patrón, si se encuetra se imprime el párrafo.
/'$1'/ p
'

6. Apéndice A: Quitando Tags XML. El Criterio "The Longest Match"

Para mostrar cómo se hace haré el siguiente ejercicio. Suponga
el siguiente código HTML:


Contenido


1 Historia

2 Ventajas del XML

3 Estructura del XML

Para obtener el texto sin los tags podría acceder a la página
ya procesada por el navegador web, copiar el texto con Ctrl-c y pegarlo con
Ctrl-v en mi editor favorito (las teclas pueden cambiar según el entorno
en el que estemos trabajando). Pero aquí, como mi intención es
mostrar el sed, lo haré con esta herramienta.

Lo que se me ocurre es sustituir el patrón "<.*>"
por una cadena vacía. Sin embargo el resultado obtendido luego de
ejecutar "sed 's/<.*>//g' temp" es varias líneas
vacías.

Lo que pasa es que el patrón es ambiguo. Por ejemplo para
"

Contenido

" sed comenzaría leyendo desde
el primer "<", pero podría detenerse en el ">"
detrás del primer h2 o en el ">" detrás del segundo
h2. Y los creadores de la herramienta han decidido que se tome siempre la
coincidencia más larga, "the longest match".
Una solución al problema sería, por ejemplo, utilizar el
patrón "<[^<]*>". "[^<]" significa
cualquier caracter que no sea "<". En ese caso el resultado
sería:


Contenido
1 Historia
2 Ventajas del XML
3 Estructura del XML

7. Apéndice B: El Editor "ed"

Los comandos del sed provienen del editor más primitivo de Unix, llamado
"ed". Este editor, a diferencia de sed que es un editor de flujo, es
un editor común y corriente... bueno, casi. A diferencia de los editores
modernos no es "WYSIWYG" (What You See Is What You Get, o "lo que
vés es lo que obtenés"), o sea que no nos muestra el texto
que estamos editando, simplemente nos permite escribir comandos (más o
menos los mismos que el sed) de manera interactiva.

El uso de este editor no es común en estos tiempos, ya que la
mayoría de los programadores y administradores de Unix prefieren trabajar
con el "vi". Sin embargo, el ed puede aprovecharse como otro comando
para nuestros scripts cuando necesitamos abrir un archivo, hacer una
edición y volver a grabarlo. En ese caso no precisamos un editor de
flujo como el sed, sino más bien alguno que edite el archivo en el lugar.

Volvamos al ejemplo de eliminar los espacios sobrantes.


Aquí   me pongo a   cantar
al  compás de    la vigüela,
que al hombre  que lo desvela
una   pena     estrordinaria,
como la ave solitaria
con    el cantar se   consuela.

Imagínese que el texto se encuentra en el archivo "prueba.txt".
Si lo resolviésemos con el sed, como hicimos en el ejemplo pasado,
obtendríamos el resultado en la salida estándar o en otro archivo. Sin
embargo queremos que los datos permanezcan en "prueba.txt" luego de la
transformación. Por lo que tenemos dos opciones: a) obtener los datos
en un archivo auxiliar y luego reemplazar "prueba.txt" por este
archivo; o b) editar el archivo en el lugar utilizando el "ed".

El comando para editar el archivo en "ed" es el mismo que en el
"sed" pero con tres salvedades. La primera es que "ed" no
tiene como rango implícito todas las líneas del archivo, por lo
que sí o sí tenemos que indicarle el rango
"1,$" delante del comando. La segunda es que luego de la
transformación debemos ejecutar el comando "w" para grabar
el archivo, ya que "ed" no lo hará automáticamente.
Y la tercera es que los comandos se separan con una nueva línea, y no
con un ";".

"ed" recibe el nombre del archivo como parámetro y lee los
comandos desde la entrada estándar. También requiere la
opción "-n" para suprimir molestos mensajes. Por lo que
quedaría de la siguiente manera:

ed -s prueba.txt <<< $'1,$s/ \+/ /g\nw'

Pero algunas implementaciones modernas del "sed", como por ejemplo la
de GNU, también poseen la opción "-i" que permite
modificar el archivo en el lugar y obtener el mismo resultado:

sed -i 's/ \+/ /g' prueba.txt

8. Final

"sed" se encuentra siempre entre mi reducido y selecto repertorio de
herramientas de trabajo. Podría decir que está entre las muy
primeras opciones a la hora de realizar cualquier tipo de transformación
sobre textos extensos y que no conozco otra cosa que lo haga mejor.

Además de eso he tenido la oportunidad de operar en varios sistemas
tipo Unix distintos y todos poseen la herramienta. Y cuando me encontré
trabajando con sistemas de otro tipo, a falta de alguna mejor opción, he
tenido la necesidad de instalarla. Dicho sea de paso, he conseguido
implementaciones libres en la internet que se instalan fácilmente y sin
ningún tipo de problema.

La herramienta es más bien compacta, sencilla y poderosa. Por lo que se
logra dominar luego de usarla un par de veces, siempre y cuando se esté
familiarizado con las expresiones regulares. Y si no lo está es muy
recomendable que lea algún tutorial pequeño sobre el asunto y lo
ponga en práctica.

Hasta aquí espero que haya obtenido una idea acerca del "sed" y
del provecho que le puede sacar tanto para crear scripts o para transformar
todo tipo de textos.

Para más información sugiero que lea la documentación de
la implementación en su sistema operativo. Si tiene GNU instalado
escriba "info sed". También encontrará muchos textos
escritos en todos los idiomas en la internet, lo que es un punto a favor
del uso del "sed".

TkPong

2008-11-25T23:22:00.011-02:00

Screenshoot

TkPong is a pong implemented by Héctor Francisco Hernández in Tcl/Tk. This is Free/Libre Software. You will find the code here in the Tcl/Tk wiki.

TkPong es un pong implementado por Héctor Francisco Hernández en Tcl/Tk. Es software libre, Encontrará el código aquí en la wiki de Tcl/Tk.

jsGorilla

2008-07-13T00:00:00.006-03:00

Héctor Francisco Hernández <hectorfh@gmail.com>

Download

RMI: Remote Method Invocation (Invocación de Método Remota)

2008-01-10T11:41:00.005-02:00

Copyright (c) 2008 Héctor Francisco Hernández <hectorfh@gmail.com>.

Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, Versión 1.3 o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia se encuentra en http://www.gnu.org/copyleft/fdl.html.

Introducción.

RMI es un protocolo propietario de Java que permite que métodos de objetos que existen en una máquina virtual puedan ser invocados desde otros objetos en otra máquina virtual, probablemente en un host distinto.

RMI sólo permite la comunicación entre tecnología Java. Si se requiere comunicar con otras tecnologías debe usarse CORBA o SOAP.

Al estar específicamente diseñado para Java, RMI puede darse el lujo de ser muy amigable para los programadores, proveyendo pasaje por referencia de objetos (cosa que no hace SOAP), "recolección de basura" distribuida y pasaje de tipos arbitrarios (funcionalidad no provista por CORBA).

Por medio de RMI un programa puede hacer disponible un objeto en la red. Otro programa entonces podría invocar métodos de dicho objeto como si invocara métodos de objetos propios, de un modo transparente al programador, sin tener que lidiar con sockets de bajo nivel.

Cuando un programador invoca un método de un objeto remoto, los parámetros son serializados (convertidos en un flujo de bytes capaz de ser enviados a través de un socket). Luego se envían a través de la red, mientras que el método que hizo la invocación queda esperando. El método remoto realiza el procesamiento, serializa el valor de retorno y se lo devuelve al llamador. Esto implica que el pasaje de parámetros que no tienen interfaz remota definida (objetos no remotos), cuando se trata de métodos remotos, es por copia.

Por este motivo se requiere que los parámetros del método remoto y del dato que retorna sean de clases que se puedan serializar (en Java, que implementen la interfaz "Serializable").

El encargado de hacer públicos los objetos remotos es el registro RMI. Se trata de un servicio, cuyo puerto TCP por defecto es el 1099 (aunque es posible elegir otro), que mantiene información acerca de los objetos exportados y sus correspondientes direcciones. El servidor debe registrar en él sus objetos remotos mediante el método "Naming.bind("dirección", objeto)" y el cliente debe solicitarlos llamando a "Naming.lookup("dirección")".

Haciendo uso de RMI.

Para aprender más hacemos uso de la tecnología por nuestra cuenta.

Para utilizar objetos remotos, lo primero que debemos hacer es definir una interfaz con los métodos que serán utilizados remotamente. Está especificado que está interfaz debe heredar de la interfaz "Remote".

Los métodos remotos lanzan excepciones de la clase "RemoteException", y no de la clase "Exception".


import java.rmi.Remote;
import java.rmi.RemoteException;

public interface InterfazRemota extends Remote
{
  public String recibirMensaje(String mensaje) throws RemoteException;
}

Aunque el cliente no conozca la implementación del objeto remoto, deberá conocer su interfaz para invocar los métodos, por lo tanto deberemos compilar el cliente también utilizando esa interfaz.

Luego implementamos la clase del objeto remoto. Las clases remotas deben heredar de "UnicastRemoteObject".


import java.rmi.server.UnicastRemoteObject;
import java.rmi.RemoteException;
import java.net.InetAddress;

public class ClaseRemota extends UnicastRemoteObject
    implements InterfazRemota
{
  public ClaseRemota() throws RemoteException
  {
  }

  public String recibirMensaje(String mensaje)
      throws RemoteException
  {
    try {
      System.out.println(mensaje);
      return "Soy " +
          InetAddress.getLocalHost().getHostAddress() +
          " y el mensaje ha sido impreso en mi consola.";
    }
    catch (Exception e)
    {
      throw new RemoteException("Fallo en el servidor");
    }
  }
}

Ahora ya podemos terminar el servidor. Deberá instanciar el objeto y hacerlo disponible en la red a través del registro "RMI". Para eso existe la función "Naming.bind(dirección, objeto)" que asocia nuestro objeto remoto con un nombre virtual del formato "//host:port/name". Utilizaremos ese nombre para buscar el objeto remoto desde el proceso cliente más tarde.


import java.rmi.Naming;
import java.net.InetAddress;

public class Servidor
{
  public static void main(String[] args)
  {
    try
    {
      InterfazRemota objetoRemoto = new ClaseRemota();
      Naming.bind("//" +
          InetAddress.getLocalHost().getHostAddress() +
          ":1234/PruebaRMI", objetoRemoto);
    }
    catch (Exception e)
    {
      e.printStackTrace();
    }
  }
}

Hemos escogido el puerto "1234", sin embargo, de omitir el puerto TCP, RMI utiliza por defecto 1099.

El servidor ya está en condiciones de ser compilado y ejecutado. Para ello alcanzará con el comando "javac *java". Luego para correrlo debemos previamente ejecutar el registro RMI para el correspondiente puerto (comando "rmiregistry 1234" en nuestro glorioso Slackware GNU/Linux) y luego el programa servidor propiamente dicho (comando "java Servidor").

Ahora haremos un programita cliente que simplemente busque nuestro objeto remoto en la red y ejecute el método "recibirMensaje" con el parámetro "Hola Mundo!". Para ahorrar tiempo vamos a suponer que la dirección IP del servidor es "10.0.0.10", siendo esta la dirección de la máquina en la que se hizo el experimento.

Para encontrar "objetoRemoto" se utiliza la función "Naming.lookup(dirección)".


import java.rmi.Naming;

public class Cliente
{
  public static void main(String[] args)
  {
    try
    {
      InterfazRemota objetoRemoto = (InterfazRemota)
          Naming.lookup("rmi://10.0.0.10:1234/PruebaRMI");
      String retval = objetoRemoto.recibirMensaje("Hola Mundo!");
      System.out.println("Mensaje del servidor: " + retval);
    }
    catch (Exception e)
    {
      e.printStackTrace();
    }
  }
}

Compilamos el cliente con el comando "javac Cliente.java" asegurándonos que "InterfazRemota" está en el "classpath" y lo ejecutamos. Como resultado veremos en la consola del servidor el mensaje "Hola Mundo!" que ha llegado en la invocación al método remoto, y en la del cliente "Mensaje del servidor: Soy 10.0.0.10 y el mensaje ha sido impreso en mi consola.".

Conclusión.

Según la experiencia que hemos tenido con RMI, todo se ve transparente y amigable al programador. Debido a que está pensado exclusivamente para Java, la integración con esta tecnología es perfecta y sin dolores de cabeza. Sin embargo nos vemos bastante limitados, para no decir del todo, en cuanto a interoperabilidad con el resto del universo no Java.

Referencias.

Sitio Oficial de Java (http://java.sun.com/)
Wikipedia (http://es.wikipedia.org/)
Sitio de O'Reilly (http://www.oreillynet.com/)
Proactiva Calidad (http://www.proactiva-calidad.com/)

Programación GUI con Motif.

2006-07-01T12:30:00.001-03:00

1. ¿Qué es Motif?

Motif es, ante todo, un estándar (IEEE 1295) creado en los 80', el cual define una API en lenguaje C para el desarrollo de interfaces gráficas (GUIs) sobre X Window (para entornos Unix). También especifica una "Guía de estilo", detallando el aspecto que debería tener una aplicación Motif.
Por supuesto, esta denominación también se aplica a la biblioteca que implementa el estándar, y fue originalmente desarrollada por el Open Source Fundation, para competir con OpenLook. Actualmente es mantenida por el Open Group. Existen varias implementaciones de Motif además de la original, entre ellas OpenMotif (una versión libre para sistemas operativos de código abierto, como GNU/Linux o FreeBSD), Lesstif y SGI Motif.

2. ¿Porque Motif?

Habiendo tantas bibliotecas ("toolkits") disponibles (entre ellas GTK+, creada precisamente para reemplazar a Motif en el desarrollo de El Gimp), cabe preguntarse que utilidad tiene aprender a programar con esta biblioteca. Bien, en primer lugar, porque se encuentra estandarizada. Esto significa que existe estabilidad en la API, y si surgen nuevas adiciones a la biblioteca, probablemente no será necesario modificar el código fuente de nuestro programa. A pesar de sus años, sigue siendo la biblioteca de ventanas nativa de los sistemas Unix. Se ha utilizado en miles de programas, y hoy día se mantiene como el toolkit líder en estaciones de trabajo profesionales, para el desarrollo de aplicaciones críticas. También es relativamente pequeña, y muy eficiente (es probablemente la biblioteca de este tipo más rápida, en parte por su sencillez). Ese carácter minimalista hace que Motif no sea tan "bonita" en comparación con GTK+ o Qt, pero es sin duda eficaz. Incluso es posible compilarla estáticamente para obtener ejecutables de tamaño razonable, y prescindir de la instalación de bibliotecas dinámicas en el sistema destino. Motif también soporta Unicode, por lo que es apta para aplicaciones internacionalizadas.

3. Obteniendo la biblioteca.

La última especificación de Motif es la 2.1. Existen muchas implementaciones de este estándar, pero la mayoría de ellas son comerciales (debemos pagar por las licencias). La principal, por supuesto, es la del Open Group. Sin embargo, las versiones que se tendrán en cuenta en este artículo son las disponibles gratuitamente: OpenMotif y Lesstif.

OpenMotif es una versión libre, siempre que las aplicaciones se utilicen en sistemas operativos que también sean libres. La última versión estable es la 2.2, pero puede obtenerse la beta de la 2.3.

Lesstif es un proyecto de un grupo de programadores denominado "The Hungry Programmers". Si bien aún no implementa la totalidad del estándar, es una versión muy completa y evolucionada. Tiene licencia LGPL, por lo que resulta menos restrictiva que OpenMotif, y se puede usar en cualquier entorno Unix (o incluso bajo Windows, mediante Cygwin). La última versión es la 0.95.0.

Los que posean distribuciones de GNU/Linux basadas en Debian, pueden buscar en los repositorios de dichos sistemas ámbas bibliotecas.

4. Widgets, Gadgets y generalidades.

Motif es un toolkit construido sobre la biblioteca Xt Intrinsics (X Toolkit), que a su vez es soportada por Xlib (la API básica de X Window). Xt ofrece una serie de estructuras y funciones que pueden usarse como base para construir conjuntos de "widgets". También esconde la mayor parte de la complejidad de Xlib, facilitando la programación. Tanto Motif como Xt están dirigidas por eventos, lo que en pocas palabras significa que la aplicación entra, luego de su ejecución, en un bucle o "loop", manejando mensajes de X Window hasta que se ordena cerrar la aplicación (se sale del bucle). Este tutorial no discutirá las características distribuidas de X Window, y tampoco analizará en profundidad la biblioteca Xt.

Los "widgets" son los elementos que constituyen una interfaz gráfica (GUI), como por ejemplo ventanas, botones, etiquetas, etc. Los mismos operan de forma independiente de la aplicación, salvo por acciones predefinidas por el usuario. En Motif, los widgets se encuentran declarados en archivos de cabecera, como <MainW.h>, <PushB.h>, <Text.h>, entre muchos otros. Pueden encontrarse en la carpeta <Xm>, habitualmente ubicada en </usr/include>. Puede observarse que en dicha carpeta hay otros archivos con los mismos nombres que los citados anteriormente, con la salvedad de que terminan con una letra 'P' (por ejemplo, <PushBP.h>). Estos archivos son cabeceras privadas, y representan funciones y tipos de datos que se ocultan de la interfaz pública de Motif. Esto es así porque la biblioteca (al igual que Xt) está orientada a objetos, y por ende implementa conceptos como encapsulamiento y herencia (mediante la definición de clases de widgets), todo esto a pesar de estar escrita en C, un lenguaje que no brinda soporte explícito para dicho paradigma. Bizarro, sin lugar a dudas. Por cierto, también se pueden encontrar archivos cuyos nombres terminan con G. Estos son "gadgets", y son similares a los widgets en su aspecto. Sin embargo, el comportamiento de estos gadgets no está definido dentro de los mismos, sino que es responsabilidad del widget que los contiene. Por ejemplo, un gadget no se redibuja a si mismo en forma automática. Poseen la ventaja de ser más "ligeros" que los widgets (en lo que respecta a consumo de recursos), pero en las últimas versiones de Motif los widgets están más optimizados (al igual que lo está X Windows), por lo que no es común usar gadgets, y en el presente artículo no se los volverá a mencionar.

5. Funciones de la biblioteca.

Todo programa Motif necesita de dos elementos básicos: un "Application Context" (una estructura que utiliza Xt para manejar información interna relacionada con nuestra aplicación), y un "Top Level Widget", o widget principal (el cuál representa el control de más alta jerarquía, y será el "padre" de todos los demás widgets). Además, los widgets disponen de recursos ("resources"), los cuales son atributos configurables. Hay un gran número de recursos por cada widget, en parte debido a que son heredables. Los recursos tienen un nombre, que generalmente comienzan con "XmN"; por ejemplo, los botones (PushButtons) tienen recursos como XmNlabelString (el texto del botón) o XmNshadowThickness (el grosor de la sombra del botón). Un tipo de recurso especial es el denominado "callback resource". El mismo es un puntero a una función que debe ejecutarse cuando se efectúa cierta acción sobre el widget. Volviendo al caso del PushButton, el recurso XmNactivateCallback apunta a una función que será llamada al pulsar el botón (click con el botón izquierdo). Los recursos se pueden introducir al momento de crear el widget, o bien pueden ser modificados posteriormente con las siguientes funciones:

void XtSetValues(Widget hW, ArgList pArgs, Cardinal iNumArgs);
void XtVaSetValues(Widget hW, ...);

En la primera, hW es el widget, pArgs es un array de elementos "Arg" (los cuales contienen cadenas de caracteres que representan a los recursos), y iNumArgs es simplemente un entero que indica el número de elementos del array pArgs. En el caso de XtVaSetValues, además del widget, se pasan los parámetros de a pares (el nombre del recurso primero, y luego el valor del mismo), terminando con un carácter nulo ("NULL"). Por ejemplo, para cambiar el texto y el grosor de la sombra de un botón previamente creado, se pueden usar las llamadas:

XmString sText = XmStringCreateLocalized ("Aceptar");
XtVaSetValues(hW, XmNlabelString, sText, XmNshadowThickness, 5, NULL );

XmString es un tipo definido por Motif para manejar strings con soporte internacionalizado. Para crear los widgets, suelen llamarse a funciones del siguiente estilo:

Widget XmCreate<nombre del widget>(Widget hWparent, String szName, ArgList pArgs, Cardinal iNumArgs);

hWparent es el widget padre (normalmente, el que contiene al widget que estamos creando), szName es el nombre del widget, pArgs es el array de recursos, y por último iNumArgs es la cantidad de elementos de pArgs. Cada vez que se crea un widget, debe llamarse a la siguiente función:

void XtManageChild(Widget hWchild);

donde hWchild es el widget que se acaba de crear. Esta llamada hará que Xt se encargue de administrar al widget. Existen otras funciones que habrá que utilizar, como XtVaOpenApplication, XtAddCallBack, XtRealizeWidget y XtAppMainLoop. Las mismas se explicarán brevemente con un ejemplo. Probablemente ya haya notado los prefijos "Xm" y "Xt" en todas las funciones expuestas hasta ahora. No es difícil adivinar su utilidad: "Xm" se refiere a las funciones que corresponden a la API de Motif, y "Xt" hace lo propio con X Toolkit. Se trata de una convención muy popular para evadir las colisiones de espacio de nombres.

6. Un ejemplo sencillo

El siguiente código representa uno de los programas Motif mas elementales, y está basado en un ejemplo del Manual del Programador Motif:


/* <hello.c> Ejemplo de programación Motif */
/*01*/ #include <Xm/PushB.h>
/*02*/ void button_pushed_cb (Widget hWidget, XtPointer pClientData, XtPointer pCallData)
/*03*/ {
/*04*/   printf ("¡Hola Mundo!"\n");
/*05*/ }
/*06*/ 
/*07*/ int main (int argc, char *argv[])
/*08*/ {
/*09*/   Widget hToplevel, hButton;
/*10*/   XtAppContext  hApp;
/*11*/   Arg sArgs[2];
/*12*/ 
/*13*/   XtSetLanguageProc (NULL, NULL, NULL);
/*14*/   hToplevel = XtVaOpenApplication (&hApp, "Hello", NULL, 0, &argc, argv,
/*15*/                                    NULL,sessionShellWidgetClass, NULL);    
/*16*/ 
/*17*/   hButton = XmCreatePushButton (hToplevel, "button", NULL, NULL);
/*18*/ 
/*19*/   XmString sText = XmStringCreateLocalized ("Presione, por favor ");
/*20*/   XtVaSetValues(hButton, XmNlabelString, sText, NULL);
/*21*/   XtAddCallback (hButton, XmNactivateCallback, button_pushed_cb, NULL);
/*22*/ 
/*23*/   XtManageChild (hButton);
/*24*/   XtRealizeWidget (hToplevel);
/*25*/   XtAppMainLoop (hApp);
/*26*/ }

Puede compilarse <hello.c> con el siguiente comando:

cc -o hello hello.c -lXm -lXt -lX11

Observe el orden en el que se enlazan las bibliotecas (no debe alterarlo). El resultado de ejecutar el ejemplo es una pequeña ventana, cuyo único contenido es un botón, el cuál al pulsarlo imprimirá un saludo en la salida del terminal.

En la primer línea se incluye el archivo de cabecera que corresponde al widget PushButton. Luego se define una función, button_pushed_cb, que se llamará al presionar el botón. Observe los últimos tres caracteres del nombre de la función; es una convención que se recomienda usar para las funciones "callbacks" (de retrollamada). Esta función será el único "callback resource" que se utilizará en este programa. Ya dentro del main, en la línea 12 se declaran dos widgets (uno para el programa en sí, y otro para el PushButton). En la línea 13 se declara el "Application Context" de <hello.c>.

La función XtSetLanguageProc invocada en la línea 15 configura una función para el manejo del lenguaje local, asociada al "application context" del programa. En este caso, todos sus parámetros son NULL, por lo que se usa el procedimiento por defecto (es lo más común).

En la línea 16 se llama a XtVaOpenApplication. La misma realiza una variedad de acciones, de las cuales las más importantes son el crear el "application context" de nuestro programa, y llamar a XtOpenDisplay para abrir una ventana de X Window, sobre la cuál se mostrará la aplicación. Los parámetros usados en el ejemplo son los más comunes, como por ejemplo el tercero (el nombre de la aplicación), o el octavo (la "clase" del widget TopLevel). También se observa que se le pasan los parámetros obtenidos de la línea de comandos (argc y argv). De hecho, el título de la ventana de nuestro ejemplo será "hello", el cuál es por supuesto el valor de argv[0]. No es el objetivo de este tutorial describir a Xt, por lo que se omitirá el detalle de esta función. Pueden consultarse los enlaces recomendados para encontrar la documentación de Xt.

En la línea 19 se crea un PushButton (cuyo widget se guarda en la variable hButton), y en las líneas 21 y 22 se le asigna una etiqueta al mismo. En la siguiente línea se llama a XtAddCallback, la cuál tiene el siguiente prototipo:

void XtAddCallback(Widget hW, String szCallbackName, 
    XtCallbackProc pfCallback, XtPointer pClientData);

En la llamada, hW es el widget a configurar; szCallbackName es el nombre del recurso; pfCallback es un puntero a función, y pClientData es un parámetro que se le pasará a la función button_pushed_cb cuando sea invocada. En forma genérica, el prototipo de las funciones de retrollamada debe ser:

void myfunc_cb(Widget hW, XtPointer pClientData, XtPointer pCallData);

en donde hW es el widget al que se asoció la función. pClientData es un valor adicional, el cuál se registra al llamar a XtAddCallback; y por último, pCallData es un parámetro que el widget le pasa a myfunc_cb cuando la invoca. Este último parámetro depende del tipo de callback registrado, y suele ser un puntero a alguna estructura con información acerca del estado del widget.

En la línea 25 se asocia el botón a nuestra aplicación, y en la línea 26 se llama a XtRealizeWidget. Esta última función tiene una tarea un tanto compleja, la cual consiste (en síntesis), en recorrer la jerarquía de widgets (a partir del widget pasado como parámetro, o sea hTopLevel), inicializarlos y volverlos visibles. Por último, en la línea 27 se llama a XtAppMainLoop, que se encargará de entrar en un bucle infinito y procesar eventos de X Window, hasta que se ordene cerrar la ventana, en cuyo caso interrumpirá el bucle y dará por terminada la ejecución.

7. Enlaces recomendados

http://www.opengroup.org/motif/

El sitio oficial de Motif. Aquí pueden adquirirse licencias comerciales de la biblioteca.

http://www.motifzone.com

Documentación y foros sobre Motif. Además, pueden bajarse las últimas versiones de OpenMotif.

http://www.lesstif.org

Sitio oficial de Lesstif, la implementación LGPL de Motif.

http://www.ist.co.uk/motif/books/vol6A/BookTOC.fm.html

Manual del programador de Motif. Imprescindible para desarrollar aplicaciones serias.

http://docs.linux.cz/programming/gui/motif/motif.html

Muy buen tutorial de Motif (algo desactualizado, pero igual muy recomendable).

http://lesstif.sourceforge.net/doc/super-ux/g1ae03e/part1/contents.html#Part1

Manual de Xt, importante para entender con un poco más de profundidad la programación en X Windows.

Cómo intercambiar el valor de dos variables sin utilizar una tercera.

2006-06-18T03:15:00.001-03:00

Cualquier alumno de programación
básica podría reconocer el siguiente código:

aux = x; x = y; y = aux;

Se trata del clásico intercambio
de variables.

Sin embargo existen otras formas de
intercambiar el valor de dos variables; formas que no requieren
utilizar otra auxiliar.

Aquí expondré dos que
conozco, la primera utilizando aritmética básica y la
segunda utilizando álgebra de Bool.

Utilizando aritmética básica.

El código es el siguiente:

x = x + y; y = x - y; x = x - y;

Este código es muy interesante,
sin embargo es posible que, si la suma de “x” y “y” diera un
valor muy alto, provoquemos un desbordamiento (overflow) en la
variable “x” y todo salga mal.

Utilizando álgebra de Bool.

Tal vez los programadores de lenguaje
de ensamblador (assembly) estén familiarizados con esta forma.
Se trata de utilizar la operación binaria “XOR” (o
excluyente).

a ^= b; b ^= a; a ^= b;

Alternativamente se puede hacer en una
línea:

a ^= b ^= a ^= b;

Este código es la gloria. Aunque
según tengo entendido no es portable, ¡así que no
lo usen!

Mezclando C con Assembly

2006-06-14T23:19:00.010-03:00

Anteriormente titulado "Cómo mezclar C con código de ensamblador (assembly)"

Copyright (c) 2006, 2007, 2008, 2009 Héctor Francisco Hernández <hectorfh@gmail.com>.
Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, Versión 1.3 o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia se encuentra en http://www.gnu.org/copyleft/fdl.html.

1. Introducción.

Existe una relación muy estrecha entre la programación en C y la programación en ensamblador. C fue creado para evitarle a los programadores del sistema operativo UNIX seguir escribiéndolo en ensamblador. Las ventajas de programar en C lo mismo que antes se programaba en ensamblador son obvias: portabilidad y legibilidad a través de un código bien estructurado. Sin embargo las partes del sistema en las que es necesario trabajar con características específicas del hardware no pueden ser escritas en C.

En general hay dos estrategias para mezclar código en C con código en ensamblador. La primera consiste en compilar archivos escritos en C y ensamblar otros escritos en código de ensamblador para luego enlazarlos todos juntos. La segunda se trata de embeber código escrito en ensamblador dentro de código escrito en C a través de algún mecanismo que ofrezca el compilador usado. En este artículo se tratará sólo la primera estrategia.

Aunque las ideas que aquí se exponen son útiles independientemente de cualquier plataforma, toda la nota presupone un sistema tipo UNIX (GNU en particular) en una arquitectura de procesador 80386 o superior.

2. Construyendo programas.

Dado un conjunto de archivos en C, es necesario seguir ciertos pasos para obtener uno ejecutable.

Para comenzar se deben incorporar los archivos de cabecera (los que se incluyeron mediante "#include"), expandir las macros y constantes (las que se declararon mediante "#define") y quitar el código que no satisfaga las condiciones para ser compilado (condiciones establecidas mediante "#ifndef", "#ifdef" o alguna otra estructura condicional del preprocesador). Esto en C se conoce como "preprocesar" el código fuente. En GNU/Linux los archivos "preprocesados" poseen la extensión ".i" y se generan con cualquiera de los siguientes comandos:

$ cpp ejemplo1.c > ejemplo1.i

o

$ cc -E ejemplo1.c > ejemplo1.i

El próximo paso consiste en traducir el código en C preprocesado a código en ensamblador. Esto se hace del siguiente modo:

$ cc -S ejemplo1.i

Sin embargo también es posible obtener el código en ensamblador a partir del archivo "ejemplo1.c":

$ cc -S ejemplo1.c

En este último caso el compilador preprocesará el archivo automáticamente y al terminar la traducción eliminará "ejemplo1.i". De cualquier forma se obtendrá el mismo resultado, el archivo "ejemplo1.s".

El tercer paso será ensamblar para conseguir código de máquina:

$ as -o ejemplo1.o ejemplo1.s

Alternativamente se puede hacer con el comando

$ cc -c ejemplo1.s

Así el compilador de C llamará al ensamblador automáticamente.

Como resultado deberíamos obtener un archivo objeto con extensión ".o". Los archivos objeto contienen código de máquina en el que las direcciones de memoria no han sido definidas aún. Hay distintos formatos para estos archivos, entre ellos ELF (de Linux), COFF (algunos sistemas tipo UNIX), OMF (algunos sistemas de microchot).

Llegado a este punto debo decir que se podría haber obtenido el archivo "ejemplo1.o" directamente de "ejemplo1.c" de la siguiente forma:

$ cc -c ejemplo1.c

Ahora sólo resta enlazar todos los archivos objeto para obtener el archivo ejecutable "programa-ejemplo":

$ cc -o programa-ejemplo ejemplo1.o ejemplo2.o ejemplo3.o

Para hacer esto también es posible llamar al enlazador directamente con el comando "ld". Aunque no recomiendo hacerlo ya que es necesario pasarle demasiados parámetros. Para ver un ejemplo visite el enlace sugerido al final del artículo al tutorial de gcc de Víctor Alberto González Barbone.

La compilación separada.

Note que podríamos haber compilado todo junto con

$ cc -o programa-ejemplo ejemplo1.c ejemplo2.c ejemplo3.c

Sin embargo compilar todo en un único paso no es una buena opción. Cada vez que cambiaremos algunos de los archivos habrá que volver a compilar todos nuevamente, y eso llevará tiempo. Además, si ocurriere un error la compilación se suspenderá perdiendo los resultados intermedios.

Para manejar la compilación de varios archivos por separado la herramienta adecuada es el "make". Explicar cómo utilizarlo excede los límites de este artículo. Nuevamente sugiero visitar los enlaces al final para más información.

3. Mezclando código en lenguaje C con código en ensamblador.

Un ejemplo introductorio.

Comenzaré mostrando un inútil programa que recibe como parámetro un número real y lo redondea. Aunque no entienda muy bien el código, no se preocupe, lo importante ahora es que comprenda la estructura.

Se trata de tres archivos: "main.c", "redon.s" y "redon.h". El primero es el que contiene la función "main" escrita en C, ahí es donde comienza la ejecución. El segundo contiene la función "redon", que recibe como parámetro un número flotante, lo redondea y lo convierte en entero. En el tercero está el prototipo de "redon", necesario para que la función pueda ser llamada desde otros archivos.

El archivo "main.c":

#include "redon.h"
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv [])
{
float n;
int n_redon;

if (2 != argc) {
    fprintf(stderr, "Error: debe haber un parámetro\n");
    return 1;
}

n = (float) atof(argv [1]);
n_redon = redon(n);

printf("El número entero que más se aproxima a %f es %d.\n",
      n, n_redon);

return 0;
}

El archivo "redon.s":

.text

.globl redon
redon:
flds        0x04 (%esp)
fistpl      0x04 (%esp)
movl        0x04 (%esp), %eax
ret

El archivo "redon.h":

#ifndef REDON_H
#define REDON_H

int redon (float);

#endif /* REDON_H */

Observe el uso de las directivas ".text" y ".globl". La primera, aunque no parezca, indica que lo que sigue es código. La segunda, que "redon" podrá ser llamada desde funciones que estén en otros archivos objeto. Esto contrasta con las funciones en C, las cuales son globales por defecto a no ser que se indique lo contrario mediante la palabra clave "static".

Para compilar y enlazar todo se deben ejecutar los siguientes comandos:

$ cc -Wall -O -c main.c
$ cc -c redon.s
$ cc -o redondear main.o redon.o

Las tres convenciones.

Para escribir funciones en ensamblador que puedan ser llamadas desde otras en C debe conocer tres convenciones. La primera tiene que ver con el pasaje de parámetros, la segunda con el retorno de valores y la tercera con la preservación de los valores en los registros.

i. Pasaje de parámetros

Cuando un programa se ejecuta el sistema operativo le asigna memoria para que pueda operar. Parte de la memoria asignada al programa es utilizada como una pila para almacenar las variables locales a las funciones (a excepción de las declaradas con la palabra clave "static"), los parámetros y algunas cosas más.

En una arquitectura 80386 el registro "esp" (puntero de pila) es el que se encarga de guardar un puntero hacia el tope de la pila. Cuando se insertan datos en la pila a través de la instrucción "push" el tope de la pila ya no es el mismo, entonces el puntero de pila (que está guardado en el registro "esp") es cambiado automáticamente para que pueda continuar apuntando hacia el tope. Lo inverso ocurre cuando se quitan datos de la pila a través de la instrucción "pop". Cabe recordar que en una pila no es posible insertar o quitar datos de otro lugar que no sea su tope, de lo contrario no sería una pila.

Si no está familiarizado con lo que estoy diciendo, probablemente tampoco esté familiarizado con la programación en ensamblador. Entonces sería muy conveniente que lea algún apunte introductorio acerca del tema. En Internet debe haber alguno corto. La programación en ensamblador excede los límites de este humilde artículo.

Volviendo al punto, la importancia de la pila aquí es que es el mecanismo mediante el cual se pasan los parámetros a las funciones. Los parámetros son pasados de derecha a izquierda, es decir, primero se inserta en la pila el último parámetro, luego el penúltimo, y así se continúa hasta insertar finalmente el primero. La función que llama a otra es la que se encarga de colocar los parámetros en la pila y también de quitarlos. Esta es la convención en C, aunque existen otras convenciones en otros lenguajes en las cuales es la función llamada la que quita los parámetros de la pila.

En un intento de aclarar el tema diré que para invocar a la función

void f (int param1, int param2, int param3);

con param1 = 3, param2 = 2 y param3 = 5 se debería escribir el siguiente código en C:

f (3, 2, 5);

y el siguiente en ensamblador:

pushl   $5
pushl   $2
pushl   $3
call    f
addl    $12, %esp

Las tres primeras instrucciones colocan los parámetros en la pila. La cuarta llama a la función "f" y la quinta le adiciona doce al puntero de pila. Esto es porque los parámetros insertados ocupan doce bytes entre los tres (cuatro cada uno).

Adicionarle y sustraerle al puntero de pila son maneras de liberar espacio y de hacer espacio en la pila respectivamente.

Notará que luego de "push" y de "add" hay una "l". Esto no es propio del lenguaje ensamblador 80x86 de Intel. Sino que pertenece a la notación de AT&T, que es la adoptada por el ensamblador de GNU. Esta "l" significa que el parámetro de la instrucción es de 32 bits.

ii. Retorno de valores.

Según el tipo del valor retornado se procede de distinto modo.

Para los tipos de datos predefinidos por el lenguaje la función llamada deposita el valor retornado en determinado registro. Luego la función que ha realizado el llamado asumirá que está en el registro convenido y accederá a él para obtenerlo. El registro que se utiliza depende del tipo de dato del valor retornado.

A continuación listaré distintos tipos de datos y los registros utilizados:

int / unsigned int / long / unsigned long -> eax
short / unsigned short -> ax
char / unsigned char -> al
punteros -> eax
float / double -> st (0)

Las funciones que devuelven un tipo de dato definido por el usuario mediante "struct" o "union" cuentan automáticamente con un primer parámetro implícito adicional que indica la dirección de memoria en donde será copiado el valor devuelto.

Por lo tanto se podría decir que las funciones:

struct s f (int param1, int param2, int param3);

y

void f (struct s *retval, int param1, int param2, int param3);

una vez traducidas al ensamblador tienen los mismos parámetros.

Los tipos de datos definidos con "enum" se implementan del mismo modo que un numero entero, por lo tanto se devuelven copiando el valor al registro "eax".

iii. Preservación de los valores de los registros.

En el momento de retorno de una función se espera que el valor de ciertos registros sea el mismo que en el momento de su llamado. Estos registros son ebp, esp, ebx, esi y edi. Por lo tanto si la función hará uso de ellos deberá guardarlos previamente y restaurarlos a sus valores originales luego, o asegurarse de cualquier otra forma que queden como los puso la función que hizo el llamado.

Los registros eax, ecx, edx, eflags y los de la unidad de punto flotante (st (0), st (1), st (2), ..., st (7) y los registros de control y estado) pueden ser utilizados sin cuidado alguno. El resto de los registros del procesador (que no enumeraré) sólo puede ser modificado por el sistema operativo, por lo tanto se descarta su posibilidad de uso.

4. Algunos consejos.

Llegando ya al final me gustaría mencionar algunas sugerencias.

i. El compilador de C es una buena herramienta para estudiar ensamblador.

Escribir funciones en C y utilizar el compilador para traducirlas al ensamblador es una excelente manera de conseguir ejemplos de rutinas en este lenguaje. Debería ser uno de los primeros recursos para eliminar todas las dudas que surjan.

Es aconsejable hacerlo activando la opción de optimización para obtener un buen código y las advertencias para detectar errores. El comando para hacer esto es el siguiente:

$ cc -Wall -O -S ejemplo.c

ii. Cuidado con el "decorado de nombres" en C++ y en algunos sistemas operativos.

Es muy probable que algunos, tras leer este artículo, intenten mezclar ensamblador con C++ y las cosas no funcionen. Este lenguaje posee una propiedad denominada "decorado de nombre" (name decoration) o "planchado de nombre" (name mangling) que consiste en cambiar el nombre de las funciones cuando son traducidas al ensamblador. C++ necesita hacer esto para soportar la sobrecarga de funciones, las funciones miembro y otras características del lenguaje. Por lo tanto esperará que todos los nombres hayan sido decorados adecuadamente.

A pesar de esto es posible invocar funciones cuyo nombre no ha sido "decorado" encerrando sus prototipos en un bloque precedido por la frase "extern "C" ".

Para ilustrar con un ejemplo, el archivo "redon.h", para poder ser usado en C y también en C++, debería escribirse así:

#ifndef REDON_H
#define REDON_H

#ifdef __cplusplus
extern "C" {
#endif

int redon (float);

#ifdef __cplusplus
}
#endif

#endif /* REDON_H */

El compilador de C en un popular sistema operativo no POSIX propenso a fallas realiza también un decorado según la convención de llamada de la función. Sin embargo consiste sólo en agregarle un guión bajo al nombre. Así, por ejemplo, el archivo "redon.s" debería sustituirse por el siguiente:

.text

.globl _redon
_redon:
   flds        0x04 (%esp)
   fistpl      0x04 (%esp)
   movl        0x04 (%esp), %eax
   ret

Pero "redon.h" no debería ser modificado.

Para una mejor explicación del asunto se recomienda visitar los enlaces al final del artículo.

iii. Utilice el comando "objdump" para desensamblar archivos binarios.

Este comando propio del UNIX desensambla archivos objeto y archivos ejecutables.

Para hacerlo debe invocar el comando con la opción "-d":

$ objdump -d ejemplo.o

Consulte la documentación del sistema operativo para ver otras opciones que acepta el comando.

iv. Utilice el comando "nm" para listar las funciones en un archivo binario.

En los sistemas tipo UNIX el comando "nm" lista las funciones y variables que están dentro de un archivo objeto o un archivo ejecutable y a las que hacen referencia funciones dentro del archivo.

Puede utilizarlo del siguiente modo:

$ nm ejemplo.o

Para aprender a leer el listado que genera sugiero recurrir a la documentación del comando.

5. Enlaces que se sugiere visitar.

Programación Bizarra

250 caracteres

Las Interrupciones en los Procesadores 80x86

1. Origen de las interrupciones.

1.1. Excepciones.

Vector

1.2. Interrupciones externas.

1.3. Interrupciones por software.

2. Tratamiento de las interrupciones

2.1 Interrupt descriptor table (IDT).

2.2 Formas de atender a las interrupciones.

Anexo 2.B. Programa de ejemplo.

La "reventa" del software

Bandera en ASCII

What the Hex?

No sé lo que quiero bajar, pero lo quiero ya

Bases de datos, passwords, seguridad y otras yerbas

¿No sabe qué nombre ponerle a sus clases?

Los verdaderos programadores

Iterando strings en Java

Los lenguajes de verdad vs Java

Mi equipo de programadores

La tierra de c++

Porqué importa el software terminado

Traducido de Why working software is important, por Joe Little.

Fusionando secuencias ordenedas con Python

Tabla periódica de Perl 6

Dilbert: GUI button

Firefox es un panda

El tutorial más corto sobre Autoconf y Automake

El juego más fácil del mundo

Java Hashing

El contrato de un HashCode

Objetos que son iguales, pero retornan diferentes hashCodes

Objetos que no son iguales, pero retornan el mismo hashCode

¿Por qué almacenar en baldes?

Sobreescribir el método hashCode()

Retornar un valor fijo (es una mala idea...)

Método de Effective Java

Apache HashCodeBuilder

Objetos mutables como clave

Traducido de Java Hashing, publicado en DZone.

awk continúa pateando traseros

Gadgets en abowman.com

Tcl/Tk, un lenguaje con actitud de rock

Los lenguajes más populares

Presentación de Log4j

Construye tu propia tira cómica online

La tabla periódica de las fuentes

¿Por qué en GNU/Linux no hay virus?

El juego de la vida de Conway

El problema con la planificación

Café Instantáneo

Cómo NO hacer programas

El juego más difícil del mundo

Unix, el sistema operativo "hackeable"

El día internacional del software libre

La velocidad mata

Traducido de Speed kills, por Uncle Bob.

I wish I were the moon

Ejemplo de GUI Bizarra...

Sobre el IQ

Frase del día

A Una Década Del Ultimo Sueño de Sega

No se recomienda borrar datos

Basado en Deleting data is not a recommended practice.

Programación Talabartera Volumen 1

Recreo: el diccionario del Eclipse

La felicidad del usuario según la funcionalidad del software

Consejos para Entrevistar Usuarios

Sobre el Planeamiento

Durante la Entrevista

Luego de la Entrevista

¿Qué es el Software?

Referencias

Herramientas Libres para OLAP: Mondrian y JPivot

I. ¿Qué es OLAP?

Bases de datos OLAP

II. Herramientas Libres para OLAP: Mondrian y JPivot

Mondrian