Archive for the '15035' Category

Resoluciones del Nuevo Mes: Julio 2014

Wednesday, July 9th, 2014

Un nuevo mes comenzó, tiempo de revisar mis resoluciones de Junio 2014, y escribir las nuevas:

– Continuar AjErl [pendiente]
– Continuar ScalaSharp [completo] repo 
– Continuar SharpGo [completo] repo
– Alcance de variables en lenguaje Mass [completo] repo
– Comenzar SimpleItems [pendiente]
– Continuar SimpleApps [partial] repo
– Continuar ClojSharp [pendiente]
– Continuar DictSharp [pendiente]
– Primer caso de uso distribuido de AjErl [pendiente]
– Primer caso de uso distribuido de Aktores [pendiente]
– Escribir C# Posts [completo] Posts
– Escribir TDD Post [completo] Post
– Mejorar el código de mi sitio personal [completo]

También estuve trabajando en:

– Crear y publicar primer versión SimpleCurry, para programación funcional en JavaScript [completo]  repo
– Crear y publicar primer versión LoadJsons, lee un modelo JSON desde varios archivos, para JavaScript/Node [completo]  repo
– Crear un sitio dinámicado, definido por JSON, para Express 4 [completo]  repo
– Generar código para Express 4 usando AjGenesisNode [completo]  repo
– Generar código Sinatra usando AjGenesisNode [completo]  repo
– Mejorar AjGenesisNode, AjGenesisNode-Model, AjGenesisNode-Entity [completo]  repo repo repo
– Continuar DylanSharp [completo]  repo
– Crear SharpBus, un service bus tipo Mule, en C# [completo]  repo

Estas son mis resoluciones para Julio 2014:

– Seguir mejorando la generación de código de AjGenesisNode para Express
– Seguir mejorando la generación de código de AjGenesisNode para Sinatra
– Primer generación de código de AjGenesisNode para Laravel 
– Mejorar la carga de módulos y la exportación de variables/funciones en el lenguaje Mass
– Continuar con SharpBus
– Continuar con Dynamic Site
– Dar una charla sobre Node.js/Express
– Dar una jornada sobre Node.js/Express
– Seguir mejorar el código de mi sitio personal
– Escribir post de TDD
– Escribir posts de C#
– Caso de uso distribuido en Aktores
– Revisar, refactorizar y continuar la implementación de RustScript

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

SharpStorm Implementando Storm en C# (1) Proyecto Inicial

Monday, June 30th, 2014

