Angel "Java" Lopez : Smalltalk, C Sharp

AjTalk en C# (3) Environments

lopez — Thu, 27 Dec 2012 17:10:00 GMT

Hace unas semanas, agregué el soporte de environments (ambiente, entorno) a mi proyecto de código abierto AjTalk, una máquina virtual Smalltalk escrita en C# (hay otras versiones, en Java y en JavaScript). ¿Qué es un environment en mi jerga? Es un diccionario, donde puedo guardar artefactos por nombre, un directorio. Por ejemplo, para guardar clases por nombre. La variable global Smalltalk es un environment clásico. Pero en un Smalltalk clásico, todas las clases definidas van a parar a ese diccionario global, lo que puede dar lugar a colisión de nombres. La forma normal de solucionar (p.ej. en Squeak y Pharo) es agregarle un prefijo (de dos letras) a cada clase de nuestra librería. Pero yo quiero tener el soporte de tener otros environments, como pasa con los namespaces de .NET o los package de Java. Smalltalk clásico también tiene los llamados pool dictionary, pero hasta donde sé, son para usar desde una clase y sus derivados. Yo quiero tener la noción de paquete: todas estas clases se ven entre sí, pero no están en el environment del tope, en Smalltalk, sino en un environment dedicado a mi librería. Agregué una implementación inicial, con estos tests:

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Tests/AssertTests/EnvironmentTests.st

Al comienzo, verifico que Smalltalk es un ambiente, un environment y es el actual:

"Current environment is Smalltalk"
[Environment current == Smalltalk] assert.

Puedo crear nuevos entornos:

env := Environment new: #MyEnvironment.

Automáticamente, el nuevo entorno se registra/agrega al entorno actual, en este caso, a Smalltalk:

"The new environment was defined as global at Smalltalk"

