RV: DNG-Win32 Bit VM

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
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

Hola Hernán, una pregunta, esto lo implementaron o es un trabajo
teórico? (de cualquier manera me parece muy interesante)

Diego

On Aug 2, 7:36 am, Hernan Wilkinson <[hidden email]>
wrote:

> Alejandra De Bonnis es su tesis de licenciatura reifico el method lookup de
> tal manera que cada objeto podía definir cómo buscar un método a partir de
> un mensaje. De esta manera teníamos en el mismo ambiente prototipos y clases
> por ejemplo. Haciendo esto usar dnu o method wrappers, etc. dejó de tener
> sentido... imaginense, cada OBJETO puede definir que hacer cuando recibe un
> mensaje (delegarlo, buscar su método, tomarlo prestado, etc).
> Como dice Gaby, el problema de la regresión existió pero lo resolvirmos
> fácil jeje... o sea, los objetos que se usaban para reificar el method
> lookup no podía reificar su method lookup jeje, pero igual había que
> trabajar un poco más en cómo estaba implementado.
> A mi entender fue un trabajo muy pero muy interesante, lástima que como
> muchas cosas quedó ahí muerto por falta de tiempo para investigar, guita
> para invertir, etc.
> En fin, si alguien tiene ganas de verlo avise
>
> Hernán.
>

> 2010/7/27 Gabriel Brunstein <[hidden email]>

>
>
>
> > 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
> >> 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
>

> ...
>
> read more »- 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