Para mantener las cosas simples, empezaremos reconociendo solo integers, para nuestros operadores aritmeticos basicos, ademas tambien incluiremos un operador unario absoluto.

* Los primeros 5 patrones son operadores literales, escritos entre comillas, y las acciones por ahora solo imprimiran un mensaje que indican que hicieron match. Las comillas le dicen a flex que use las cademas como estan, mas que interpretarlas como expresiones regulares.

* El sexto patron busca un integer. La accion imprimira el patron que ha detectado usando el apuntador char *yytext que el scanner establece despues de cada match.

* El septimo patron marca un caracter de nueva linea, representado por el usual \n .

* El octavo patron ignora los espacios en blanco. Este hace match sobre cualquier unico espacio en blanco o tab (\t), y la accion vacia sencillamente no hace nada.

* El patron final es el cachalo todo, este cachara todo lo que los otros patrones no cacharon. Su codigo de accion imprira un mensaje informativo.

Estos 9 patrones ahora proveen reglas para hacer match con cualquier cosa que el usuario pudiece alimentar a nuestro scanner (de moemnto).

Y aqui compilamos el analizador lexico generado con flex..

El Scanner como Corutina
La mayoria de los programas con scanners flex, usan el scanner para retornar un flujo de tokens que son tomados por un parser. Cada que el programa requiere un token, este llama a yylex(), el cual lee un pequeña entrada y retorna el token. Cuando este requiere otro token, este llama a yylex() de nuevo. Entonces se puede decir que el scanner actua como una corutina, esto significa que cada vez que este retorne algo , este recuerda donde estaba, y la siguiente llamada se traera lo que sigue.

Ahora modificaremos nuestro scanner , entonces este retornara tokens que un parser puede usar para implementar una calculadora.

Tokens y Valores
Cuando un scanner flex retorna un flujo de tokens, cada token de hecho tendra 2 partes, el token y el valor del token. El token es un pequeño entero. Los numeros de token son arbitrarios, excepto que el token zero siempre simboliza fin de archivo. Cuando bison crea un parser, bison asigna los numeros de token automaticamente, iniciando en 258 (esto para evitar coliciones con los token de caracteres literales, cosa que discutiremos despues) y crea un .h con definiciones de numeros de tokens. Pero por ahora, nosotros definiremos algunos a mano:

Calculador Scanner fb1-4.l (Primera Version)

En esta version de calculadora hemos definido los numeros de token en un enum de C. Agregamos una variable yylval, es la variable que almacenara el valor del token, un integer, lo cual es lo adecuado para la primera version de nuestro calculador.
Como podran observar la lista de patrones es la misma como en el ejemplo anterio, pero el codigo de acciones es diferente. Para cada uno de los tokens, el scanner retorna el codigo apropiado para el token; para numeros, este convierte el string de digitos a integer y almacena este en yylval despues del retorno. El patron espacio en blanco no retornara nada, entonces el scaner solo seguira buscando lo que sigue.

Solo por probar, aqui tenemos un pequeño programa que llama a yylex(), que imprimira los valores de token, y, y para los tokens NUMBER , tambien se imprimira yylval.

Ahora que tenemos trabajando nuestro scanner, voltearemos nuestro atencion al parseo.

Gramaticas y Parseo
El trabajo del parser is deducir la relacion entre los tokens de entrada. Una manera comun de desplegar tales relaciones es un arbol de parseo. Por ejemplo, bajo la usuales reglas de la aritmetica, la expresion aritmetica 1 * 2 + 3 * 4 + 5 la cual podria tener el siguiente arbol de parseo

La Multiplicacion tiene una mas alta precedencia que la adicion, entonces las dos primeras expresiones son 1 * 2 y 3 * 4. Entonces estas dos expressiones son agregadas juntas, y esta suma es entonces agregada a 5. Cave mencionar que cualquier parser bison parser genera un arbol de parseo a como este parsea su entrada.