[(Smalltalk at: #MyEnvironment) isNil not] assert.
[(Smalltalk at: #MyEnvironment) == MyEnvironment] assert.
[(Smalltalk at: #MyEnvironment) == env] assert.

[MyEnvironment isNil not] assert.
[MyEnvironment == env] assert.

Cada nuevo entorno tiene automáticamente una entrada Smalltalk que apunta al original global:

"Dotted expression syntax sugar for MyEnvironment at: #Smalltalk"

[MyEnvironment.Smalltalk == Smalltalk] assert.

Podemos pasar a tener un nuevo entorno actual:

env setCurrent.

"Current environment check"

[Environment current == env] assert.
[Environment current == Smalltalk.MyEnvironment] assert.

Y ahora, la característica principal de lo que quería implementar, de ahora en más, las definiciones de clases (sin cambiar el código de su definición) quedan registradas en el entorno actual:

"Define a class at current env environment, no change to syntax"

Object subclass:#MyClass
    instanceVariableNames:''
    classVariableNames:''
    poolDictionaries:''
    category:''
.

[(env at: #MyClass) isNil not] assert.
[(Smalltalk at: #MyClass) isNil] assert.

Ortogonal a esto de environments, implementé además módulos (algo apareció en el post anterior): una forma de buscar y leer archivos file out, y ejecutarlos dentro de un nuevo entorno. Esto es similar al import de Python, y algo menos parecido, al require de Node.js/CommonJS. Bueno, pero eso es tema para otro post ;-)

Nos leemos!

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

AjTalk en C# (2): Un Simple Servidor Web

lopez — Mon, 17 Dec 2012 16:45:00 GMT

Anterior Post
Siguiente Post

Estoy trabajando completando mi máquina virtual Smalltalk, escrita en C#, el AjTalk, el repositorio en https://github.com/ajlopez/AjTalk . Hace unas semanas, escribí un ejemplo de simple servidor web, basado en mi trabajo previo en PythonSharp (1) Un servidor web mínimo. El código de este nuevo servidor en:

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Console/Programs/WebServer.st

Object subclass: #WebServer
	instanceVariableNames: 'root listener bytes'
	classVariableNames: ''
	poolDictionaries: ''
	category: ''
!

!WebServer class methods!

new
	^self basicNew initialize
! !

!WebServer methods!

initialize
	bytes := @System.Array !!CreateInstance: @System.Byte with: 1024 * 16.
	listener := @System.Net.HttpListener !!new.
	listener !!Prefixes !!Add: 'http://*:8000/'.
	root := 'c:/apache-tomcat-6.0.18/webapps/docs'.
	@System.Console !!WriteLine: 'initialize'
!

process: context
	| filename input nbytes |
	filename := context !!Request !!Url !!AbsolutePath.
	
	@System.Console !!WriteLine: filename.
	
	(filename = '' or: [filename = '/']) ifTrue: [filename := 'index.html'].
	
	(filename !!StartsWith: '/') ifTrue: [filename := filename !!Substring: 1].
	@System.Console !!WriteLine: filename.
	
	filename := @System.IO.Path !!Combine: root with: filename.

	@System.Console !!WriteLine: filename.	
	
	(@System.IO.File !!Exists: filename) 
	ifFalse: [ context !!Response !!Abort. ]
	ifTrue: [		
		input := @System.IO.FileStream !!new: filename with: @System.IO.FileMode !!Open.
		[[nbytes := input !!Read: bytes with: 0 with: bytes !!Length] value > 0] whileTrue: [
			context !!Response !!OutputStream !!Write: bytes with: 0 with: nbytes.
		].
		
		input !!Close.
		
		context !!Response !!OutputStream !!Close
	]
!

start
	listener !!Start.
	@System.Console !!WriteLine: 'start'.
	[true] whileTrue: [
		| context |
		@System.Console !!WriteLine: 'get context'.
		context := listener !!GetContext.
		@System.Console !!WriteLine: 'new request'.
		self process: context.
	].
	@System.Console !!WriteLine: 'end start'
! !

WebServer new start
!

Como el anterior, es una prueba de concepto, “quick and dirty”, para mostrar que puedo reutilizar las clases de .NET. Pueden lanzarlo desde el programa de consola de AjTalk (el resultado de compilar el proyecto AjTalk.Console):

ajtalk lib\Library.st Programs\WebServer.st

El resultado en http://localhost:8000 (jeje, reusando unas páginas estáticas que tengo en mi disco local):

Luego escribí un ejemplo más claro y modular en

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Console/Programs/WebSiteTomcat.st

Module import: #Web.

!

| server |

server := Web.Server new
	root: 'c:/apache-tomcat-6.0.18/webapps/docs';
	addPrefix: 'http://*:8000/';
	start
!

Pero ahí estoy usando Module import:, algo que implementé basado en lo que hice de PythonSharp import para cargar programas. Pero esa lógica ya es tema para otro post.

Nos leemos!

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

AjTalk en C# (1): Una imagen mínima, con Hello, World

lopez — Fri, 14 Dec 2012 12:50:00 GMT

Siguiente Post

Si leen este blog (y tienen la paciencia de seguirme en Twitter ;-), ya saben que, luego de PyCon 2012 Argentina, he estado ocupado trabajando en mi máquina virtual Smalltalk AjTalk, escrita en C#:

https://github.com/ajlopez/AjTalk

He aquí un pequeño Hello, World:

nil subclass:#Object
	instanceVariableNames:''
	classVariableNames:''
	poolDictionaries:''
	category:'Kernel-Objects'
!

Object subclass:#Program
	instanceVariableNames:''
	classVariableNames:''
	poolDictionaries:''
	category:'Kernel-Objects'
!

!Program class methods!

main @System.Console writeLine: 'Hello, world'! !

En el repo:

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Console/Programs/HelloWorld.st

Podría ser menor, pero necesito el Program main como punto de entrada de una imagen grabada en disco. El programa que genera la imagen es

ajtalk Programas/HelloWorld.st –s hello.im

y se lanza la imagen con

ajtalk hello.im

De esta forma, AjTalk busca una variable global Program con un método main, y si existe, es invocado luego de la carga.

La notación del nombre con @ para @System.Console es la forma que tiene AjTalk de referirse a tipos nativos de .NET.

Noten que no cargo toda la librería de clases, solamente las que necesito para ejecutar este Hello, world. AjTalk puede manejar varias máquinas en memoria, cada una de las cuales tiene sus propias clases y métodos. Aún más: le he agregado que una máquina virtual pueda operar sobre otra, y hasta “prestarle” sus métodos. De esta manera, puedo tener una máquina A con todas las clases de desarrollo, y manejar desde ahí el contenido de la máquina B. Puedo entonces producir imágenes mínimas. En vez de tener una sola y gran imagen en memoria, y hacer toda clase de contorsiones para reducirla, mis máquinas YA NACEN livianas por diseño. Esto es un ejemplo de “pensar fuera de la caja”: por décadas, los desarrolladores Smalltalk pensaron siempre en tener una sola imagen, y se metieron en el problema de COMO hacerla decrecer. Mi aproximación al problema es distinta: cada máquina va creciendo desde lo mínimo, y si es necesario usar algo (algún método compile: por ejemplo), lo provee otra máquina, sin que tenga que crecer la primera.

Tengo que escribir más sobre lo que le agregué a esta versión. Por ejemplo: objetos remotos (revisitado), métodos por objeto, procesos, semáforos, múltiples threads, acceso a tipos nativos, grabar/leer imágenes, un AST interno, visitors para recorrer ese árbol, generación de código para JavaScript, módulos (a la import de Python o el require de Node.js), ambientes (como espacios de nombre, para evitar la colisión de nombres), y bastante más (como tener un Process que pueda ser suspendido y reanudado en cualquier momento, quizás llegue a call con continuations).

Nos leemos!

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

Trabajando de nuevo en on AjTalk: Smalltalk Virtual Machine, en C#

lopez — Fri, 30 Nov 2012 16:19:05 GMT

Luego de trabajar en ejemplos distribuidos con Node.js (ver Genetic Algorithms), y en mi intérprete Python en .NET (Post, GitHub repo), volví a trabajar en AjTalk, mi implementación de una VM Smalltalk. Tengo tres proyectos (versión C#, versión Java, versión JavaScript), pero en estos días estroy trabajando en la versión C#.

El fin de semana pasado, agregué un simple/ingenuo pero funcional grabado/lecturan de imágenes, y tengo un nuevo compilador de bytecodes: en vez de “parsear” el código y directamente generar “bytecodes”, ahora hay una implementación alternativa que construye un árbol AST, en memoria, y usando el patrón Visitorr, genera los “bytecodes” correspondientes. El año pasado había implementado el AST para con un Visitor ir recorriendo los nodos e ir generando código JavaScript, que se levanta con la versión AjTalk en JavaScript. El patrón Visitor podría usarse para generar distintas salidas, usando el mismo AST. Por ejemplo, tengo pensado como “prueba ácida”, armar un Visitor que genere Python (alternativas: que genere Ruby o C#, en este último caso exploraría el usar objetos dynamic).

Desde hace tiempo, puedo crear más de una Machine: una imagen viva en memoria, cada una con su propio Object, Class, ClassDescriptor, etc. En vez de ser un Singleton, puedo crear y levantar desde imágenes más de una Machine. El código principal en:

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk/Machine.cs

Pude entonces generar una imagen mínima de un “Hello world” con menos de 300 bytes (! ;-), ver el código en:

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Console/Programs/HelloWorld.st

También estube entrenando a los dos parsers para lean y ejecuten código de Pharo:

https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Tests/CodeFiles/PharoCoreKernelObjects.st
https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Tests/CodeFiles/PharoKernelNumbers.st
https://github.com/ajlopez/AjTalk/blob/master/Src/AjTalk.Tests/CodeFiles/PharoKernelClasses.st

Y todo escrito usando TDD.

Ahora que tengo varias máquinas en memoria, quiero implementar esta idea:

- Cargar/Crear una Machine A (con sus clases, métodos, objetos) teniendo una librería completa de clases
- Cargar/Crear una Machine B, teniendo solamente algunas clases y objetos
- Hacer que la Machine A sea el “host” de la Machine B. Es decir, que se ocupe de darle lo que no tiene, ver el próximo punto.
- Reimplementar el proceso del mensaje #doesNotUnderstand en la Machine B para que, si el método correspondiente no es encontrado en esa máquina, la búsqueda del mismo continúe en la máquina “host”, la Machine A. De esta manera, podría usar todo el poder la Machine A, para operar sobre una Machine B más liviana, manteniendo la “liviandad” de ésta. La Machine A podría tener todas las herramientas de desarrollo, clases, objetos, métodos, mientras que la Machine B sigue teniendo un tamaño mínimo. Ideas similares están siendo exploradas por @morplenauta (“committer” de Squeak, ver la lista en español.

(Actualización: hoy a la mañana, conseguí implentar lo de arriba, pero será tema de otro post).

Otro proyecto: tener implementado un servidor web mínimo, que sirva archivo estáticos, aprovechando clases nativas de .NET, por ejemplo, lo de System.NET.

Nos leemos!

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

Popularidad de Lenguajes de Programación

lopez — Wed, 08 Jul 2009 09:50:06 GMT

Me temo que AjLisp y AjBasic lo usamos yo y nadie más… snif… :-). Pero hay lenguajes más populares que esos. Ya es clásica la lista de TIOBE Software:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

donde aparece Java como el lenguaje más popular, lo que no me asombra. Pero sí me llama la atención la popularidad de C y C++, que deben tener su gran uso en el ambiente Unix, Linux, y otros. Como cuarto, encuentro hoy, Julio de 2009, a PHP, que lo entiendo: la mayor parte del código de sitios dinámicos está en PHP, lejos quedaron los años del predominio del venerable Perl. Y recién en sexto y séptimo lugar, está Visual Basic (parece que agrupan el de .NET y el clásico), y C#. Vean que al final de la lista, aparecen lenguajes con mínimos porcentajes, pero aparecen: RPG, Pascal, Abap, Lisp/Scheme. Más abajo, en la misma página encontraran la lista de posición 21 a 50, donde aparecen COBOL, Objective-C, Fortran, Logo, Prolog, Ada (todavía anda por ahí? :-), Scala, Erlang…. y esta es la lista de 51 a 100:

ABC, AD, Algol, Alpha, Applescript, Beta, Boo, C shell, cg, Clean, Cobra, cT, Curl, Dylan, Eiffel, Euphoria, Factor, Fan, Icon, IDL, Inform, Io, Lingo, MAD, Magic, Maple, Mathematica, MAX/MSP, MOO, MUMPS, Natural, Oberon, Occam, Oz, PL/I, Postscript, PowerBuilder, Progress, Q, R, Revolution, REXX, S-lang, SIGNAL, SPSS, SuperCollider, VBScript, Verilog, VHDL, XSLT

Notable lista, recomendaría tantos lenguajes de esa lista, simplemente para aprender nuevas formas de programar (notable que aparezca todavía MUMPS, REXX, tendría que ver con más detalle a Io). Esta lista de popularidad se basa en el examen de búsquedas en Google, hace un tiempo pasaron a agregar MSN y Yahoo.

Pero en estos días, encontré otra página:

http://langpop.com/

con información de ranking de popularidad, pero con agrupadas con distintas fuentes, como Yahoo Search, search en Google Code, Freshmeat, Craiglist, Amazon.

En lo que veo hoy ahí, julio de 2009, según Yahoo Search C es más popular que Java. Pero para Craiglist, primero PHP, segundo SQL (!!!), en Amazon ganan C, C++ y C#, por encima de Java. Y así, noto dispersión de los resultados, dependiendo de la fuente.

La popularidad de un lenguaje importa. No tanto para entender el lenguaje (muchos lenguajes “boutique” tienen interesantes conceptos, a estudiar con detalle), sino para tener una idea de qué tecnología ha sido adoptada por la comunidad, pero habría que ver más allá: por qué la eligieron, y en qué tipo de proyectos. Dudo que haya muchas aplicaciones desktop, en PHP.

Resumen: gran cantidad de lenguajes, hay lenguajes viejos, desde COBOL y Smalltalk, y más “nuevos” como Boo, Ruby, Python. Y `cuatros grandes grupos: Java, C/C++, lenguajes .NET (VB.NET, C#), PHP, como claros grupos líderes.

Pienso que, como desarrolladores de software, debemos tener contacto con esos cuatro grupos, y además, con alguno de los “otros”, para aprender otras ideas y formas de programar.

No me enojo si intentan ver AjLisp o AjBasic… :-)

Nos leemos!

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

AjTalk: un intérprete tipo Smalltalk

lopez — Tue, 15 Jul 2008 09:18:24 GMT

Hace unas semanas, estuve trabajando en mi proyecto de código abierto AjTalk, un intérprete tipo Smalltalk, escrito en .NET (con C#, para facilitar la migración a Mono, si alguien lo necesita), y ahora, quiero presentar el estado actual de ese trabajo. Desde los tempranos ochenta del siglo pasado, me ha interesado Smalltalk y siempre vuelvo al tema, aunque sólo en mi tiempo libre, no como desarrollador profesional. No es la primera vez que escribo un intérprete de este tipo (el primero que escribí en aquellos años era muy simple: en C, sin recolector de basura, interface solo texto), pero ahora quiero implementar uno más, esta vez más completo, apoyándome en la librería de clases .NET.

La versión actual es mínima, pero va tomando forma. La idea es tener objetos dinámicos, como en Smalltalk, y, en algún momento, agregarle el soporte de prototipos. Los objetos y el intérprete accederían a todo el framework .NET y otras librerías. Tengo la experiencia previa de haber logrado eso en mi intérprete AjBasic, que uso en mi proyecto de generación de código AjGenesis.

La versión inicial de AjTalk está publicada en Google Code:

http://code.google.com/p/ajtalk/

La solución

Estoy usando Visual Studio 2005 Professional. La solución contiene cuatro proyectos.

AjTalk es el proyecto principal, una librería de clases conteniendo el núcleo del sistema.

AjTalk.Test01 y AjTalk.Test02 son aplicaciones de consola, para usar en pruebas manuales.

AjTalk.Tests contiene los unit tests, escritos usando NUnit framework 2.2.8.

Mucho del sistema núcleo consiste en interfaces, que definen las conductas de base, y clases implementando esas interfaces.

El objeto

El proyecto contiene una interface para representar cualquier objeto:

using System;

namespace AjTalk
{
    public interface IObject
    {
        IClass Class { get; }
        object this[int n] { get; set;}
        object SendMessage(string msgname, object [] args);
    }
}

Podría hacer que un mensaje sea un objeto (del tipo Message), pero por ahora, el mensaje es sólo un nombre y un arreglo de argumentos.

El índice this[int n] accesde a las variables de instancia. Cada valor en AjTalk puede apuntar a cualquier objeto .NET, no solamente a objetos que implementen IObject. De esta forma, puedo manejar int, long, String, DataSet, desde objetos IObject.

La clase

Estoy implementando una interface simple IClass, sin distinción entre clase, behavior, y otras clases, como sería en el Smalltalk clásico. Separaré esas clases en una futura versión, cuando llegue a ser necesario. Por ahora, estoy manejando sólo una interface:

using System;
using System.Collections;
using System.Collections.Generic;

namespace AjTalk
{
    public interface IClass : IObject
    {
        IClass SuperClass { get; }
        string Name { get; }

        void DefineClassMethod(IMethod method);
        void DefineInstanceMethod(IMethod method);

        void DefineClassVariable(string varname);
        void DefineInstanceVariable(string varname);

        IObject NewObject();

        IMethod GetClassMethod(string mthname);
        IMethod GetInstanceMethod(string mthname);
        int GetClassVariableOffset(string varname);
        int GetInstanceVariableOffset(string varname);
    }
}

Hay un diccionaro para los métodos de clase y otro para los de instancia, y listas de variables de instancia y de clase. No soporta todavía variables indexadas. La interface IClass está implementada en la clase BaseClass.

El método

Hay una interface IMethod:

using System;

namespace AjTalk
{
    public interface IMethod
    {
        string Name { get; }
        IClass Class { get; }
        object Execute(IObject receiver, object [] args);        
    }
}

La clase concreta Método implementa esa interfaces. Su método Execute tiene:

        public object Execute(IObject receiver, object[] args)
        {
            return (new ExecutionBlock(receiver,receiver,this,args)).Execute();
        }

Los Execution blocks tienen variables locales y argumentos. El Execute de un bloque de ejecución toma instrucciones (bytecodes) desde métodos "compilados", y los ejecuta. Aquí, me aparto de nuevo de Smalltalk original: acá el bloque de ejecución no es un objeto AjTalk. De esta forma, yo puedo ejecutar este intérprete sin necesidad de implementar gran cantidad de clases de base. Tengo que investigar las ventajas y problemas que esta decisión podría tener sobre el diseño e implementación de esta solución.

Los bytecodes

Tengo que meditar sobre usar un árbol de objetos (como en el patrón Interpreter) o bytecodes. En esta versión, uso bytecodes. Son las instrucciones básicas que mi "máquina virtul" entiende y ejecuta paso a paso.

Esta es su enumeración:

namespace AjTalk
{
    public enum ByteCode : byte
    {
        Nop = 0,
        GetVariable = 1,
        SetVariable = 2,
        GetArgument = 3,
        SetArgument = 4,
        GetConstant = 5,
        GetLocal = 6,
        SetLocal = 7,
        GetClassVariable = 8,
        SetClassVariable = 9,

        GetSelf = 20,
        GetClass = 21,
        GetSuperClass = 22,
        NewObject = 23,
        Pop = 24,
        ReturnSub = 25,
        ReturnPop = 26,

        Add = 40,
        Substract = 41,
        Multiply = 42,
        Divide = 43,

        Send = 50
    }
}

Los bytecodes contenidos en un método, son interpretados y ejecutados en un Execution Blog. Un fragmento de ese código:

    while (ip < method.ByteCodes.Length) 
    {
        ByteCode bc = (ByteCode) method.ByteCodes;
        Byte arg;

        switch (bc) 
        {
            case ByteCode.ReturnSub:
                return null;
            case ByteCode.ReturnPop:
                return Top;
            case ByteCode.GetConstant:
                ip++;
                arg = method.ByteCodes;
                Push(method.GetConstant(arg));
                break;
            case ByteCode.GetArgument:
                ip++;
                arg = method.ByteCodes;
                Push(arguments[arg]);
                break;
....

Todo con Test

El código inicial había sido escrito en VB.NET. El año pasado lo comencé a pasar a C#. Este año cambié a modo "TDD", tarde pero seguro, y agregué varios tests para el NUnit:

Bootstraping

Uso un archivo de texto, con un formato ad'hoc, para inyectar las definiciones iniciales de clases y objetos. Ahora, en el proyectos AjTest.Test02, hay un ejemplo de ese formato en el archivo Definitions.txt:

class Point
variables x y

method
x ^x.
method
y ^y.
class Rectangle
variables point1 point2
class Square Rectangle

Próximos pasos

Hay una pila de trabajo pendiente:

- Completar la jerarquía de clases base (Behavior, Class, ....)

- Implementar más bytecodes

- Soporte de variables locales en métodos

- Un archivo de text estándard

- Acceso a objetos .NET nativos

- Usar AjTalk desde aplicaciones .NET (no veo necesario entonces implementar una interface de ventanas en AjTalk, solamente consumirlo adecuadamente desde cualquier aplicación .NET)

- Definir las clases y métodos para una implementación mínima

- Serialización/deserialización de la imagen en memoria

- Soporte de agregado de variables en una clase que ya tenga instancias creadas (puede ser un tema difícil)

- Soporte de become: (el problema de todo intérprete)

- Y mil más....

Pero tengo confianza en la forma que va tomando el proyecto. Estoy aplicando "baby steps", para mejorar el código de base y su funcionalidad.

Este artículo en Anglish (Angel's English):

AjTalk: a Smalltalk-like interpreter

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/en