Hola gente! Gracias Guillermo, por la informacion para Squeak, la voy a estudiar, por ahora no, que estoy leyendo todavia GemStone, y no probe nada de el.
Jeje... casi todo estaba implementado el lunes pasado, cuando envie el codigo en el primer mensaje de este thread que abri ese lunes 11, que recuerde. Lo unico que agregue, con dos horas del domingo, es lo de tener el objeto creado en M2, y que viaje como proxy a M1: antes se serializaba completo. Pueden ver el log del SVN del proyecto para ver como fue avanzando. Luego, ayer me dedique a mis primeros pasos en transacciones de objetos, pero eso es Work In Progress, todavia. Con lo que agregue ayer, ahora, si desde M1 hago rectRemoto := host evaluate: 'rectEnM2 asRemote'. queda en la variable local rectRemoto un proxy al objeto Rectangle rectEnM2 que quedo en M2. Cualquier mensaje rectRemoto width: 10. se envia a M2 y se EJECUTA en M2. Si hago desde M1: rectCopia := host evaluate: 'rectEnM2'. viaja serializado el rectangulo y queda una copia en M1, que se invoca en M1 y asi. Guillermo, vamos a tus preguntas: 1. Los publico evaluando algo en M2 y aplicando el mensaje que tienen todos los Object (ver el pastie que envie http://pastie.org/1213856 como se define el mensaje asRemote); Entonces, si desde M2 a M1 quiero enviar un resultado serializado, implemente devuelvo result Si quiero enviar el objeto resultado pero como "objeto clavado en M2", devuelvo result asRemote Es decision del programar si lo hace de una forma u otra. 2. Si llega un mensaje a un objeto cuando esta procesando otro, es lo mismo que hago cuando estoy en local, con objetos locales y "threads" (no tengo un full Process class implementado todavia): si dos "threads" acceden al mismo objeto, es cuestion del programador no hacer nada o poner algun lockeo. Volviendo entonces al caso distribuido. Cuando desde M1 invoco a rectRemoto en M2, se ejecuta en M2, de la misma forma: si en M2 hay varios accediendo a ese objeto (que es local en M2, y remoto en M1), es lo mismo que pasa en cualquier Smalltalk, creo: es cuestion de programar si quiero contemplar ese caso o no. Como quiero tener cada vez mas proceso distribuido, y en paralelo (distribuido o no), he agregado a AjTalk el concepto de "agente" (lo podria haber llamado actor, por ahora quedo asi). Por ejemplo: Object agent: #MyAgent Es como una clase, pero cuando crea objetos, los crea normales, con un cambio: se cambio el proceso de enviarle un mensaje. Cuando: myAgent := MyAgent new. myAgent haceAlgoCuandoPuedas: usandoEsteArreglo cuando envio ese mensaje, lo coloco en una cola. El agente va procesando en paralelo mensajes de esa cola. Tranquilamente combinar distribuido y agentes. Desde M1 con host apuntando a M2, puedo hacer: myRemoteAgent := host evaluate: 'MyAgente new asRemote' 3. En el pastie que envie, esta el codigo de como hago la exportacion. Es host export: ClaseEnM1 Lo que hago es enviar el string que define a la clase, y se ejecuta en M2. Si esa clase deriva de otra que NO esta en M2, es responsabilidad del programador (todavia, estoy pensando alternativas), haber hecho antes: host export: ClaseEnM1 superclass No hay forma de saber (todavia) si en M2 YA esta esa clase o no. 4. Los parametros que paso al objeto remoto, son serializados (saca una copia que se reifica del otro lado). Si desde M1 hago objetoRemotoEnM2 haceDunga: obj1 yMasDunga: obj2 tanto obj1 como obj2 se serializan. Si quisiera que no viajaran, deberia poner (tengo que testear, no tengo un caso ahora): objetoRemotoEnM2 haceDunga: obj1 asRemote yMasDunga: obj2 asRemote 5. Queria seguir los pasos sugeridos por Mariano. Por explorar ese tema. Podria usarse, como presenta Mariano en su charla, para cuando hay poca memoria. Otra que se me ocurre, es para implementar todo un dominio de objetos en memoria, de forma transaparente. Por temas de limite de memoria, necesitaria no tener todos al mismo tiempo en memoria. Los cambios a los objetos en memoria, podria ir serializandolos, a un archivo de cambios binario. Tengo algunas ideas de implementacion, pero implica usar el objeto intermedio que comento Mariano. Yo veo a ese objeto intermedio como una celda en lo que era un Object Table. Quisiera ponerle ahi lo minimo, y como explique en otro email, que esa "celda"/Objeto intermedio apunte al real, o a un decorador del real (para poner mas conducta como la que sugeria Mariano, pero no toda en la celda, objeto intermedio). Pero aclaro: esto de serializar lo no usado, es ortogonal a lo de distribuido. Era para local, un experimento para seguir las ideas de Mariano y su equipo (pregunto, enlace del equipo? blog? otras publicaciones?) 6. No vi en detalle MapReduce, solo algo hace dos anios, jugando con MPI (Message Passing Interface), en un cluster. Pero apenas para hacer una demo y calcular algo. Si lo hiciera con AjTalk... hmmm... a ver seria algo como: myLocalAgent := MyLocalAgent new. "recibira los resultados" "y por cada hostN, haria" hostN export: MyWorkerClass. myRemoteWorker := hostN evaluate: 'MyWorkerClass new'. myRemoteWorker process: thisDataPartN sendingResultTo: myLocalAgent asRemote "para que no vaya serializado y el local agent siga aca, en M0, digamos" Se entendio? Cualquier cosa, me preguntan. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/17 Guillermo Schwarz <[email protected]> > Que rápido. Me parece que pasó menos de una semana. > > Unas preguntas: > > 1. ¿Cómo publicas los objetos que reciben mensajes remotos para ser > usados por las máquinas remotas? ¿Existe un servicio básico que indica > cuáles son etos objetos y los mensajes que están dispuestos a recibir? > 2. ¿Usas colas de mensajes? ¿Cómo haces en caso de que llegue un mensaje > a un objeto cuando aún está ejecutando el mensaje anterior? > 3. Cuando declaras una clase en M1 y la exportas a M2, ¿recompilas la > clase en M2 o simplemente envías el objeto compilado? > 4. Los objetos que son pasados como parámetro son siempre serializados o > también se puede enviar un proxy de ellos (por ejemplo podría ser "ob > asProxy") de modo que automáticamente se cree un proxy de ese objeto en > M2 apuntando al objeto en M1. En EJB eso se puede hacer aunque es una > mala práctica, porque luego es natural que el protocolo de comunicación > se vuelva "chatty". > 5. ¿Porqué quieres los objetos que no se han usado se serialicen? > ¿Quedan vivos los resultados que se enviaron a otra máquina? > 6. ¿Cómo implementarías map-reduce con AjTalk? Suponiendo que tengo un > arreglo de proxies en M0 donde cada elemento del arreglo tiene un proxy > a M1, M2, ... M10 (supogamos que son 10 máquinas) y que cada petición se > hace de manera asíncrona (cuando la respuesta se recibe se ejecuta un > bloque). ¿Consideras eso implementable? > > Tengo entendido que en Squeak existe un ambiente distribuido de objetos > llamado Croquet. Y bueno en Open Cobalt, que al parecer es un mundo > virtual construido sobre Croquet, se puede hacer mundos 3D sobre los que > se puede ejecutar aplicaciones Windows y compartirlas con otros > usuarios... > > http://en.wikipedia.org/wiki/Open_Cobalt > > Según recuerdo la gran idea de Croquet es que en vez de enviar los > objetos para ejecutar de manera remota, se puede enviar "la computación" > para ejecutarla localmente y de esa manera obtener un mejor desempeño. > > Saludos, > Guillermo. > > On Sun, 2010-10-17 at 17:44 -0300, Angel Java Lopez wrote: > > Hola gente! > > > > Ya tengo objetos distribuidos en mi pet project AjTalk: > > > > http://pastie.org/1213856 > > > > Puedo comunicar N maquinas, cada una puede ser cliente o servidora de > > otra maquina. > > Puedo declarar una clase en maquina M1, y exportarla a M2. > > Puedo ejecutar texto definido en M1, en la maquina M2. > > Puedo evaluar texto definido en M1, en la maquina M2, y serializar > > (como copia) el resultado calculado en M2, para que viaje y se > > reifique en M1. > > Puedo evaluar texto definido en M1, en la maquina M2, y pedirle que > > devuelva el proxy que apunta a ese objeto que queda en M2. > > Usando el proxy en M1, como un objeto mas, puedo enviar mensajes al > > objeto remoto que todavia reside en M2. > > > > Hay que mejorar puntos, pero la "base esta" ;-) > > > > Proximos pasos: investigar la idea de "objeto intermedio" de Mariano, > > implementarlo, implementar que los objetos que no se usan desde un > > tiempo se serializen, implementar transacciones de objetos como la > > describi en otro thread... pero tengo que ver en que orden, que > > tiempo. > > > > Nos leemos! > > > > Angel "Java" Lopez > > http://www.ajlopez.com > > http://twitter.com/ajlopez > > > > > > 2010/10/11 Andres Valloud <[email protected]> > > Ah, para clarificar. > > > > >> Che, si es esto > > > > esto = "tener proxies y mandar mensajes remotos a objetos sin > > perder > > la identidad del objeto", por ejemplo... > > > > >> a lo que Mariano se referia, no nos olvidemos de > > >> GemStone que hace no se, 25 años que esta con su base de > > objetos > > >> (esencialmente se puede ver como una imagen compartida > > entre N otras > > >> imagenes, con transacciones). Si eso > > > > > > eso = "resolver el problema de distribucion de mensajes a > > objetos > > distribuidos de manera razonablemente general, como por > > ejemplo lo > > hace GemStone"... > > > > >> es lo que aca se describio como > > >> "trivial", desde ya que de ninguna manera es trivial ese > > problema. > > >> Trivial podra ser una primera aproximacion a la > > serializacion, pero > > >> literalmente "objetos distribuidos" asi como en GemStone, > > ni ahi. > > > > > > Andres. > > > > > > > > 2010/10/11 Angel Java Lopez <[email protected]>: > > > Hola gente! > > > > > > Ah! Yo, por lo menos, nunca mencione GemStone (que alguien > > bueno de Sugar > > > (Smalltalk Users Group de Argentina) me comento en los > > noventa, el bueno de > > > Leandro Caniglia, recuerdo su implementacion en Luchetti, > > que recuerde). > > > > > > Lo que me gustaria (tengo codigo, pero no tengo test, asi > > que nada de > > > publicado ahora), es: > > > > > > anObject msg: par1 .... > > > > > > y anObject sea un proxy local, que deriva a un objeto > > residente en otra > > > maquina ese mensaje. El programador puede haberlo creado > > local (como para > > > probar su algoritmo en una sola maquina) o puede haberlo > > creado en otro nodo > > > de una red. En los casos de uso que tengo en mente, el > > programador sabe que > > > hay un costo en eso, asi que no esta conversando con esos > > objetos a cada > > > milisegundo. Es mas: te doy una tarea, despues, llegado el > > caso, en algun > > > momento, por otro canal, recibire una respuesta. > > > > > > Tambien quiero implementar: > > > > > > anObject msg: par1 ... > > > > > > y que anObject por abajo, derive el mensaje a uno, a todos, > > o a algunos de > > > otros objetos, remotos o locales. > > > > > > Y algo ortogonal a todo eso, que tengo implementando, pero > > tendria que > > > unirlo con lo de remoting: > > > > > > anObject msg: par1 ... > > > > > > que anObject reciba el mensaje, y lo atienda en su propio > > thread. Recibe el > > > mensaje, lo coloca en una cola en memoria, y lo atiende en > > su propio thread, > > > cuando este disponible. El objeto que envie el mensaje sigue > > su camino. Esto > > > permite implementar algoritmos en paralelo, sin el tema "te > > envio algo, y te > > > espero a que termines para seguir yo". > > > > > > Interesante el paper que enviaste, lo conocia, pero no lo > > recordaba. Ya lo > > > mando a twitter. > > > > > > No entendi si "si es esto a lo que Mariano se referia", y > > "Si eso es lo que > > > aca", digo, no entendi "si esto" en la primera frase se > > refiere a lo mismo a > > > lo que se refiere "si eso", en la segunda. > > > > > > Nos leemos! > > > > > > Angel "Java" Lopez > > > http://www.ajlopez.com > > > http://twitter.com/ajlopez > > > > > > 2010/10/11 Andres Valloud <[email protected]> > > >> > > >> Che, si es esto a lo que Mariano se referia, no nos > > olvidemos de > > >> GemStone que hace no se, 25 años que esta con su base de > > objetos > > >> (esencialmente se puede ver como una imagen compartida > > entre N otras > > >> imagenes, con transacciones). Si eso es lo que aca se > > describio como > > >> "trivial", desde ya que de ninguna manera es trivial ese > > problema. > > >> Trivial podra ser una primera aproximacion a la > > serializacion, pero > > >> literalmente "objetos distribuidos" asi como en GemStone, > > ni ahi. > > >> > > >> Ah, hablando de esto, hace poco encontre este articulo que > > me parecio > > >> interesante. > > >> > > >> http://www.rgoarchitects.com/Files/fallacies.pdf > > >> > > >> 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 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 clubSmalltalk > > [email protected] > > > > http://www.clubSmalltalk.org > > -- > Simplex Veri Sigillum > > -- > 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
