Hola gente! Si, lo he visto, no solo en Smalltalk.
La idea es hacerlo transparente, ponerlo a nivel de VM, sin necesidad de eso, y explorar que se puede hacer de interesante con eso. Por ejemplo, una VM con esa capacidad, puedo implementar otro lenguaje encima de esa VM, no necesariamente Smalltalk. Y no quiero enviar todos los objetos relacionados. Solo los que necesito poner en otra maquina. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/6 Guillermo Schwarz <[email protected]> > En Smalltalk lo que dices de migrar un objeto de una máquina a otra es (o > debería ser) trivial. > > 1. Se serializa la clase en la máquina 1 (representación en texto). Hay > bibliotecas para hacer eso que recojen incluso todos los objetos > relacionados. Se debe incluir el método y la línea que estaba ejecutando, > eso es trivial con thisContext. > > 2. Se envía a la máquina remota, se deserializa y se le indica al > "thisContext" que continúe ejecutando. > > No lo he probado, pero debería funcionar. ;-) > > Lo que sí he probado es tener objetos remotos persistentes. Es muy > parecido. > > 1. Creo una clase PersistentRemoteDictionary que serialice los objetos y > lso envíe a través de un socket a un servidor ejecutando C++ o Java. > 2. En el servidor coloco GDBM o JDBM e implemento put y get. (#at:put: y > #at: sería el equivalente en Smalltalk). > > Listo. ;-) > > Ahora cualquier Dictionary se puede reemplazar > por PersistentRemoteDictionary y puedo tener todos los clientes Smalltalk > que quiera compartiendo los objetos a través de un servidor, como un > PoorManObjectDatabase y el desempeño es como correr local, porque los > sockets son super eficientes y JDBM también. > > Saludos, > Guillermo. > > 2010/10/6 Angel Java Lopez <[email protected]> > >> Hola gente! >> >> Guillermo, no, todavia no lo he intentado, lo de los objetos remotos. >> >> Con respecto a los threads del sistema operativo, no habria problema en >> reimplementar el dispatching de los mensajes a los agentes de esta forma: >> >> - En vez de tener una cola por agente, hay una sola cola con <mensaje>, >> con <mensaje, receptor> >> - N threads consumiendo esa cola, y enviando el mensaje al agente >> correspondiente. >> >> De nuevo, es un cambio en la VM, nada de lo escrito en AjTalk con agentes >> deberia cambiar, tengo los tests de TDD para asegurarme que eso se cumpla >> (espero ... :-). >> >> No estoy tan seguro que los threads del sistema operativo sean los mismos >> que la VM: una VM tiene un concepto de thread mas logico aun. Solo un thread >> de la VM activo necesitaria un thread del sistema operativo. Por lo menos, >> en .NET, hay una propiedad del thread llamada ManagedId, que recuerde, que >> no parece tener una aplicacion directa a tal thread del sistema operativo. >> >> Lo de objetos remotos, lo tengo en AjShap, todavia me falta ponerlo en >> AjTalk. >> >> Me gustaria: >> >> - Definir una clase en la maquina M, poder instanciar un nuevo objeto en >> la maquina N (viajando de alguna forma la definicion de la clase definida). >> - Definir una clase en la maquina M, crear una instancia en esa maquina, y >> hacerla viajar a la maquina N (mas dificil: si la instancia tiene >> referencias a otros objetos, que objetos hacemos viajar a N y cuales >> permanecen como una referencia remota en N al objeto en M?). >> >> Si traslado lo de AjSharp, podria ponerlo en AjTalk como en el nodo M >> >> MiClase at: <objetoquedescribeelnodoremotoN> new: .... >> >> Me quedaria en M un objeto cuyos mensajes son reenviados a la instancia >> recien creada del nodo N. >> >> >> Nos leemos! >> >> Angel "Java" Lopez >> http://www.ajlopez.com >> http://twitter.com/ajlopez >> >> >> Nos leemos! >> >> Angel "Java" Lopez >> http://www.ajlopez.com >> http://twitter.com/ajlopez >> >> >> 2010/10/6 Guillermo Schwarz <[email protected]> >> >>> Tengo entendido que la mayor parte de los sistemas operativos tienen un >>> limite de entre 256 y 1024 threads, e incluso algunas versiones de linux >>> soportan 8192 threads y no tienen problemas de desempeño. >>> >>> Pero una vm de smalltalk debe tener unos 5000 objetos activos (no lo he >>> revisado pero no creo que pueda tener menos), y un seaside con 10 mil >>> conexiones activas se iría de espaldas rapidamente usando tu diseño. >>> >>> Si queremos tener arquitecturas escalables, debemos limitar el uso de >>> recursos que a nivel del sistema operativo son limitados. >>> >>> A todo esto, tu diseño parece que podría de manera trivial publicar >>> objetos para ser llamados de manera remota. ?lo haz intentado? >>> >>> Saludos, >>> Guillermo Schwarz. >>> >>> El 06-10-2010, a las 11:18, Angel Java Lopez <[email protected]> >>> escribió: >>> >>> Hola gente! >>> >>> Guillermo, me parece interesante ponerlo ya a nivel de la expresividad de >>> un lenguaje, que esa conducta "envio mensaje y sigo con mis cosas" se vea >>> como natural, ya puesto en el mensaje. Podria implementar eso directamente >>> en el proceso de mensaje de agente1, para que sea transparente para el >>> llamador, pero me parecio interesante (me tomo menos de una hora, usando >>> TDD) directamente ponerlo en la VM. >>> >>> Los threads en .NET son, digamos, logicos. Lo mismo, que recuerde, en >>> Java. Las VM luego mapearan los threads a lo que haya disponible en los >>> sistemas operativos, hardware, y demas que se encuentren hoy o el dia de >>> maniana. Bloquear un thread, no lo deja "ocupado". Y aun los threads de un >>> sistema operativo, son, digamos, virtuales. Lo real es la asignacion de un >>> thread a un procesador. Lo que si consume un thread es memoria en algun >>> lado, para mantener su estado, aun cuando este suspendido. Pero imagino que >>> la parte del leon, en eso, se la lleva el proceso, mas que el thread. >>> >>> Puedo copiar objetos, pero la idea es: si copio objetos y los coloco en >>> la misma maquina, puedo mejorar algo el rendimiento de la aplicacion. Pero >>> mas interesante de explorar, es copiar los objetos en OTRAS maquinas, de >>> forma que sea transparente >>> >>> agente1 doSomething: param1 with: .... >>> >>> que agente1 este local o remoto. Por supuesto, el programador de la >>> aplicacion debera ver que esa llamada tiene un costo. Pero mi idea, es que >>> si el agente1 es local o remoto, sea algo que se decida en otro lado del >>> codigo (o configuracion), sin tener que cambiar el codigo de la aplicacion. >>> De esta forma, puedo probar un algoritmo, aplicacion, de forma local, y >>> luego, comenzar a distribuirla y hacer escalamiento horizontal. El ejemplo >>> que uso es un Web Crawler. Ahi en las referencias que envia, habia algunas >>> implementaciones. >>> >>> Tambien, la idea (tengo algo en AjSharp implementado) es que agente1 en >>> realidad, sea local, y haga una especie de load balancing con varios objetos >>> remotos. Por ejemplo, en un web crawler, podria enviar >>> >>> downloader downloadUrl: ´ <http://mycompany.com>http://mycompany.com´ >>> >>> y downloader por abajo, envia ese trabajo (bajar tal pagina) a si mismo, >>> o enviarlo a cualquiera de los 400 downloaders que tendria en mi >>> laboratorio... mmmbuajjajaja... :-) >>> >>> Tanto AjSharp como AjTalk (y otros Aj ... :-)... como AjBasic, AjGenesis, >>> AjLisp, AjProlog....), se pueden reimplementar en Java: practicamente no >>> estoy usando nada especial de .NET, por ahora. Por ejemplo, cuando comence a >>> escribir algunos de esos, en .NET tenia Generics y en Java todavia no: y no >>> use generics, recien ahora lo estoy usando minimamente. En el caso de >>> objetos distribuidos, si, hay algo que uso para hacerlo rapido: Remoting >>> binario en .NET, tendria que investigar el estado del arte de la >>> serializacion en Java. >>> >>> Nos leemos! >>> >>> Angel "Java" Lopez >>> <http://www.ajlopez.com>http://www.ajlopez.com >>> <http://twitter.com/ajlopez>http://twitter.com/ajlopez >>> >>> 2010/10/6 Guillermo Schwarz < <[email protected]> >>> [email protected]> >>> >>>> Autopoyesis es copia, no autoorganización. Que conduzca a la >>>> autoorganización es otra cosa. >>>> >>>> ¿Como es eso de que te llamas Angel Java Lopez e implementas un >>>> Smalltalk asíncrono en C#? ;-) >>>> >>>> ¿Porqué no usas colas de mensajes y un colocas los objetos sobre un >>>> thread en la medida que lo van necesitando? Sí, lo de lo mensajes lo >>>> hiciste, y lo del watermark (que se queden pegados los enviadores cuando se >>>> llena la cola también), lo interesente es que los objetos enviadores se >>>> queden bloqueados pero los threads no, para reutilizar los threads con >>>> otros >>>> objetos. >>>> >>>> (Eventualemtne sospecho que los sistemas operativos harán esto, pero en >>>> el intertanto...) >>>> >>>> Podrías además crear copias de los objetos que reciben los mensajes para >>>> que operen más rápido. Claro que todo esto serían un overkill si no lo >>>> aplicas en algo que lo necesite, como por ejemplo pdoría ser en slashdot. >>>> >>>> Saludos, >>>> Guillermo. >>>> >>>> 2010/10/6 Angel Java Lopez < <[email protected]> >>>> [email protected]> >>>> >>>>> Hola gente! >>>>> >>>>> El termino autopoyesis me parece innecesario, ya estaba el termino >>>>> autoorganizacion. Con eso basta. Hmmm... supongo que el clasico a leer >>>>> sobre >>>>> la vida, es el clasico de Monod, Azar y Necesidad. Supongo que un tema >>>>> relacionado a intencionalidad en organismos y evolucion biologica, seria >>>>> teleologia. Leeria ahi a Ernst Mayr, que distingue varias acepciones de >>>>> esa >>>>> palabra. >>>>> >>>>> Con respecto a los mensajes y su envio, en este thread Valloud habia >>>>> mencionado algo como "un objeto envia un mensaje a otro, y se queda >>>>> esperando la respuesta". Siempre me parecio interesante ir a explorar otro >>>>> camino "un objeto envia un mensaje a otro" y ya esta. Es asi como >>>>> funcionan >>>>> las partes de los sistemas vivos. >>>>> >>>>> En mi caso, lo estoy implementando en mi VM pet project, AjTalk [1]. >>>>> Tengo algo como >>>>> >>>>> Object agent:.... >>>>> en lugar >>>>> Object subclass:.... >>>>> >>>>> Lo llame agent como podria llamarlo de otra forma. Entonces, los >>>>> objetos de esa clase que se define, tienen metodos, todo igual, pero >>>>> cuando >>>>> uno envia un mensaje tipo >>>>> >>>>> agente1 msg: par1 with: ... "o lo que sea" >>>>> >>>>> el enviador del mensaje no se queda esperando la devolución. Y el >>>>> objeto agente va atendiendo los mensajes que le llegan de a uno >>>>> (actualmente, en un thread aparte, para cada agente, pero podria cambiar >>>>> la >>>>> implementacion). También implementé que la cola de mensajes del agente, >>>>> tenga un tamaño limitado, asi si hay varios que producen mensajes para ese >>>>> agente, y la cola de mensajes se llena, automaticamente se van >>>>> suspendiendo >>>>> a los threads/procesos del objetos enviadores, reanundando su actividad ni >>>>> bien tienen lugar en para dejar su mensaje en la cola de mensajes del >>>>> agente. Espero producir asi una auto-regulacion de las velocidades de >>>>> produccion y atencion de los mensajes. >>>>> >>>>> La idea, es conseguir tambien objetos y agentes distribuidos, como en >>>>> AjSharp [2], en varias maquinas. Pero para eso me falta un poco... :-) >>>>> >>>>> [1] <http://code.google.com/p/ajtalk>http://code.google.com/p/ajtalk >>>>> [2] <http://ajlopez.wordpress.com/category/ajsharp/> >>>>> http://ajlopez.wordpress.com/category/ajsharp/ >>>>> >>>>> >>>>> Nos leemos! >>>>> >>>>> Angel "Java" Lopez >>>>> <http://www.ajlopez.com>http://www.ajlopez.com >>>>> <http://twitter.com/ajlopez>http://twitter.com/ajlopez >>>>> >>>>> >>>>> 2010/10/6 Guillermo Schwarz < <[email protected]> >>>>> [email protected]> >>>>> >>>>>> Suena a que tiraste la toalla. >>>>>> >>>>>> Lo de la intencionalidad está bien para los seres humanos, pero en el >>>>>> caso de la naturaleza en vez de intencionalidad hay oportunidad (nichos >>>>>> ecológicos) que son llenados por elementos con autopoyesis >>>>>> <http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm> >>>>>> http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm >>>>>> >>>>>> Esto es interesante para el punto en discusión porque al ser Alan Kay >>>>>> un biólogo molecular y al tratar de modelar los objetos como si fueran >>>>>> células que responden a mensajes, la idea era que el comportamiento >>>>>> "emergiera". Esto es también uno de los objetivos de eXtreme Programming, >>>>>> que emerja la auto-organización del programa, por más extraño que resulte >>>>>> para una visión donde todo tiene intencionalidad. >>>>>> >>>>>> Un ejemplo de la vida real en el mundo del software son los proyectos >>>>>> open source. No existe una autoridad central que los organice y sólo en >>>>>> la >>>>>> medida que van teniendo éxito (más gente los usa) van mejorando. Desde el >>>>>> punto de vista de la "intencionalidad" eso no podría funcionar nunca, ni >>>>>> los >>>>>> wikis, etc. >>>>>> >>>>>> >>>>>> <http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm> >>>>>> Saludos, >>>>>> Guillermo. >>>>>> >>>>>> On Tue, Oct 5, 2010 at 11:14 PM, Andres Valloud >>>>>> <<[email protected]> >>>>>> [email protected]> wrote: >>>>>> >>>>>>> > Si todas las cosas dependen de las intenciones, ¿dónde dejas la ley >>>>>>> de >>>>>>> > las consecuencias indeseadas (unintended consequences)? >>>>>>> >>>>>>> No por querer volar logro despegar el chancho. >>>>>>> >>>>>>> Andres. >>>>>>> >>>>>>> -- >>>>>>> To post to this group, send email to >>>>>>> <[email protected]>[email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> <clubsmalltalk%[email protected]> >>>>>>> [email protected] >>>>>>> >>>>>>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Saludos cordiales, >>>>>> >>>>>> Guillermo Schwarz >>>>>> Sun Certified Enterprise Architect >>>>>> >>>>>> -- >>>>>> To post to this group, send email to <[email protected]> >>>>>> [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> <clubsmalltalk%[email protected]> >>>>>> [email protected] >>>>>> >>>>>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>>>>> >>>>> >>>>> -- >>>>> To post to this group, send email to <[email protected]> >>>>> [email protected] >>>>> To unsubscribe from this group, send email to >>>>> <clubsmalltalk%[email protected]> >>>>> [email protected] >>>>> >>>>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Saludos cordiales, >>>> >>>> Guillermo Schwarz >>>> Sun Certified Enterprise Architect >>>> >>>> -- >>>> To post to this group, send email to <[email protected]> >>>> [email protected] >>>> To unsubscribe from this group, send email to >>>> <clubsmalltalk%[email protected]> >>>> [email protected] >>>> >>>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>>> >>> >>> -- >>> To post to this group, send email to <[email protected]> >>> [email protected] >>> To unsubscribe from this group, send email to >>> <[email protected]> >>> [email protected] >>> >>> <http://www.clubSmalltalk.org>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 >> > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > 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
