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] http://www.clubSmalltalk.org