Gramaticas BNF
En orden a escribir un parser, requerimos una manera para describir las reglas que usara un parser para convertir una secuencia de tokens dentro de un arbol de parseo.

La mas comun clase de lenguaje que un parser de computadora toma es uno que sea CFG (Context Free gramar). La forma estandart para escribir CFG es la forma Backus-Naur (BNF - backus Naur forma), creada alrededor de 1960 para describir Algol 60 y fue bautizado por 2 miembros del comite Algol.

Afortunadamente BNF es sencillo. Aqui tenemos un ejemplo para la expresion aritmetica 1 * 2 + 3 * 4 + 5:

Cada linea es una regla que indica como crear una rama del arbol de parseo. En BNF, ::= puede ser leido “es un” o “se convierte en” y | es “un OR logico” o si lo quieres ver asi, una manera de crear una rama del mismo tipo. El lado izquierdo de una regla es nombrado simbolo o terminal.

Por convencion, todos los tokens son considerados simbolos, pero ojo con esto , tambien existen simbolos que no son tokens. Usualmente el muy util BNF es invariablemente y sin lugar a dudas recursivo, con reglas que hacen referencias a ellas mismas directa o indirectamente.

El lenguaje de reglas para la entrada de Bison
Las reglas de Bison son basicamente BNF, con la puntuaxcion simplificada un poquito para hacerlas a estas faciles de typear (verbo ochentero para teclar algo en el keyboard de tu computador) .

Aqui lo que seria el codigo Bison, inclullendo el BNF, para la primera version de nuestra calculadora.

Observece que los programas Bison tienen (creanme que esto no es por coincidencia) las mismas 3 partes estructuradas como los programas flex

Compilando los programas de Flex y Bison Juntos! (que barbaridad)
Antes de que compilemos el scanner y el parser dentro de un programa funcional. Tendremos que hacer unos pequeños cambios en el scanner, para que este pueda ser llamado desde el parser. Mas que definir token explicitos en la primera parte, incluiremos un archivo .h que bison va a crear por nosotros , el cual inclulle ambas definiciones (la de los tokens y yyval).

Ahora compilamos… siguiendo el siguiente orden

$ bison -d ARCHIVO_SINTACTICO.y
$ flex ARCHIVO_LEXICO.l
$ gcc lex.yy.c fb1-5.tab.c -lfl -o calculadora

Gramaticas Ambiguas
Una de las grandes fortalezas de bison, y simultaneamente uno de sus mas impresionantes aspectos es, que este no puede parsear gramatica ambigua. Esto nos garantiza que cualquier parser que creemos con bison tendra solo una forma de parsear cualquier entrada que este parsee. La gramatica previa es ambigua, ya que 1 - 2 + 3 podria ser parseadado como (1-2) + 3 o como 1 - (2+3), lo cual son dos expresiones diferentes con valores diferentes. Tal vez en algunos casos este sutil nivel de ambiguedad podria ignorarce (como por ejemplo, 1+2+3), pero en la mayoria de los casos la ambiguedad es considerada un error que debera ser arreglado.

Agrando mas reglas para terminar con las Gramaticas Ambiguas

listo … ahora nuestra calculadora basica permite agrupar operaciones con parentesis.

Un ejemplo sencillo del uso de Flex, un mini programa flex

Nuestro programita se llamara fb1-1.l, y el objetivo de este es contar la cantidad de lineas, caracteres y palabras que reciba la entrada de nuestro scanner.

Un programa flex consiste de 3 secciones , separadas por las lineas %% .

* La primera seccion contiene declaraciones y opciones de parametrizacion.
* La segunda contiene una lista de patrones y sus acciones.
* La tercera codigo en c que es copiado al scanner generado.

Ejecucion de nuestro ejemplo:

Explicacion detallada de nuestro ejemplo:
* Se manda a llamar al interprete flex y este transformara el fichero fb1-1.l a un archivo de c. Ahora que tenemos nuestro analizador lexico en c, procedemos a compilarlo con el gcc , no olvides hacer referencia a la libreria flex (esto es posible agregando -lfl como libreria a la hora de llamar a gcc)
* Te preguntaras y que cojones hace yylex() ? pues esta funcion es la rutina scanner (observa su nombre .. ya que lleva la abreviacion lex de la palabra analizador lexico), en ausencia de cualquier otra parametrizacion, el scanner leera de la entrada estandart (stdinput)

Nota sobre CTRL + D: ^D es un caracter de fin de archivo en Unix/Linux. Sobre windows es ^Z

Teniendo la siguiente expresion alfa = beta + gama podriamos decir que:

Escaneo o analisis lexico: Es el Proceso encargado de dividir el texto leido sobre un archivo o buffer de memoria, y traducirlo a pequeños pedacitos llamados tokens. Se podria decir que el scanner (aquel proceso que realiza el analisis lexico) divide el texto alimentado en tokens como alpha , beta , gama, signo de mas, signo igual .. etc.

Parseo o analisis sintactico: Se podria decir que el parser (aquel proceso que hace el analisis sintactico) determinara que “beta + gama” es una expresion y que la expresion es asignada a alfa.

conclusiones:
* Flex es un Analizador Lexico
* Bison es un Analizador Sintactico

#!/bin/sh
echo "recursively removing .svn folders from"
pwd
rm -rf `find . -type d -name .svn

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package com.xpress.sinimportancia;

import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import java.io.StringWriter;
import java.util.LinkedHashMap;
import java.util.Iterator;
import java.util.Properties;

/**
 *
 * @author pianodaemon
 */
public class QuicklyVelocityTemplate {

    private static VelocityContext convert2context( LinkedHashMap params){
        VelocityContext context = new VelocityContext();
        Iterator it = params.keySet().iterator();
        while (it.hasNext()) {
            String key = ( String ) it.next();
            String value = ( String ) params.get( key );
            context.put(key , value);
        }
        return context;
    }

    public static String pegarDatosConPlantilla(String filevm , LinkedHashMap params){
        String valor_retorno = null;
        Template template = null;
        StringWriter writer = new StringWriter();
        VelocityEngine engine = new VelocityEngine();

        String ruta_platillas = System.getenv(”HOME”) + “/” + “vmtemplates/”;

        System.out.println(ruta_platillas);

        Properties p = new Properties();
        p.setProperty(”resource.loader”, “file”);
        p.setProperty(”runtime.log.logsystem.class”, “org.apache.velocity.runtime.log.SimpleLog4JLogSystem”);
        p.setProperty(”runtime.log.logsystem.log4j.category”,”org.apache.velocity.runtime.log.SimpleLog4JLogSystem”);
        p.setProperty(”file.resource.loader.cache”,”false”);
        p.setProperty(”file.resource.loader.modificationCheckInterval”,”2″);
        p.setProperty(”file.resource.loader.class”,”org.apache.velocity.runtime.resource.loader.FileResourceLoader”);
        p.setProperty(”file.resource.loader.path”, ruta_platillas);

        try {
            engine.init(p);
            template = engine.getTemplate(filevm);
            template.merge( convert2context(params) , writer );
            valor_retorno = writer.toString();
        } catch( Exception e ) {
            System.out.println(”Exception caught: ” + e.toString());
        }        

        return valor_retorno;
    }
}

package com.xpress.ejemplodevelocity;

import com.xpress.sinimportancia.QuicklyVelocityTemplate;
import java.util.LinkedHashMap;

/**
 * Hello world!
 *
 */
public class App {

    public static void main( String[] args ){

        String mi_plantilla = "ejemplo.vm";
        String nombre = "Edwin Plauchu";

        LinkedHashMap params =  new LinkedHashMap();

        params.put(”programador”,nombre);

        System.out.println( QuicklyVelocityTemplate.pegarDatosConPlantilla(mi_plantilla, params) );

    }
}

Aqui mi archivo ejemplo.vm

--------------------
Esto es una salida
Pantalla formateada
por: $programador
--------------------

Mi salida Generada

--------------------
Esto es una salida
Pantalla formateada
por: Edwin Plauchu
--------------------

Por ultimo esto son los jar requeridos
velocity-1.6.3-dep.jar
commons-collections-3.2.1.jar
commons-lang-2.5.jar
commons-io-1.4.jar

Un ejemplo bastante sencillo

#include string.h
#include stdio.h

char string[] = "una cadena de  tokens";
char *token;

int main(void){

        token = strtok(string , " "); /*Separamos por espacios*/
        while (token != NULL){
                printf("El token es:  %s\n", token);
                token = strtok(NULL," ");
        }

        return 0;
}

Esta sera la salida obtenida despues de compilarlo y ejecutarlo
Edwins-MacBook-Pro:~ pianodaemon$ gcc ejemplo.c
Edwins-MacBook-Pro:~ pianodaemon$ ./a.out

El token es:  una
El token es:  cadena
El token es:  de
El token es:  tokens

Cada que se lea una longitud de bytes determinada por la variable len, los bytes leidos caeran en buf, estos bytes leidos proveendran de la actual posicion de desplazamiento (comunmente conocida como offset) del archivo referenciado por el descriptor de archivo fd.

Cuando se invoca a la funcion read() con exito, el numero de bytes escritos dentro de buf , sera el valor retorno que nos regrese la funcion. En caso de suceder un error, la llamada al sistema read nos retornara -1, y la variable errno sera establecida al tipo de error que se sucito.

* Un ejemplo impractico de su uso (pero ilustrativo)

Este ejemplo lee de el file descriptor fd y pasa lo leido a word. El numero de bytes leidos es igual a la medida de el tipo unsigned long type, el cual suele ser cuatro bytes sobre sistemas Linux de 32-bit, y ocho bytes sobre sistemas de 64 bits.

* Mas consideraciones a tomar en base a los Valores de Retorno que nos puede arrojar read()

Es muy legal que read( ) nos llegue a retornar un valor menor que len. Esto puede suceder por distintas razones:
a) Menos bytes que los indicados por len pudieron haber estado disponibles
b) La llamada pudo haber sido interrumpida por una señal
c) La tuberia fue rota (si fd fuece una tuberia)
d) Algunas cosas mas.

La posibilidad de un valor de retorno 0 es otra consideracion cuando usamos read( ). La llamada al sistema read( ) retorna 0 para indicar fin de archivo o EOF (end-of-file), en este caso no existen mas bytes que leer del archivo a que hace referencia el fd.

EOF: no es considerado un error, este simplemente indica que la posicion del archivo avanzo mas alla de el ultimo offset valido en el archivo.

* Direfencia entre EOF y la lectura de bytes que aun no estan disponibles

Que pasaria si un llamada a read fuece hecha por la cantidad de bytes que indica len, pero estos bytes no estubiecen disponibles para lectura, read se bloquearia (dormiria) hasta que los bytes estubiecen disponibles (asumiendo que el descriptor de archivo no fue abierto en modo non-blocking). Aclaremos de que esto es totalmente diferente de un tipo de un retorno EOF. Esto es, ya que existe una diferencia entre “no hay data disponible” y “fin del data”. En el caso de EOF, el final de archivo fue alcanzado. En el caso del bloqueo, read se quedo esperando por mas data, esto suele ser una cosa frecuente en la lectura de datos desde socketes o archivos que representan dispositivos.

* Algunas situaciones se pueden solucionar

Si una llamada a la read( ) es interrunpida por un señal antes que cualquier byte sea leido.

Una tipica llamada a create:

Es similar a lo que hariamos con open de esta manera:

La llamada al sistema open( ) mapea el archivo dado por el pathname hacia el file descriptor. La posicion sera establecida a zero, y entonces el archivo es accesado acorde a la flags (banderas) previamente suministradas.

Flags para open( )
El argumento bandera debera ser uno de O_RDONLY, O_WRONLY, o O_RDWR. Respectivamente, estos argumentos solicitan que el archivo sea abierto solo para lectura, solo para escritura, o para ambos lectura y escritura.

Por ejemplo el siguiente codigo abre /home/j4nusx/plauchu.txt para lectura:

     int fd;
     fd = open ("/home/j4nusx/plauchu.txt", O_RDONLY);
     if (fd == -1)
          /* error */

Los flags puede tambien ser la combinacion, con el operador de bits OR (|), de una o mas de las siguientes flags:

O_CREAT
O_EXCL
O_NOCTTY
O_APPEND
O_TRUNC

Y alguna otras cuyo proposito puede ser consultado en la pagina de manual open(2)

Por ejemplo, el siguiente codigo abre para escritura el archivo /home/teach/groovy. Si el archivo ya existiera, este sera truncado a la longitud de cero. Pero si el archivo no existiece ya que el flag O_CREAT no fue especificado, si el archivo no existe la llamada al sistema fallara (nos arrojara un -1):

int fd;
     fd = open ("/home/teach/groovy", O_WRONLY | O_TRUNC);
     if (fd == -1)
         /* error */

Propietarios de los nuevos archivos creados

Determinar que usuario es propietario de un archivo recien creado es algo directo: el uid de del propietario del archivo es el uid del proceso que lo creo.

Determinar el grupo propietario es algo mas complicado. El comportamiento por default es establecer el grupo del archivo a el efective gid del proceso que ha creado el archivo. Este suele ser el comportamiento del System V (este fue el modelo adoptado por linux), y el modus operndi standard de Linux.

Para hacerlo dificil , ademas, BSD definio su propio comportamiento: El grupo propietario del archivo es establecido al gid del directorio padre. Este comportamiento es disponible en linux con la opcion mount.

Permisos de los nuevos archivos creados
Ambas de las forma de llamar la llamada al sistema open( ) son validas. El modo argumento es ignorado hasta que el archivo es creado; Es este requerido si O_CREAT es dado. Si olvidaste proveer el argumento modo cuando se usa O_CREAT, los resultados suelen ser indefinidos, y a menudo un poco feos, por lo que te recomiendo no olvidarlo!

Cuando un archivo es creado, el argumento modo provee los permiso al nuevo archivo creado. El modo no es checado sobre el archivo abierto, lo que nos permite realizar operaciones contradictorias, como lo es abrir el archivo para escritura, pero asignando a su vez permisos de solo lectura a este.

El argumento modo es el familiar estilo octal de Unix (esto para definir el conjunto de bits) como lo es 0644.

Para compensar la no portabilidad de las posiciones de los bit en el argumento modo, POSIX introdujo el siguiente conjunto de constantes:

S_IRWXU
Owner has read, write, and execute permission.

S_IRUSR
Owner has read permission.

S_IWUSR
Owner has write permission.

S_IXUSR
Owner has execute permission.

S_IRWXG
Group has read, write, and execute permission.

S_IRGRP
Group has read permission.

S_IWGRP
Group has write permission.

S_IXGRP
Group has execute permission.

S_IRWXO
Everyone else has read, write, and execute permission.

S_IROTH
Everyone else has read permission.

S_IWOTH
Everyone else has write permission.

S_IXOTH
Everyone else has execute permission.

La creacion de nuevos archivos y sus permisos sera afectada por umask (
umask (abreviatura de user mask, mascara de usuario) es una orden y una funcion en entornos POSIX que establece los permisos por defecto para los nuevos archivos y directorios creados por el proceso actual ).