Pharo 2.0

> Hola Gente:
>
> Como la mayoría sabe tengo soluciones en producción en Pharo pero
> también varias en Squeak (algunas con versiones viejas y otras no
> tanto, e impulsadas por el soporte SSL que trajo WebClient antes que
> nadie).
>
> Hace un tiempo que le estoy dedicando horas a Cuis porque tiene
> algunas cosas que me encantan:
>
> 1. La posibilidad de entender todo el ambiente completo y que cambia
> menos que el resto....o lo hace a un ritmo que yo puedo seguir.
> 2. La posibilidad de guardar paquetes e interactuar con GitHub de un
> modo MUY cómodo.
> 3. Lo compacto y rápido que es.
>
> Pero tiene otras que hacen difícil adoptarlo rápidamente para
> soluciones para clientes, creo yo el mayor obstáculo es la necesidad
> de portar muchos paquetes que no funcionan de una, sino que hay que
> hacer un trabajo importante para que anden.
>
> Así que en este contexto, puedo seguir apostando a Cuis para un futuro
> (portando y aprendiendo cosas) pero para el hoy necesito echar mando
> de otras que ya funcionan juntas, más que nada estoy hablando de pharo
> con seaside, magritte, xml, criptografiA, swazoo, etc, etc.
>
> Ahora bien, la gran duda que me surge y es la que me motivó a escribir
> este mail es preguntar a quienes estén más profundamente involucrados
> con Pharo, qué se persigue con la versión 2.0 y qué niveles de
> incompatibilidad habrá versus 1.4. Yo leí el paper Pharo visión, pero
> no me quedan claras muchas cosas y no sigo la lista al detalle, ya no,
> porque es imposible por el volumen de tráfico que tiene.
>
> Si alguien tiene ganas de hacer un pequeño resumen, será más que bienvenido.
>
> Gracias.
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogpost.com
> ============================================
>

> **
>
>
> Aloha :)
>
> Yo tampoco estoy siguiendo muy atentamente la lista de Pharo (infinito
> laburo e infinitas cosas de la facu para hacer) pero, hasta donde yo se, la
> idea de Pharo 2.0 es tener una imagen minima basada en Pharo Kernel de
> Pavel (las clases basicas + Fuel + zinc+etc) que sea customizable a gusto y
> piaccere del usuario... Entonces estan haciendo una gran limpieza y
> poniendo todo lo que consideran no core en paquetes de extension. Algo de
> eso ya hay en Pharo 1.4 (hay que chusmear en el Configuration Browser).
>
> Tambien Guille Polito esta laburando para hacer un bootstrap de la imagen,
> y me consta que quieren que nautilus sea el browser por default. Otra cosa
> que se que estan haciendo es mejorar el tema de las vms, Guille quiere
> cambiar todo el modelo de shortcuts para que sea independiente de la
> plataforma (hay cosas que estan hardcodeadas segun sean para linux, windows
> o mac xD) .
>
> Y una cosa copada, inferencia de tipos. No se si va a estar eso para 2.0,
> pero bleh.
>
> Bueno, mas o menos eso. Capaz alguien que sepa mas puede venir y
> corregirme o aportar mas :)
>
> Esperemos que nuestros diagramas de smallUML esten listos para 2.0 :D
>
> Saludos!
>
> Sent from Yahoo! Mail on Android
>
>  
>

