Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico,
entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga nada por esto :) ) Además usa GitHub, lo cual significa que no ensucia la imagen con cientos de cosas sólo para armar paquetes, requisitos, versiones, etc y nos integramos con un mundo de programadores de otros lenguajes también (Claramente esto no ocurre ni con Squeaksource ni con SmalltalkHub). Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les falta muy poco, según pueden ver acà: https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md Algunas actualizaciones a lo que ahí dice: - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. Bueno, quería comentarles a la gente del Bar para que no se pierdan la oportunidad de probar Cuis 4.1. -- Sincerely, Germán Arduino about.me/garduino |
> Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico,
> entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga nada > por esto :) ) > > > Además usa GitHub, lo cual significa que no ensucia la imagen con cientos de > cosas sólo para armar paquetes, requisitos, versiones, etc y nos integramos > con un mundo de programadores de otros lenguajes también (Claramente esto no > ocurre ni con Squeaksource ni con SmalltalkHub). > > Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les falta > muy poco, según pueden ver acà: > https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md > > Algunas actualizaciones a lo que ahí dice: > > - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas > relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). > - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. > > Bueno, quería comentarles a la gente del Bar para que no se pierdan la > oportunidad de probar Cuis 4.1. > > > -- > Sincerely, > Germán Arduino > about.me/garduino Espero que Cuis siga creciendo y que los recalcitrantes aprendan de su buen código. Edgar |
Una verdadera pena quería decir.
Enviado desde mi dispositivo BlackBerry® de Orange. -----Original Message----- From: "Edgar J. De Cleene" <[hidden email]> Sender: [hidden email] Date: Tue, 15 Jan 2013 06:40:27 To: <[hidden email]> Reply-To: [hidden email] Subject: Re: [squeakRos] Cuis va creciendo > Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico, > entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga nada > por esto :) ) > > > Además usa GitHub, lo cual significa que no ensucia la imagen con cientos de > cosas sólo para armar paquetes, requisitos, versiones, etc y nos integramos > con un mundo de programadores de otros lenguajes también (Claramente esto no > ocurre ni con Squeaksource ni con SmalltalkHub). > > Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les falta > muy poco, según pueden ver acà: > https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md > > Algunas actualizaciones a lo que ahí dice: > > - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas > relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). > - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. > > Bueno, quería comentarles a la gente del Bar para que no se pierdan la > oportunidad de probar Cuis 4.1. > > > -- > Sincerely, > Germán Arduino > about.me/garduino Espero que Cuis siga creciendo y que los recalcitrantes aprendan de su buen código. Edgar |
In reply to this post by garduino
Che! que bueno German!! me re alegro que estén haciendo crecer Cuis. Con
Juan nos vemos de vez en cuando y charlamos sobre este tema muchas veces pero lamentablemente no tengo el tiempo físico para poder dedicarle. Algo que siempre que le comenté a Juan que para mi sería buenísimo tener en Cuis y que es "el motivo" por el cual no lo usamos en la facu es el tema de los refactorings... o sea, no tener refactorings integrados al ambiente es un stoper para usarlo lo cual es una lástima!... vos tenes pensado agregar eso en algún momento? Abrazo y me encanta que te hayas enganchado con Smalltalk de vuelta! (aunque sea por diversión) Hernan 2013/1/14 Germán Arduino <[hidden email]> > ** > > > Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico, > entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga > nada por esto :) ) > > Además usa GitHub, lo cual significa que no ensucia la imagen con cientos > de cosas sólo para armar paquetes, requisitos, versiones, etc y nos > integramos con un mundo de programadores de otros lenguajes también > (Claramente esto no ocurre ni con Squeaksource ni con SmalltalkHub). > > Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les > falta muy poco, según pueden ver acà: > https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md > > Algunas actualizaciones a lo que ahí dice: > > - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas > relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). > - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. > > Bueno, quería comentarles a la gente del Bar para que no se pierdan la > oportunidad de probar Cuis 4.1. > > > -- > Sincerely, > Germán Arduino > about.me/garduino > > > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina |
Hola Hernán:
Un poco de lo que estoy haciendo con Cuis y mis planes están resumidos acá: http://germanarduino.blogspot.com.ar/2013/01/trabajando-con-cuis.html El tema refactorings es algo que no tenía en mente, sería bueno saber qué opina Juan al respecto. Por lo demás, te agradezco tus palabras, creo que uno nunca se puede ir del Smalltalk, cuando uno conoció Smalltalk es como que ninguna otra cosa conforma....por lo menos es lo que me pasa a mi. Y si, por ahora es por diversión, pero ojo, tengo planes muy serios, comerciales también! Veremos que pasa. -- Sincerely, Germán Arduino about.me/garduino El 16 de enero de 2013 08:58, Hernan Wilkinson <[hidden email]>escribió: > ** > > > Che! que bueno German!! me re alegro que estén haciendo crecer Cuis. Con > Juan nos vemos de vez en cuando y charlamos sobre este tema muchas veces > pero lamentablemente no tengo el tiempo físico para poder dedicarle. > Algo que siempre que le comenté a Juan que para mi sería buenísimo tener > en Cuis y que es "el motivo" por el cual no lo usamos en la facu es el tema > de los refactorings... o sea, no tener refactorings integrados al ambiente > es un stoper para usarlo lo cual es una lástima!... vos tenes pensado > agregar eso en algún momento? > > Abrazo y me encanta que te hayas enganchado con Smalltalk de vuelta! > (aunque sea por diversión) > Hernan > > > 2013/1/14 Germán Arduino <[hidden email]> > >> ** >> >> >> Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico, >> entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga >> nada por esto :) ) >> >> Además usa GitHub, lo cual significa que no ensucia la imagen con cientos >> de cosas sólo para armar paquetes, requisitos, versiones, etc y nos >> integramos con un mundo de programadores de otros lenguajes también >> (Claramente esto no ocurre ni con Squeaksource ni con SmalltalkHub). >> >> Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les >> falta muy poco, según pueden ver acà: >> https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md >> >> Algunas actualizaciones a lo que ahí dice: >> >> - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas >> relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). >> - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. >> >> Bueno, quería comentarles a la gente del Bar para que no se pierdan la >> oportunidad de probar Cuis 4.1. >> >> >> -- >> Sincerely, >> Germán Arduino >> about.me/garduino >> >> > > > -- > *Hernán Wilkinson > Agile Software Development, Teaching & Coaching* > *Phone: +54 - 011 - *6091 - 3125* > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > |
In reply to this post by hernan.wilkinson
Hola Hernán, Se me ocurren varias cosas para comentar. No hay ningún otro Smalltalk en el que se hayan hecho refactorings tan profundos como lo que hice yo en Cuis, en particular en Morphic. No usar un browser que automatize operaciones de refactoring no significa que el sistema no se pueda refactorizar! Lo que hace que el sistema se pueda refactorizar es el énfasis constante en reducir y simplificar, para poder entender. Por eso decir "Cuis no tiene refactorings" suena demasiado fuerte para mí. También hay una cuestión de gusto personal. Cuando empecé con Morphic3, hace unos 5 años, quise renombrar todos los Morphs existentes como "OldMorph". Porté, parcialmente, un browser para eso. Creo que era el RefactoringBrowser de Squeak. Lo usé un poco, y no me enganché. Entiendo mejor el código si hago el refactoring "a mano", mirando con cuidado, y así lo seguí haciendo desde entonces. A otras personas les puede gustar una herramienta automática. Eso está bien también. Por otra parte, esto es open source. No funciona decir "le falta xyz, es un stopper, no se puede usar". "xyz" será seguramente algo distinto para cada persona! No hay forma de que un o unos pocas core devs hagan todos los "xyz" de todo el mundo. No escala. Yo me encargo de mantener el kernel y las herramientas básicas, que funcionen, y que el código sea de buena calidad. La comunidad tiene que encargarse de agregar a eso lo que necesite. La manera de que esto funcione es que las personas que más necesitan un mismo "xyz" se junten y lo hagan. Con los paquetes que está portando, Germán está dando un muy buen ejemplo de esto!Yo tambíen hago eso con mi sombrero de "usuario de Cuis", en las áreas que a mí más me interesan (gráficos, procesamiento de imágenes, sonido, etc). "Elegir un browser alternativo (RefactoringBrowser, OmniBrowser, Wishker, Nautilus, etc), justificar la elección, y portarlo a Cuis" suena como un buen enunciado para un proyecto de una materia de programación en Smalltalk en una Universidad, no? Saludos, Juan Vuletich Quoting Hernan Wilkinson <[hidden email]>: > Che! que bueno German!! me re alegro que estén haciendo crecer Cuis. Con Juan nos vemos de vez en cuando y charlamos sobre este tema muchas veces pero lamentablemente no tengo el tiempo físico para poder dedicarle. > Algo que siempre que le comenté a Juan que para mi sería buenísimo tener en Cuis y que es "el motivo" por el cual no lo usamos en la facu es el tema de los refactorings... o sea, no tener refactorings integrados al ambiente es un stoper para usarlo lo cual es una lástima!... vos tenes pensado agregar eso en algún momento? > > > Abrazo y me encanta que te hayas enganchado con Smalltalk de vuelta! (aunque sea por diversión) > Hernan > > 2013/1/14 Germán Arduino <[hidden email]> > > > > Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico, entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga nada por esto :) ) > > > > > > Además usa GitHub, lo cual significa que no ensucia la imagen con cientos de cosas sólo para armar paquetes, requisitos, versiones, etc y nos integramos con un mundo de programadores de otros lenguajes también (Claramente esto no ocurre ni con Squeaksource ni con SmalltalkHub). > > > > > > Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les falta muy poco, según pueden ver acà: https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md > > > > > > Algunas actualizaciones a lo que ahí dice: > > > > > > - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). > > - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. > > > > > > Bueno, quería comentarles a la gente del Bar para que no se pierdan la oportunidad de probar Cuis 4.1. > > > > -- > > Sincerely, > > Germán Arduino > > about.me/garduino > > -- > > HERNáN WILKINSON > Agile Software Development, Teaching & Coaching > PHONE: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > Cheers, Juan Vuletich Links: ------ [1] mailto:[hidden email]?subject=Re%3A%20%5BsqueakRos%5D%20Cuis%20va%20creciendo [2] http://ar.groups.yahoo.com/group/squeakRos/post;_ylc=X3oDMTJwMG91cHFzBF9TAzk3NDkwNDI5BGdycElkAzYyNTAyMDYEZ3Jwc3BJZAMxNjcwMzk5MDk5BG1zZ0lkAzU4MzgEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMzU4Mzc3OTA5?act=reply&messageNum=5838 [3] http://ar.groups.yahoo.com/group/squeakRos/message/5828;_ylc=X3oDMTM0ZXFudXBzBF9TAzk3NDkwNDI5BGdycElkAzYyNTAyMDYEZ3Jwc3BJZAMxNjcwMzk5MDk5BG1zZ0lkAzU4MzgEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMzU4Mzc3OTA5BHRwY0lkAzU4Mjg- 39l1ksj9i7ggc@gator167.hostgator.com (3K) Download Attachment 1jce1elbojkc@gator167.hostgator.com (62 bytes) Download Attachment |
> También hay una cuestión de gusto personal. Cuando empecé con Morphic3, hace
> unos 5 años, quise renombrar todos los Morphs existentes como "OldMorph". > Porté, parcialmente, un browser para eso. Creo que era el RefactoringBrowser > de Squeak. Lo usé un poco, y no me enganché. Entiendo mejor el código si > hago el refactoring "a mano", mirando con cuidado, y así lo seguí haciendo > desde entonces. Adhiero. |
In reply to this post by garduino
Hola Germán,
Como todos los que tenemos nuestro corazoncito puesto en Smalltalk, me alegra mucho oir esto !!! Un Abrazo, Francisco El mié, 16-01-2013 a las 23:43 -0300, Germán Arduino escribió: > Y si, por ahora es por diversión, pero ojo, tengo planes muy serios, > comerciales también! Veremos que pasa. |
In reply to this post by J. Vuletich (mail lists)
2013/1/17 Juan Vuletich (mail lists) <[hidden email]>
> Hola Hernán, > > Se me ocurren varias cosas para comentar. > No hay ningún otro Smalltalk en el que se hayan hecho refactorings tan > profundos como lo que hice yo en Cuis, en particular en Morphic. No usar un > browser que automatize operaciones de refactoring no significa que el > sistema no se pueda refactorizar! > Completamente de acuerdo. Igual tené en cuenta que estoy usando el termino original de refactoring, o sea, modificar diseño sin modificar comportamiento, por supuesto que hay cambios de diseño que cambian comportamiento, agregan features, sacan otros, etc. que son los más interesantes y es lo que imagino que más habrás hecho con Morph > Lo que hace que el sistema se pueda refactorizar es el énfasis constante > en reducir y simplificar, para poder entender. Por eso decir "Cuis no tiene > refactorings" suena demasiado fuerte para mí. > Me referia a poder hacer refactorings automáticamente!, no que Cuis no tiene "hecho" ningun refactoring :-) > También hay una cuestión de gusto personal. Cuando empecé con Morphic3, > hace unos 5 años, quise renombrar todos los Morphs existentes como > "OldMorph". Porté, parcialmente, un browser para eso. Creo que era el > RefactoringBrowser de Squeak. Lo usé un poco, y no me enganché. Entiendo > mejor el código si hago el refactoring "a mano", mirando con cuidado, y así > lo seguí haciendo desde entonces. A otras personas les puede gustar una > herramienta automática. Eso está bien también. > Hacer refactorings automáticamente que son muy repetitivos y tediosos está bueno para mi y eso no implica que uno deje de mirar código... la idea es poder invertir mejor el tiempo nomás, dejar que la compu hago lo repetitivo y uno poder concentranse en lo interesante. El motivo por el cual este es un punto importante para la facu ya lo habíamos hablado antes y no tiene unicamente que ver con el tema tecnico sino de marketing... todos los pibes que toman los cursos estan acostumbrados eclipse, rubymine, visualstudio, etc donde los refactorings automaticos son parte de la herramienta y se usan bastante, mas aun cuando se hace TDD, por lo tanto un Smalltalk sin esas herramientas termina generando el comentario "uh, esto es una cagada, es viejo! no tiene refactorings automaticos", etc. y prefiero evitar esos comentarios mas aun cuando todavia no estan capacitados para apreciar lo que ocmentas mas arriba... es empezar con el pie izquierdo. > Por otra parte, esto es open source. No funciona decir "le falta xyz, es > un stopper, no se puede usar". > Estoy de acuerdo que asi no funciona... por eso dije al principio que lamentablemente no tengo tiempo para dedicarle, no fue mi intención lavarme las manos o delegarle a otro la responsabilidad > "xyz" será seguramente algo distinto para cada persona! No hay forma de > que un o unos pocas core devs hagan todos los "xyz" de todo el mundo. No > escala. Yo me encargo de mantener el kernel y las herramientas básicas, que > funcionen, y que el código sea de buena calidad. > > La comunidad tiene que encargarse de agregar a eso lo que necesite. La > manera de que esto funcione es que las personas que más necesitan un mismo > "xyz" se junten y lo hagan. Con los paquetes que está portando, Germán está > dando un muy buen ejemplo de esto! > si me parece muy bueno, ojala más gente pueda prenderse > Yo tambíen hago eso con mi sombrero de "usuario de Cuis", en las áreas que > a mí más me interesan (gráficos, procesamiento de imágenes, sonido, etc). > > "Elegir un browser alternativo (RefactoringBrowser, OmniBrowser, > Wishker, Nautilus, etc), justificar la elección, y portarlo a Cuis" suena > como un buen enunciado para un proyecto de una materia de programación en > Smalltalk en una Universidad, no? > Es una buena idea como trabajo practico, habría que ver si alcanza para un cuatrimestre pero es una buena opcion, si me acuerdo lo hacemos este año. Abrazo Hernán > > Saludos, > > Juan Vuletich > > > Quoting Hernan Wilkinson <[hidden email]>: > > > Che! que bueno German!! me re alegro que estén haciendo crecer Cuis. Con > Juan nos vemos de vez en cuando y charlamos sobre este tema muchas veces > pero lamentablemente no tengo el tiempo físico para poder dedicarle. > Algo que siempre que le comenté a Juan que para mi sería buenísimo tener > en Cuis y que es "el motivo" por el cual no lo usamos en la facu es el tema > de los refactorings... o sea, no tener refactorings integrados al ambiente > es un stoper para usarlo lo cual es una lástima!... vos tenes pensado > agregar eso en algún momento? > > Abrazo y me encanta que te hayas enganchado con Smalltalk de vuelta! > (aunque sea por diversión) > Hernan > > > 2013/1/14 Germán Arduino <[hidden email]> > >> ** >> >> Gente, para el que le interese usar un Smalltalk-80 bien hecho, chico, >> entendible, rápido, les pido que prueben Cuis. (no, no, Juan no me paga >> nada por esto :) ) >> >> Además usa GitHub, lo cual significa que no ensucia la imagen con cientos >> de cosas sólo para armar paquetes, requisitos, versiones, etc y nos >> integramos con un mundo de programadores de otros lenguajes también >> (Claramente esto no ocurre ni con Squeaksource ni con SmalltalkHub). >> >> Ya vamos teniendo unos cuantos paquetes usables, y otros a los que les >> falta muy poco, según pueden ver acà: >> https://github.com/hhzl/Cuis/blob/master/ListOfCuisPackages.md >> >> Algunas actualizaciones a lo que ahí dice: >> >> - Tengo casi funcionando Sport & Swazoo (me queda afinar algunas cosas >> relacionadas con el fork de Cuis que no devuelve el proceso y muy poco mas). >> - Tengo también muy cerca de cerrar WebClient con toda su funcionalidad. >> >> Bueno, quería comentarles a la gente del Bar para que no se pierdan la >> oportunidad de probar Cuis 4.1. >> >> >> -- >> Sincerely, >> Germán Arduino >> about.me/garduino >> >> >> > > > > -- > *Hernán Wilkinson > Agile Software Development, Teaching & Coaching* > *Phone: +54 - 011 - *6091 - 3125* > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > > > Cheers, > Juan Vuletich > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina 39l1ksj9i7ggc@gator167.hostgator.com (3K) Download Attachment 1jce1elbojkc@gator167.hostgator.com (60 bytes) Download Attachment |
Hola Hernán, Quoting Hernan Wilkinson <[hidden email]>: > 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > > > > Hola Hernán, > > > > > > Se me ocurren varias cosas para comentar. > > > No hay ningún otro Smalltalk en el que se hayan hecho refactorings tan profundos como lo que hice yo en Cuis, en particular en Morphic. No usar un browser que automatize operaciones de refactoring no significa que el sistema no se pueda refactorizar! > > > Completamente de acuerdo. Igual tené en cuenta que estoy usando el termino original de refactoring, o sea, modificar diseño sin modificar comportamiento, por supuesto que hay cambios de diseño que cambian comportamiento, agregan features, sacan otros, etc. que son los más interesantes y es lo que imagino que más habrás hecho con Morph Esto me da pie para comentar algo de cómo laburo. Cuando estoy haciendo cambios de diseño y comportamiento importantes en Morphic, es muy usual tener que tocar muchas clases y muchos métodos. Muchas veces aplico un refactoring (manteniendo el comportamiento), para facilitar los cambios grandes, o experimentos peligrosos, que pueden romper la imagen. Después hago los cambios de verdad. Por ejemplo eliminar mucho comportamiento. Ahí el refactoring previo fue factorizar el comportamiento que quiero eliminar, para desacoplarlo del que quiero dejar. Y después, puede haber una etapa de limpieza final, que también es un refactoring.. Algo parecido hice para tomar los cambios al compilador para closures. Lo primero que hice fue un refactoring para permitir que el Compiler viejo y el nuevo convivan, y sea trivial switchear. Entonces, puse por ahi un handler de excepcion, que al primer problema con el compiler repone el viejo. Eso me salvo la vida un par de veces. Después puse a punto el compiler nuevo, y recompilé toda la imagen. Y después eliminé el viejo. O sea, que salvo el instante que toqué una variable para habilitar el compiler nuevo, todo lo demás fue una secuencia de refactorings. Incluso el cambio más profundo que hice, eliminar un montón de variables de Morph, cambiar la jerarquía y las responsabilidades, y usar coordenadas Float locales. Todo eso puede verse como un refactoring o una secuencia de ellos. Esto es así porque el sistema, desde afuera, todavía hace exactamente lo mismo que antes. En algún momento incorporaré el motor de Morphic 3 y otros cambios, y recién ahí va a haber cambios reales de comportamiento. Así que el refactoring manual es algo que hago todo el tiempo, y parte fundamental de los cambios de comportamiento, ya sea para agregar o eliminar features. > ... > > > > "Elegir un browser alternativo (RefactoringBrowser, OmniBrowser, Wishker, Nautilus, etc), justificar la elección, y portarlo a Cuis" suena como un buen enunciado para un proyecto de una materia de programación en Smalltalk en una Universidad, no? > > Es una buena idea como trabajo practico, habría que ver si alcanza para un cuatrimestre pero es una buena opcion, si me acuerdo lo hacemos este año. Eso sería fantástico! Un abrazo, Juan Vuletich > Abrazo > Hernán |
Che, buenísimo como hiciste esos cambios... que maravilloso es Smalltalk
por Dios! dos compiladores simultaneos, si uno falla usa el otro jaja! buenisimo. Nosotros en la facu le decimos que hagan lo mismo cuando estan tocando herramientas del sistema como el debugger, browser etc puest que es muy lindo tener un ambiente escrito en si mismo pero una cagada cuando tocas mal la herramienta que estas usando :-) Abrazo Hernan. 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > Hola Hernán, > > Quoting Hernan Wilkinson <[hidden email]>: > > > > > 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > >> Hola Hernán, >> >> Se me ocurren varias cosas para comentar. >> > No hay ningún otro Smalltalk en el que se hayan hecho refactorings tan >> profundos como lo que hice yo en Cuis, en particular en Morphic. No usar un >> browser que automatize operaciones de refactoring no significa que el >> sistema no se pueda refactorizar! >> > Completamente de acuerdo. Igual tené en cuenta que estoy usando el termino > original de refactoring, o sea, modificar diseño sin modificar > comportamiento, por supuesto que hay cambios de diseño que cambian > comportamiento, agregan features, sacan otros, etc. que son los más > interesantes y es lo que imagino que más habrás hecho con Morph > > > Esto me da pie para comentar algo de cómo laburo. Cuando estoy haciendo > cambios de diseño y comportamiento importantes en Morphic, es muy usual > tener que tocar muchas clases y muchos métodos. Muchas veces aplico un > refactoring (manteniendo el comportamiento), para facilitar los cambios > grandes, o experimentos peligrosos, que pueden romper la imagen. > > Después hago los cambios de verdad. Por ejemplo eliminar mucho > comportamiento. Ahí el refactoring previo fue factorizar el comportamiento > que quiero eliminar, para desacoplarlo del que quiero dejar. Y después, > puede haber una etapa de limpieza final, que también es un refactoring. > > Algo parecido hice para tomar los cambios al compilador para closures. Lo > primero que hice fue un refactoring para permitir que el Compiler viejo y > el nuevo convivan, y sea trivial switchear. Entonces, puse por ahi un > handler de excepcion, que al primer problema con el compiler repone el > viejo. Eso me salvo la vida un par de veces. Después puse a punto el > compiler nuevo, y recompilé toda la imagen. Y después eliminé el viejo. O > sea, que salvo el instante que toqué una variable para habilitar el > compiler nuevo, todo lo demás fue una secuencia de refactorings. > > Incluso el cambio más profundo que hice, eliminar un montón de variables > de Morph, cambiar la jerarquía y las responsabilidades, y usar coordenadas > Float locales. Todo eso puede verse como un refactoring o una secuencia de > ellos. Esto es así porque el sistema, desde afuera, todavía hace > exactamente lo mismo que antes. En algún momento incorporaré el motor de > Morphic 3 y otros cambios, y recién ahí va a haber cambios reales de > comportamiento. > > Así que el refactoring manual es algo que hago todo el tiempo, y parte > fundamental de los cambios de comportamiento, ya sea para agregar o > eliminar features. > > ... > > "Elegir un browser alternativo (RefactoringBrowser, OmniBrowser, >> Wishker, Nautilus, etc), justificar la elección, y portarlo a Cuis" suena >> como un buen enunciado para un proyecto de una materia de programación en >> Smalltalk en una Universidad, no? >> > > Es una buena idea como trabajo practico, habría que ver si alcanza para un > cuatrimestre pero es una buena opcion, si me acuerdo lo hacemos este año. > > > Eso sería fantástico! > > Un abrazo, > Juan Vuletich > > Abrazo > Hernán > > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina |
In reply to this post by J. Vuletich (mail lists)
El 17 de enero de 2013 14:37, Juan Vuletich (mail lists) <
[hidden email]> escribió: > ** > > Esto me da pie para comentar algo de cómo laburo. Cuando estoy haciendo > cambios de diseño y comportamiento importantes en Morphic, es muy usual > tener que tocar muchas clases y muchos métodos. Muchas veces aplico un > refactoring (manteniendo el comportamiento), para facilitar los cambios > grandes, o experimentos peligrosos, que pueden romper la imagen. > > Después hago los cambios de verdad. Por ejemplo eliminar mucho > comportamiento. Ahí el refactoring previo fue factorizar el comportamiento > que quiero eliminar, para desacoplarlo del que quiero dejar. Y después, > puede haber una etapa de limpieza final, que también es un refactoring. > > Algo parecido hice para tomar los cambios al compilador para closures. Lo > primero que hice fue un refactoring para permitir que el Compiler viejo y > el nuevo convivan, y sea trivial switchear. Entonces, puse por ahi un > handler de excepcion, que al primer problema con el compiler repone el > viejo. Eso me salvo la vida un par de veces. Después puse a punto el > compiler nuevo, y recompilé toda la imagen. Y después eliminé el viejo. O > sea, que salvo el instante que toqué una variable para habilitar el > compiler nuevo, todo lo demás fue una secuencia de refactorings. > > Incluso el cambio más profundo que hice, eliminar un montón de variables > de Morph, cambiar la jerarquía y las responsabilidades, y usar coordenadas > Float locales. Todo eso puede verse como un refactoring o una secuencia de > ellos. Esto es así porque el sistema, desde afuera, todavía hace > exactamente lo mismo que antes. En algún momento incorporaré el motor de > Morphic 3 y otros cambios, y recién ahí va a haber cambios reales de > comportamiento. > > Así que el refactoring manual es algo que hago todo el tiempo, y parte > fundamental de los cambios de comportamiento, ya sea para agregar o > eliminar features. > > Extraordinario que compartas estas cosas! son las que exactamente los que sabemos menos esperamos de Uds, los que saben más! Gracias! -- Sincerely, Germán Arduino about.me/garduino |
In reply to this post by Francisco A. Lizarralde
Gracias Francisco! No se si es para tanto jaaa, pero por lo menos voy a
intentar ayudar a Cuis, dentro de mis posibilidades, y luego usarlo "en serio" :) Saludos. El 17 de enero de 2013 10:13, Francisco A. Lizarralde < [hidden email]> escribió: > ** > > > Hola Germán, > > Como todos los que tenemos nuestro corazoncito puesto en Smalltalk, me > alegra mucho oir esto !!! > > Un Abrazo, > > Francisco > > El mié, 16-01-2013 a las 23:43 -0300, Germán Arduino escribió: > > > Y si, por ahora es por diversión, pero ojo, tengo planes muy serios, > > comerciales también! Veremos que pasa. > > > |
In reply to this post by J. Vuletich (mail lists)
Me toco hacer de esos refactorings varias veces. El proceso que segui es
el que describis. A veces lo pienso en terminos de una infeccion viral. Algo lindo de hacer cambios asi es que es posible extraer una secuencia de cambios a fileouts por ejemplo, y si haces filein de cada fileout en la misma secuencia entonces el proceso es reproducible. Todavia no me toco hacerle eso al compilador, pero si hice de esos que Juan dice en Morphic en su momento, y varias veces con hashing y con la tabla de simbolos. De hecho, hice lo mismo y cambie identityHash (notese que identityHash se usa para los simbolos, y para los metodos compilados, en VisualWorks para los namespaces, etc). Y tambien hice lo mismo con unos experimentos para cambiar el formato de los diccionarios de metodos. Es agradable agarrar los method dictionaries y hacerles esto: MethodDictionary allInstances do: [:each | each copyAsSparse become: each] En 0.3 segundos tenes otro tipo de method dictionaries, y todo sigue andando... 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > ** > > > Hola Hernán, > > Quoting Hernan Wilkinson <[hidden email]>: > > > > > 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > >> Hola Hernán, >> >> Se me ocurren varias cosas para comentar. >> > No hay ningún otro Smalltalk en el que se hayan hecho refactorings tan >> profundos como lo que hice yo en Cuis, en particular en Morphic. No usar un >> browser que automatize operaciones de refactoring no significa que el >> sistema no se pueda refactorizar! >> > Completamente de acuerdo. Igual tené en cuenta que estoy usando el termino > original de refactoring, o sea, modificar diseño sin modificar > comportamiento, por supuesto que hay cambios de diseño que cambian > comportamiento, agregan features, sacan otros, etc. que son los más > interesantes y es lo que imagino que más habrás hecho con Morph > > > Esto me da pie para comentar algo de cómo laburo. Cuando estoy haciendo > cambios de diseño y comportamiento importantes en Morphic, es muy usual > tener que tocar muchas clases y muchos métodos. Muchas veces aplico un > refactoring (manteniendo el comportamiento), para facilitar los cambios > grandes, o experimentos peligrosos, que pueden romper la imagen. > > Después hago los cambios de verdad. Por ejemplo eliminar mucho > comportamiento. Ahí el refactoring previo fue factorizar el comportamiento > que quiero eliminar, para desacoplarlo del que quiero dejar. Y después, > puede haber una etapa de limpieza final, que también es un refactoring. > > Algo parecido hice para tomar los cambios al compilador para closures. Lo > primero que hice fue un refactoring para permitir que el Compiler viejo y > el nuevo convivan, y sea trivial switchear. Entonces, puse por ahi un > handler de excepcion, que al primer problema con el compiler repone el > viejo. Eso me salvo la vida un par de veces. Después puse a punto el > compiler nuevo, y recompilé toda la imagen. Y después eliminé el viejo. O > sea, que salvo el instante que toqué una variable para habilitar el > compiler nuevo, todo lo demás fue una secuencia de refactorings. > > Incluso el cambio más profundo que hice, eliminar un montón de variables > de Morph, cambiar la jerarquía y las responsabilidades, y usar coordenadas > Float locales. Todo eso puede verse como un refactoring o una secuencia de > ellos. Esto es así porque el sistema, desde afuera, todavía hace > exactamente lo mismo que antes. En algún momento incorporaré el motor de > Morphic 3 y otros cambios, y recién ahí va a haber cambios reales de > comportamiento. > > Así que el refactoring manual es algo que hago todo el tiempo, y parte > fundamental de los cambios de comportamiento, ya sea para agregar o > eliminar features. > > ... > > "Elegir un browser alternativo (RefactoringBrowser, OmniBrowser, >> Wishker, Nautilus, etc), justificar la elección, y portarlo a Cuis" suena >> como un buen enunciado para un proyecto de una materia de programación en >> Smalltalk en una Universidad, no? >> > > Es una buena idea como trabajo practico, habría que ver si alcanza para un > cuatrimestre pero es una buena opcion, si me acuerdo lo hacemos este año. > > > Eso sería fantástico! > > Un abrazo, > Juan Vuletich > > Abrazo > Hernán > > > |
Hola gente!
Lo que describe Andres lo pueden encontrar con mas detalle en su libro de Fundamentals of Smalltalk Programming Technique, Volume 1 http://www.lulu.com/shop/andres-valloud/fundamentals-of-smalltalk-programming-technique-volume-1/paperback/product-5299835.html 2013/1/18 Andres Valloud <[hidden email]> > ** > > > Me toco hacer de esos refactorings varias veces. El proceso que segui es > el que describis. A veces lo pienso en terminos de una infeccion viral. > > Algo lindo de hacer cambios asi es que es posible extraer una secuencia de > cambios a fileouts por ejemplo, y si haces filein de cada fileout en la > misma secuencia entonces el proceso es reproducible. Todavia no me toco > hacerle eso al compilador, pero si hice de esos que Juan dice en Morphic en > su momento, y varias veces con hashing y con la tabla de simbolos. De > hecho, hice lo mismo y cambie identityHash (notese que identityHash se usa > para los simbolos, y para los metodos compilados, en VisualWorks para los > namespaces, etc). Y tambien hice lo mismo con unos experimentos para > cambiar el formato de los diccionarios de metodos. Es agradable agarrar > los method dictionaries y hacerles esto: > > MethodDictionary allInstances do: > [:each | each copyAsSparse become: each] > > En 0.3 segundos tenes otro tipo de method dictionaries, y todo sigue > andando... > > |
Jaja me habia olvidado pero es cierto, lo escribi en detalle!
2013/1/17 Angel Java Lopez <[hidden email]> > ** > > > Hola gente! > > Lo que describe Andres lo pueden encontrar con mas detalle en su libro de > Fundamentals of Smalltalk Programming Technique, Volume 1 > http://www.lulu.com/shop/andres-valloud/fundamentals-of-smalltalk-programming-technique-volume-1/paperback/product-5299835.html > > > 2013/1/18 Andres Valloud <[hidden email]> > >> ** >> >> >> Me toco hacer de esos refactorings varias veces. El proceso que segui es >> el que describis. A veces lo pienso en terminos de una infeccion viral. >> >> Algo lindo de hacer cambios asi es que es posible extraer una secuencia >> de cambios a fileouts por ejemplo, y si haces filein de cada fileout en la >> misma secuencia entonces el proceso es reproducible. Todavia no me toco >> hacerle eso al compilador, pero si hice de esos que Juan dice en Morphic en >> su momento, y varias veces con hashing y con la tabla de simbolos. De >> hecho, hice lo mismo y cambie identityHash (notese que identityHash se usa >> para los simbolos, y para los metodos compilados, en VisualWorks para los >> namespaces, etc). Y tambien hice lo mismo con unos experimentos para >> cambiar el formato de los diccionarios de metodos. Es agradable agarrar >> los method dictionaries y hacerles esto: >> >> MethodDictionary allInstances do: >> [:each | each copyAsSparse become: each] >> >> En 0.3 segundos tenes otro tipo de method dictionaries, y todo sigue >> andando... >> >> > |
In reply to this post by Andres Valloud-5
Quoting Andres Valloud <[hidden email]>: > Me toco hacer de esos refactorings varias veces. El proceso que segui es el que describis. A veces lo pienso en terminos de una infeccion viral. > > Algo lindo de hacer cambios asi es que es posible extraer una secuencia de cambios a fileouts por ejemplo, y si haces filein de cada fileout en la misma secuencia entonces el proceso es reproducible. Eso es absolutamente fundamental en Cuis. Cualquier usuario puede actualizar su imagen aplicando la secuencia de updates. Y todos los releases de Cuis a partir de 1.0 se hicieron aplicando los updates al release anterior. Así que el proceso es realmente reproducido muchas veces. > Todavia no me toco hacerle eso al compilador, pero si hice de esos que Juan dice en Morphic en su momento, y varias veces con hashing y con la tabla de simbolos. De hecho, hice lo mismo y cambie identityHash (notese que identityHash se usa para los simbolos, y para los metodos compilados, en VisualWorks para los namespaces, etc). Y tambien hice lo mismo con unos experimentos para cambiar el formato de los diccionarios de metodos. Es agradable agarrar los method dictionaries y hacerles esto: > > MethodDictionary allInstances do: > [:each | each copyAsSparse become: each] > > En 0.3 segundos tenes otro tipo de method dictionaries, y todo sigue andando... :) > 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > > > > Hola Hernán, > > > > Quoting Hernan Wilkinson <[hidden email]>: > > > > > 2013/1/17 Juan Vuletich (mail lists) <[hidden email]> > > > > > > > > > > Hola Hernán, > > > > > > > > > > > > Se me ocurren varias cosas para comentar. > > > > > > > No hay ningún otro Smalltalk en el que se hayan hecho refactorings tan profundos como lo que hice yo en Cuis, en particular en Morphic. No usar un browser que automatize operaciones de refactoring no significa que el sistema no se pueda refactorizar! > > > > > > > > > Completamente de acuerdo. Igual tené en cuenta que estoy usando el termino original de refactoring, o sea, modificar diseño sin modificar comportamiento, por supuesto que hay cambios de diseño que cambian comportamiento, agregan features, sacan otros, etc. que son los más interesantes y es lo que imagino que más habrás hecho con Morph > > > > Esto me da pie para comentar algo de cómo laburo. Cuando estoy haciendo cambios de diseño y comportamiento importantes en Morphic, es muy usual tener que tocar muchas clases y muchos métodos. Muchas veces aplico un refactoring (manteniendo el comportamiento), para facilitar los cambios grandes, o experimentos peligrosos, que pueden romper la imagen. > > > > Después hago los cambios de verdad. Por ejemplo eliminar mucho comportamiento. Ahí el refactoring previo fue factorizar el comportamiento que quiero eliminar, para desacoplarlo del que quiero dejar. Y después, puede haber una etapa de limpieza final, que también es un refactoring. > > > > Algo parecido hice para tomar los cambios al compilador para closures. Lo primero que hice fue un refactoring para permitir que el Compiler viejo y el nuevo convivan, y sea trivial switchear. Entonces, puse por ahi un handler de excepcion, que al primer problema con el compiler repone el viejo. Eso me salvo la vida un par de veces. Después puse a punto el compiler nuevo, y recompilé toda la imagen. Y después eliminé el viejo. O sea, que salvo el instante que toqué una variable para habilitar el compiler nuevo, todo lo demás fue una secuencia de refactorings. > > > > Incluso el cambio más profundo que hice, eliminar un montón de variables de Morph, cambiar la jerarquía y las responsabilidades, y usar coordenadas Float locales. Todo eso puede verse como un refactoring o una secuencia de ellos. Esto es así porque el sistema, desde afuera, todavía hace exactamente lo mismo que antes. En algún momento incorporaré el motor de Morphic 3 y otros cambios, y recién ahí va a haber cambios reales de comportamiento. > > > > Así que el refactoring manual es algo que hago todo el tiempo, y parte fundamental de los cambios de comportamiento, ya sea para agregar o eliminar features. > > > > > ... > > > > > > > "Elegir un browser alternativo (RefactoringBrowser, OmniBrowser, Wishker, Nautilus, etc), justificar la elección, y portarlo a Cuis" suena como un buen enunciado para un proyecto de una materia de programación en Smalltalk en una Universidad, no? > > > > > > Es una buena idea como trabajo practico, habría que ver si alcanza para un cuatrimestre pero es una buena opcion, si me acuerdo lo hacemos este año. > > > > Eso sería fantástico! > > > > Un abrazo, > > Juan Vuletich > > > > > Abrazo > > > Hernán > > Cheers, Juan Vuletich Links: ------ [1] mailto:[hidden email]?subject=Re%3A%20%5BsqueakRos%5D%20Cuis%20va%20creciendo [2] http://ar.groups.yahoo.com/group/squeakRos/post;_ylc=X3oDMTJwMmY1NTFuBF9TAzk3NDkwNDI5BGdycElkAzYyNTAyMDYEZ3Jwc3BJZAMxNjcwMzk5MDk5BG1zZ0lkAzU4NDkEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMzU4NDk0MTQx?act=reply&messageNum=5849 [3] http://ar.groups.yahoo.com/group/squeakRos/message/5828;_ylc=X3oDMTM0ZThlNTk4BF9TAzk3NDkwNDI5BGdycElkAzYyNTAyMDYEZ3Jwc3BJZAMxNjcwMzk5MDk5BG1zZ0lkAzU4NDkEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMzU4NDk0MTQxBHRwY0lkAzU4Mjg- 7vpy9wmvqy0j@gator167.hostgator.com (3K) Download Attachment 5vnyudbgilzp@gator167.hostgator.com (62 bytes) Download Attachment |
Free forum by Nabble | Edit this page |