En los dos últimos años estuve explorando las ideas de Storm (ver https://storm.incubator.apache.org/), implementándo alguna topología local en Node.js. Llegó la hora de practicar más C# y TDD (Test-Driven Development), con:

https://github.com/ajlopez/SharpStorm

El estado inicial del proyecto:

La idea es implementar bolt, spout y un builder de topologies. Leo en

https://storm.incubator.apache.org/about/simple-api.html

There are just three abstractions in Storm: spouts, bolts, and topologies. A spout is a source of streams in a computation. Typically a spout reads from a queueing broker such as Kestrel, RabbitMQ, or Kafka, but a spout can also generate its own stream or read from somewhere like the Twitter streaming API. Spout implementations already exist for most queueing systems.

A bolt processes any number of input streams and produces any number of new output streams. Most of the logic of a computation goes into bolts, such as functions, filters, streaming joins, streaming aggregations, talking to databases, and so on.

A topology is a network of spouts and bolts, with each edge in the network representing a bolt subscribing to the output stream of some other spout or bolt. A topology is an arbitrarily complex multi-stage stream computation. Topologies run indefinitely when deployed.

Como ven, en el proyecto por ahora están definidas las interfaces que espero por ahora tengan bolts y spouts, y un topology builder para armar una topología. Por ahora, quiero una implementación local (sin procesamiento distribuido). Luego, espero implementar el algoritmo de ACK que tiene Storm original, que permite saber cuándo un mensaje entrante quedó completamente procesado (incluso los procesos de los mensajes que produjo en el medio del proceso).

Próximos temas: revisar ISpout, IBolt, y como se arma una topología.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

SharpDoop Implementando Map reduce en C# (1) El Proyecto

Monday, June 30th, 2014

Ya estuve experimentando con map-reduce en Node.js/JavaScript. Pero también es interesante implementar algo del algoritmo en C#, para practicar TDD (Test-Driven Development) y para aprender más sobre lo que implica implementar el algoritmo. El proyecto que inicié es:

https://github.com/ajlopez/SharpDoop

El estado del proyecto a hoy:

Tiene un proyecto de librería de clases, y el proyecto de test. Todavía no llegué a pensar en algo distribuido. Lo único que quiero por ahora es especificar el algoritmo de map, el de reduce, y enviarlo a que procese como un job, dentro de este proyecto.

Vean que hay entonces un MapReduceJob. Es la clase base que se encarga de ejecutar un map (un lambda o Action que toma clave, valor y va procesándolo) y un reduce (toma clave, una lista de valores de esa clave, y emite resultado). Gracias a C#, esas dos operaciones se pueden expresar como lambdas o como métodos delegados en un objeto más complejo. Por ahora, están funcionando los casos simples que planteo en los tests.

Como divertimento, armé también un MapProcessJob, que es una variante de map/reduce a discutir. En vez de procesar primero todas las claves, y luego pasarlas por el reduce, trata de hacer todo junto. En algunos casos de uso puede ser más eficiente, pero es un tema a discutir con más detalle.

Próximos temas: revisar más en profundidad la implementación y las ideas, como el map/process.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

AjTalk Implementando Smalltalk en C# (4) El Proyecto

Sunday, June 29th, 2014

Anterior Post

Hace ya año y medio que no escribo de este proyecto en C#, pero fui trabajando en él, y en la implementación paralela que tengo en JavaScript (de hecho, presenté algunos conceptos de ambos en la Smalltalks 2013 que se realizó el año pasado, en Rosario, Argentina).

El proyecto está en:

https://github.com/ajlopez/AjTalk

La estructura actual:

Veamos. Los proyectos son:

AjTalk: librería de clases, con la implementación de un compilador a bytecodes (y también a JavaScript), y un intérprete de los bytecodes compilados.

AjTalk.Compiler: un proyecto de consola que permite, usando el compilador mencionado en el proyecto anterior, generar código JavaScript.

AjTalk.Console: un REPL (Read Eval Print Loop)

AjTalk.Gui: una implementación sin terminar de ventanas

AjTalk.Tests: los tests que fui escribiendo, siguiendo el flujo de trabajo de TDD (Test-Driven Development)

El compilador a JavaScript creo que no lo voy a necesitar, porque en el último año he conseguido que el proyecto de JavaScript:

https://github.com/ajlopez/AjTalkJs

sea autosuficiente (ahora compila a bytecodes, pero también podría compilar a JavaScript; el tema que el intérprete de bytecodes me permite algunas operaciones más flexibles).

Y la implementación de ventanas (muy primitiva) la voy a sacar, para seguir por el camino de crear ventanas desde el propio AjTalk, en Smalltalk, accediendo a los tipos y objetos de .NET.

Un punto que me parece muy interesante (en ambos proyectos, el de C# y el de JavaScript) es tener una implementación modular: en vez de cargar una imagen con todo definido, poder definir módulos a cargar, como pasa en el ambiente Node.js. Los módulos estarían publicados en el NPM (El Node Package Manager), y cada cual podría indicar qué módulos necesita en su programa, en lugar de levantar todo Smalltalk.

Otro tema: en este proyecto de C# tengo implementado que pueda levantar más de una máquina AjTalk al mismo tiempo. E incluso puedo hacer que una máquina “ayude” a la otra. Por ejemplo, si la máquina A no tiene los métodos para compilar nuevos métodos, la máquina B puede ir en su auxilio. Así, la máquina A (y su imagen, que ya estoy grabando imagen binaria) puede mantenerse de tamaño pequeño.

Otra característica que tengo implementada: la capacidad de enviar un mensaje a un objeto, sin esperar una respuesta, un “fire and forget”. Y que el objeto destino pueda atender esos mensajes DE A UNO, como en los modelos de actores.

Tengo que revisar la implementación de objetos remotos (hoy basada en el viejo Remoting de .NET). Pero pienso que es una característica importante a mantener y explorar.

Bien, como ven, quedan multitud de temas para otros posts, como detalles de implementación de conceptos de Smalltalk, como Object, Class, ClassDescription, Behavior, MetaClass, etc.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

AjKeyvs Implementando KeyValue Store en C# (1) El Proyecto

Sunday, June 29th, 2014

Quería implementar un key-value store (como Redis) en C#, para ensayar algunas estructuras de datos y practicar TDD (Test-Driven Development). El proyecto que inicié es:

https://github.com/ajlopez/AjKeyvs

La estructura actual del proyecto:

Hay un proyecto de librería de clases, AjKeyvs, que contiene las colecciones que manejo en un repositorio. Lo interesante para este proyecto es implementar arreglos y conjuntos que puedan ser “sparse”, es decir que puedan tener claves muy diferentes. Ejemplo, tener una clave 1 (entero uno), y una clave 1000000 (entero un millon) y no tener que reservar un millon de lugares en el “arreglo”, sino solamente reservar lo que se usa. Y también tener un buen tiempo de acceso y modificación. Otras veces tendré claves String, con jerarquía, tipo “user”, “user:1”, “user:1:email”, etc. Y también quiero acceder rápidamente a ese tipo de estructura. Hay casos de uso que implican implementar conjuntos (con unión, intersección, etc), y en el caso de ser los elementos enteros, he implementado un conjunto donde prendo o apago un bit, de acuerdo a si el elemento correspondiente está o no está en el conjunto. Pero ya vendrá más detalle en próximos posts.

Si bien esa librería se puede usar in-process, también estuve armando un servidor, y un programa cliente. El servidor escucha y procesa comandos que le envían los clientes, enviándolos al repositorio de colecciones. Todas las colecciones se guardan en memoria. El tema persistencia me parece ortogonal a estos casos de uso. Veré si lo adoso a los comandos, o queda a responsabilidad del consumidor.

Y como es usual, hay un proyecto con los tests que fui armando siguiendo el flujo de trabajo de TDD.

Próximos temas: estructuras de datos, colecciones, comandos, concurrencia, etc.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

DylanSharp Implementando Dylan en C# (1) El Proyecto

Saturday, June 28th, 2014

Hace unos meses comencé a implementar un intérprete del lenguaje Dylan, para practicar TDD en C#, además de aprender algo de programación funcional. Leo en:

http://opendylan.org/

Dylan is a multi-paradigm functional and object-oriented programming language. It is dynamic while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors.

Lo interesante de Dylan es que incorpora tipos y objetos. Por ahora no pretendo generar código de máquina, sino, siguiendo “baby steps”, implementar los conceptos principales del lenguaje como un intérprete. Me gustaría igual agregar acceso a las librerías .NET, lo que me parece interesante para ampliar el alcance del lenguaje. Pueden aprender más del lenguaje en:

http://opendylan.org/documentation/intro-dylan/index.html

El proyecto que escribo en C# está en:

https://github.com/ajlopez/DylanSharp

y su estructura actual es:

Consta de una librería de clases, y un proyecto de tests. Hasta ahora hay algunas expresiones simples implementadas, un Parser, un Lexer, y un concepto del lenguaje implementado como clase C#: List, que implementa listas como en Lisp. Como en otros proyectos, tengo Context para mantener los valores de las variables, y recuperarlas por nombre. Notablemente, en Dylan las variables tienen tipo, pero aún no estoy controlando los tipos, simplemente evaluando expresiones cualesquiera. Tendré que tomar la decisión en algún momento, de controlar los tipos en el momento de compilar/procesar el programa. Según:

http://opendylan.org/documentation/intro-dylan/expressions-variables.html#type-declarations

Type mismatch errors should be caught at compile time.

Pero ya llegará el momento. Avanzando con TDD, tengo confianza en que llegado el caso podré hacer un refactor/rediseño de los que llamo quirúrgico, sin que sufra mucho el proyecto. Podría hacerlo en la próxima iteración o más adelante. Antecendentes de ese “approach” los he tenido en ScalaSharp, por ejemplo.

Próximos pasos: seguir implementado expresiones, definiciones de clases, módulos, comandos, funciones anónimas. Y controlar los tipos.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

ClojSharp Implementando Clojure en C# (1) El Proyecto

Thursday, June 26th, 2014

Desde la década pasada que me interesa Clojure, y desde siempre Lisp. Clojure está implementando sobre la máquina virtual de Java, pero también está implementado sobre .NET (que recuerde, usando Dynamic Language Runtime). La versión de Java compila a bytecodes Java. También hay una versión para JavaScript, llamada ClojureScript. La comunidad es muy activa, y ha traido un aire de renovación dentro de Java. Tiene características como la inmutabilidad de sus estructuras orientadas al trabajo en múltiples hilos evitando los problemas de lockeo y concurrencia. Tiene Software Transactional Memory, usando refs y transacciones,  pero ha sido menos usada por lo que veo. Han surgido frameworks web, y tiene un manejador de proyectos y dependencias Leiningen muy bien armado. Algunos enlaces en mis posts de Clojure.

Para practicar TDD (Test-Driven Development) y C#, he estado armando un intérprete (no un compilador a bytecodes), en .NET. Ver el proyecto en:

https://github.com/ajlopez/ClojSharp

El estado actual:

Tiene una librería de clases, otra de tests, y ya apareció un REPL (Read Eval Print Loop) sencillo como programa de consola.

En Lisp, una expresión se compone de un verbo y argumentos, expresados en una lista entre paréntesis. Por ejemplo una lista que al evaluarse devuelve la suma de 1, 2 y 3:

(+ 1 2 3)

Acá + (el signo más) es un símbolo que apunta a lo que en Lisp se llama una form, algo que recibe argumentos, opera con ellos y devuelve un resultado. Los argumentos que recibe un form en general se evalúan antes de serle entregados:

(+ 1 (- 3 4) 3)

Acá el primer argumento es una constante que vale uno, y el segundo argumento, antes de llegar al form de suma, ya es evaluado y vale –1 (menos uno). Pero hay forms que no necesitan evaluar los argumentos. Los reciben, digamos, en crudo. Se llaman special forms. Tengo implementados:

Y también tengo implementadas algunas forms (no especiales) como primitivas en C#. Muchas podrían ser implementadas en Lisp mismo, pero por ser tan básicas las implementé directamente en C#, usando TDD como es usual:

Próximos temas: la implementación de Machine, el Context, como se usa Parser y Lexer, más sobre evaluación de expresiones. Y mil temas más, como estructuras inmutables, macros, recursión optimizada, etc.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

Aktores Implementando Akka Actor Model en C# (1) El Proyecto

Wednesday, June 25th, 2014

Siguiente Post

Llegó la hora de escribir sobre el proyecto:

https://github.com/ajlopez/Aktores

Estoy implementando los primeros pasos hacia un modelo de actores, con pasaje de mensajes, tomando ideas de Akka. Ya había trabajado algo en Node.js, y en C# directo, teniendo actores que se mandan mensajes entre sí, pero esta vez quiero seguir el camino de Akka, paso a paso, como por ejemplo, tener nombres de actores, en un árbol, sistema de actores distribuidos, y la supervisión de agentes.

El estado del proyecto a hoy:

Veamos la implementación actual de actores:

Primero, un Actor es una clase abstracta, a implementar en cada caso por nosotros en cada sistema de actores que armemos. El resto del sistema no conversa con un actor directamente, sino a través de un ActorRef. Por ejemplo, para enviar un mensaje, hay un método Tell en el ActorRef. Internamente, tampoco lo envía a procesar al actor directamente, sino que cada actor tiene una Mailbox, y es a ese componente al que el ActorRef envia el mensaje. El objeto Actor es un objeto pasivo: no consulta la Mailbox directamente, sino que hay hilos de ejecución que van a ir consultando las tareas pendientes a hacer (como enviar un mensaje X a un actor A). Y el sistema internamente se asegura que al actor A sólo llegue a procesar UN mensaje por vez, para que el programador del actor no tenga que preocuparse por concurrencia desde múltiples hilos. Vean que, notablemente, el Actor no tiene una referencia a Mailbox. Pero eso es tema para próximos posts.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

AjErl Implementando Erlang en C# (1) El proyecto

Tuesday, June 24th, 2014

Siguiente Post

Hace ya un tiempo, para practicar C# y TDD y explorar ideas de Erlang, inicié:

https://github.com/ajlopez/AjErl

La estructura de la solución:

Tiene el proyecto núcleo de librería de clases, el proyecto de tests, y estoy armando un REPL (Read Eval Print Loop) como programa de consola. Lo interesante de Erlang es que internamente tiene procesos livianos, implementados en la propia máquina virtual, que pueden comunicarse entre sí enviando y recibiendo mensajes inmutables. No pretendo implementar una máquina virtual de ese tipo, sino tener procesos en threads. Nunca van a llegar a ser tan rápidos como los de Erlang, pero es un primer “baby step” a explorar, antes de tratar de mejorar la implementación.

Los mensajes se pueden enviar a una cola por proceso (thread en este caso), y ya tengo implementado la aceptación de los mensajes, su rechazo y vuelta a procesar, como en Erlang nativo.

Pero hoy quería comentar brevemente la implementación de cómo transforma texto de entrada en expresiones y formas Erlang:

Hay un Lexer que devuelve tokens, y estos tokens tienen un valor y un tipo. Ya puedo reconocer un átomo (un nombre que comienza en letra minúscula), una variable, delimitadores, operadores, números enteros y reales, strings. El Lexer es consumido por un Parser, que tiene dos grandes métodos públicos: uno que parsea expresiones, usado desde el REPL, y otro que parsea lo que en Erlang se llama un form, sería como una definición de función en un módulo de Erlang. También hay formas que declaran el nombre del módulo, o que otras formas se exportan con nombre y cantidad de argumentos. En dichos módulos no se aceptan expresiones, sino solamente ese tipo de declaraciones form.

Si ven la historia de los commits, verán que no todo se desarrolló de antemano, sino que fue creciendo de a poco, a medida que me planteaba pequeños casos de uso a implementar.

Próximos temas: comentar la implementación de expresiones, forms, procesos como threads con mailbox para mensajes, y el REPL. Tengo que seguir trabajando en la implementación de mensajes y procesos distribuidos.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

SharpGo Implementando Go en C# (1) El proyecto

Monday, June 23rd, 2014

Otro proyecto que tengo para practicar TDD (Test-Driven Development) y C#, es

https://github.com/ajlopez/SharpGo

Un intérprete (no compilador) del lenguaje Go de Google en C#. Como es usual, tiene un proyecto de librería y un proyecto de tests de la librería. Como el lenguaje Go es un lenguaje tipado, no puedo seguir el camino de armar un árbol de expresiones y evaluarla, como en RubySharp, PythonSharp y Mass, sino que el compilador tiene que tener varias fases, como en ScalaSharp, para ir detectando incosistencias de tipos, y declaraciones de tipos que todavía no se conocen al momento de analizar una sentencia o expresión.

Parte del proyecto, los nodos del AST que por ahora están implementados:

Los nodos que estoy armando del AST (Abstract Syntax Tree), se agrupan en dos grandes grupos:

– Nodos de Comandos, que deben producir comandos que se ejecutan.

– Nodos de Expresiones, que deben producir expresiones a evaluar, que devuelvan un valor. Tienen tipo.

Las comandos que declaran variables también tienen tipo. Por ahora, tengo todo dispuesto para comenzar a ir comenzando a:

– Declarar los tipos de algunas declaraciones de variables y funciones

– Controlar que los tipos sean los correctos, por ejemplo que a una variable entera no se le asigne un string

– Comenzar a emitir los comandos y expresiones adecuados

Como en otros proyectos, espero poder agregar acceso a los tipos y librerías propios de .NET. Un tema que tengo que examinar es cuánto del lenguaje Go puedo implementar. Un punto a estudiar: hay referencias a estructuras, que tengo que revisar si es posible mantener la semántica original o no en un lenguaje como C#. Parece interesante implementar canales, que ya hace unos años lo había implementado, tomando ideas de Go, en C# y en AjSharp.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez