2010/10/13 Angel Java Lopez <[email protected]>
> Hola gente!
>
> Mariano, interesantisimo tu email... Por ahora (en medio de mi cena),
> contesto solo lo sobre become:...
>
> Recuerdo que cuando vi a Squeak, me causo impresion el tema de como
> implementaban become:... se terminaban "bailando la conga", como bien
> indicas, no tenian Object Table (desconozco como sera actualmente Squeak, lo
> habre visto a fines de los noventa, no estoy seguro).
>
Sigue siendo asi :(
>
> Lo que tengo pensado en mi implementacion, en mi pet project (no
> implementado todavia), es que become: lo que hace es:
>
> - Cambiar el "puntero" de un objeto X a su clase.
> - Esa referencia, cambia a un nuevo objeto especial en mi implementacion,
> que dice, no es una clase cualquiera, es una clase que envia todos sus
> mensajes, no al objeto original, sino a otro objeto, el parametro de lo que
> era become:
> A ver si puedo explicarme...
>
Entendi perfecto.
>
> Si
>
> anObject become: x
>
> el anObject class cambia su clase a una "clase" especial, que hace que todo
> mensaje dirigido a anObject, se deriva al x del become:
> En cuanto guarde la imagen, puedo reemplazar toda referencia al anObject
> original al nuevo x.
Este es el mayor problema de tu solucion para mi. Porque si tenes
otroObject apuntando al mismo objeto, no se va a actualizar sino hasta que
se guarde la imagen ?
> Pero mientras no guarde la imagen, puedo usar el "trick" que describo (no
> se si se entendio mi explicacion)
>
> - Toda referencia a anObject no necesita cambia. Lo que pasa, que cualquier
> envio de mensaje a anObject, termina siendo redirigida al x del become: x.
>
"todo menesaje" ->>> revisa bien el tema de los bytecodes. Ponele, si te
mando hago anObject become: x y despues hago anObject == otroObject
(suponiendo que otroObject apunta al mismo objeto) eso va a dar
true....execpto que te pongas a modificar todos los bytecodes speciales.
>
> - Cuando grabe la imagen, en vez de anObject, se graba directamente x,
como haces eso?
> entonces, al cabo de algunos dias, cuando levante la imagen, toda
> referencia a anObject, termina apuntando a x.
>
> - No tengo problemas con false, true.... terminan funcionando igual (en mi
> implementacion son bool false, y bool true, de la maquina VM de abajo, en
> este caso, .NET). Es decir, todos los false y true, serializados o no,
> funcionan igual.
>
> - Los symbol, para mi, en mi pet project, son simples String. Como la VM
> "de abajo", sea .NET o Java, identifican como "iguales" todo string que
> tenga el mismo valor, inclusi cuando se usan como keys en diccionarios. Es
> decir
>
> "pepe".Equals("pepe")
>
> no importa que "pepe" sea un objeto "distinto" (ocupando otro lugar en la
> memoria) de "pepe".
>
> Y cualquiera "pepe" tiene el mismo HashTag de cualquier otro "pepe".. y
> como todo String es inmutable.. .no hace falta distinguir entre Symbol y
> String.... por lo menos en mi implementacion (no me supe explicar del todo,
> cualquier duda, me preguntan).
>
> En caso de que fuera necesario, podria implementar Symbol como
> "pepe".intern() que transforma un string en su represatacion canonica, de
> tal forma que todo "pepe".intern() sea exactamente igual , a cualquier
> "pepe".intern()
>
> Algunos puntos mas:
>
> - Puedo serializar un metodo compilado, aunque todavia no encontre que
> fuera necesario.
>
> Bueno, escribi rapido, no se si se entendio todo... acabo de ver
> #BenditaTv, aca en Argentina, tengan piedad ... ;-)
>
>
jajajaja
> Maniana, espero, pregunto sobre dudas que me quedaron del email de
> Mariano...
>
> Vermu con papa fritas, y gud show! ;-) (chiste para argentinos)
>
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
>
> 2010/10/12 Mariano Martinez Peck <[email protected]>
>
> Hola angel. Quiero opinar sobre 2 cosas que estoy laburando en mi PhD y
>> están bastante relacionados. Proxies y serializacion. Uno cree que son
>> faciles, pero ninguno de los dos es asi.
>>
>> Problemas con proxies:
>>
>> - Acordate que en ST todo son objetos. Por lo tanto el objeto que vas a
>> convertir en proxy, puede ser cualquier cosa: Clases, CompiledMethods,
>> Closures, etc.
>>
>> - Cuando en ST nos quedamos sin Object Table, el #become ES LENTO. Se
>> tiene que traversar todos los objetos de la memoria. Por esto en Gemstome el
>> become anda mas rapido (tienen object table)
>>
>> - Trataste de hacer un unaClase become: MyProxy new ? Cuando luego le
>> mandas un mensaje a una instancia de unaClase, se rompe todo. Principalmente
>> porque el proxy es un objeto no una clase (obviemos el detalle que una clase
>> es un objeto), y la VM para acceder al MethoDict accede DIRECTAMENTE al
>> offset the las variables. O sea, asume que la clase tiene X cantidad de
>> variables y que el methodDIct esta en la posicion X.
>>
>> - Muchas veces el doesNotUnderstand: no es suficiente. En varios casos
>> podes usar el hack de poner el methodDict en nil, e implementar
>> #cannotInterpret: en la superclase.
>>
>> - Lo mismo para los CompiledMethod. Poner un proxy no es igual que para
>> todo el mundo. Tenes que implementar #run:with:in: y algunos otros
>> mensajes mas.
>>
>> - Hay un montón de mensajes que no van como un bytecode send comun, sino
>> con bytecodes especiales. Por lo tanto el dnu o cannotInterpret: pueden ni
>> llamarse. Evalua "ProtoObject class" y vas a que anda..sin embargo
>> ProtoObject no implementa #class. Y asi como #class hay varios bytecodes
>> speciales que te cagan. Mira Smalltalk specialSelectors.
>>
>> - Tenes que tener mucho cuidado a lo que becomeas con un proxy. Podes
>> romper todo muy facil. Hay cosas core que no se pueden reemplazar.
>>
>> - Debugear es muy dificil porque el mismo debugger manda mensajes para
>> imprimirlos o cosas asi entonces te los vuelve a traer jjajajaj
>>
>> - Si un objecto X tiene como instancia una refencia a un objeto Y, y haces
>> un become de X a un proxy, el proxy no va a apuntar a Y. POr lo tanto, si
>> nadie mas estaba apuntando a Y, el GC te llevó a Y. ImageSegments soluciona
>> esto de una manera muy buena.
>>
>>
>>
>> Respecto a Serializacion:
>>
>> - Es muy dificil hacer un serializador que sea rapido. Acá en mi lab están
>> haciendo una implementación parecida a Parcels (de VW) y está andando bien.
>> Pero hay que tener en cuenta un monton de problemas:
>>
>> - Ciclos en el subgrafo
>>
>> - CompiledMethod, ContextPart (y subclases), Process, Continuations, etc
>> etc son dificilies de serializar
>>
>> - endianess (big or blah)
>>
>> - que haces con nil, true, false, etc? y Symbol ? A la hora de cargarlo
>> en la misma image o en otra, no podes crear duplicados, y los objetos tienen
>> que apuntar a los ya existentes. Tambien tenes que hacer un rehash de los
>> sets cuando los traes nuevamente. etc......etc etc.
>>
>>
>> Bueno, eso nomas. Muchas veces las cosas parecen más faciles no?
>>
>> saludos
>>
>> Mariano
>>
>>
>> 2010/10/11 Angel Java Lopez <[email protected]>
>>
>>> Hola gente!
>>>
>>>
>>> Interesante la discusion del Thread "Blog", pero tambien algo se fue por
>>> las ramas... Cambio de titulo en este mensaje.
>>>
>>> Estuve agregando objetos distribuidos a mi pet project [1], quedo algo
>>> asi:
>>>
>>> http://pastie.org/1213856
>>>
>>> Tengan encuenta que no tengo libreria de clases de base, asi que tengo
>>> que comenzar desde nil subclass:... ';-)
>>>
>>> Puedo:
>>>
>>> - Levantar un servidor (tecnologia Remoting .NET), en nodo A.
>>> - Levantar un cliente remoto a ese servidor, en nodo B.
>>> - Definir una clase en nodo B.
>>> - Exportar su definicion de B a nodo A.
>>> - Ejecutar desde nodo B algo en nodo A.
>>> - Evaluar en nodo A y devolver el objeto serializado (contemplando grafos
>>> con ciclos, repeticion de objetos, etc..) a B.
>>>
>>> Me falta evaluar en nodo A y que el resultado quede en A, viajando a B
>>> una especie de proxy, de tal manera que invocando a ese objeto en B, se
>>> ejecute el mensaje en nodo A.
>>>
>>> Mi idea es que si B devuelve un objeto a A, ese resultado viaja completo.
>>> Sino, definiria algo como
>>>
>>> ^host asProxy: result.
>>>
>>> Tendria que escribir post, pero por ahora, tengo esto para mostrar.
>>>
>>> [1] http://code.google.com/p/ajtalk
>>>
>>> Nos leemos!
>>>
>>> Angel "Java" Lopez
>>> http://www.ajlopez.com
>>> http://twitter.com/ajlopez
>>>
>>>
>>>
>>> --
>>> To post to this group, send email to [email protected]
>>> To unsubscribe from this group, send email to
>>> [email protected]<clubsmalltalk%[email protected]>
>>>
>>> http://www.clubSmalltalk.org
>>>
>>
>> --
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]<clubsmalltalk%[email protected]>
>>
>> http://www.clubSmalltalk.org
>>
>
> --
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<clubsmalltalk%[email protected]>
>
> http://www.clubSmalltalk.org
>
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
