Pero de alguna manera hay que decirle que los números y los strings no los "remotee".
Como son más los objetos locales que los remotos y deseas usar los objetos remotos como si fueran locales, proxy está pintado para eso. No creo que sea necesario intervenir la VM. De hecho la experiencia en Java en ese caso ha sido desastrosa: Usar generación de código que interviene las llamadas para hacerlas remotas, con todos sus stubs y todas esas payasadas, resutla ser muy pesado, mucho código generado (CORBA) y cuando hay algún tipo de error por que el generador de código que interviene las llamadas para "remotearlas" ha fallado o generado código incompatible con "algo", put your head between your legs and kiss your but goodbye ;-) En el caso de usar proxy es trivial y liviano y si el mecanismo funciona para uno, funciona para todos. Saludos, Guillermo. 2010/10/6 Angel Java Lopez <[email protected]> > 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]<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] http://www.clubSmalltalk.org