> **
>
>
> Hola,
>
> Aprovecho el mail para saludar a la lista... soy un lector, aunque no un
> "participador", por motivos de tiempo (tengo todos los días más de 250
> mails que revisar y algunos que contestar, y obvio, después tengo que
> laburar). No se enojen si no me ven... yo sigo la (las) listas, aunque no
> pueda meterme en todas las charlas.
>
> Hace unos días mandé un resumen de los objetivos "tecnológicos" de Pharo
> 2.0, que podés ver acá:
> http://forum.world.st/About-the-new-release-process-td4574410.html
>
> Igual, les cuento el "gran objetivo" de pharo 2.0 es lograr la tantas
> veces mentada modularidad total del sistema. Para cuando la release este
> terminada, si todo va bien, se va a empezar desde una imagen mínima (la más
> mínima conseguida hasta ahora, funcional y todo, pesa 1.5m) y se va a poder
> cargar el sistema a partir de configuraciones de metacello independientes.
> Pharo 2.0 entonces va a ser el conjunto de subproyectos que hacen que la
> imágen sea una herramienta poderosa (porque el kernel es muy lindo, pero
> así solo no sirve para nada).
> En parte, por eso no tuvimos empacho en meter un montón de cosas de golpe
> cuando arrancamos el desarrollo de 2.0... igual para cuando terminemos, si
> no lo querés en tu imágen, vas a poder armarte a piacere.
>
> No estamos tan lejos, yo estoy trabajando directamente en eso y creo que
> en menos de 2 meses voy a tenerlo aceitado (la semana que viene termino la
> primera iteración).
> Para las imágenes míinimas se van a usar las PharoKernel de Pavel en
> primera instancia, y probablemente 2.0 salga con ella, pero la idea es
> hacer un bootstrap desde cero, ser capaz de reconstruir la imagen desde
> cero (Guillermo y Benjamin están laburando en eso, y ya  pueden producir
> imágenes "hijas" a partir de una imagen...
>
> ¿Por qué todo esto es bueno y necesario? Bueno, hay millones de motivos...
> uno que normalmente no se toma en cuenta es la "repetibilidad del proceso"
> es decir, que yo pueda reconstruir mi proyecto desde cero, sin necesidad de
> ser "incrementales" (es decir, mi imagen no se basa en la imágen anterior,
> sino que puedo partir de nada). En parte (y para que veas que sí leo la
> lista, Edgar),
>

> -En algún punto, no es posible mantener los caminos alineados (no
> existirían forks de ser así). Todavía no ha pasado, y no digo que sea algo
> bueno ni deseable. Pero si creo que es inevitable.
>
> -Adoptamos cosas de otros sistemas. De hecho, nos la pasamos monitoreando
> cambios en cuis y squeak (honestamente, más en cuis que en squeak,
> ultimamente) para tratar de tomar las cosas que nos gustan y que podemos
> (no se olviden de que los caminos divergen, y a veces simplemente no es
> posible). Por otro lado, y no es por tirar chicanas, yo sí veo una actitud
> de mierda por parte de cierta gente de "la otra comunidad" para con
> nosotros... pero bueno, eso es quedarse en pequeñeces.
>
>

> Hace unos días mandé un resumen de los objetivos "tecnológicos" de Pharo 2.0,
> que podés ver acá:
> http://forum.world.st/About-the-new-release-process-td4574410.html
>
> Igual, les cuento el "gran objetivo" de pharo 2.0 es lograr la tantas veces
> mentada modularidad total del sistema. Para cuando la release este terminada,
> si todo va bien, se va a empezar desde una imagen mínima (la más mínima
> conseguida hasta ahora, funcional y todo, pesa 1.5m) y se va a poder cargar el
> sistema a partir de configuraciones de metacello independientes.
> Pharo 2.0 entonces va a ser el conjunto de subproyectos que hacen que la
> imágen sea una herramienta poderosa (porque el kernel es muy lindo, pero así
> solo no sirve para nada).
> En parte, por eso no tuvimos empacho en meter un montón de cosas de golpe
> cuando arrancamos el desarrollo de 2.0... igual para cuando terminemos, si no
> lo querés en tu imágen, vas a poder armarte a piacere.

>, yo creo que uno de los motivos por los que muchos proyectos hermosos
> como scratch terminan fracasando (aunque en particular no creo que scratch
> haya fracasado), es porque al terminar encadenados a una versión, se vuelve
> muy difícil adoptar cambios "de afuera", quedando obligado a evolucionar vos
> tu sistema, sin crecer como comunidad.
>
> Hay muchas más cosas en la galera... hay cosas que tiene pharo 2.0 que es
> simplemente la cristalización de lo que se viene haciendo desde antes.
>
> Y bueno, eso... aprovecho que tengo un ratito ahora para tirar algunas
> respuestas random de cosas que se han dicho en la lista:
>
> -En algún punto, no es posible mantener los caminos alineados (no existirían
> forks de ser así). Todavía no ha pasado, y no digo que sea algo bueno ni
> deseable. Pero si creo que es inevitable.
>
> -Adoptamos cosas de otros sistemas. De hecho, nos la pasamos monitoreando
> cambios en cuis y squeak (honestamente, más en cuis que en squeak,
> ultimamente) para tratar de tomar las cosas que nos gustan y que podemos (no
> se olviden de que los caminos divergen, y a veces simplemente no es posible).
> Por otro lado, y no es por tirar chicanas, yo sí veo una actitud de mierda por
> parte de cierta gente de "la otra comunidad" para con nosotros... pero bueno,
> eso es quedarse en pequeñeces.

> **
>
>
>
>
>   ------------------------------
> *De:* Edgar J. De Cleene <[hidden email]>
> *Para:* [hidden email]
> *Enviado:* viernes, 11 de mayo de 2012 18:03
> *Asunto:* Re: [squeakRos] Pharo 2.0
>
>
> > Aloha :)
> Namaste
>
> > Yo tampoco estoy siguiendo muy atentamente la lista de Pharo (infinito
> laburo
> > e infinitas cosas de la facu para hacer) pero, hasta donde yo se, la
> idea de
> > Pharo 2.0 es tener una imagen minima basada en Pharo Kernel de Pavel (las
> > clases basicas + Fuel + zinc+etc) que sea customizable a gusto y
> piaccere del
> > usuario... Entonces estan haciendo una gran limpieza y poniendo todo lo
> que
> > consideran no core en paquetes de extension. Algo de eso ya hay en Pharo
> 1.4
> > (hay que chusmear en el Configuration Browser).
>
> Como pongo en el mail a Esteban, lo conocia pero es bueno tener muchos
> puntos de vista de estos temas.
> > Tambien Guille Polito esta laburando para hacer un bootstrap de la
> imagen,
>
> Si, me meti de prepo en ese proyecto.
> Si lo conocen personalmente, invitenlo al Bar .
> Le digo :)
> > me consta que quieren que nautilus sea el browser por default.
>
> Que no se me enojen, pero en esto no estoy tan de acuerdo.
> Algun dia tendriamos que hacer otra discusión sobre Browsers.
>
> A mí tampoco me gusta. Tampoco estuve jugando mucho con nautilus, pero
> todavía no me convence xD
>
>

>
> El 11 de mayo de 2012 18:10, Clara Allende <[hidden email]>
> escribió:
>
>>
>>
>>
>>
>> ________________________________
>> De: Edgar J. De Cleene <[hidden email]>
>> Para: [hidden email]
>> Enviado: viernes, 11 de mayo de 2012 18:03
>> Asunto: Re: [squeakRos] Pharo 2.0
>>
>>
>> > Aloha :)
>> Namaste
>>
>> > Yo tampoco estoy siguiendo muy atentamente la lista de Pharo (infinito
>> > laburo
>> > e infinitas cosas de la facu para hacer) pero, hasta donde yo se, la
>> > idea de
>> > Pharo 2.0 es tener una imagen minima basada en Pharo Kernel de Pavel
>> > (las
>> > clases basicas + Fuel + zinc+etc) que sea customizable a gusto y
>> > piaccere del
>> > usuario... Entonces estan haciendo una gran limpieza y poniendo todo lo
>> > que
>> > consideran no core en paquetes de extension. Algo de eso ya hay en Pharo
>> > 1.4
>> > (hay que chusmear en el Configuration Browser).
>>
>> Como pongo en el mail a Esteban, lo conocia pero es bueno tener muchos
>> puntos de vista de estos temas.
>> > Tambien Guille Polito esta laburando para hacer un bootstrap de la
>> > imagen,
>>
>> Si, me meti de prepo en ese proyecto.
>> Si lo conocen personalmente, invitenlo al Bar .
>> Le digo :)
>> > me consta que quieren que nautilus sea el browser por default.
>>
>> Que no se me enojen, pero en esto no estoy tan de acuerdo.
>> Algun dia tendriamos que hacer otra discusión sobre Browsers.
>>
>> A mí tampoco me gusta. Tampoco estuve jugando mucho con nautilus, pero
>> todavía no me convence xD
>>
>
>
> Acá aparece contrera.....jeje, pero a mi el Natilus me gusta bastante, lo
> veo cómodo, sobretodo a la hora de guardar paquetes (commits) a un teclazo,
> eso me gustó.
>
>
>>
>> Es lo de Pancho Garau ?
>> Otra idea copadisima
>> A el no lo conozco, pero si conozco a Santi Bragagnolo que estaba
>> laburando en eso como parte de su proyecto en GSoC.
>>
>
> Bueno, invitalo también al grupo :) (Edgar dice Bar, pero no tenemos nada
> para tomar virtualmente aún.....)
>
> Saludos!

> Aloha :)
>
> Yo tampoco estoy siguiendo muy atentamente la lista de Pharo (infinito laburo e infinitas cosas de la facu para hacer) pero, hasta donde yo se, la idea de Pharo 2.0 es tener una imagen minima basada en Pharo Kernel de Pavel (las clases basicas + Fuel + zinc+etc) que sea customizable a gusto y piaccere del usuario... Entonces estan haciendo una gran limpieza y poniendo todo lo que consideran no core en paquetes de extension. Algo de eso ya hay en Pharo 1.4 (hay que chusmear en el Configuration Browser).
>
> Tambien Guille Polito esta laburando para hacer un bootstrap de la imagen, y me consta que quieren que nautilus sea el browser por default. Otra cosa que se que estan haciendo es mejorar el tema de las vms, Guille quiere cambiar todo el modelo de shortcuts para que sea independiente de la plataforma (hay cosas que estan hardcodeadas segun sean para linux, windows o mac xD) .
>
> Y una cosa copada, inferencia de tipos. No se si va a estar eso para 2.0, pero bleh.
>
> Bueno, mas o menos eso. Capaz alguien que sepa mas puede venir y corregirme o aportar mas :)
>
> Esperemos que nuestros diagramas de smallUML esten listos para 2.0 :D
>
> Saludos!
>
> Sent from Yahoo! Mail on Android
>
>
>

> **
>
>
> Hola,
>
> On May 11, 2012, at 10:29 PM, Germán Arduino wrote:
>
>
>
> Ey Esteban!
>
> ¿Cómo va? Un gustazo leer unas líneas tuyas acá!!
>
>
> gracias :)
>
>
> Gracias por el link de los objetivos tecnológicos así como también por el
> mail, muy explicativo.
>
> De lo que escribís, me queda la certeza que habrá un nivel de
> incompatibilidad importante, con respecto a 1.4, verdad?
>
>
> En realidad, el 99% de los cambios deberían ser transparentes. Nuestras
> modificaciones van principalmente a la infraestructura y los tools. La API
> es en la mayoría de los casos la misma.
> Obvio que si una aplicación usa alguno de los subsistemas que estamos
> reemplazando, hay que adaptarse.
>
>

> Entiendo que vos sufriste la adaptación del RPC por el reemplazo de
> Zinc... pero bueno, justo te afectó ese reemplazo. Esas cosas pueden y van
> a seguir pasando, porque para progresar a veces es necesario romper
> compatibilidad, pero nuestra idea es joder lo menos posible. Solo rompemos
> compatibilidad si tenemos una buena razón y no encontramos una forma de
> evitar la ruptura, no es algo que nos guste.
> En fin... esperamos no joder demasiado, pero hay cosas que hay que cambiar
> :)
>
>

> Hola!
>
> Lo de pharópatas no puede ofender! Es una palabra (a mi me parece así)
> fabulosamente cómica, es como que describe una mezcla de fanatismo,
> genialidad y necedad :) jajjaa, bueno, cada uno lo entiende como quiere, a
> mi me causa mucha gracias (Estas y otras cosas del castellano de Edgar!! )
>
>
>
> El 11 de mayo de 2012 19:23, Esteban Lorenzano <[hidden email]>escribió:
>
>  **
>>
>>
>> Hola,
>>
>> On May 11, 2012, at 10:29 PM, Germán Arduino wrote:
>>
>>
>>
>> Ey Esteban!
>>
>> ¿Cómo va? Un gustazo leer unas líneas tuyas acá!!
>>
>>
>> gracias :)
>>
>>
>> Gracias por el link de los objetivos tecnológicos así como también por el
>> mail, muy explicativo.
>>
>> De lo que escribís, me queda la certeza que habrá un nivel de
>> incompatibilidad importante, con respecto a 1.4, verdad?
>>
>>
>> En realidad, el 99% de los cambios deberían ser transparentes. Nuestras
>> modificaciones van principalmente a la infraestructura y los tools. La API
>> es en la mayoría de los casos la misma.
>> Obvio que si una aplicación usa alguno de los subsistemas que estamos
>> reemplazando, hay que adaptarse.
>>
>>
> Es bueno saberlo, yo pensaba que la incompatibilidad iba a ser mucho mayor.
>
>
>
>> En ese sentido, creo que el más problemático va a ser el cambio de
>> FileSystem (obviamente MUY usado). Pero el viejo es una bosta y el nuevo
>> (si bien no es perfecto), es muchísimo mejor... ahí... y si, va a ser
>> necesario un paso de adaptación.
>>
>>
> Ah, no estoy al tanto (como de tantas otras cosas :) pero uso bastante las
> cosas de FileSystem y no tuve mayores problemas, pero si uds dicen que es
> malo.... no se, por algo será....
>
>
>
>> Entiendo que vos sufriste la adaptación del RPC por el reemplazo de
>> Zinc... pero bueno, justo te afectó ese reemplazo. Esas cosas pueden y van
>> a seguir pasando, porque para progresar a veces es necesario romper
>> compatibilidad, pero nuestra idea es joder lo menos posible. Solo rompemos
>> compatibilidad si tenemos una buena razón y no encontramos una forma de
>> evitar la ruptura, no es algo que nos guste.
>> En fin... esperamos no joder demasiado, pero hay cosas que hay que
>> cambiar :)
>>
>>
> Si, si, esto se entiende perfectamente. El tema del xmlrpc, bueno, lo
> pongo aparte como los de todos los frameworks, en realidad es medio
> inevitable tocar estas cosas para poder avanzar.
>
> Me preocupan mucho más los sistemas que uno hace para clientes.....donde
> es mucho más problemático avanzar en versiones del "lenguaje" o de los
> "frameworks" porque en general para el cliente no involucran mejoras
> funcionales y eso hace muy complicado poder cobrar las horas necesarias.
> Uno sabe que necesita ir para adelante para evitar problemas en el futuro,
> pero lo cierto es que es complicado monetizar esa parte del trabajo y en
> general uno se queda con sistemas viejos corriendo en plataformas viejas y
> un dia....pummm, algo se rompe y lo arreglás si sos brujo, o tenés que
> ponerte en ese momento a hacer lo que no hiciste de evolución en el tiempo
> transcurrido.
>
> Pero es una historia que medio se repite siempre, en los 25 años que llevo
> en el rubro....siempre pasa.....
>
> Mi pregunta (y ya está respondida) apuntaba más a que pasa si ahora encaro
> un desarrollo con Pharo 1.4 que me va a llevar unos cuantos meses y cuando
> lo termino ya está 2.0 estable, qué nivel de incompatibilidad tendré en ese
> momento...o que cosas podría tener en cuenta desde ahora. La verdad,
> considero que no da para empezar en 2.0, pero tampoco quiero mal invertir
> meses en 1.4.
>
> Bueno, eso era todo, muchas gracias!
>
>
>
>
>
>> Un abrazo,
>> Esteban
>>
>>  
>>
>
>
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogpost.com
> ============================================
>
>

