RV: DNG-Win32 Bit VM
Locked
1234
1234
 
|
> Coincido en que hacer algo que ande es relativamente sencillo y hacer algo que ande bien es extremadamente complejo.
Y si... tal cual. > Entre las cosas que hoy le pediría a un VM es en que aumenten los límites en cantidad de objetos, que soporten 64 bits No es por ser pretencioso, pero VisualWorks tiene VMs de 64 bits para Linux en x86, Solaris en x86, y Solaris en SPARC. Trabajamos mucho con las VMs y las imagenes de 64 bits en este tiempo, y las versiones que estan a punto de salir son muchisimo mejores que lo que teniamos hace unos años (esto no lo digo yo o nosotros (Cincom)... lo puso por escrito gente de GemStone en la lista de VisualWorks acerca de 7.7). Tambien estamos trabajando en un port a Windows 64 bits. Esto ultimo es mas dificil de lo que parece. Por ejemplo, al contrario de mas o menos todo el mundo, en Windows de 64 bits un long tiene 32 bits. Asi que si, digamos, tenes codigo multiplataforma que habla de longs todo el tiempo porque hasta ahora siempre (la VM de VisualWorks tiene cerca de 30 años encima) en 64 bits un long tenia 64 bits, y en 32 bits un long tenia 32 bits... hmmm... > y algo que siempre quisiera tener es mucho mas control sobre el method lookup, que a mi entender es la principal limitación de Smalltalk. Podrias contar mas de esto? Donde le ves la limitacion? Que te gustaria que hubiera pero no hay? Andres. 2010/7/26 [hidden email] <[hidden email]>: > Coincido con Gerardo, muy bueno el correo de Andrés, muchas gracias. > Sería bueno que alguna vez alguien documentara o publicara algo acerca > de VMs de calidad, hay poca gente que lo podría hacer bien, y ese > material aportaría a la continuidad de Smalltalk como plataforma a > largo plazo. Todo smalltalker alguna vez tiene su época de querer > hacerse la VM, yo la pasé y si me distraigo un poco supongo que > volveré a lo mismo, es como recurrente el tema. Coincido en que hacer > algo que ande es relativamente sencillo y hacer algo que ande bien es > extremadamente complejo. Además la problemática a resolver tiene poco > que ver con Smalltalk (lo cual no lo hace menos divertido). Me parecen > válidos todos los enfoques, desde los que arrancan del assembler mas > crudo hasta los que se suben arriba de otra VM o lenguaje de alto > nivel, cada uno en su lugar y contexto no deja de ser interesante. > Entre las cosas que hoy le pediría a un VM es en que aumenten los > límites en cantidad de objetos, que soporten 64 bits y algo que > siempre quisiera tener es mucho mas control sobre el method lookup, > que a mi entender es la principal limitación de Smalltalk. > > Pero insisto en que sería bueno, que quienes saben del tema, alguna > vez publiquen y/o hagan docencia sobre el tema, al menos a modo de > memorias antes de retirarse. Creo que muchos pagaríamos gustosos un > libro sobre eso, porque nos ahorraría tiempo en lo que igual queremos > o vamos a hacer. Y además, difundir esto podría tener un efecto > positivo y podría originar la aparición de mas alternativas que las > que existen hoy, que son pocas. > > Saludos y gracias por la información. > > Diego Coronel > > > > > > > > > > On Jul 26, 2:41 pm, Gerardo Richarte <[hidden email]> wrote: >> excelente andres!!! >> >> espero que todo esto tambi n lo tengas en formato powerpoint :) >> >> ya sab s que a unos cuantos nos interesa, ponele una tonelada de >> detalles t cnicos, y agregale una pizca de rant tambi n :) >> listo! receta perfecta :) >> >> en un rato vuelvo a leer el mail y mando algunas preguntas tambi n >> >> saludos! > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: RV: DNG-Win32 Bit VM
|
|
Hola Andrés
Contesto entre líneas... On Jul 26, 8:57 pm, Andres Valloud <[hidden email]> wrote: > > Coincido en que hacer algo que ande es relativamente sencillo y hacer algo que ande bien es extremadamente complejo. > > Y si... tal cual. > > > Entre las cosas que hoy le pediría a un VM es en que aumenten los límites en cantidad de objetos, que soporten 64 bits > > No es por ser pretencioso, pero VisualWorks tiene VMs de 64 bits para > Linux en x86, Solaris en x86, y Solaris en SPARC. Trabajamos mucho > con las VMs y las imagenes de 64 bits en este tiempo, y las versiones > que estan a punto de salir son muchisimo mejores que lo que teniamos > hace unos años (esto no lo digo yo o nosotros (Cincom)... lo puso por > escrito gente de GemStone en la lista de VisualWorks acerca de 7.7). > > Tambien estamos trabajando en un port a Windows 64 bits. Esto ultimo > es mas dificil de lo que parece. Por ejemplo, al contrario de mas o > menos todo el mundo, en Windows de 64 bits un long tiene 32 bits. Asi > que si, digamos, tenes codigo multiplataforma que habla de longs todo > el tiempo porque hasta ahora siempre (la VM de VisualWorks tiene cerca > de 30 años encima) en 64 bits un long tenia 64 bits, y en 32 bits un > long tenia 32 bits... hmmm... caso uso Dolphin o Squeak por motivos comerciales. > > y algo que siempre quisiera tener es mucho mas control sobre el method lookup, que a mi entender es la principal limitación de Smalltalk. > > Podrias contar mas de esto? Donde le ves la limitacion? Que te > gustaria que hubiera pero no hay? Cuando envío un mensaje a un objeto, este busca en la clase, superclases, etc. y ejectua el método. Toda esta convención es invariable y define, sin posibilidad de modificar nada, cosas muy importantes como la herencia y otras yerbas. Esta convención nos parece bien a todos porque nos parece bien que si mando el mensaje #print se ejecute el método #print, y también nos parece bien a todos utilizar herencia simple, y también a casi todos nos parecen bien las clases, metaclases y todo lo que defendemos desde la practicidad. Sin embargo, no poder modificar esta convención, trae mas limitaciones de las que generalmente pensamos (porque nos acostumbramos y nos gusta la convención) y usualmente resolvemos de manera sucia y limitada. Son conocidos los casos no muy bien resueltos con herencia simple (como la jerarquia de Stream), son conocidos los trucos de usar #dnu para activar métodos que no están presentes en la clase del receptor (como en los proxies) y personalmente me molesta que esté conceptualmente tan acoplado el método con el mensaje, dos cosas muy distintas. Una solución que me suena factible, y tal vez compleja de implementar decentemente, sería que el methodLookup estuviera implementado en Smalltalk, en Object supongo. La implementación default podría ser una primitiva que hiciera lo mismo que esperamos hoy en día, pero que al modificarla en subclases nos abriera un campo de posibilidades muy amplias y muy peligrosas (tan peligrosas como cualquier otra de Smalltalk). Sería trivial implementar proxies, hacer delegaciones mas sofisticadas y generar diseños hoy imposibles, de manera muy clara. Por ejemplo, hoy es común ver que los proxies para persistencia en bases de datos, o para sistemas distribuidos se hacen heredando de ProtoObject, o de clases con pocos métodos, cosa que ya es sucia de entrada, luego se agregan #dnu que son mas sucios. No sería mas adecuado que la clase de un proxy fuera el misma que la del subject? al menos parecida?, de esta manera se podrían delegar en el subject la resolución de algunos métodos y en el proxy la resolución de otros, podría incluso haber cooperación entre estos objetos. Esto es largo de explicar, pero creo qeu se podría resolver mucho, programando poco, mas claro y simple de debuggear. Otro ejemplo sería la herencia múltiple, quedaría de una manera muy prolija, porque se podría acotar a una parte muy pequeña del sistema, no estaría condicionada por otra convención (como en c++), no tendría porqué tener que limitarse a clases, podría ser entre objetos (como en la herencia de prototipos que usaba en el NewtonScript de Apple). Es mas el polimorfismo se ampliaría porque un objecto podría resolver mensajes que hoy no entendería. Creo que también desaparecerían los intentos de solucionar estos problemas mediante traits o cosas similares. Todo esto, tal vez genere mas incertidumbre, pero creo que sería muy interesante TENERLO, ir usándolo con mucho cuidado, y posiblemente aparezcan patterns que mejoren sustancialmente las recetas actuales. Entiendo, no estoy seguro, que las primeras versiones de la VM de Smalltalk tenían algo similar y que luego se descartó por temas de perfomance, supongo que 35 años mas tarde se podría tratar de resolver ese "problemita". Saludos Diego Coronel > Andres. > > 2010/7/26 [hidden email] <[hidden email]>: > > > > > Coincido con Gerardo, muy bueno el correo de Andrés, muchas gracias. > > Sería bueno que alguna vez alguien documentara o publicara algo acerca > > de VMs de calidad, hay poca gente que lo podría hacer bien, y ese > > material aportaría a la continuidad de Smalltalk como plataforma a > > largo plazo. Todo smalltalker alguna vez tiene su época de querer > > hacerse la VM, yo la pasé y si me distraigo un poco supongo que > > volveré a lo mismo, es como recurrente el tema. Coincido en que hacer > > algo que ande es relativamente sencillo y hacer algo que ande bien es > > extremadamente complejo. Además la problemática a resolver tiene poco > > que ver con Smalltalk (lo cual no lo hace menos divertido). Me parecen > > válidos todos los enfoques, desde los que arrancan del assembler mas > > crudo hasta los que se suben arriba de otra VM o lenguaje de alto > > nivel, cada uno en su lugar y contexto no deja de ser interesante. > > Entre las cosas que hoy le pediría a un VM es en que aumenten los > > límites en cantidad de objetos, que soporten 64 bits y algo que > > siempre quisiera tener es mucho mas control sobre el method lookup, > > que a mi entender es la principal limitación de Smalltalk. > > > Pero insisto en que sería bueno, que quienes saben del tema, alguna > > vez publiquen y/o hagan docencia sobre el tema, al menos a modo de > > memorias antes de retirarse. Creo que muchos pagaríamos gustosos un > > libro sobre eso, porque nos ahorraría tiempo en lo que igual queremos > > o vamos a hacer. Y además, difundir esto podría tener un efecto > > positivo y podría originar la aparición de mas alternativas que las > > que existen hoy, que son pocas. > > > Saludos y gracias por la información. > > > Diego Coronel > > > On Jul 26, 2:41 pm, Gerardo Richarte <[hidden email]> wrote: > >> excelente andres!!! > > >> espero que todo esto tambi n lo tengas en formato powerpoint :) > > >> ya sab s que a unos cuantos nos interesa, ponele una tonelada de > >> detalles t cnicos, y agregale una pizca de rant tambi n :) > >> listo! receta perfecta :) > > >> en un rato vuelvo a leer el mail y mando algunas preguntas tambi n > > >> saludos! > > > -- > > To post to this group, send email to [hidden email] > > To unsubscribe from this group, send email to [hidden email] > > >http://www.clubSmalltalk.org- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: RV: DNG-Win32 Bit VM
|
|
In reply to this post by Andres Valloud-5
Hola,
Respecto a los libros, no me he topado con ninguno de Smalltalk que me haya servido (no leí los tuyos), creo que escribir sobre Smalltalk es como una utopía muy loable pero tiene como un problema de fondo. A veces pueden ser interesantes esos libros por otro motivos, pero no veo que funcionen con la misma efectividad que los libros de lenguages de programación mas formales. Salvando las distancias, creo que es como intentar escribir un libro para aprender guitarra o jugar al tenis (que lo hay). No logro imaginarme cómo sería un buen libro de Smalltalk, por lo cual lo imagino que es un desafío muy interesante para todo aquel que se anime a escribirlo. Un libro sobre VMs creo que sería algo muy distinto, mas lleno de formalidades, de conocimiento muy específico, muy técnico. Acá creo que el desafío es saber mucho de lo que se está escribiendo, ya que hay tantos niveles de calidad para resolver una VM, que solo poca gente lo podría hacer bien. Parece lógico que te tomes el tiempo para sentirte seguro antes de arrancar, incluso cuando ya sepas muchisimo del tema. Y me agrada mucho saber que tenés pensado encarar ese tema a futuro, seré un agradecido mas por tener acceso a información de dificil acceso. Diego Coronel On Jul 26, 8:45 pm, Andres Valloud <[hidden email]> wrote: > Con respecto a los libros, mi experiencia es que hay un monton de > informacion en la gente que ya sabia mucho mas o menos en 1995, pero > que por la razon que quieras no escribieron al respecto. A mi gusto, > hay un vacio en la literatura de Smalltalk... o sea, abundan las > introducciones y libros para empezar con temas muy diversos, pero los > libros mas avanzados parecen escasear. Creo que es importante que > haya cosas escritas que te lleven mas alla de lo de todos los dias, me > parece que es un buen camino para ir desafiandose a uno mismo con > cosas cada vez mas dificiles. > > Espero estar haciendo un trabajo razonable para tapar el (que a mi > gusto es un) bache con lo que escribo. Eventualmente me pasare a > escribir libros acerca de VMs. Me parece que voy a escribir de eso > cuando sienta que lo que tenga para decir este maduro. Quiza el libro > de AGC este mas cerca, pero me gustaria terminar el segundo (y quiza > tercer) volumen de Fundamentals antes, y tambien otro libro acerca de > usos del patron de percepcion. Ya con eso me parece que puedo > escribir el libro de AGC mas tranquilo. Y despues de eso no se, > tendre que ver que escribo despues. > > Andres. > > 2010/7/26 [hidden email] <[hidden email]>: > > > > > Coincido con Gerardo, muy bueno el correo de Andrés, muchas gracias. > > Sería bueno que alguna vez alguien documentara o publicara algo acerca > > de VMs de calidad, hay poca gente que lo podría hacer bien, y ese > > material aportaría a la continuidad de Smalltalk como plataforma a > > largo plazo. Todo smalltalker alguna vez tiene su época de querer > > hacerse la VM, yo la pasé y si me distraigo un poco supongo que > > volveré a lo mismo, es como recurrente el tema. Coincido en que hacer > > algo que ande es relativamente sencillo y hacer algo que ande bien es > > extremadamente complejo. Además la problemática a resolver tiene poco > > que ver con Smalltalk (lo cual no lo hace menos divertido). Me parecen > > válidos todos los enfoques, desde los que arrancan del assembler mas > > crudo hasta los que se suben arriba de otra VM o lenguaje de alto > > nivel, cada uno en su lugar y contexto no deja de ser interesante. > > Entre las cosas que hoy le pediría a un VM es en que aumenten los > > límites en cantidad de objetos, que soporten 64 bits y algo que > > siempre quisiera tener es mucho mas control sobre el method lookup, > > que a mi entender es la principal limitación de Smalltalk. > > > Pero insisto en que sería bueno, que quienes saben del tema, alguna > > vez publiquen y/o hagan docencia sobre el tema, al menos a modo de > > memorias antes de retirarse. Creo que muchos pagaríamos gustosos un > > libro sobre eso, porque nos ahorraría tiempo en lo que igual queremos > > o vamos a hacer. Y además, difundir esto podría tener un efecto > > positivo y podría originar la aparición de mas alternativas que las > > que existen hoy, que son pocas. > > > Saludos y gracias por la información. > > > Diego Coronel > > > On Jul 26, 2:41 pm, Gerardo Richarte <[hidden email]> wrote: > >> excelente andres!!! > > >> espero que todo esto tambi n lo tengas en formato powerpoint :) > > >> ya sab s que a unos cuantos nos interesa, ponele una tonelada de > >> detalles t cnicos, y agregale una pizca de rant tambi n :) > >> listo! receta perfecta :) > > >> en un rato vuelvo a leer el mail y mando algunas preguntas tambi n > > >> saludos! > > > -- > > To post to this group, send email to [hidden email] > > To unsubscribe from this group, send email to [hidden email] > > >http://www.clubSmalltalk.org- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by dcoronel32@gmail.com
Me parece que la jerarquia de Stream no esta linda porque seguimos
usando la primera que se programo, basicamente. Nunca llegue a pensarlo del todo, pero a veces me parece que lo que hace falta es un Stream que tenga un read policy y un write policy, cosa de poder mezclar lo que quieras sin necesidad de pegotearlo antes de tiempo en una clase determinada... 2010/7/27 [hidden email] <[hidden email]>: > Hola Andrés > Contesto entre líneas... > > On Jul 26, 8:57 pm, Andres Valloud <[hidden email]> wrote: >> > Coincido en que hacer algo que ande es relativamente sencillo y hacer algo que ande bien es extremadamente complejo. >> >> Y si... tal cual. >> >> > Entre las cosas que hoy le pediría a un VM es en que aumenten los límites en cantidad de objetos, que soporten 64 bits >> >> No es por ser pretencioso, pero VisualWorks tiene VMs de 64 bits para >> Linux en x86, Solaris en x86, y Solaris en SPARC. Trabajamos mucho >> con las VMs y las imagenes de 64 bits en este tiempo, y las versiones >> que estan a punto de salir son muchisimo mejores que lo que teniamos >> hace unos años (esto no lo digo yo o nosotros (Cincom)... lo puso por >> escrito gente de GemStone en la lista de VisualWorks acerca de 7.7). >> >> Tambien estamos trabajando en un port a Windows 64 bits. Esto ultimo >> es mas dificil de lo que parece. Por ejemplo, al contrario de mas o >> menos todo el mundo, en Windows de 64 bits un long tiene 32 bits. Asi >> que si, digamos, tenes codigo multiplataforma que habla de longs todo >> el tiempo porque hasta ahora siempre (la VM de VisualWorks tiene cerca >> de 30 años encima) en 64 bits un long tenia 64 bits, y en 32 bits un >> long tenia 32 bits... hmmm... > Si, puedo imaginar a VW y Gemstone muy bien armados en todo eso, en mi > caso uso Dolphin o Squeak por motivos comerciales. > > > >> > y algo que siempre quisiera tener es mucho mas control sobre el method lookup, que a mi entender es la principal limitación de Smalltalk. >> >> Podrias contar mas de esto? Donde le ves la limitacion? Que te >> gustaria que hubiera pero no hay? > > Cuando envío un mensaje a un objeto, este busca en la clase, > superclases, etc. y ejectua el método. Toda esta convención es > invariable y define, sin posibilidad de modificar nada, cosas muy > importantes como la herencia y otras yerbas. Esta convención nos > parece bien a todos porque nos parece bien que si mando el mensaje > #print se ejecute el método #print, y también nos parece bien a todos > utilizar herencia simple, y también a casi todos nos parecen bien las > clases, metaclases y todo lo que defendemos desde la practicidad. Sin > embargo, no poder modificar esta convención, trae mas limitaciones de > las que generalmente pensamos (porque nos acostumbramos y nos gusta la > convención) y usualmente resolvemos de manera sucia y limitada. Son > conocidos los casos no muy bien resueltos con herencia simple (como la > jerarquia de Stream), son conocidos los trucos de usar #dnu para > activar métodos que no están presentes en la clase del receptor (como > en los proxies) y personalmente me molesta que esté conceptualmente > tan acoplado el método con el mensaje, dos cosas muy distintas. Una > solución que me suena factible, y tal vez compleja de implementar > decentemente, sería que el methodLookup estuviera implementado en > Smalltalk, en Object supongo. La implementación default podría ser una > primitiva que hiciera lo mismo que esperamos hoy en día, pero que al > modificarla en subclases nos abriera un campo de posibilidades muy > amplias y muy peligrosas (tan peligrosas como cualquier otra de > Smalltalk). Sería trivial implementar proxies, hacer delegaciones mas > sofisticadas y generar diseños hoy imposibles, de manera muy clara. > Por ejemplo, hoy es común ver que los proxies para persistencia en > bases de datos, o para sistemas distribuidos se hacen heredando de > ProtoObject, o de clases con pocos métodos, cosa que ya es sucia de > entrada, luego se agregan #dnu que son mas sucios. No sería mas > adecuado que la clase de un proxy fuera el misma que la del subject? > al menos parecida?, de esta manera se podrían delegar en el subject la > resolución de algunos métodos y en el proxy la resolución de otros, > podría incluso haber cooperación entre estos objetos. Esto es largo de > explicar, pero creo qeu se podría resolver mucho, programando poco, > mas claro y simple de debuggear. Otro ejemplo sería la herencia > múltiple, quedaría de una manera muy prolija, porque se podría acotar > a una parte muy pequeña del sistema, no estaría condicionada por otra > convención (como en c++), no tendría porqué tener que limitarse a > clases, podría ser entre objetos (como en la herencia de prototipos > que usaba en el NewtonScript de Apple). Es mas el polimorfismo se > ampliaría porque un objecto podría resolver mensajes que hoy no > entendería. Creo que también desaparecerían los intentos de solucionar > estos problemas mediante traits o cosas similares. Todo esto, tal vez > genere mas incertidumbre, pero creo que sería muy interesante TENERLO, > ir usándolo con mucho cuidado, y posiblemente aparezcan patterns que > mejoren sustancialmente las recetas actuales. Entiendo, no estoy > seguro, que las primeras versiones de la VM de Smalltalk tenían algo > similar y que luego se descartó por temas de perfomance, supongo que > 35 años mas tarde se podría tratar de resolver ese "problemita". > > Saludos > > Diego Coronel > >> Andres. >> >> 2010/7/26 [hidden email] <[hidden email]>: >> >> >> >> > Coincido con Gerardo, muy bueno el correo de Andrés, muchas gracias. >> > Sería bueno que alguna vez alguien documentara o publicara algo acerca >> > de VMs de calidad, hay poca gente que lo podría hacer bien, y ese >> > material aportaría a la continuidad de Smalltalk como plataforma a >> > largo plazo. Todo smalltalker alguna vez tiene su época de querer >> > hacerse la VM, yo la pasé y si me distraigo un poco supongo que >> > volveré a lo mismo, es como recurrente el tema. Coincido en que hacer >> > algo que ande es relativamente sencillo y hacer algo que ande bien es >> > extremadamente complejo. Además la problemática a resolver tiene poco >> > que ver con Smalltalk (lo cual no lo hace menos divertido). Me parecen >> > válidos todos los enfoques, desde los que arrancan del assembler mas >> > crudo hasta los que se suben arriba de otra VM o lenguaje de alto >> > nivel, cada uno en su lugar y contexto no deja de ser interesante. >> > Entre las cosas que hoy le pediría a un VM es en que aumenten los >> > límites en cantidad de objetos, que soporten 64 bits y algo que >> > siempre quisiera tener es mucho mas control sobre el method lookup, >> > que a mi entender es la principal limitación de Smalltalk. >> >> > Pero insisto en que sería bueno, que quienes saben del tema, alguna >> > vez publiquen y/o hagan docencia sobre el tema, al menos a modo de >> > memorias antes de retirarse. Creo que muchos pagaríamos gustosos un >> > libro sobre eso, porque nos ahorraría tiempo en lo que igual queremos >> > o vamos a hacer. Y además, difundir esto podría tener un efecto >> > positivo y podría originar la aparición de mas alternativas que las >> > que existen hoy, que son pocas. >> >> > Saludos y gracias por la información. >> >> > Diego Coronel >> >> > On Jul 26, 2:41 pm, Gerardo Richarte <[hidden email]> wrote: >> >> excelente andres!!! >> >> >> espero que todo esto tambi n lo tengas en formato powerpoint :) >> >> >> ya sab s que a unos cuantos nos interesa, ponele una tonelada de >> >> detalles t cnicos, y agregale una pizca de rant tambi n :) >> >> listo! receta perfecta :) >> >> >> en un rato vuelvo a leer el mail y mando algunas preguntas tambi n >> >> >> saludos! >> >> > -- >> > To post to this group, send email to [hidden email] >> > To unsubscribe from this group, send email to [hidden email] >> >> >http://www.clubSmalltalk.org- Hide quoted text - >> >> - Show quoted text - > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by dcoronel32@gmail.com
Hola gente!
Diego, veo que te interesa el dispatch de mensajes, y VMs... Hace un tiempo que no leo el tema que voy a sugerir, pero es un camino a explorar para conseguir una VM mas básica, sobre la que se puedan montar distintas estrategias de msg dispatch, herencia y mezclas de otras yerbas: http://msmvps.com/blogs/lopez/archive/2008/01/14/self-sustaining-systems-col a-pepsi-coke-y-mate.aspx Leer los paper de Piumarta. Mi propia implementacion parcial en .NET: http://ajlopez.wordpress.com/2009/01/25/presenting-ajsoda/ (faltan las imágenes... snif... sobrepase el bandwith del sitio donde las tengo, el 1ero de Agosto esta en línea de nuevo... :-) Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ http://twitter.com/ajlopez -----Mensaje original----- De: [hidden email] [mailto:[hidden email]] En nombre de [hidden email] Enviado el: martes, 27 de julio de 2010 17:32 Para: ClubSmalltalk Asunto: [clubSmalltalk] Re: RV: DNG-Win32 Bit VM Hola Andrés Contesto entre líneas... On Jul 26, 8:57 pm, Andres Valloud <[hidden email]> wrote: > > Coincido en que hacer algo que ande es relativamente sencillo y hacer algo que ande bien es extremadamente complejo. > > Y si... tal cual. > > > Entre las cosas que hoy le pediría a un VM es en que aumenten los límites en cantidad de objetos, que soporten 64 bits ... -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by dcoronel32@gmail.com
Diego, en realidad el method dictionary se puede modificar, y se pueden usar wrappers bastante sofisticados, como method wrappers o instance wrappers (con clases anónimas). Creo que vos te referís a tener reificado en Smalltalk el algoritmo de method lookup, cosa que sería muy interesante de ver como se resolvería (hay un problema de regresión infinita, ya que el propio algoritmo tendría que evaluarse utilizándose, algo loco..). Si esto se logra sería muy interesante para experimentar, pero no hay que subestimar el problema de performance que podría ocasionar.
Por otro lado, según entiendo, lo que vos decías es tener un modelo de prototipos y delegación como el de Self (de donde se influenció NewtonScript). Yo también creo que sería más natural partir de un esquema de ese tipo y luego agregarle el esquema de clasificación como el de Smalltalk, así podrías combinar ambos.
Pero creo que estos cambios implicarían un nuevo ambiente, ya no sería Smalltalk. Estaría muy bueno todo esto, pero por como están las cosas después de 35 años no creo que pase nada...
2010/7/27 [hidden email] <[hidden email]> Hola Andrés To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola a todos, El tema de performance es crítico, en mi caso hice una VM totalmente
nueva dentro de Dolphin, cambie totalmente la forma de ruteo de los mensajes. Esta nueva VM tiene Traits y otras yerbas relacionadas con UML y
creación de prototipos Web (usando AIDA), cosa que Dolphin no tiene. Pero como dice Gabriel te queda otro ambiente. Lo que hice es una clase UMLVirtualMachine que hace el lookup, obtengo
el método parseado (con mi propio algoritmo para poder usar Traits) y luego lo
ejecuto paso a paso todos los mensajes. El tema que esta nueva VM es más lenta que la de Dolphin. Además
hay que programar el Contexto de Ejecución, en mi caso mapeo los objetos vivos
con el método parseado, usando tres clases: ·
ExecutionSnapshot o
WorkspaceSnapshot o
MethodSnapshot Se puede, pero no sé si es aplicable en la práctica. En mi caso NO importa pq lo que hice es una ambiente de Simulación
UML, así que la performance NO es crítica, pero si lo vas usar en producción à no se cuan viable sea… Saludos, Bruno PD: Más allá de todo en el proceso aprendes pila, dado que te quedan
dos ambientes de objetos que se pueden comunicar. El tema de programar las primitivas es muy interesante… Si alguien le interesa el link: http://smalltalkuy.wordpress.com/ De:
[hidden email] [mailto:[hidden email]] En
nombre de Gabriel Brunstein Diego, en realidad el method dictionary se puede modificar,
y se pueden usar wrappers bastante sofisticados, como method wrappers o
instance wrappers (con clases anónimas). Creo que vos te referís a tener
reificado en Smalltalk el algoritmo de method lookup, cosa que sería muy
interesante de ver como se resolvería (hay un problema de regresión infinita,
ya que el propio algoritmo tendría que evaluarse utilizándose, algo
loco..). Si esto se logra sería muy interesante para experimentar, pero no hay
que subestimar el problema de performance que podría ocasionar. Por otro lado, según entiendo, lo que vos decías es tener un
modelo de prototipos y delegación como el de Self (de donde se influenció NewtonScript).
Yo también creo que sería más natural partir de un esquema de ese tipo y luego
agregarle el esquema de clasificación como el de Smalltalk, así podrías
combinar ambos. Pero creo que estos cambios implicarían un nuevo ambiente,
ya no sería Smalltalk. Estaría muy bueno todo esto, pero por como están las
cosas después de 35 años no creo que pase nada... 2010/7/27 [hidden email]
<[hidden email]> Hola Andrés
Si, puedo imaginar a VW y Gemstone muy bien armados en todo
eso, en mi
Cuando envío un mensaje a un objeto, este busca en la clase, > > >http://www.clubSmalltalk.org- Hide quoted text - To post to this group, send email to [hidden email] -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: RV: DNG-Win32 Bit VM
|
|
In reply to this post by Gaboto
Gabriel,
On Jul 27, 4:41 pm, Gabriel Brunstein <[hidden email]> wrote: > Diego, en realidad el method dictionary se puede modificar, y se pueden usar > wrappers bastante sofisticados, como method wrappers o instance wrappers > (con clases anónimas). Es que no se trataría solo de nombres sino del algorímo, como decís mas abajo. Creo que vos te referís a tener reificado en > Smalltalk el algoritmo de method lookup, cosa que sería muy interesante de > ver como se resolvería (hay un problema de regresión infinita, ya que el > propio algoritmo tendría que evaluarse utilizándose, algo loco..). No veo recursividad, fijate que el "override" de este método cambia solo la clase/subclase que definis, podés meterte en ese lío pero sería muy natural no hacerlo, lo que si hay un doble envío de mensajes en la primera implementación que se me ocurre. Pero con algún flag en la representación interna de los objetos esto se podría resolver. O sea, al menos parece simple pensar que las clases que no tengan "alterardo" esto, no sean mas lentas. Incluso se podrían tener algunas primitivas básicas con implementación clásicas de method lookups. Si esto > se logra sería muy interesante para experimentar, pero no hay que subestimar > el problema de performance que podría ocasionar. > Por otro lado, según entiendo, lo que vos decías es tener un modelo de > prototipos y delegación como el de Self (de donde se influenció > NewtonScript). Yo también creo que sería más natural partir de un esquema de > ese tipo y luego agregarle el esquema de clasificación como el de Smalltalk, > así podrías combinar ambos. No te sabría decir, a mi me gustan las clases, metaclases y todo lo que ya viene en Smalltalk, y creo que me gusta tal como está. No se cuánto valor tiene reducirlo conceptualmente y luego reconstruirlo, tal vez pueda ser. Sin embargo lo que te decía de herencia de prototipos no viene tanto por ahi, sino por tener la libertad de seleccionar distintas convenciones según me convenga. A cualquier smalltalker le resultaría loco (o sucio) enviarle el mensaje #color a una puerta que está dentro de un auto que es rojo, y obtener rojo. En casos esos recursos están bien y sirven. > Pero creo que estos cambios implicarían un nuevo ambiente, ya no sería > Smalltalk. Estaría muy bueno todo esto, pero por como están las cosas > después de 35 años no creo que pase nada... No lo veo como otro ambiente, es Smalltalk, hay objetos, mensajes y el 99% del image quedaría igual. No recuerdo quién ni cuándo, pero este tipo de cosas se hicieron hace no mucho tiempo. Saludos. Diego Coronel > 2010/7/27 [hidden email] <[hidden email]> > > > > > Hola Andrés > > Contesto entre líneas... > > > On Jul 26, 8:57 pm, Andres Valloud <[hidden email]> wrote: > > > > Coincido en que hacer algo que ande es relativamente sencillo y hacer > > algo que ande bien es extremadamente complejo. > > > > Y si... tal cual. > > > > > Entre las cosas que hoy le pediría a un VM es en que aumenten los > > límites en cantidad de objetos, que soporten 64 bits > > > > No es por ser pretencioso, pero VisualWorks tiene VMs de 64 bits para > > > Linux en x86, Solaris en x86, y Solaris en SPARC. Trabajamos mucho > > > con las VMs y las imagenes de 64 bits en este tiempo, y las versiones > > > que estan a punto de salir son muchisimo mejores que lo que teniamos > > > hace unos años (esto no lo digo yo o nosotros (Cincom)... lo puso por > > > escrito gente de GemStone en la lista de VisualWorks acerca de 7.7). > > > > Tambien estamos trabajando en un port a Windows 64 bits. Esto ultimo > > > es mas dificil de lo que parece. Por ejemplo, al contrario de mas o > > > menos todo el mundo, en Windows de 64 bits un long tiene 32 bits. Asi > > > que si, digamos, tenes codigo multiplataforma que habla de longs todo > > > el tiempo porque hasta ahora siempre (la VM de VisualWorks tiene cerca > > > de 30 años encima) en 64 bits un long tenia 64 bits, y en 32 bits un > > > long tenia 32 bits... hmmm... > > Si, puedo imaginar a VW y Gemstone muy bien armados en todo eso, en mi > > caso uso Dolphin o Squeak por motivos comerciales. > > > > > y algo que siempre quisiera tener es mucho mas control sobre el method > > lookup, que a mi entender es la principal limitación de Smalltalk. > > > > Podrias contar mas de esto? Donde le ves la limitacion? Que te > > > gustaria que hubiera pero no hay? > > > Cuando envío un mensaje a un objeto, este busca en la clase, > > superclases, etc. y ejectua el método. Toda esta convención es > > invariable y define, sin posibilidad de modificar nada, cosas muy > > importantes como la herencia y otras yerbas. Esta convención nos > > parece bien a todos porque nos parece bien que si mando el mensaje > > #print se ejecute el método #print, y también nos parece bien a todos > > utilizar herencia simple, y también a casi todos nos parecen bien las > > clases, metaclases y todo lo que defendemos desde la practicidad. Sin > > embargo, no poder modificar esta convención, trae mas limitaciones de > > las que generalmente pensamos (porque nos acostumbramos y nos gusta la > > convención) y usualmente resolvemos de manera sucia y limitada. Son > > conocidos los casos no muy bien resueltos con herencia simple (como la > > jerarquia de Stream), son conocidos los trucos de usar #dnu para > > activar métodos que no están presentes en la clase del receptor (como > > en los proxies) y personalmente me molesta que esté conceptualmente > > tan acoplado el método con el mensaje, dos cosas muy distintas. Una > > solución que me suena factible, y tal vez compleja de implementar > > decentemente, sería que el methodLookup estuviera implementado en > > Smalltalk, en Object supongo. La implementación default podría ser una > > primitiva que hiciera lo mismo que esperamos hoy en día, pero que al > > modificarla en subclases nos abriera un campo de posibilidades muy > > amplias y muy peligrosas (tan peligrosas como cualquier otra de > > Smalltalk). Sería trivial implementar proxies, hacer delegaciones mas > > sofisticadas y generar diseños hoy imposibles, de manera muy clara. > > Por ejemplo, hoy es común ver que los proxies para persistencia en > > bases de datos, o para sistemas distribuidos se hacen heredando de > > ProtoObject, o de clases con pocos métodos, cosa que ya es sucia de > > entrada, luego se agregan #dnu que son mas sucios. No sería mas > > adecuado que la clase de un proxy fuera el misma que la del subject? > > al menos parecida?, de esta manera se podrían delegar en el subject la > > resolución de algunos métodos y en el proxy la resolución de otros, > > podría incluso haber cooperación entre estos objetos. Esto es largo de > > explicar, pero creo qeu se podría resolver mucho, programando poco, > > mas claro y simple de debuggear. Otro ejemplo sería la herencia > > múltiple, quedaría de una manera muy prolija, porque se podría acotar > > a una parte muy pequeña del sistema, no estaría condicionada por otra > > convención (como en c++), no tendría porqué tener que limitarse a > > clases, podría ser entre objetos (como en la herencia de prototipos > > que usaba en el NewtonScript de Apple). Es mas el polimorfismo se > > ampliaría porque un objecto podría resolver mensajes que hoy no > > entendería. Creo que también desaparecerían los intentos de solucionar > > estos problemas mediante traits o cosas similares. Todo esto, tal vez > > genere mas incertidumbre, pero creo que sería muy interesante TENERLO, > > ir usándolo con mucho cuidado, y posiblemente aparezcan patterns que > > mejoren sustancialmente las recetas actuales. Entiendo, no estoy > > seguro, que las primeras versiones de la VM de Smalltalk tenían algo > > similar y que luego se descartó por temas de perfomance, supongo que > > 35 años mas tarde se podría tratar de resolver ese "problemita". > > > Saludos > > > Diego Coronel > > > > Andres. > > > > 2010/7/26 [hidden email] <[hidden email]>: > > > > > Coincido con Gerardo, muy bueno el correo de Andrés, muchas gracias. > > > > Sería bueno que alguna vez alguien documentara o publicara algo acerca > > > > de VMs de calidad, hay poca gente que lo podría hacer bien, y ese > > > > material aportaría a la continuidad de Smalltalk como plataforma a > > > > largo plazo. Todo smalltalker alguna vez tiene su época de querer > > > > hacerse la VM, yo la pasé y si me distraigo un poco supongo que > > > > volveré a lo mismo, es como recurrente el tema. Coincido en que hacer > > > > algo que ande es relativamente sencillo y hacer algo que ande bien es > > > > extremadamente complejo. Además la problemática a resolver tiene poco > > > > que ver con Smalltalk (lo cual no lo hace menos divertido). Me parecen > > > > válidos todos los enfoques, desde los que arrancan del assembler mas > > > > crudo hasta los que se suben arriba de otra VM o lenguaje de alto > > > > nivel, cada uno en su lugar y contexto no deja de ser interesante. > > > > Entre las cosas que hoy le pediría a un VM es en que aumenten los > > > > límites en cantidad de objetos, que soporten 64 bits y algo que > > > > siempre quisiera tener es mucho mas control sobre el method lookup, > > > > que a mi entender es la principal limitación de Smalltalk. > > > > > Pero insisto en que sería bueno, que quienes saben del tema, alguna > > > > vez publiquen y/o hagan docencia sobre el tema, al menos a modo de > > > > memorias antes de retirarse. Creo que muchos pagaríamos gustosos un > > > > libro sobre eso, porque nos ahorraría tiempo en lo que igual queremos > > > > o vamos a hacer. Y además, difundir esto podría tener un efecto > > > > positivo y podría originar la aparición de mas alternativas que las > > > > que existen hoy, que son pocas. > > > > > Saludos y gracias por la información. > > > > > Diego Coronel > > > > > On Jul 26, 2:41 pm, Gerardo Richarte <[hidden email]> wrote: > > > >> excelente andres!!! > > > > >> espero que todo esto tambi n lo tengas en formato powerpoint :) > > > > >> ya sab s que a unos cuantos nos interesa, ponele una tonelada de > > > >> detalles t cnicos, y agregale una pizca de rant tambi n :) > > > >> listo! receta perfecta :) > > > > >> en un rato vuelvo a leer el mail y mando algunas preguntas tambi n > > > > >> saludos! > > > > > -- > > > > To post to this group, send email to [hidden email] > > > > To unsubscribe from this group, send email to > > [hidden email]<clubSmalltalk%2Bunsubscribe@googlegroups.com> > > > > >http://www.clubSmalltalk.org-Hide quoted text - > > > > - Show quoted text - > > > -- > > To post to this group, send email to [hidden email] > > To unsubscribe from this group, send email to > > [hidden email]<clubSmalltalk%2Bunsubscribe@googlegroups.com> > > >http://www.clubSmalltalk.org- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by dcoronel32@gmail.com
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
James Robertson se la pasa haciendo screencasts...
2010/7/28 Jose Gregoris <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: RV: DNG-Win32 Bit VM
|
|
Kikote, sos un ídolo! Esteban A. Maringolo El 28 de julio de 2010 17:59, Jose Gregoris <[hidden email]> escribió:
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Jose Gregoris
La verdad de estos videos no tengo mucha idea porque en general no miro esas cosas. Lamento haberte mandado a mirar algo que no te sirvio. Ahora, que se yo, desarrollo dinamico... en su momento me grabe programando el concurso de Smalltalks 2008, y la verdad lo unico que se ve es a alguien que se la pasa escribiendo codigo... cada tanto una pausa para pensar algo o ir a mirar alguna cosa, y sigue la escritura...
No se, a mi me parece que lo mejor es pensar todo en la cabeza primero porque ahi se piensa mas rapido. A mi gusto, si te la pasas usando los botoncitos y las ventanitas y todo eso, es como estar usando el pagefile en vez de pensar con la cache... Andres. 2010/7/28 Jose Gregoris <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola:
Bueno es que los videos de Andy Bower estan buenos porque justo muestran la programación (y cambio) mientras el programa esta ejecutando. Es una pabada pero para alguien que labura en un ambiente no dinamico por ahi llama la atencion.
Para quienes no lo vieron es algo como el ejemplo del autito de Squeak pero sin usar etoys, programando en Smalltalk con lo que uno puede ver tambien como se usan browsers, senders, implementors y como se programa desde el debugger usando mensajes que aún no han sido implementados...
Saludos GallegO
-- El 28 de julio de 2010 18:31, Andres Valloud <[hidden email]> escribió: La verdad de estos videos no tengo mucha idea porque en general no miro esas cosas. Lamento haberte mandado a mirar algo que no te sirvio. Ahora, que se yo, desarrollo dinamico... en su momento me grabe programando el concurso de Smalltalks 2008, y la verdad lo unico que se ve es a alguien que se la pasa escribiendo codigo... cada tanto una pausa para pensar algo o ir a mirar alguna cosa, y sigue la escritura... To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
El 28 de julio de 2010 18:31, Andres Valloud <[hidden email]> escribió: La verdad de estos videos no tengo mucha idea porque en general no miro esas cosas. Lamento haberte mandado a mirar algo que no te sirvio. Ahora, que se yo, desarrollo dinamico... en su momento me grabe programando el concurso de Smalltalks 2008, y la verdad lo unico que se ve es a alguien que se la pasa escribiendo codigo... cada tanto una pausa para pensar algo o ir a mirar alguna cosa, y sigue la escritura... Muy interesante todo el thread, y ahora que derivó para este asunto, me sumo a esta opinión, con mi 2 centavitos. A mi también me resulta más cómodo pensar bastante primero, y realmente cuando uno escribe, hay que ver a qué se llama "desarrollo dinámico", ya que podrían existir varias interpretaciones. Una de ellas es ir usando objetos que aún no definimos, e ir trabajando en el debugger....esta es una práctica que me parece particularmente piola y que uso bastante [1]. Pero, por supuesto, no se aplica al 100% de las situaciones. Saludos. [1] Ver libro "Programando con Smalltalk" de Diego Gómez Deck: http://diegogomezdeck.blogspot.com/2006/02/libro-programando-con-smalltalk.html. -- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com ================================================= -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Jaja, no pasa nada, como me voy a ofender tan facil :)...
2010/7/29 Jose Gregoris <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Sebastian Calvo
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Jaja... pense que te habías olvidado, pero si estamos con mucho laburo!
El 31 de julio de 2010 11:11, Jose Gregoris <[hidden email]> escribió:
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |