Etiqueta: pharo

Buenas nuevas para la comunidad Pharo

En primer lugar tenemos el release de la versión 1.2.1, iupi!!!! La imagen core incluye 693 issues resueltos y entre los cambios mas relevantes se encuentran:

  • Agregado del nuevo framework de undo
  • Agregado del nuevo DummyUIManager para trabajar sin UI
  • Inclusión del preview de SimpleMorphic
  • Un nuevo finder
  • Integración con SUnit 4
  • Muchísimos cambios en la estructura de clases del sistemas que ofrecen mejor modularización

En particular este último punto me pone muy contento ya que colaboré en la detección e implementación de algunos de los cambios.

Por otro lado, Mariano finalmente se decidió a compartir su conocimiento escribiendo un blog. Como bien el propio Mariano indica en su post inicial, si sos un experto en Smalltalk, poco tal sea poco lo que puedas aprender. Pero si sos un simple usuario con ganas de aprender y compartir conocimiento, estoy seguro que el blog de Mariano te resultará muy entretenido. Para los interesados, el blog es: http://marianopeck.wordpress.com. Felicitaciones Mariano, ¡nos leemos!

Otro argumento por Pharo

Esta mañana estaba leyendo la lista de correo de Pharo y encontré un mail de Stef. Duccase sobre la visión de Pharo, transcribo algunos de los párrafos que me parecen importantes.

«Some days ago we were chatting with igor and he made an interesting remark about a kind of hidden philosophy
behind pharo: the idea that we systematically want to make the system better.
In fact I realized that what we are doing is to make a system nice, robust and powerful so that everybody can use
to realize their goals. But we want to have a system where not only smart guys can manage to do something with it but also less talented people…»

«…I want a system that let me learn from itself. I think that lot of things fall naturally in place from this vision (documentation, oo practices – not having car inheriting from wheel, tests comments, adequate abstractions, modularity). I want a system that everybody can nicely build his own software.
So in short I want pharo to be like a nice garden with greenhouses for building new garden with tools versus a jungle where only skilled adventurers can make it through.»

Totalmente de acuerdo. Y esto me lleva a pretuntarte: ¿sabes tu cual es la visión que tienen los createdores de tu lenguaje de desarrollo preferido?

¿Por qué Pharo?

A la hora de trabajar con Smalltalk uno debe elegir algún dialecto al igual que al trabajar con Java uno debe de elegir algún IDE. El tema con Smalltalk es que el dialecto es algo mucho más relevante que el IDE, pues en la mayoría de los casos el dialecto determina no solo el IDE a utilizar sino que además determina entre otras la máquina virtual en la cual se ejecutará nuestra aplicación. En la actualidad existe una interesente variedad de dialectos entre los que se destacan: VisualWorks, Visual Age, GNU-Smalltalk, Dolphin, Squeak y Pharo.

Mi elección personal es Pharo, y en los siguientes párrafos voy exponer mis motivos.

Licencia

Pharo es gratuito y de código abierto, en particular es desarrollado bajo licencia MIT, lo cual otorga una gran libertad.

Comunidad

Sin duda es una de las comunidades más activas y es definitivamente la más activa de las que participo. Por la lista del proyecto pasan más de 60 mails diarios. Para una herramienta de desarrollo (sea IDE, framework, compilador, etc) la comunidad es clave y más aún en el caso de iniciativas código abierto. Adicionalmente es una comunidad muy abierta, todo el mundo puede commitear fixes y todas la preguntas son contestadas en la lista de correo.

Experiencia de usuario

Comenzando por la super cool interface de usuario, el logo RE-copado y siguiendo por las infinitas posibilidades de personalización que ofrece, no conozco otro IDE tan «feliz para el programador» (es cierto, este argumento es muuyyyy subjetivo, pero no deja de ser un argumento).

¿y todo es color de rosa?

Bueno, casi. Hay algunas funcionalidades que por momentos se tornan un poquitin inestable, pero creo que se debe a todas las yerbas particulares que le he agregado a mi imagen.

¡¡¡Aguante Pharo!!!

Pharo sprint en INRIA Lille

Junto con MartinD fuimos los primeros en llegar alrededor de las 9. Junto con Stef y Marcus hicimos el setup inicial de la sala acomodando mesas, sillas y cables. El grueso de la gente arribó alrededor de las 10.

El objetivo del sprint era avanzar hacia el release 1.2. La dinámica fue simple, revisamos la lista de issues abiertos, hicimos una grilla en el pizarrón con 4 columnas: número de issue, team member atacándolo, fix ready, already integrated. Una vez hecha la lista, cada uno (o en pares) tomaba un issue para trabajar, al completarlo marcaba la columna fix ready,  lo cual le indicaba al integrador que el fix estaba en condiciones de agregarse al siguiente build. Una vez que el fix era integrado en el build, se marcaba la columna already integrated y con ello se daba por cerrado el issue.

A lo largo del día ataqué 3 issues, el primero de ellos fue un refactoring en Monticello, el segundo tuvo que ver con la ajustar Anymorph para funcionar en 1.2 y el tercero estuvo relacionado a la relación SystemDictionary<->SystemOrganizer. Para este último caso trabamos en conjunto con DamienP utilizando un enfoque TDD.

Muy cerca mio estaba sentado MarianoP, quien me mostró la imagen tuneada que creó para trabajar en su proyecto de doctorado (codename: Marea). Más allá de las herramientas adicionales agregadas a la imagen, Mariano modificó algunas cuestiones estéticas de la imagen que le pedí que compartiera. Sumando las modificaciones que me pasó Mariano y los fixes que apliqué sobre Anymorph, ajusté la gráfica de mi imagen, aquí les comparto un screenshot.

Para lograr esto, basta con seguir los 3 pasos que indico a continuación.

Paso 1: cargar una imagen de fondo:

World backgroundImage: (ImageReadWriter formFromFileNamed: ‘pharoBackground.png’) layout: #scaled.

Paso 2: cargar el logo de fiuba:

myImage :=  ImageReadWriter formFromFileNamed: ‘pharoBackground.png’.
myImage asMorph openInWorld

Paso 3: cargar Anymorph, esto es un poquitin más complejo, por eso los voy explicar en un post siguiente.

Aqui dejo algunas fotos que saqué durante sprint.

Enjoy it!

Proyecto Seed (tercera parte)

En el post anterior nos habíamos quedado en: ¿que es lo mínimo que debemos poner dentro de la una imagen?

La respuesta depende de qué querramos hacer con la imagen. Básicamente podriamos decir que hay dos fines posibles:

– Cargar la imagen y trabajar creando instancias de las clases existentes, SIN agregar nuevas clases ni modificar las existentes.

– Idem caso anterior pero agregando capacidades para que la imagen pueda evolucionar incorporando nuevas clases. Para este caso es hay varias alternativas todas ellas partiendo del caso anterior y agregando por ejemplo un Compilador o algún componente capaz de cargar código binario (hay gente del equipo RMoD trabajando en esta última alternativa).

Casualmente esta mañana tuvimos una reunión en la que reorientamos nuestro enfoque y en este momento el plan es comenzar trabajando con el kernel definido por Pavel, analizarlo con algunas herramientas de análisis componentes y en base a eso identificar concretamente los cambios a realizar en cuanto a la estructura de paquetes y dependencias. El resultado de este análisis será un conjunto de backlog items para la una futura versión de Pharo (tentativamente la 1.2).

Bien, con este último post de esta serie de 3 doy por terminada la explicación de lo que intentamos hacer con el Proyecto Seed. En futuros post iré compartiendo los avances que tengamos.

Espero que se haya entendido.

Proyecto Seed (segunda parte)

Habiendo seteado algo de contexto en la primera parte ahora voy a hablar en concreto de lo que estamos haciendo en Seed. Arrancaré como bien dicen las practicas de proyectos por definir nuestra visión y misión.

Visión: Pharo cuenta con un kernel mínimo, límpio y extensible.

Misión: experimentar con distintas estrategias para crear un paquete que nos permita crear imagenes mínimas y customizables de Pharo.

Si bien esto parece bastante claro a estas alturas, las primeras 3 semanas de proyecto por momentos me sentí como turco en la neblina, pues había algunas cosas que no me cerraban. Al mismo tiempo, al comienzo nos dedicamos hacer algunas pruebas de concepto experimentado con los enfoques utilizados en otro proyectos y por momento era darse la cabeza contra la pared demasiado seguido. Por suerte, ya durante la cuarta semana de trabajo y luego de varias sesiones de peloteo con Stef y Marcus pusimos norte a nuestro barco definiendo el roadmap de trabajo.

Existen distintas posibilidades para atacar esta problemática, algunas de las cuales ya hemos descartado de entrada. Por ejemplo, hemos decidido manejar el mismo formato de imagen que Pharo, o sea, queremos seguir utilizando la misma máquina virtual (aunque no se decarta que en futuras versiones del proyecto se propongan cambios en la máquina virtual para así optimazar el funcionamiento del sistema).

Si pensamos en nuestro problema como «obtener una imagen tan chica como sea posible», básicamente existen 2 alternativas:

  1. Partir de una imagen existente y recortarla todo lo posible
  2. Partir de una imagen vacia y agregar lo mínimo necesario

Como se podrán imaginar, nosotros no somos lo primeros en atacar esta problemática, ya ha habido proyectos anteriores entre los que me parece importante destacar:

  • Chácharas: sin entrar en detalles, lo que hace es crear una imagen «vacia» y la va llenando en runtime y on the fly. O sea si cuando envia un mensaje a la clase X se intercepta la llamada, se chequea la validez del mensaje y si el mismo no se puede resolver se comunica con otro imagen e importa las clases que resulten necesarias para poder resolver la llamada. El detalle es que requiere de una máquina virtual modificada.
  • Gwen Bootstrap: este desarrollo lo hizo Gweneal Cassasio quien es también parte del equipo RMoD. Básicamente Gwen trabajó sobre Gnu-Smalltalk, modificó la máquina virtual y definió su propia imagen desde cero.
  • PharoKernel: este es un desarrollo de Pavel Krivanek quien a muy grandes rasgos tomó una imagen de Pharo y la entró a recortar y mediante prueba y error se aseguro que el subconjunto final era suficiente para cargar el sistema.