> hoy me colgué con las respuestas :)
>
>
> inferencia de tipos NO va a ser parte de Pharo (en el sentido de incorporado y
> distribuído). El proyecto es interesantísimo y con grandes posibilidades, pero
> va a ser algo "cargable"... al menos en las próximas versiones.
> En particular, inferencia de tipos tiene aplicaciones interesantes en:
> -análisis (la gente de moose, bah)
> -optimización de compilador/vm (ahí ya me interesa más...).
> En ambos casos por ahora lo que se maneja es algo opcional...
>
> En realidad la apuesta a largo plazo (de Pharo) no son los tipos sino los
> Slots. La cosa es así: en lugar de declarar simples atributos, vos podés
> declarar slots, que pueden ser: InstanceSlot, PropertySlot, BitSlot (y lo que
> quieras). Por default, todo Slot es un InstanceSlot, que es exactamente lo que
> tenemos ahora, con la diferencia de:
> 1) se puede agregar metadata
> 2) se pueden modelar las relaciones
> los BitSlot y PropertySlot son cosas que sirven para optimizar ciertas cosas
> de la VM (ya se imaginarán...), pero son solo dos ejemplos... obviamente, dado
> que esto es smalltalk, se pueden definir tipos de slots (que son clases) a
> gusto y placer...
>
> El chiste de esto (para mi) es que se puede jugar muchisimo con el compilador,
> para optimizar sin perder la esencia de smalltalk :)
>
> bue, eso... van otras "random answers":
>
> - con respecto a Nautilus como default browser: Obviamente, Edgar, yo sí estoy
> de acuerdo. Tener un browser de mierda que nadie (o nadie quiere usar) usa
> como default no le sirve a nadie. Lo que pasa es que el browser (y cualquier
> tool) también tendría que ser (y va a ser) cargable a gusto.
>
> - el "problema" con nautilus es que es "technology preview", esta en
> desarrollo y si bien tiene cosas grosas (y va a tener más)... está en
> desarrollo.
>
> - ¿Y por qué no seguir con OmniBrowser? a mi particularmente me gusta, pero
> tiene varios problemas:
> -- el "Omni Framework" (como yo le llamo al "hacedor de browsers" de
> omnibrowser es una cagada. Es dificil de entender e imposible de mejorar.
> -- a pesar de eso, lo hubiéramos conservado, si no fuera porque el mantenedor
> se negó a mantenerlo para Pharo 1.4 (y mucho menos para 2.0), y a cambio
> exigió que no introdujéramos más cambios en Pharo para, de ese modo, el ser
> feliz jugando y modificando sus cosas. Obviamente, eso es inaceptable.
> -- la decisión (y esto es responsabilidad exclusivamente mía, yo se la impuse
> al equipo) es no depender de una sola persona para el mantenimiento de nada.
> Nuestro sistema no puede depender del tiempo y la buena voluntad de una
> persona. Incluso si esa persona es un genio. No, no no :) En consecuencia,
> preferimos algo inmaduro (Nautilus) sobre algo groso (OB) pero que solo puede
> mantenerlo una persona.
>
> - por cierto, en parte eso aplica a muchas cosas que parece que andan pero que
> en realidad son un dolor de bolas. La mayor de las modificaciones que hacemos
> hoy por hoy es para lograr la modularidad... cosa tremendamente difícil en un
> sistema construido monolíticamente durante 15 años...
>
> - Edgar, obvio que lo de pharopatas no lo decís con saña... si así lo
> entendiera te lo hubiera marcado hace milenios. Somos argentinos, en nuestra
> cultura esta reirnos de esas cosas :)
>
> Abrazo,
> Esteban

> Me olvidé de otra de Edgar: "Cuisomancia" el arte de entender y dominar Cuis
> (jeje, hay que buscar mails viejos, pero seguro está por ahí).
>
> Esta en http://www.squeakros.org o ³la vuelta larga² para los nuevos
> Ahora levanta un Pier donde ya hay algunos que tienen su lugar para poner lo
> que quieran.
>
> No para reventarlo !!!!!
>
> Así que si alguno desea su lugar inmortal en la web, no tiene mas que
> contactarse por privada para arreglar
>
>
> Edgar
>
>