Smalltalk › Español (Spanish)

RV: DNG-Win32 Bit VM

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

69 messages Options

1234

Diogenes Moreira

Re: RV: DNG-Win32 Bit VM

2010/6/25 GallegO <[hidden email]>

Bueno, pero la mejora del lado del server sería una perfomance
superior sobre 2.8 según dicen los Seasiders no?
Vos lo pudiste verificar?

Mira en la opción 3.0 con continuation de 2.8.. la performance es mas o menos la misma... no tiene grandes diferencias..

Por otro lado creo que tendrias una ventaja importante al construir
sobre Seaside 3.0 por si más adelante querés migrar.

Si eso si es una ventaja. listo tengo para entretenerme el fin de semana y terminar :)

Entonces te quedo funcionando con full continuations o medio rengo? No
entendi bien lo del jquery...

El tema es el siguiente, no tiene mucho que ver con seaside en si, sino con lo que esta arriba. la implementacion de mucho de los componentes que hay hoy en la integación Scriptacoulus-JQuery para seaside 2.8.. usan clases que viene de tienen dependencias con la integracion prototype-scriptacolous. En la implementacion de los componentes de javascript que esta incluida en seaside 3.0, esa dependencia no existe mas. esta mas prolijo, y deja las cosas limpitas para anexar nuevos componetes de JQuery y JQuery-ui al framework... y las soluciones programarlas en Smalltalk :).

Esteba Lorenzano hizo algo que se llaman Dynamic Componentes que exploran este concepto (estan hechos para squeak y pharo). Me los DC esta en desarrollo..y se van extendiendo como va haciendo falta. Creo que los voy a tener que portar a dophin, para el proyecto que estoy desarrollando ahora.

Saludos

Saludos

El día 25 de junio de 2010 16:27, Diogenes Moreira

<[hidden email]> escribió:
> Mira, empece ese camino, pero quedo un SS 2.8 con el jquery en render..., lo
> bueno es que no que dependiendo de prototype, de lado de cliente.... pero no
> hay ninguna mejora, del lado del Server..
> Para eso esperemos que a NG :).
> Saludos
> 2010/6/25 GallegO <[hidden email]>
>>
>> Diogenes:
>>
>> Una opcion que no probe pero podria andar es volver la parte de
>> rendering (el ciclo) de Seaside 3.0 a como es en 2.8.
>> No deberia ser un gran cambio, el tema es que es dificil ver donde
>> afecta. Para eso tenemos los tests. La verdad que ando con poco tiempo
>> y no pude darle un vistazo.
>>
>> SAludos
>>
>> El día 25 de junio de 2010 14:24, Diogenes Moreira
>> <[hidden email]> escribió:
>> >
>> >
>> > 2010/6/25 Guillermo Schwarz <[hidden email]>
>> >>
>> >>
>> >> 2010/6/24 Diogenes Moreira <[hidden email]>
>> >>>
>> >>> Guillermo alguno de comentarios entre linea.. lo hago así para que no
>> >>> sea
>> >>> una prosa interminadbles
>> >>>
>> >>>
>> >>> 2010/6/24 Mariano Martinez Peck <[hidden email]>
>> >>>>
>> >>>>
>> >>>> 2010/6/24 Guillermo Schwarz <[hidden email]>
>> >>>>>
>> >>>>> Diogenes,
>> >>>>>
>> >>>>> Si no me equivoco "raificar los procesos" se refiere a que los
>> >>>>> procesos
>> >>>>> sean objetos, no que echen raices. Eso porque en Inglés "to reify"
>> >>>>> es volver
>> >>>>> concreto lo abstracto, más como un error conceptual (u ontológico si
>> >>>>> prefieres) ya que en folosofía se asume que volver concreto lo
>> >>>>> abstracto es
>> >>>>> sinòmimo de equivocarse, pero en computación no sólo es aceptado
>> >>>>> sino que
>> >>>>> produce resultados bastante interesantes, como lo que se pretende
>> >>>>> que es
>> >>>>> hacer que los procesos sean más fáciles de manipular.
>> >>>>> http://www.merriam-webster.com/dictionary/reify Pensé que esto
>> >>>>> Smalltalk ya
>> >>>>> lo tenía.
>> >>>
>> >>> Dolphin 6, no tiene una completa raificación de los procesos y el
>> >>> context. Otros dialectos Si. terminas instanciando un "Debugger"
>> >>> Dolphin
>> >>> tiene un monton de cosas buenas pero precisamente en esto esta flojo.
>> >>> Es
>> >>> mas, si ves la implementacion de los continuarions en seaside 2.8 para
>> >>> dolphin para poder operar desde el contexto.
>> >>
>> >> Nice. Me gustarìa mirarlo, pero imagino que el còdigo no serà
>> >> precisamente
>> >> bonito.
>> >> En Smalltalk existe thisContext que es una pseudovariable similar a
>> >> self y
>> >> super, pero que da acceso al bloque en ejecución, lo que en mi opinión
>> >> es
>> >> increíble limpio. Supongo que te refieres a que guarda thisContext en
>> >> un
>> >> stream como dicen por ahi (supongo que se refieren a un String) y luego
>> >> lo
>> >> recuperan y le dicen "sigue ejecutando".
>> >> En Smalltalk existe la idea de que un proceso es un objeto y vice
>> >> versa.
>> >> Por eso se puede pasar una "computación" a ejecutar de manera
>> >> postergada
>> >> (delayed evaluation), lo que en lenguajes funcionales se conoce como
>> >> lazy
>> >> evaluation pero es más automático y lo más parecido en Lisp sería una
>> >> expresión lambda.
>> >
>> > Si yo me refiero a al context que vos decis, pero particularmente en
>> > Dolphin
>> > el thisContext, lo mismo que el Sender, solo es un puntero para ser
>> > usado
>> > con otros objectos, y mucho del context no esta raificado. Es por eso
>> > que se
>> > no hace muy dificil implementar los partials continuations, para Seaside
>> > 3.0..(intente hacerlo basandome en lo que habia avanzado en
>> > infoil http://www.infoil.com.ar/seaside/, pero quede a media agua.. y me
>> > quedo algo raro, así decidi volver a Seaside 2.8. ).
>> > Otros Smalltalk como Pharo o VW tiene esto resuelto mas OO. Esperemos
>> > que
>> > Dolphin NG tenga esto raificado.
>> > Dolphin tiene muchas otras cosas muy buenas.
>> > Saludos
>> >
>> >>>>>
>> >>>>> Eso de los continuations lo entiendo. Es lo mismo que lo anterior.
>> >>>>> Le
>> >>>>> dices a un proceso que pare y que siga después en el punto en que
>> >>>>> paró. Eso
>> >>>>> en Smalltalk lo tienes con yield y continue si no me equivoco.
>> >>>
>> >>>
>> >>> No es eso.. es dado un proceso y su contexto (incluyendo todos los
>> >>> objectos), modelar un punto de ejecución el cual puede ser enviado a
>> >>> otro
>> >>> objecto, para su posterior ejecución .
>> >>
>> >> Y sí a eso me refería. Con yield puedes detener la ejecución, luego
>> >> agarras thisContext, empaquetas ese objeto (bloque) a medio ejecutar y
>> >> cuando lo desempaquetas le dices "continue".
>> >>
>> >> Obviamente debe ser más complicado que eso porque el thread (o tarea)
>> >> actual no puede empaquetarse a sí mismo, o tal vez sí... ;-)
>> >>
>> >>>
>> >>> La potencialidad de esto es mucha. sino mira la utilización de Seaside
>> >>> de
>> >>> los continuations para generar su propio lenguaje de dominio.
>> >>
>> >> La verdad es que no me imagino buceando por seaside para ver dònde
>> >> encuentro eso. Podrìas dar un ejemplo conciso?
>> >>>
>> >>> No quiero repetir los link, pero digamos que vengo con una ejecución,
>> >>> y
>> >>> ahi le pido al proceso que me diga lo que esta haciendo, de tal manera
>> >>> que
>> >>> puede continuar con lo que esta haciendo en otro momento el u otro.
>> >>> Esta muy
>> >>> lejos de un yield. Estamos hablando de los procesos conceptialmente y
>> >>> no
>> >>> como un thread que este ejecutandose en ese momento en el ambiente.
>> >>>
>> >>>>>
>> >>>>> Eso de los partial continuations, ¿de qué se trata? Acá dice que
>> >>>>> guardamos sólo parte de la computación que llevamos calculando...
>> >>>>>
>> >>>>> http://double.co.nz/scheme/partial-continuations/partial-continuations.html
>> >>>>> ... eso me suena a increíblemente complicado de programar.
>> >>>>>
>> >>>> t
>> >>>
>> >>> Mira como mucho en OOP tiene una base compleja para que el framework
>> >>> haga
>> >>> el trabajo. El uso de cache y proxy en glorp es muy complejo, pero vos
>> >>> programar que usas el framework te abstraes de todo ese kilombo y
>> >>> solamente
>> >>> lo usas y listo.
>> >>>
>> >>>>
>> >>>> Yo tenía este link que me parece bastante bueno:
>> >>>>
>> >>>> http://blog.fitzell.ca/2009/01/seaside-partial-continuations.html
>> >>>>
>> >>>> saludos
>> >>>>
>> >>>> mariano
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> En general prefiero las abstracciones que simplifican el problema,
>> >>>>> no
>> >>>>> aquellas que agregan un grado de complejidad mayor (como los threads
>> >>>>> en
>> >>>>> Java). Mira "la Quinta Disciplina" de Peter Senge, ahí dice que el
>> >>>>> problema
>> >>>>> de las organizaciones es que ante problemas complejos desarrollan
>> >>>>> soluciones
>> >>>>> complejas, de modo que las soluciones se vuelven parte del problema
>> >>>>> porque
>> >>>>> agregan complejidad en vez de reducirla.
>> >>>>>
>> >>>>> Es lo mismo que dice la gente de Smalltalk (aunque al parecer no
>> >>>>> toda
>> >>>>> ;-) respecto de que no se debe agregar comportamiento, sino dejar
>> >>>>> que el
>> >>>>> comportamiento "emerja", aunque es una versión más sutil (detallada)
>> >>>>> en mi
>> >>>>> opinión.
>> >>>>>
>> >>> Si esto es completamente cierto y creo que no estas teniendo total
>> >>> dimensión de mi comentario. Yo no estoy diciendo hacer mas complejo al
>> >>> proceso, sino que lo que estoy diciendo, dame acceso a comportamiento
>> >>> que
>> >>> este momento esta atras de un puntero y que es inaccesible atras de
>> >>> primitivas.
>> >>>
>> >>> Hay veces que solo te alcanza con un fork, otras veces no.
>> >>>
>> >>> Igual te comparto algo con la mejor onda, hubo un antes y un después
>> >>> en
>> >>> mi vida de programador, cuando entendí las cosas que podes hacer con
>> >>> la meta
>> >>> programación.. el código que mucho mas simple.
>> >>>
>> >>> Saludos
>> >>>
>> >>>>>
>> >>>>> Saludos,
>> >>>>> Guillermo.
>> >>>>>
>> >>>>> 2010/6/23 Diogenes Moreira <[hidden email]>
>> >>>>>>
>> >>>>>> Esperemos que tenga raificados los procesos y soporte los partial
>> >>>>>> continuations :).
>> >>>>>>
>> >>>>>> Con respecto a que tiene mejor Dolphin que Pharo..
>> >>>>>>
>> >>>>>> Siendo impartial... el grano en el o.. de pharo al igual que de
>> >>>>>> squeak, es Morphic esta hecho con los pies, hay mucho que laburar
>> >>>>>> para que
>> >>>>>> el ambiente tenga algo decente.. Morphic 3(Grande Juan) esta mucho
>> >>>>>> mejor,
>> >>>>>> pero todavía no esta es la base de las imagen core... despues la VM
>> >>>>>> es
>> >>>>>> bastante rebusta.
>> >>>>>>
>> >>>>>> Tiene otras cosas, pero de a poco se van mejorando.
>> >>>>>>
>> >>>>>> Por su parte Dolphin y MVP, para aplicaciones clientes esta muy
>> >>>>>> bueno,
>> >>>>>> es de lo mejorsito que he visto
>> >>>>>>
>> >>>>>> Ahora hacer una comparación de un proyecto Open Source, vs un
>> >>>>>> smalltalk licenciado.. es medio comparar chancho con batatas..
>> >>>>>>
>> >>>>>> DNG viene a darle vida a un base instalada muy grande, del dolphin
>> >>>>>> actual. Por ejemplo donde laburo tenemos un producto hecho en
>> >>>>>> dolphin y ya
>> >>>>>> estaba viendo con cariño una migración de dialecto. Espero que no
>> >>>>>> haga
>> >>>>>> falta.
>> >>>>>>
>> >>>>>> Pregunta alguien sabe si es multiplataforma o va ser windows
>> >>>>>> only???
>> >>>>>>
>> >>>>>> Saludos.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Jun 23, 2010 at 11:00 PM, Esteban A. Maringolo
>> >>>>>> <[hidden email]> wrote:
>> >>>>>>>
>> >>>>>>> 2010/6/23 Guillermo Schwarz <[hidden email]>
>> >>>>>>> >
>> >>>>>>> > ¿Qué ventaja tiene sobre Pharo?
>> >>>>>>>
>> >>>>>>> Lo tiene a Reimondo en el equipo.
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> 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
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Saludos cordiales,
>> >>>>>
>> >>>>> Guillermo Schwarz
>> >>>>> Sun Certified Enterprise Architect
>> >>>>>
>> >>>>> --
>> >>>>> 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
>> >>>
>> >>> --
>> >>> To post to this group, send email to [hidden email]
>> >>> To unsubscribe from this group, send email to
>> >>> [hidden email]
>> >>>
>> >>> http://www.clubSmalltalk.org
>> >>
>> >>
>> >> --
>> >> Saludos cordiales,
>> >>
>> >> Guillermo Schwarz
>> >> Sun Certified Enterprise Architect
>> >>
>> >> --
>> >> 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
>>
>> --
>> 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

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

leodm

RE: RV: DNG-Win32 Bit VM

In reply to this post by Esteban A. Maringolo

Guenas...
la verdad hace mucho que no ando chusmeando el mundo smalltalk tradicional y
no conocia a pharo :) ahí me lo estoy bajando.

Igualmente sumo a lo que dice Esteban, lo mas importante desde mi punto de
vista, que no creo que tenga ni Pharo ni ningun otro
es que esta hecho por dos grandes smalltalkers que algunos quizas mas viejos
en la industria es una especie de
certificado de calidad asegurada, como es tener una VM de Frank y un soporte
para VSE de uno de los expertos nro 1 en ese ambiente,
como lo es Alejandro. Mas alla de eso la VM tiene estas caracteristicas:
http://www.dng.st/dngwin32_vm.htm

conociendolo a Frank y Alejandro, no dudaria en decir que estamos ante un
producto turbovolcanico! jajaja

Igualemente habra que esperar a que empieze a rodar y ver como va, tiene
algunas caracteristicas que a mi entender hay que tener en cuenta:
-Tiene un framework para .net que lo hace muy interesante para los que
interactuen (o tengan que hacerlo) con .net
-Tiene compatibilidad nativa con VSE y Dolphin, para algunos esto es
fundamental
-La VM es hasta 4 veces mas rapida que la de VS y tiene muchas mejoras
respecto de esa vm (soporte nativo unicode y multithred entre ellos)
-Esta en manos de smalltalkers! (esto a mi me parece fundamental)

Saludos,
Leo

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre de Esteban A.
> Maringolo
> Enviado el: miércoles, 23 de junio de 2010 11:01 p.m.
> Para: [hidden email]
> Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM
>
> 2010/6/23 Guillermo Schwarz <[hidden email]>
> >
> > ¿Qué ventaja tiene sobre Pharo?
>
> Lo tiene a Reimondo en el equipo.
>
> --
> 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

Sebastian Calvo

Re: RV: DNG-Win32 Bit VM

Hola:

A mi me pareceria fundamental que tambien pueda usarse para Dolphin y
no solo un eslogan :)
Espero que algun día esto se haga realidad y si es posible dentro de
un rango de precios cercano al de Dolphin.

Suena raro que en la lista de Dolphin no se hable casi nada de DNG.

Saludos
GallegO

El día 30 de junio de 2010 12:39, Leo De Marco <[hidden email]> escribió:

> Guenas...
> la verdad hace mucho que no ando chusmeando el mundo smalltalk tradicional y
> no conocia a pharo :) ahí me lo estoy bajando.
>
> Igualmente sumo a lo que dice Esteban, lo mas importante desde mi punto de
> vista, que no creo que tenga ni Pharo ni ningun otro
> es que esta hecho por dos grandes smalltalkers que algunos quizas mas viejos
> en la industria es una especie de
> certificado de calidad asegurada, como es tener una VM de Frank y un soporte
> para VSE de uno de los expertos nro 1 en ese ambiente,
> como lo es Alejandro. Mas alla de eso la VM tiene estas caracteristicas:
> http://www.dng.st/dngwin32_vm.htm
>
> conociendolo a Frank y Alejandro, no dudaria en decir que estamos ante un
> producto turbovolcanico! jajaja
>
> Igualemente habra que esperar a que empieze a rodar y ver como va, tiene
> algunas caracteristicas que a mi entender hay que tener en cuenta:
> -Tiene un framework para .net que lo hace muy interesante para los que
> interactuen (o tengan que hacerlo) con .net
> -Tiene compatibilidad nativa con VSE y Dolphin, para algunos esto es
> fundamental
> -La VM es hasta 4 veces mas rapida que la de VS y tiene muchas mejoras
> respecto de esa vm (soporte nativo unicode y multithred entre ellos)
> -Esta en manos de smalltalkers! (esto a mi me parece fundamental)
>
> Saludos,
> Leo
>
>> -----Mensaje original-----
>> De: [hidden email]
>> [mailto:[hidden email]] En nombre de Esteban A.
>> Maringolo
>> Enviado el: miércoles, 23 de junio de 2010 11:01 p.m.
>> Para: [hidden email]
>> Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM
>>
>> 2010/6/23 Guillermo Schwarz <[hidden email]>
>> >
>> > ¿Qué ventaja tiene sobre Pharo?
>>
>> Lo tiene a Reimondo en el equipo.
>>
>> --
>> 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

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Angel "Java" Lopez

RE: RV: DNG-Win32 Bit VM

In reply to this post by leodm

Hola gente!

Disculpen, no encontré el email de Leo... semi offtopic, mensaje para Leo:

Jeje... vos por que no vista AjTalk... :-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]]
En nombre de Leo De Marco
Enviado el: miércoles, 30 de junio de 2010 12:40
Para: [hidden email]
Asunto: RE: [clubSmalltalk] RV: DNG-Win32 Bit VM

Guenas...
la verdad hace mucho que no ando chusmeando el mundo smalltalk tradicional y
no conocia a pharo :) ahí me lo estoy bajando.

Igualmente sumo a lo que dice Esteban, lo mas importante desde mi punto de
vista, que no creo que tenga ni Pharo ni ningun otro
es que esta hecho por dos grandes smalltalkers que algunos quizas mas viejos
en la industria es una especie de
certificado de calidad asegurada, como es tener una VM de Frank y un soporte
para VSE de uno de los expertos nro 1 en ese ambiente,
como lo es Alejandro. Mas alla de eso la VM tiene estas caracteristicas:
http://www.dng.st/dngwin32_vm.htm

conociendolo a Frank y Alejandro, no dudaria en decir que estamos ante un
producto turbovolcanico! jajaja

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Gerardo Richarte

Re: RV: DNG-Win32 Bit VM

In reply to this post by Diogenes Moreira

On 06/24/2010 12:34 AM, Diogenes Moreira wrote:

Esperemos que tenga raificados los procesos y soporte los partial continuations :).

En Digitalk Visual Smalltalk no están reíficados los procesos, pero está todo lo necesario para poder hacerlo, incluso para poder implentar Continuations desde Smalltalk. Acá hay un paper del año pasado donde está explicado todo eso:

Process Frames.pdf

y ya que estamos, acá hay otro explicando un poco los Bytecodes de la VM:

Digitalk Bytecodes.pdf

Prepárence para este Smalltalks 2010, jeje
richie

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Gerardo Richarte

Re: RV: DNG-Win32 Bit VM

In reply to this post by Esteban A. Maringolo

On 06/24/2010 09:30 AM, Esteban A. Maringolo wrote:
> De hecho en lo que se preocuparon mucho, al parecer, fue en que la VM
> de DNG corra VSE sin modificar nada.
>
eso era al principio de esta vm, y era bit compatible con la de VS
(delta algunos bugs). Pero al final cambiaron de rumbo y se asociaron
con Dolphin, y se volcaron a hacerla compatible con Dolphin (creo que
bit compatible, pero no estoy seguro). Y para VS ahora creo que no es
más bit compatible, si no que tenés que portar tu aplicación. Aunque
aparentemente es muy fácil de hacer porque te dan un pack de
portabilidad, o algo así

richie

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

leodm

RE: RV: DNG-Win32 Bit VM

Asi es, existe una especie de migrador que levanta tu "vieja" aplicación
hecha en VS.
Pero en varias pruebas grandes aplicaciones en VS han levantado en el primer
intento,
pero por supuesto hay un laburo minimo de migracion. Creo que la eleccion de
Dolphin
fue acertada ya que en muchas cosas es superior a VS (lo cual es obvio de
acuerdo a
su concepcion mas moderna). Lo lindo es que no se pelean, tiene lo mejor de
cada uno
+ una VM enfierrada jajaja.

Saludos,
Leo

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre de Gerardo Richarte
> Enviado el: jueves, 01 de julio de 2010 01:38 a.m.
> Para: [hidden email]
> Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM
>
> On 06/24/2010 09:30 AM, Esteban A. Maringolo wrote:
> > De hecho en lo que se preocuparon mucho, al parecer, fue en que la VM
> > de DNG corra VSE sin modificar nada.
> >
> eso era al principio de esta vm, y era bit compatible con la de VS
> (delta algunos bugs). Pero al final cambiaron de rumbo y se asociaron
> con Dolphin, y se volcaron a hacerla compatible con Dolphin (creo que
> bit compatible, pero no estoy seguro). Y para VS ahora creo que no es
> más bit compatible, si no que tenés que portar tu aplicación. Aunque
> aparentemente es muy fácil de hacer porque te dan un pack de
> portabilidad, o algo así
>
> richie
>
> --
> 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

leodm

RE: RV: DNG-Win32 Bit VM

In reply to this post by Angel "Java" Lopez

Angel! como va???

El AjTalk lo conozco en sus tripas, incluso vi su codigo en tu portatil jaja
cuando vamos a poder probarlo??

Saludos,
Leo

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre de Angel "Java" Lopez
> Enviado el: miércoles, 30 de junio de 2010 01:18 p.m.
> Para: [hidden email]
> Asunto: RE: [clubSmalltalk] RV: DNG-Win32 Bit VM
>
> Hola gente!
>
> Disculpen, no encontré el email de Leo... semi offtopic, mensaje para
> Leo:
>
> Jeje... vos por que no vista AjTalk... :-)
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com/
> http://twitter.com/ajlopez
>
> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]]
> En nombre de Leo De Marco
> Enviado el: miércoles, 30 de junio de 2010 12:40
> Para: [hidden email]
> Asunto: RE: [clubSmalltalk] RV: DNG-Win32 Bit VM
>
> Guenas...
> la verdad hace mucho que no ando chusmeando el mundo smalltalk
> tradicional y
> no conocia a pharo :) ahí me lo estoy bajando.
>
> Igualmente sumo a lo que dice Esteban, lo mas importante desde mi punto
> de
> vista, que no creo que tenga ni Pharo ni ningun otro
> es que esta hecho por dos grandes smalltalkers que algunos quizas mas
> viejos
> en la industria es una especie de
> certificado de calidad asegurada, como es tener una VM de Frank y un
> soporte
> para VSE de uno de los expertos nro 1 en ese ambiente,
> como lo es Alejandro. Mas alla de eso la VM tiene estas
> caracteristicas:
> http://www.dng.st/dngwin32_vm.htm
>
> conociendolo a Frank y Alejandro, no dudaria en decir que estamos ante
> un
> producto turbovolcanico! jajaja
>
>
> --
> 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

Angel "Java" Lopez

RE: RV: DNG-Win32 Bit VM

Hola gente!

Leo, siempre esta disponible para probar, aunque esta verdisimo:
http://code.google.com/p/ajtalk/

Por ahora es interprete. Podria generar en algun momento código MSIL, o usar
DLR (Dynamic Language Runtime), o generar código .NET o Java, pero primero
lo primero: completar el interprete, que insisto, es un toy todavía. Lo
largo es escribir una librería de clases base. Mi motivación es, no obtener
un entorno grafico, sino usarlo desde cualquier lenguaje .NET por ahora,
como librería, e implementar objetos distribuidos.

Armado con TDD, creo que tiene buen code coverage.

Tendria que escribir un post actualizado, por ahora, escribi "para vos" el
anio pasado:
http://ajlopez.wordpress.com/category/ajtalk/
(espero por lo menos que dejes ahí comentario, o envíes un RT por twitter...
:-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]]
En nombre de Leo De Marco
Enviado el: jueves, 08 de julio de 2010 11:02
Para: [hidden email]
Asunto: RE: [clubSmalltalk] RV: DNG-Win32 Bit VM

Angel! como va???

El AjTalk lo conozco en sus tripas, incluso vi su codigo en tu portatil jaja
cuando vamos a poder probarlo??

Saludos,
Leo

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to
[hidden email]

http://www.clubSmalltalk.org
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.439 / Virus Database: 271.1.1/2989 - Release Date: 07/08/10
06:36:00

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Andres Valloud-5

Re: RV: DNG-Win32 Bit VM

In reply to this post by leodm

Gente, acuerdense que ejecutar bytecodes es solo una pequeña parte de
lo que hace una VM. Ademas de eso, hay un mundo de otras cosas que
tambien tienen que funcionar. No todo es el benchmark nfib o similar.

2010/6/30 Leo De Marco <[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

Angel "Java" Lopez

RE: RV: DNG-Win32 Bit VM

Hola gente!

Andres, interesante... Podrias enumerar por aquí una lista de lo que hace
una VM? Hace unos meses se planteo el tema en la lista de Smalltalk
Research, pero seria interesante plantear el tema por aca, y conocer tu
posición.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]]
En nombre de Andres Valloud
Enviado el: viernes, 23 de julio de 2010 21:29
Para: [hidden email]
Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM

Gente, acuerdense que ejecutar bytecodes es solo una pequeña parte de
lo que hace una VM. Ademas de eso, hay un mundo de otras cosas que
tambien tienen que funcionar. No todo es el benchmark nfib o similar.

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Gerardo Richarte

Re: RV: DNG-Win32 Bit VM

On 07/26/2010 09:25 AM, Angel "Java" Lopez wrote:
> Andres, interesante... Podrias enumerar por aquí una lista de lo que hace
> una VM?
>
che, a mi también me interesa mucho la verdad, ya a esta idea nos fuimos
armando una idea, pero estaría bueno escuchar tu opinion. Para mi en
este momento, con toda la experiencia que ganaste en estos años siendo
el que está a cargo [una] de las VM de Smalltalk más usadas [la de VW]
tu palabra vale mucho.

Yo tiro algo, veamos:

. Bytecode execution engine (interprete y/o JIT)
. primitives
. garbage collection
. method lookup
. FFI
. Process scheduler (?)
. Callback mechanism (?)

a ver?
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

Andres Valloud-5

Re: RV: DNG-Win32 Bit VM

Antes de laburar en esto, tenia una idea bastante ingenua. Pensaba
que "VM" queria decir "ejecutar bytecodes y todas las optimizaciones
que tienen que ver con eso" y nada mas. Grave error...

Por ejemplo, si, hay que programar primitivas, pero no son todas
iguales. Por ejemplo, tenes cosas como identityHash, basicAt:put:,
size, en algunos Smalltalks next/nextPut:,
replaceFrom:to:with:startingAt:, new, small integer, large integer,
float, double, y todo eso. Hasta ahi viene mas o menos facil la mano.
Pero tambien hay cosas como archivos, sockets, impresoras, mouse,
teclado, graficos, ventanas, eventos (digo de Windows)... eso ya es
mas pesado, en particular si tu VM tiene que andar en N plataformas.
Encima de eso hay cosas ya mas fuleras como signals (que te
interrumpen tu VM en cualquier momento, en particular mientras tu VM
esta en codigo JITeado), y timers asi te anda Delay. Donde estan los
standards de esto para cada plataforma asi se pueden programar solo
una vez? Los timers que estas usando son independientes del cambio de
hora o no? Resolver eso, y dejar a la imagen andando "como siempre"
no es facil. Como te las arreglas para que un signal *siempre*
interrumpa a Smalltalk asi la VM puede fijarse que paso y reaccionar
acorde, pero sin matar la performance ni hacer polls (por ejemplo,
salto un timer asociado con un delay, asi que ahora hay que hacerle
signal a un semaphore y correr de nuevo el process scheduler porque el
proceso que estaba esperando en el semaphore puede tener mas prioridad
que el proceso que esta corriendo ahora --- y si salta un timer
mientras te estas fijando que proceso correr (porque x ej la imagen
hizo Processor yield o Semaphore wait), que?)?

Tambien pensaba que el GC era bastante mas simple de lo que es. Mas
que garbage collect hay que pensar en memory management. Cuando la
imagen dice "new", donde pones ese objeto? Como decidis eso rapido?
Si la imagen te dice "quiero mas memoria", que haces? malloc()?
mmap()? sbrk()? Y si alguno de esos falla, que pasa? Y si la
memoria que te da el sistema operativo no te sirve porque la direccion
no es la que queres, que pasa? Esta bueno tener varios espacios de
objetos (new, old, fixed, etc). Que pasa cuando la imagen hace un
become: entre objetos en diferentes espacios? Que pasa con
oneWayBecome:? Y si hay que copiar objetos y el nuevo no entra, que?
Como haces que la VM proteste cuando no hay espacio? Esto requiere
una cantidad de laburo grande en la imagen para que funcione bien el
tandem. Como se graba la imagen, y como la volves a cargar? Eso
tampoco es facil, tener que manosear todos los punteros. Mas espacios
de objetos tenes, mas complicado se pone. Si tenes un incremental
garbage collector, mas complicado todavia. Ademas le tenes que
agregar weak objects, ephemerons, y finalization.

En VW, todo esto tiene que andar junto y bien: el scavenger de new
space, el IGC, el data compactor, el GC (mark/sweep), el global GC
(mark/sweep, pero tambien de perm space), weak objects, ephemerons,
finalization, los remember tables de turno, y tambien en 64 bits la
tabla de clases que es weak pero que durante un scavenge es strong si
esta funcionando el IGC. Solo esto ya es complicado...

Ademas de que la imagen llame a cosas y permita callbacks, tambien
esta bueno que alguien llame a la VM y le diga cosas como "che fiera
ejecutame este codigo y decime que pasa". O que te caiga un callback
que no pediste inmediatamente antes (o sea que se ejecuta en un thread
que no es el que lo pidio --- o sea que el thread ese no puede tocar
objetos porque en otro thread puede estar funcionando el garbage
collector, ouch).

Lo que si es la muerte es algo de lo que hable alla en Smalltalks: los
standards que rigen el mundo de C son demasiado grandes para una sola
persona (o para un grupo reducido de personas). Mencione el manual de
GCC que en su momento tenia 662 paginas. Bueno, porque la VM de Linux
en x86/64 se colgaba con SIGSEGV, mientras todas las otras VMs
andaban? Porque el compilador era GCC, y ademas porque en 64 bits se
dan todas estas casualidades juntas:

1. las entradas de la tabla de objetos tienen un bitfield al final.
2. las entradas de la tabla de objetos estan contra el borde superior
de un cacho de memoria que te dio mmap() (o malloc(), o sbrk()...).
3. el codigo C que lee esos bitfields resulta en diferente assembler
segun como cambia otro codigo C que no tiene nada que ver... o sea, el
estado interno del compilador resulta en unas instrucciones u otras
instrucciones.
4. Algunas de esas instrucciones hacen, esencialmente,

mov 12+[objectTableEntryPtr], %eax

o si no

mov 13+[objectTableEntryPtr], %eax

Estoy haciendo el ejemplo asi no mas, pero esa es la idea: el
compilador hace un read, y despues hace shl y and de %eax para
conseguir el valor del bitfield que corresponde. Cada object entry
tiene 16 bytes. Que pasa cuando el objectTableEntryPtr apunta al
ultimo object table entry y el CPU trata de leer 4 bytes empezando en
13+objectTableEntryPtr? El ultimo byte esta afuera del segmento
otorgado por el sistema operativo => SIGSEGV. Y cuando ocurre el bug?
Cuando la imagen le pide el identityHash a un objeto que tiene el
ultimo objectTableEntry en un segmento. La imagen le pide
identityHash a los objetos con frecuencia? Si, pero obviamente no a
todos... asi que si tenes suerte, no pasa nada. Y si no tenes suerte,
bueh...

En 32 bits, no se dan todas las casualidades asi que las VMs
compiladas con GCC andan igual. Pero si no te pasa el problema en 64
bits, tenes idea real de lo que esta pasando? Igual hay que
arreglarlo, y para arreglar tenes que encontrar el error primero.
Podes pensar "jaja, es un error del optimizador, asi que ahora
compilamos con -O0", pero eso no es "encontrar el error" sino "voy a
cambiar cosas al azar hasta que el error desaparezca, y despues digo
que arregle lo que estaba mal". Eso no esta bien. Asi que hay que
ponerse a investigar. Y, investigando, al final uno encuentra que el
manual de GCC dice claramente que esto es un problema del compilador:

============
# Accesses to bit-fields even in volatile objects works by accessing
larger objects, such as a byte or a word. You cannot rely on what size
of object is accessed in order to read or write the bit-field; it may
even vary for a given bit-field according to the precise usage.

If you care about controlling the amount of memory that is accessed,
use volatile but do not use bit-fields.
============

http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Disappointments.html#Disappointments

Pero quien se lee todo el manual de GCC con cada version nueva que
sacan ANTES DE USARLO? Y quien se lee todo MSDN, la documentacion de
Apple, etc? Eso si que es dificil: te la pasas leyendo documentacion
para ver si lo que estas haciendo esta bien o mal. Invariablemente,
como cada cosita que haces esta relacionada con alguna otra cosa, eso
te lleva de documento en documento como si estuvieras webeando en la
Wikipedia --- pero esta vez tenes que estudiar!

Por ejemplo: muchas funciones comunes de Unix te dicen como fallaron a
traves de un coso que se llama errno. A veces tambien tenes que usar
esas funciones en signal handlers. El standard de turno te dice
cuales podes usar y cuales no en un signal handler (printf(), por
ejemplo, no se puede). Esas funciones tambien manosean el valor de
errno si fallan. Y que pasa si un signal handler interrumpe tu codigo
justo despues de que falla una funcion pero antes de que el codigo se
fije el valor de errno, y el signal handler llama a una funcion que
tambien falla y cambia el valor de errno? Cuando vuelve el signal
handler a tu programa, te podes encontrar que no pudiste abrir un
archivo porque (para inventar) la ultima vez que dividiste un numero
de punto flotante por otro el resultado fue NaN...

Para mi, el problema mas serio es que determinar que algo esta
Bien(TM) es MUY DIFICIL. Esa investigacion constante lleva un monton
de tiempo y esfuerzo. Por eso me parece mas valioso lo que esta
tratando de hacer Alan Kay... que se pueda programar una computadora
de manera decente pero que tengas que estudiar, como mucho, 20 mil
lineas de codigo. 20 mil lineas no es nada!

Ah, pero como, habia que ejecutar bytecodes?... :). Bueno,
exactamente que haces cuando en el JIT tenes que hacer shl %cl, %reg,
y resulta que

1. %ecx lo estas usando para otra cosa,
2. %reg puede ser %ecx,
3. no podes hacer push/pop,
4. no hay registros disponibles (estan todos asignados),
5. y ademas te tenes que guardar una copia de %reg antes de hacer el
shift en algun lado.

Ahi te pones a investigar la papeleria de Intel y descubris que aun
hoy solo se puede hacer shl/shr/sar usando a %cl. Y ahora?... a
investigar de nuevo...

Andres.

2010/7/26 Gerardo Richarte <[hidden email]>:

> On 07/26/2010 09:25 AM, Angel "Java" Lopez wrote:
>> Andres, interesante... Podrias enumerar por aquí una lista de lo que hace
>> una VM?
>>
> che, a mi también me interesa mucho la verdad, ya a esta idea nos fuimos
> armando una idea, pero estaría bueno escuchar tu opinion. Para mi en
> este momento, con toda la experiencia que ganaste en estos años siendo
> el que está a cargo [una] de las VM de Smalltalk más usadas [la de VW]
> tu palabra vale mucho.
>
> Yo tiro algo, veamos:
>
> . Bytecode execution engine (interprete y/o JIT)
> . primitives
> . garbage collection
> . method lookup
> . FFI
> . Process scheduler (?)
> . Callback mechanism (?)
>
> a ver?
> 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

Angel "Java" Lopez

RE: RV: DNG-Win32 Bit VM

Hola gente!

Gracias por el detalle, a Andres y a Gerardo.

Con respecto a lo que plantea Andres, no se resuelve gran parte de eso
adoptando como lenguaje de implementación algo sobre Java o .NET? Cuanto se
resolvería asi? Yo, en mi pet Project, no tengo que preocuparme de GC o de
FFI, simplemente accedo a .NET (como podria acceder a Java, si reimplemento
todo en Java).

Veo en los últimos anios varios lenguajes implementados asi (desde Clojure a
IronRuby, IronPython, IronScheme, etc..). Hasta creo recordar a Dan Ingalls
o Alan Kay, reimplementando un Smalltalk VM en Java.

Cuales serian los problemas que encontrarían o ya se encontraron, en ese
camino?

Independientemente de eso, alguien mas sobre un detalle de que incluir en
una VM?

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]]
En nombre de Andres Valloud
Enviado el: lunes, 26 de julio de 2010 16:02
Para: [hidden email]
Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM

Antes de laburar en esto, tenia una idea bastante ingenua. Pensaba
que "VM" queria decir "ejecutar bytecodes y todas las optimizaciones
que tienen que ver con eso" y nada mas. Grave error...

Por ejemplo, si, hay que programar primitivas, pero no son todas
iguales. Por ejemplo, tenes cosas como identityHash, basicAt:put:,
size, en algunos Smalltalks next/nextPut:,
replaceFrom:to:with:startingAt:, new, small integer, large integer,
float, double, y todo eso. Hasta ahi viene mas o menos facil la mano.
Pero tambien hay cosas como archivos, sockets, impresoras, mouse,
teclado, graficos, ventanas, eventos (digo de Windows)... eso ya es
mas pesado, en particular si tu VM tiene que andar en N plataformas.
Encima de eso hay cosas ya mas fuleras como signals (que te
interrumpen tu VM en cualquier momento, en particular mientras tu VM
esta en codigo JITeado), y timers asi te anda Delay. Donde estan los
standards de esto para cada plataforma asi se pueden programar solo
una vez? Los timers que estas usando son independientes del cambio de
hora o no? Resolver eso, y dejar a la imagen andando "como siempre"
no es facil. Como te las arreglas para que un signal *siempre*
interrumpa a Smalltalk asi la VM puede fijarse que paso y reaccionar
acorde, pero sin matar la performance ni hacer polls (por ejemplo,
salto un timer asociado con un delay, asi que ahora hay que hacerle
signal a un semaphore y correr de nuevo el process scheduler porque el
proceso que estaba esperando en el semaphore puede tener mas prioridad
que el proceso que esta corriendo ahora --- y si salta un timer
mientras te estas fijando que proceso correr (porque x ej la imagen
hizo Processor yield o Semaphore wait), que?)?

Tambien pensaba que el GC era bastante mas simple de lo que es. Mas
que garbage collect hay que pensar en memory management. Cuando la
imagen dice "new", donde pones ese objeto? Como decidis eso rapido?
Si la imagen te dice "quiero mas memoria", que haces? malloc()?
mmap()? sbrk()? Y si alguno de esos falla, que pasa? Y si la
memoria que te da el sistema operativo no te sirve porque la direccion
no es la que queres, que pasa? Esta bueno tener varios espacios de
objetos (new, old, fixed, etc). Que pasa cuando la imagen hace un
become: entre objetos en diferentes espacios? Que pasa con
oneWayBecome:? Y si hay que copiar objetos y el nuevo no entra, que?
Como haces que la VM proteste cuando no hay espacio? Esto requiere
una cantidad de laburo grande en la imagen para que funcione bien el
tandem. Como se graba la imagen, y como la volves a cargar? Eso
tampoco es facil, tener que manosear todos los punteros. Mas espacios
de objetos tenes, mas complicado se pone. Si tenes un incremental
garbage collector, mas complicado todavia. Ademas le tenes que
agregar weak objects, ephemerons, y finalization.

En VW, todo esto tiene que andar junto y bien: el scavenger de new
space, el IGC, el data compactor, el GC (mark/sweep), el global GC
(mark/sweep, pero tambien de perm space), weak objects, ephemerons,
finalization, los remember tables de turno, y tambien en 64 bits la
tabla de clases que es weak pero que durante un scavenge es strong si
esta funcionando el IGC. Solo esto ya es complicado...

Ademas de que la imagen llame a cosas y permita callbacks, tambien
esta bueno que alguien llame a la VM y le diga cosas como "che fiera
ejecutame este codigo y decime que pasa". O que te caiga un callback
que no pediste inmediatamente antes (o sea que se ejecuta en un thread
que no es el que lo pidio --- o sea que el thread ese no puede tocar
objetos porque en otro thread puede estar funcionando el garbage
collector, ouch).

Lo que si es la muerte es algo de lo que hable alla en Smalltalks: los
standards que rigen el mundo de C son demasiado grandes para una sola
persona (o para un grupo reducido de personas). Mencione el manual de
GCC que en su momento tenia 662 paginas. Bueno, porque la VM de Linux
en x86/64 se colgaba con SIGSEGV, mientras todas las otras VMs
andaban? Porque el compilador era GCC, y ademas porque en 64 bits se
dan todas estas casualidades juntas:

1. las entradas de la tabla de objetos tienen un bitfield al final.
2. las entradas de la tabla de objetos estan contra el borde superior
de un cacho de memoria que te dio mmap() (o malloc(), o sbrk()...).
3. el codigo C que lee esos bitfields resulta en diferente assembler
segun como cambia otro codigo C que no tiene nada que ver... o sea, el
estado interno del compilador resulta en unas instrucciones u otras
instrucciones.
4. Algunas de esas instrucciones hacen, esencialmente,

mov 12+[objectTableEntryPtr], %eax

o si no

mov 13+[objectTableEntryPtr], %eax

Estoy haciendo el ejemplo asi no mas, pero esa es la idea: el
compilador hace un read, y despues hace shl y and de %eax para
conseguir el valor del bitfield que corresponde. Cada object entry
tiene 16 bytes. Que pasa cuando el objectTableEntryPtr apunta al
ultimo object table entry y el CPU trata de leer 4 bytes empezando en
13+objectTableEntryPtr? El ultimo byte esta afuera del segmento
otorgado por el sistema operativo => SIGSEGV. Y cuando ocurre el bug?
Cuando la imagen le pide el identityHash a un objeto que tiene el
ultimo objectTableEntry en un segmento. La imagen le pide
identityHash a los objetos con frecuencia? Si, pero obviamente no a
todos... asi que si tenes suerte, no pasa nada. Y si no tenes suerte,
bueh...

En 32 bits, no se dan todas las casualidades asi que las VMs
compiladas con GCC andan igual. Pero si no te pasa el problema en 64
bits, tenes idea real de lo que esta pasando? Igual hay que
arreglarlo, y para arreglar tenes que encontrar el error primero.
Podes pensar "jaja, es un error del optimizador, asi que ahora
compilamos con -O0", pero eso no es "encontrar el error" sino "voy a
cambiar cosas al azar hasta que el error desaparezca, y despues digo
que arregle lo que estaba mal". Eso no esta bien. Asi que hay que
ponerse a investigar. Y, investigando, al final uno encuentra que el
manual de GCC dice claramente que esto es un problema del compilador:

============
# Accesses to bit-fields even in volatile objects works by accessing
larger objects, such as a byte or a word. You cannot rely on what size
of object is accessed in order to read or write the bit-field; it may
even vary for a given bit-field according to the precise usage.

If you care about controlling the amount of memory that is accessed,
use volatile but do not use bit-fields.
============

http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Disappointments.html#Disappointm
ents

Pero quien se lee todo el manual de GCC con cada version nueva que
sacan ANTES DE USARLO? Y quien se lee todo MSDN, la documentacion de
Apple, etc? Eso si que es dificil: te la pasas leyendo documentacion
para ver si lo que estas haciendo esta bien o mal. Invariablemente,
como cada cosita que haces esta relacionada con alguna otra cosa, eso
te lleva de documento en documento como si estuvieras webeando en la
Wikipedia --- pero esta vez tenes que estudiar!

Por ejemplo: muchas funciones comunes de Unix te dicen como fallaron a
traves de un coso que se llama errno. A veces tambien tenes que usar
esas funciones en signal handlers. El standard de turno te dice
cuales podes usar y cuales no en un signal handler (printf(), por
ejemplo, no se puede). Esas funciones tambien manosean el valor de
errno si fallan. Y que pasa si un signal handler interrumpe tu codigo
justo despues de que falla una funcion pero antes de que el codigo se
fije el valor de errno, y el signal handler llama a una funcion que
tambien falla y cambia el valor de errno? Cuando vuelve el signal
handler a tu programa, te podes encontrar que no pudiste abrir un
archivo porque (para inventar) la ultima vez que dividiste un numero
de punto flotante por otro el resultado fue NaN...

Para mi, el problema mas serio es que determinar que algo esta
Bien(TM) es MUY DIFICIL. Esa investigacion constante lleva un monton
de tiempo y esfuerzo. Por eso me parece mas valioso lo que esta
tratando de hacer Alan Kay... que se pueda programar una computadora
de manera decente pero que tengas que estudiar, como mucho, 20 mil
lineas de codigo. 20 mil lineas no es nada!

Ah, pero como, habia que ejecutar bytecodes?... :). Bueno,
exactamente que haces cuando en el JIT tenes que hacer shl %cl, %reg,
y resulta que

1. %ecx lo estas usando para otra cosa,
2. %reg puede ser %ecx,
3. no podes hacer push/pop,
4. no hay registros disponibles (estan todos asignados),
5. y ademas te tenes que guardar una copia de %reg antes de hacer el
shift en algun lado.

Ahi te pones a investigar la papeleria de Intel y descubris que aun
hoy solo se puede hacer shl/shr/sar usando a %cl. Y ahora?... a
investigar de nuevo...

Andres.

2010/7/26 Gerardo Richarte <[hidden email]>:

[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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.441 / Virus Database: 271.1.1/3029 - Release Date: 07/26/10
06:36:00

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Gerardo Richarte

Re: RV: DNG-Win32 Bit VM

In reply to this post by Andres Valloud-5

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

Gerardo Richarte

Re: RV: DNG-Win32 Bit VM

In reply to this post by Angel "Java" Lopez

On 07/26/2010 03:25 PM, Angel "Java" Lopez wrote:

no entiendo bien. Estás diciendo que tu compilador Smalltalk escupe
bytecode .NET o bytecode java? o que cuando haces new en Smalltalk
eso va directamente a un new en Java o .NET, y que en la implementación
de tu Smalltalk no manejas nada del formato de los objetos? incluso tenés
también definidos las clases también en el lenguaje de abajo? de tal forma
que un slot en Smalltalk sea un slot (con el mismo nombre?) en .NET y
Java? Pero para ejecutar el código, implementaste un interprete de
Smalltalk? y FFI? como lo implementas? también se lo pateas, via el
interprete, al execution engine que está por debajo?

Si estás compilando a bytecode de la VM de abajo está super, si no
tenés el overhead (de performance) de estar dentro de 2 VMs. Y en los
dos casos tenés la desgracia de no poder experimentar con cosas divertidas
como el GC (memory management), method lookup y caches de métodos,
y algunas otras cosas divertidas :-)... bueno, dependiendo de donde pogas
la linea de corte, claro

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

Angel "Java" Lopez

RE: RV: DNG-Win32 Bit VM

Hola gente!

Gerardo (creo que nos habremos cruzado en alguna reunión de Sugar en Buenos
Aires, en 1997), gracias por el comentario. Hmmm, algunas aclaraciones:

- Mi pet project [1] es un interprete, otros lenguajes que mencione,
implementan un compilador sobre .NET (emiten código, o se auxilian del DLR,
Dynamic Language Runtime), o código Java (como Clojure, que es interprete en
memoria, usando un patrón Interpreter, y luego visita cada nodo, y lo
compila a Java si es necesario).

- En mi proyecto, no implemento un patrón Interpreter (un objeto por cada,
digamos operación, formando un árbol), sino que implemento Block, con
bytecodes adentro, que luego, al resolver un mensaje y decidir el método a
ejecutar, voy recorriendo ese arreglo de bytecodes y ejecutándolos en
métodos .NET.

- Manejo objetos nativos e implementaciones de IObject (lo que defini que
tendrían que tener todos los objetos de esta VM). La opción hubiera sido
hacer que todos fueran IObject o algo asi, pero yo quería utilizar
directamente los Value Object primitivos de .NET (int32, int64, etc).

- Los IObject tienen slots, definidos por su definición de clase, digamos,
sus instance variables. Son object (o sea, pueden apuntar a object nativo de
.NET (o de Java si reimplementara todo en Java), y

- No uso FFI, simplemente llamo a librerías .NET cualesquiera (la gente de
Clojure llama a Java cualesquiera, y no tuvo que implementar JNI Java Native
Interface). Hay parva de código de Clojure que ha conseguido sinergia al
montarse sobre librerías de Java ya existente. Clojure es un lenguaje Lisp,
veo que Lisp por si solo nunca consiguió "momentum", y ahora con la
estrategia de Clojure de acceder a todo Java VM, se esta "popularizando". EN
mi caso, si alguien quiere llamar a algo mas básico, lo implementa en .NET

- Solo algunas clases están definidas en el lenguaje de abajo, tengo que
rever cuales si y cuales no, por ejemplo Class, Behavior, etc..

- En vez de implementar alguna forma de primitivas (como en otros Smalltalk
que tienen alguna notación para llamar a una primitiva, o cargar nuevas
primitivas al principio), tengo implementada una forma de crear objetos en
.NET y llamar métodos nativos, directamente en notación Smalltalk. Podria
implementar un Bag de Smalltalk, con todo el protocolo de métodos, teniendo
por debajo una variable de instancia que podria ser
System.Collections.Generics.List<object> o algo asi, y manejarla desde el
código de los métodos de Bag. Ejemplo de la notación que hasta va
triunfando:
@System.IO.FileInfo new: ‘aFile.txt’

- Cuando hablo de .NET arriba, tranquilamente podria reimplementar todo en
Java.

- Ahora si, quisiera pasarlo a compilador, debería emitir código nativo (C#
o IL (intermédiate language)) para cada bytecode que encontrara en cada
método. Por ahora, no lo hago, prefiero avanzar en otras cosas. Si llego a
ese punto, pienso que podria superar problemas de performance que aparezcan,
como hicieron otros implementadores, como la gente de Clojure, o IronPython

- Jeje... ya encuentro divertido hacer todo eso, y poder acceder a otras
librerías. Quiero llegar a implementar objetos distribuidos, y agentes (algo
habíamos hablado en una reunión de Sugar del siglo pasado), como hice en
otro lenguaje interpretado [2].

[1] http://ajlopez.wordpress.com/category/ajtalk/
[2] http://ajlopez.wordpress.com/category/ajsharp/

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]]
En nombre de Gerardo Richarte
Enviado el: lunes, 26 de julio de 2010 16:51
Para: [hidden email]
Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM

On 07/26/2010 03:25 PM, Angel "Java" Lopez wrote:
> Hola gente!
>
> Gracias por el detalle, a Andres y a Gerardo.
>
> Con respecto a lo que plantea Andres, no se resuelve gran parte de eso
> adoptando como lenguaje de implementación algo sobre Java o .NET? Cuanto
se
> resolvería asi? Yo, en mi pet Project, no tengo que preocuparme de GC o de
> FFI, simplemente accedo a .NET (como podria acceder a Java, si
reimplemento
> todo en Java).
>
no entiendo bien. Estás diciendo que tu compilador Smalltalk escupe
bytecode .NET o bytecode java? o que cuando haces new en Smalltalk
eso va directamente a un new en Java o .NET, y que en la implementación
de tu Smalltalk no manejas nada del formato de los objetos? incluso tenés
también definidos las clases también en el lenguaje de abajo? de tal forma
que un slot en Smalltalk sea un slot (con el mismo nombre?) en .NET y
Java? Pero para ejecutar el código, implementaste un interprete de
Smalltalk? y FFI? como lo implementas? también se lo pateas, via el
interprete, al execution engine que está por debajo?

Si estás compilando a bytecode de la VM de abajo está super, si no
tenés el overhead (de performance) de estar dentro de 2 VMs. Y en los
dos casos tenés la desgracia de no poder experimentar con cosas divertidas
como el GC (memory management), method lookup y caches de métodos,
y algunas otras cosas divertidas :-)... bueno, dependiendo de donde pogas
la linea de corte, claro

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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.441 / Virus Database: 271.1.1/3029 - Release Date: 07/26/10
06:36:00

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

dcoronel32@gmail.com

Re: RV: DNG-Win32 Bit VM

In reply to this post by Gerardo Richarte

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

Andres Valloud-5

Re: RV: DNG-Win32 Bit VM

In reply to this post by Angel "Java" Lopez

Me parece que en algunos casos quiza valga la pena, pero me parece que
atarse a lo que la gente de Java o .NET decida te saca muchas
libertades si la necesidad tecnica te lleva a contramano de lo que es
bueno para ellos.

2010/7/26 Angel "Java" Lopez <[hidden email]>:

> Hola gente!
>
> Gracias por el detalle, a Andres y a Gerardo.
>
> Con respecto a lo que plantea Andres, no se resuelve gran parte de eso
> adoptando como lenguaje de implementación algo sobre Java o .NET? Cuanto se
> resolvería asi? Yo, en mi pet Project, no tengo que preocuparme de GC o de
> FFI, simplemente accedo a .NET (como podria acceder a Java, si reimplemento
> todo en Java).
>
> Veo en los últimos anios varios lenguajes implementados asi (desde Clojure a
> IronRuby, IronPython, IronScheme, etc..). Hasta creo recordar a Dan Ingalls
> o Alan Kay, reimplementando un Smalltalk VM en Java.
>
> Cuales serian los problemas que encontrarían o ya se encontraron, en ese
> camino?
>
> Independientemente de eso, alguien mas sobre un detalle de que incluir en
> una VM?
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com/
> http://twitter.com/ajlopez
>
> -----Mensaje original-----
> De: [hidden email] [mailto:[hidden email]]
> En nombre de Andres Valloud
> Enviado el: lunes, 26 de julio de 2010 16:02
> Para: [hidden email]
> Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM
>
> Antes de laburar en esto, tenia una idea bastante ingenua. Pensaba
> que "VM" queria decir "ejecutar bytecodes y todas las optimizaciones
> que tienen que ver con eso" y nada mas. Grave error...
>
> Por ejemplo, si, hay que programar primitivas, pero no son todas
> iguales. Por ejemplo, tenes cosas como identityHash, basicAt:put:,
> size, en algunos Smalltalks next/nextPut:,
> replaceFrom:to:with:startingAt:, new, small integer, large integer,
> float, double, y todo eso. Hasta ahi viene mas o menos facil la mano.
> Pero tambien hay cosas como archivos, sockets, impresoras, mouse,
> teclado, graficos, ventanas, eventos (digo de Windows)... eso ya es
> mas pesado, en particular si tu VM tiene que andar en N plataformas.
> Encima de eso hay cosas ya mas fuleras como signals (que te
> interrumpen tu VM en cualquier momento, en particular mientras tu VM
> esta en codigo JITeado), y timers asi te anda Delay. Donde estan los
> standards de esto para cada plataforma asi se pueden programar solo
> una vez? Los timers que estas usando son independientes del cambio de
> hora o no? Resolver eso, y dejar a la imagen andando "como siempre"
> no es facil. Como te las arreglas para que un signal *siempre*
> interrumpa a Smalltalk asi la VM puede fijarse que paso y reaccionar
> acorde, pero sin matar la performance ni hacer polls (por ejemplo,
> salto un timer asociado con un delay, asi que ahora hay que hacerle
> signal a un semaphore y correr de nuevo el process scheduler porque el
> proceso que estaba esperando en el semaphore puede tener mas prioridad
> que el proceso que esta corriendo ahora --- y si salta un timer
> mientras te estas fijando que proceso correr (porque x ej la imagen
> hizo Processor yield o Semaphore wait), que?)?
>
> Tambien pensaba que el GC era bastante mas simple de lo que es. Mas
> que garbage collect hay que pensar en memory management. Cuando la
> imagen dice "new", donde pones ese objeto? Como decidis eso rapido?
> Si la imagen te dice "quiero mas memoria", que haces? malloc()?
> mmap()? sbrk()? Y si alguno de esos falla, que pasa? Y si la
> memoria que te da el sistema operativo no te sirve porque la direccion
> no es la que queres, que pasa? Esta bueno tener varios espacios de
> objetos (new, old, fixed, etc). Que pasa cuando la imagen hace un
> become: entre objetos en diferentes espacios? Que pasa con
> oneWayBecome:? Y si hay que copiar objetos y el nuevo no entra, que?
> Como haces que la VM proteste cuando no hay espacio? Esto requiere
> una cantidad de laburo grande en la imagen para que funcione bien el
> tandem. Como se graba la imagen, y como la volves a cargar? Eso
> tampoco es facil, tener que manosear todos los punteros. Mas espacios
> de objetos tenes, mas complicado se pone. Si tenes un incremental
> garbage collector, mas complicado todavia. Ademas le tenes que
> agregar weak objects, ephemerons, y finalization.
>
> En VW, todo esto tiene que andar junto y bien: el scavenger de new
> space, el IGC, el data compactor, el GC (mark/sweep), el global GC
> (mark/sweep, pero tambien de perm space), weak objects, ephemerons,
> finalization, los remember tables de turno, y tambien en 64 bits la
> tabla de clases que es weak pero que durante un scavenge es strong si
> esta funcionando el IGC. Solo esto ya es complicado...
>
> Ademas de que la imagen llame a cosas y permita callbacks, tambien
> esta bueno que alguien llame a la VM y le diga cosas como "che fiera
> ejecutame este codigo y decime que pasa". O que te caiga un callback
> que no pediste inmediatamente antes (o sea que se ejecuta en un thread
> que no es el que lo pidio --- o sea que el thread ese no puede tocar
> objetos porque en otro thread puede estar funcionando el garbage
> collector, ouch).
>
> Lo que si es la muerte es algo de lo que hable alla en Smalltalks: los
> standards que rigen el mundo de C son demasiado grandes para una sola
> persona (o para un grupo reducido de personas). Mencione el manual de
> GCC que en su momento tenia 662 paginas. Bueno, porque la VM de Linux
> en x86/64 se colgaba con SIGSEGV, mientras todas las otras VMs
> andaban? Porque el compilador era GCC, y ademas porque en 64 bits se
> dan todas estas casualidades juntas:
>
> 1. las entradas de la tabla de objetos tienen un bitfield al final.
> 2. las entradas de la tabla de objetos estan contra el borde superior
> de un cacho de memoria que te dio mmap() (o malloc(), o sbrk()...).
> 3. el codigo C que lee esos bitfields resulta en diferente assembler
> segun como cambia otro codigo C que no tiene nada que ver... o sea, el
> estado interno del compilador resulta en unas instrucciones u otras
> instrucciones.
> 4. Algunas de esas instrucciones hacen, esencialmente,
>
> mov 12+[objectTableEntryPtr], %eax
>
> o si no
>
> mov 13+[objectTableEntryPtr], %eax
>
> Estoy haciendo el ejemplo asi no mas, pero esa es la idea: el
> compilador hace un read, y despues hace shl y and de %eax para
> conseguir el valor del bitfield que corresponde. Cada object entry
> tiene 16 bytes. Que pasa cuando el objectTableEntryPtr apunta al
> ultimo object table entry y el CPU trata de leer 4 bytes empezando en
> 13+objectTableEntryPtr? El ultimo byte esta afuera del segmento
> otorgado por el sistema operativo => SIGSEGV. Y cuando ocurre el bug?
> Cuando la imagen le pide el identityHash a un objeto que tiene el
> ultimo objectTableEntry en un segmento. La imagen le pide
> identityHash a los objetos con frecuencia? Si, pero obviamente no a
> todos... asi que si tenes suerte, no pasa nada. Y si no tenes suerte,
> bueh...
>
> En 32 bits, no se dan todas las casualidades asi que las VMs
> compiladas con GCC andan igual. Pero si no te pasa el problema en 64
> bits, tenes idea real de lo que esta pasando? Igual hay que
> arreglarlo, y para arreglar tenes que encontrar el error primero.
> Podes pensar "jaja, es un error del optimizador, asi que ahora
> compilamos con -O0", pero eso no es "encontrar el error" sino "voy a
> cambiar cosas al azar hasta que el error desaparezca, y despues digo
> que arregle lo que estaba mal". Eso no esta bien. Asi que hay que
> ponerse a investigar. Y, investigando, al final uno encuentra que el
> manual de GCC dice claramente que esto es un problema del compilador:
>
> ============
> # Accesses to bit-fields even in volatile objects works by accessing
> larger objects, such as a byte or a word. You cannot rely on what size
> of object is accessed in order to read or write the bit-field; it may
> even vary for a given bit-field according to the precise usage.
>
> If you care about controlling the amount of memory that is accessed,
> use volatile but do not use bit-fields.
> ============
>
> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Disappointments.html#Disappointm
> ents
>
> Pero quien se lee todo el manual de GCC con cada version nueva que
> sacan ANTES DE USARLO? Y quien se lee todo MSDN, la documentacion de
> Apple, etc? Eso si que es dificil: te la pasas leyendo documentacion
> para ver si lo que estas haciendo esta bien o mal. Invariablemente,
> como cada cosita que haces esta relacionada con alguna otra cosa, eso
> te lleva de documento en documento como si estuvieras webeando en la
> Wikipedia --- pero esta vez tenes que estudiar!
>
> Por ejemplo: muchas funciones comunes de Unix te dicen como fallaron a
> traves de un coso que se llama errno. A veces tambien tenes que usar
> esas funciones en signal handlers. El standard de turno te dice
> cuales podes usar y cuales no en un signal handler (printf(), por
> ejemplo, no se puede). Esas funciones tambien manosean el valor de
> errno si fallan. Y que pasa si un signal handler interrumpe tu codigo
> justo despues de que falla una funcion pero antes de que el codigo se
> fije el valor de errno, y el signal handler llama a una funcion que
> tambien falla y cambia el valor de errno? Cuando vuelve el signal
> handler a tu programa, te podes encontrar que no pudiste abrir un
> archivo porque (para inventar) la ultima vez que dividiste un numero
> de punto flotante por otro el resultado fue NaN...
>
> Para mi, el problema mas serio es que determinar que algo esta
> Bien(TM) es MUY DIFICIL. Esa investigacion constante lleva un monton
> de tiempo y esfuerzo. Por eso me parece mas valioso lo que esta
> tratando de hacer Alan Kay... que se pueda programar una computadora
> de manera decente pero que tengas que estudiar, como mucho, 20 mil
> lineas de codigo. 20 mil lineas no es nada!
>
> Ah, pero como, habia que ejecutar bytecodes?... :). Bueno,
> exactamente que haces cuando en el JIT tenes que hacer shl %cl, %reg,
> y resulta que
>
> 1. %ecx lo estas usando para otra cosa,
> 2. %reg puede ser %ecx,
> 3. no podes hacer push/pop,
> 4. no hay registros disponibles (estan todos asignados),
> 5. y ademas te tenes que guardar una copia de %reg antes de hacer el
> shift en algun lado.
>
> Ahi te pones a investigar la papeleria de Intel y descubris que aun
> hoy solo se puede hacer shl/shr/sar usando a %cl. Y ahora?... a
> investigar de nuevo...
>
> Andres.
>
> 2010/7/26 Gerardo Richarte <[hidden email]>:
>> On 07/26/2010 09:25 AM, Angel "Java" Lopez wrote:
>>> Andres, interesante... Podrias enumerar por aquí una lista de lo que hace
>>> una VM?
>>>
>> che, a mi también me interesa mucho la verdad, ya a esta idea nos fuimos
>> armando una idea, pero estaría bueno escuchar tu opinion. Para mi en
>> este momento, con toda la experiencia que ganaste en estos años siendo
>> el que está a cargo [una] de las VM de Smalltalk más usadas [la de VW]
>> tu palabra vale mucho.
>>
>> Yo tiro algo, veamos:
>>
>> . Bytecode execution engine (interprete y/o JIT)
>> . primitives
>> . garbage collection
>> . method lookup
>> . FFI
>> . Process scheduler (?)
>> . Callback mechanism (?)
>>
>> a ver?
>> 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
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.441 / Virus Database: 271.1.1/3029 - Release Date: 07/26/10
> 06:36:00
>
> --
> 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

Andres Valloud-5

Re: RV: DNG-Win32 Bit VM

In reply to this post by dcoronel32@gmail.com

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

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

1234