A diferencia de estos enfoques nosotros hemos decidido comenzar de una imagen vacia e ir agregando lo mínimo indispensable y al mismo tiempo de ir identificando «cosas sospechosas» para modificar en el proceso de creación de nuestra imagen.

Ahora: ¿qué es lo mínimo? Ja! ¡Que buena pregunta Mario! La respuesta queda para la próxima entrega porque no es trivial y va a requerir unas cuantas líneas.

Continuará…

Proyecto Seed (primera parte)

Finalmente después de un mes de trabajo voy a intentar explicar sintéticamente en que consiste el proyecto en el qué me encuentro trabajando. Pero dado que para entender lo que estamos intentando hacer es necesario cierto conocimiento de Smalltalk, he decidido dividir esta explicación en 2 partes. En esta primera parte voy a explicar algunas cosas básicas (o mejor dicho históricas) de Smalltalk. En la segunda parte voy a ahondar en la problemática de nuestro proyecto y en  los distintos enfoques que analizamos.

Smalltalk a diferencia de la mayoría de los lenguajes actuales, ofrece un desarrollo basado en una imagen. Esto es: al programar uno no manipula archivos de texto con código fuente, sino que el código es manipulado en el contexto de una imagen de memoria que contiene toda la definición del sistema, o sea sus clases y sus correspondientes instancias. Esta imagen es ejecutada por una máquina virtual, y en este punto sí es como Java, C# y algunos otros lenguajes actuales.

Si bien existen distintas implementaciones de Smalltalk (Gnu Smalltalk, VisualWorks, Squeak, Dolphin, Pharo, etc), todas ellas están basadas en la especificación del Blue Book, publicado a comienzo de los años ’80.

Todo sistema Smalltalk consta de dos componentes, una máquina virtual y una imagen. Una máquina virtual puede interpretar un formato específico de imagen. En el caso particular de Pharo, el formato de imagen es compatible con el formato de Squeak, porque en cierto modo Pharo surge inicialmente como un «branch» de Squeak.

La evolución de Smalltalk y en particular de Squeak/Pharo a lo largo de más de 20 años ha consistido en modificaciones «relativamente menores» en la máquina virtual y en la imagen. Y quiero que nos detengamos en algo, la imagen de Squeak se generó UNA vez, hace unos cuantos años escribiendo byte a byte según lo que esperaba la máquina virtual, de ahí en más la evolución ha consistido en modificaciones de esa primera imagen a partir de agregar/quitar/modificar clases, métodos e instancias. Si tenemos en cuenta que la imagen original data de una época en que la orientación a objetos recién daba sus primeros pasos, no es raro que al examinar el kernel de la imagen (clases Behavior, Class, Object, etc) nos encontremos con algunas cosas sospechosas desde el punto de vista de la orientación a objetos y la separación de incumbencias (dependencias poco felices, muuuuchos métodos dentro de una misma clase, métodos deprecados, etc, etc ).

Hasta aquí los conceptos, en la segunda parte entraré en cuestiones concretas del proyecto.

Nuevo proyecto

Esta semana empecé a trabajar en el proyecto que me va entretener durante los próximos 3 meses. En forma resumida voy a estar trabajando junto al equipo de investigación RMod del Inria, experimentando con algunas ideas para optimizar el proceso bootstrap de Pharo.

Durante esta primer semana de proyecto estuve haciendo algunos ejercicios para familiarizarme con el metamodelo de objetos y alinearme con la vision que el equipo tiene sobre la problemática a resolver. Ha sido una semana de pleno aprendizaje, pues el conocimiento que tengo de Smalltalk es desde el punto de vista del usuario y como tal nunca tuve la necesidad de trabajar a bajo nivel. Un punto interesante es que a pesar de estar trabajando a bajo nivel (estoy trabajando directamente en el kernel) sigo trabajando con código Smalltalk, dado que el trabajo es dentro de la imagen y no a nivel de máquina virtual (lo que implicaria trabajar con C).

No estoy seguro si lo mencioné en algún post anterior (me parece que no), pero para realizar este trabajo me transladé a Lille, una ciudad en el norte de Francia que según los locales, es la sexta ciudad en importancia de Francia y la segunda en cuanto a cantidad de estudiantes (no si esto será efectivamente así, pero es en verdad sorprendente la cantidad de residencias para estudiantes que hay a lo largo de la ciudad). Obviamente como podrán imaginarse intentaré aprovechar mi estadia para conocer las ciudades aledañas dado que aquí en Europa todo está cerca.

Para ir cerrando les dejo aquí algunas fotos que tomé ayer a la pasada mientras caminaba por el centro de la ciudad.