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).
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...
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. 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.
- Cuando grabe la imagen, en vez de anObject, se graba directamente x,
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 ... ;-)
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]
http://www.clubSmalltalk.org
