Blog
Locked
123456
123456
 
|
+1
Gerardo Richarte escribió: > On 10/06/2010 08:16 PM, Guillermo Schwarz wrote: >> En Smalltalk lo que dices de migrar un objeto de una máquina a otra es >> (o debería ser) trivial. > che trivial, > te invito a hacerlo > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
Hola gente!
Guillermo, son decisiones personales. Hace varios anios vi la maquina virtual de Squeak, e implementar cada cosa que se me ocurria, por lo menos a mi, me tomaba mas tiempo que armar una maquina virtual mia, directamente. Al llegar a una maquina virtual ya armada, es como ya tomaron decisiones, que quien sabe si los voy a encontrar alineadas con lo que quiero. Vean que hasta a la gente de Valloud se les complican algunas cosas, como pasar de 32 a 64 bits, reimplementando la VM que ellos mismos armaron. Lo mio es mas artesanal. Un subproducto interesante, por lo menos para mi, es el gran trabajo de TDD que he aprendido a hacer. Igual, ahora, el enfasis mio esta puesto en practicar armar VM, no en aprender como implementarlo en Smalltalk o Squeak una feature. Por eso, durante varios meses, apenas mencione este tema en la lista, porque veia que aca era mas orientado a Smalltalk. Solo comence a mencionarlo, cuando se planteo el tema de la nueva VM que comento Leo di Marco hace un par de meses, y ahora, que se planteo que es objeto, y Valloud comento lo de enviar un mensaje y quedarse esperando. Y al armar la VM artesanalmente, es como que uno va viendo crecer el bebito de chiquito, y no lo encuentra ya grandulon y fumando con barba ;-) Podria decirse que es un balanceador de carga. La idea es que: - Puedo tener trabajo para hacer, en una aplicacion o varias, corriendo en una maquina - Si aparecen maquinas por ahi, que las aplicaciones que esten corriendo puedan derivar trabajo a esas otras maquinas - Que el programador (pobre como yo .. ;-) que tiene una sola maquina, igual pueda correr la aplicacion apenas cambiandola - Que el programador, cuando sepa que hay mas maquinas o que pueden aparecer dinamicamente, pueda, apenas cambiando algo, aprovecharse de esos nuevos recursos - Una maquina nueva, no sabe de antemano que elementos (clases, objetos, metodos con codigo o compilados, lo que sea) necesita, se lo debe poder enviar en el momento Tengo mis dudas de llamarlo balanceador de carga. Pero si, se aproxima por lo menos. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/7 Guillermo Schwarz <[hidden email]> Bueno sería "kiego divegtigme" o "quiero divertirme", lo otro no sé qué sería... ;-) -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Donde "reimplementar" quiere decir, entre otras cosas, "crear un
monton de cosas que en 32 bits no existen" :). 2010/10/7 Angel Java Lopez <[hidden email]>: > Hola gente! > > Guillermo, son decisiones personales. Hace varios anios vi la maquina > virtual de Squeak, e implementar cada cosa que se me ocurria, por lo menos a > mi, me tomaba mas tiempo que armar una maquina virtual mia, directamente. Al > llegar a una maquina virtual ya armada, es como ya tomaron decisiones, que > quien sabe si los voy a encontrar alineadas con lo que quiero. > > Vean que hasta a la gente de Valloud se les complican algunas cosas, como > pasar de 32 a 64 bits, reimplementando la VM que ellos mismos armaron. > > Lo mio es mas artesanal. Un subproducto interesante, por lo menos para mi, > es el gran trabajo de TDD que he aprendido a hacer. > > Igual, ahora, el enfasis mio esta puesto en practicar armar VM, no en > aprender como implementarlo en Smalltalk o Squeak una feature. Por eso, > durante varios meses, apenas mencione este tema en la lista, porque veia que > aca era mas orientado a Smalltalk. Solo comence a mencionarlo, cuando se > planteo el tema de la nueva VM que comento Leo di Marco hace un par de > meses, y ahora, que se planteo que es objeto, y Valloud comento lo de enviar > un mensaje y quedarse esperando. > > Y al armar la VM artesanalmente, es como que uno va viendo crecer el bebito > de chiquito, y no lo encuentra ya grandulon y fumando con barba ;-) > > Podria decirse que es un balanceador de carga. La idea es que: > > - Puedo tener trabajo para hacer, en una aplicacion o varias, corriendo en > una maquina > - Si aparecen maquinas por ahi, que las aplicaciones que esten corriendo > puedan derivar trabajo a esas otras maquinas > - Que el programador (pobre como yo .. ;-) que tiene una sola maquina, igual > pueda correr la aplicacion apenas cambiandola > - Que el programador, cuando sepa que hay mas maquinas o que pueden aparecer > dinamicamente, pueda, apenas cambiando algo, aprovecharse de esos nuevos > recursos > - Una maquina nueva, no sabe de antemano que elementos (clases, objetos, > metodos con codigo o compilados, lo que sea) necesita, se lo debe poder > enviar en el momento > > Tengo mis dudas de llamarlo balanceador de carga. Pero si, se aproxima por > lo menos. > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com > http://twitter.com/ajlopez > > > 2010/10/7 Guillermo Schwarz <[hidden email]> >> >> Bueno sería "kiego divegtigme" o "quiero divertirme", lo otro no sé qué >> sería... ;-) >> Supongo que lo que estás haciendo es un balanceador de carga, de otra >> manera no se entiende porque el nodo M1 no tiene el código ya alojado y >> simplemente recibe una petición en texto mediante un socket. >> Entonces si estás haciendo un balanceador de carga en el que te das cuenta >> que una operación tomará mucho tiempo y muchos recursos, creas el objeto en >> otro nodo y lo hechas a correr. >> Lo mismo podría pasar si tienes 5 porcesos que piensas que se van a >> demorar 1 segundo cada uno y lleva 1 minuto cada uno y no termina, si tienes >> 4 CPUs desocupadas los puedes mandar a terminar allá y quedarte solo con >> uno. >> Lo que yo haría sería hacerlo más rápido con Proxy y cunado esté listo ver >> si lo implemento en la VM sale más rápido. Debería, para que valga la pena >> implementarlo a nivel de VM, pero sospecho que no.¿Porqué? Porque alguna vez >> corrí Squeak dentro de Squeak. La VM de Squeak está escrita en Squeak. No sé >> si eso te dice algo. Si se te ocurre una optimización, es mucho más fácil >> escribirla en Squeak que en C o assembly language. Luego pasarla a la VM >> debiera ser trivial. >> A nivel de la CPU todos los objetos son bytes, casi no hay abstracción. A >> nadie se le ocurriría impementar un webserver en assembly language. ¿Cuál >> sería el objetivo de aprender a interactuar con elementos de tan bajo nivel >> si en la práctica todo eso puede ser reescrito en Squeak en 16 semanas? >> "By following this plan, facilities became available just as they were >> needed. For example, the interpreter and object memory were debugged using a >> temporary memory allocator that had no way to reclaim garbage. However, >> since the system only executed a few byte codes, it never got far enough to >> run out of memory. Likewise, while the translator was being prepared, most >> of the bugs in the interpreter and object memory were found and fixed by >> running them in Smalltalk. >> It was easy to stay motivated, because the virtual machine, running inside >> Apple Smalltalk, was actually simulating the byte codes of the transformed >> image just five weeks into the project. A week later, we could type "3 + 4" >> on the screen, compile it, and print the result, and the week after that the >> entire user interface was working, albeit in slow motion. We were writing >> the C translator in parallel on a commercial Smalltalk, and by the eighth >> week, the first translated interpreter displayed a window on the screen. Ten >> weeks into the project, we "crossed the bridge" and were able to use Squeak >> to evolve itself, no longer needing to port images forward from Apple >> Smalltalk. About six weeks later, Squeak's performance had improved to the >> point that it could simulate its own interpreter and run the C translator, >> and Squeak became entirely self-supporting." >> >> Fuente: http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/squeak.html >> Saludos, >> Guillermo. >> >> 2010/10/7 Angel Java Lopez <[hidden email]> >>> >>> Hola gente! >>> >>> Si, con respecto a los numeros y strings. >>> >>> Igual, todavia no llego un caso de uso que necesite que un objeto se cree >>> aca en N, y luego viaje a M. Mis casos de uso son: la clase X esta en N, y >>> necesito crear un objeto/agente que trabaje en nodo M1 (y quizas otro en M2 >>> y asi), aun cuando esos nodos no conozcan la clase X. >>> >>> E insisto, quiero hacerlo en la VM! Quiero divegtigme con eso! ;-)... >>> >>> Y en otros casos donde lo hice (el tema de levantar objetos remotos, en >>> otros nodos, en el caso de AjSharp), todavia no tuve los problemas que >>> mencionas. Mi approach no genera codigo, solamente uso dos o tres clases >>> escritas en la vm base (en este caso la VM .NET) que implementan las >>> primitivas necesarias para eso, y voila. Si alguna vez veo que esas clases >>> las puedo remover (luego de haberlas usado como apoyo de scaffolding), y >>> pasar a implementar esa funcionalidad en el lenguaje de "arriba" (AjTalk en >>> este caso) lo hare. Mientras, este approach me permite seguir jugando, >>> rapidamente. >>> >>> Nos leemos! >>> >>> Angel "Java" Lopez >>> http://www.ajlopez.com >>> http://twitter.com/ajlopez >>> >>> >>> 2010/10/7 Guillermo Schwarz <[hidden email]> >>>> >>>> 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 <[hidden email]> >>>>> >>>>> 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 <[hidden email]> >>>>>> >>>>>> 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 <[hidden email]> >>>>>>> >>>>>>> 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 <[hidden email]> >>>>>>>> >>>>>>>> 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 <[hidden email]> >>>>>>>> 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´ >>>>>>>> >>>>>>>> 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://twitter.com/ajlopez >>>>>>>> >>>>>>>> 2010/10/6 Guillermo Schwarz <[hidden email]> >>>>>>>>> >>>>>>>>> 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 <[hidden email]> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> [2] http://ajlopez.wordpress.com/category/ajsharp/ >>>>>>>>>> >>>>>>>>>> Nos leemos! >>>>>>>>>> >>>>>>>>>> Angel "Java" Lopez >>>>>>>>>> http://www.ajlopez.com >>>>>>>>>> http://twitter.com/ajlopez >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/10/6 Guillermo Schwarz <[hidden email]> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> 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. >>>>>>>>>>> Saludos, >>>>>>>>>>> Guillermo. >>>>>>>>>>> On Tue, Oct 5, 2010 at 11:14 PM, Andres Valloud >>>>>>>>>>> <[hidden email]> 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 >>>>>>>>>>>> [hidden email] >>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>> [hidden email] >>>>>>>>>>>> >>>>>>>>>>>> http://www.clubSmalltalk.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Saludos cordiales, >>>>>>>>>>> >>>>>>>>>>> Guillermo Schwarz >>>>>>>>>>> Sun Certified Enterprise Architect >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> To post to this group, send email to >>>>>>>>>>> [hidden email] >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> [hidden email] >>>>>>>>>>> >>>>>>>>>>> http://www.clubSmalltalk.org >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> To post to this group, send email to >>>>>>>>>> [hidden email] >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [hidden email] >>>>>>>>>> >>>>>>>>>> http://www.clubSmalltalk.org >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Saludos cordiales, >>>>>>>>> >>>>>>>>> Guillermo Schwarz >>>>>>>>> Sun Certified Enterprise Architect >>>>>>>>> >>>>>>>>> -- >>>>>>>>> To post to this group, send email to [hidden email] >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> [hidden email] >>>>>>>>> >>>>>>>>> http://www.clubSmalltalk.org >>>>>>>> >>>>>>>> -- >>>>>>>> To post to this group, send email to [hidden email] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [hidden email] >>>>>>>> >>>>>>>> http://www.clubSmalltalk.org >>>>>>>> >>>>>>>> -- >>>>>>>> To post to this group, send email to [hidden email] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [hidden email] >>>>>>>> >>>>>>>> http://www.clubSmalltalk.org >>>>>>> >>>>>>> -- >>>>>>> To post to this group, send email to [hidden email] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [hidden email] >>>>>>> >>>>>>> http://www.clubSmalltalk.org >>>>>> >>>>>> >>>>>> -- >>>>>> Saludos cordiales, >>>>>> >>>>>> Guillermo Schwarz >>>>>> Sun Certified Enterprise Architect >>>>>> >>>>>> -- >>>>>> To post to this group, send email to [hidden email] >>>>>> To unsubscribe from this group, send email to >>>>>> [hidden email] >>>>>> >>>>>> http://www.clubSmalltalk.org >>>>> >>>>> -- >>>>> To post to this group, send email to [hidden email] >>>>> To unsubscribe from this group, send email to >>>>> [hidden email] >>>>> >>>>> http://www.clubSmalltalk.org >>>> >>>> >>>> -- >>>> Saludos cordiales, >>>> >>>> Guillermo Schwarz >>>> Sun Certified Enterprise Architect >>>> >>>> -- >>>> To post to this group, send email to [hidden email] >>>> To unsubscribe from this group, send email to >>>> [hidden email] >>>> >>>> http://www.clubSmalltalk.org >>> >>> -- >>> To post to this group, send email to [hidden email] >>> To unsubscribe from this group, send email to >>> [hidden email] >>> >>> http://www.clubSmalltalk.org >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Gerardo Richarte
¿Y tú que parte harías?
¿Probarlo? ;-) On Thu, 2010-10-07 at 14:07 -0300, Gerardo Richarte wrote: > On 10/06/2010 08:16 PM, Guillermo Schwarz wrote: > > En Smalltalk lo que dices de migrar un objeto de una máquina a otra es > > (o debería ser) trivial. > che trivial, > te invito a hacerlo > -- Simplex Veri Sigillum -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
2010/10/8 Guillermo Schwarz <[hidden email]> ¿Y tú que parte harías? Uy! - si necesitas beta testers avisa, yo tambien me prendo ;-) -- Callarum largo vivurum
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Primero hay que ponerse de acuerdo en qué tipo de implementación vamos a
hacer: 1. Proxy que llame a un objeto remoto que ya existe en el destino (similar a EJB). 2. Proxy que vaya hasta el servidor y cree una instancia de una clase que no existe, para lo cual se requiere que el destino le pregunte al gatillador dónde está la definición de la clase, la cargue, la compile y la instancie. 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? ¿Que corran en el servidor que se indique en duro? ¿Hacer un balanceador de carga? Si los requerimientos no están claros se llegará a un engendro, pero si están claros, las decisiones de diseño serán las obvias, podremos implementar los prototipos, probarlos y no creo que sean más de un par de días tenerlo funcionando. Saludos, Guillermo. On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: > > > 2010/10/8 Guillermo Schwarz <[hidden email]> > ¿Y tú que parte harías? > > ¿Probarlo? > > ;-) > > -- > > Simplex Veri Sigillum > > > > > Uy! - si necesitas beta testers avisa, yo tambien me prendo > > > ;-) > > > -- > Callarum largo vivurum > > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org -- Simplex Veri Sigillum -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola gente!
Interesante... el caso de uso que trato de pensar, es un Web Crawler distribuido: http://ajlopez.wordpress.com/2008/05/25/web-crawler-example-using-dss-decentralized-software-services/ http://ajlopez.wordpress.com/2010/02/22/web-crawler-using-agents-and-ajsharp/ http://ajlopez.wordpress.com/2009/03/09/distributed-web-crawler-using-ajmessages/ Otro seria el calculo distribuido de algun render de imagen. Un caso mas sencillo, en paralelo seria un fractal: http://ajlopez.wordpress.com/2008/12/26/fractals-using-mpinet-and-hpc/ Un render en paralelo: http://blogs.msdn.com/b/pfxteam/archive/2008/06/04/8573863.aspx que podria transformarse en distribuido Alguno de esos podria implementar en Smalltalk con el approach de Guillermo, creo que con el punto 2. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/8 Guillermo Schwarz <[hidden email]> Primero hay que ponerse de acuerdo en qué tipo de implementación vamos a -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
Dale, la opción 3 suena piola. El requerimiento sería algo así como:
"Implementar el mensaje #executeAt: anIpAddress port: aPort en Process para que pause la ejecución, se lleve el thread con los objetos en el scope a la otra imagen y retome la ejecución del punto de partida." Me sumo al programa de beta testers para cuando esté listo en un par de días. Saludos, Andrés Guillermo Schwarz escribió: > Primero hay que ponerse de acuerdo en qué tipo de implementación vamos a > hacer: > > 1. Proxy que llame a un objeto remoto que ya existe en el destino > (similar a EJB). > 2. Proxy que vaya hasta el servidor y cree una instancia de una clase > que no existe, para lo cual se requiere que el destino le pregunte al > gatillador dónde está la definición de la clase, la cargue, la compile y > la instancie. > 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? > ¿Que corran en el servidor que se indique en duro? ¿Hacer un balanceador > de carga? > > Si los requerimientos no están claros se llegará a un engendro, pero si > están claros, las decisiones de diseño serán las obvias, podremos > implementar los prototipos, probarlos y no creo que sean más de un par > de días tenerlo funcionando. > > Saludos, > Guillermo. > > On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: >> >> 2010/10/8 Guillermo Schwarz <[hidden email]> >> ¿Y tú que parte harías? >> >> ¿Probarlo? >> >> ;-) >> >> -- >> >> Simplex Veri Sigillum >> >> >> >> >> Uy! - si necesitas beta testers avisa, yo tambien me prendo >> >> >> ;-) >> >> >> -- >> Callarum largo vivurum >> >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to clubSmalltalk >> +[hidden email] >> >> http://www.clubSmalltalk.org > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Ah! Me olvide de preguntar:
No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de Guillermo? Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/8 andres <[hidden email]> Dale, la opción 3 suena piola. El requerimiento sería algo así como: "Implementar el mensaje #executeAt: anIpAddress port: aPort en Process para que pause la ejecución, se lleve el thread con los objetos en el scope a la otra imagen y retome la ejecución del punto de partida." Me sumo al programa de beta testers para cuando esté listo en un par de días. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info:
1. Si, cubierto por Opentalk. 2. Opentalk cubre esto parcialmente, creo que se podía trabajar con clases como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las dos imágenes puede haber versiones distintas de la misma clase es un problema. 3. No que yo sepa. El tema es que cuanto mas "transparente" te quieras volver para el programador, mas decisiones tenés que tomar a priori (que muchas veces no se pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de distribuir objetos por copia o por referencia es un mundo en si mismo. Saludos, Andrés Angel Java Lopez escribió: > Ah! Me olvide de preguntar: > > No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de Guillermo? > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com > http://twitter.com/ajlopez > > 2010/10/8 andres <[hidden email]> > >> Dale, la opción 3 suena piola. El requerimiento sería algo así como: >> "Implementar el mensaje #executeAt: anIpAddress port: aPort en Process para >> que pause la ejecución, se lleve el thread con los objetos en el scope a la >> otra imagen y retome la ejecución del punto de partida." Me sumo al programa >> de beta testers para cuando esté listo en un par de días. >> >> Saludos, >> Andrés >> >> >> Guillermo Schwarz escribió: >> >> Primero hay que ponerse de acuerdo en qué tipo de implementación vamos a >>> hacer: >>> >>> 1. Proxy que llame a un objeto remoto que ya existe en el destino >>> (similar a EJB). >>> 2. Proxy que vaya hasta el servidor y cree una instancia de una clase >>> que no existe, para lo cual se requiere que el destino le pregunte al >>> gatillador dónde está la definición de la clase, la cargue, la compile y >>> la instancie. >>> 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? >>> ¿Que corran en el servidor que se indique en duro? ¿Hacer un balanceador >>> de carga? >>> >>> Si los requerimientos no están claros se llegará a un engendro, pero si >>> están claros, las decisiones de diseño serán las obvias, podremos >>> implementar los prototipos, probarlos y no creo que sean más de un par >>> de días tenerlo funcionando. >>> >>> Saludos, >>> Guillermo. >>> >>> On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: >>> >>>> 2010/10/8 Guillermo Schwarz <[hidden email]> >>>> ¿Y tú que parte harías? >>>> ¿Probarlo? >>>> ;-) >>>> -- >>>> Simplex Veri Sigillum >>>> Uy! - si necesitas beta testers avisa, yo tambien >>>> me prendo >>>> >>>> >>>> ;-) >>>> >>>> >>>> -- >>>> Callarum largo vivurum >>>> >>>> >>>> -- >>>> To post to this group, send email to [hidden email] >>>> To unsubscribe from this group, send email to clubSmalltalk >>>> +[hidden email] >>>> http://www.clubSmalltalk.org >>>> >>> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email]<clubSmalltalk%[hidden email]> >> >> http://www.clubSmalltalk.org >> > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola gente!
Gracias, Andres, por el dato. Algo relacionado, no Smalltalk, pero parecido, recuerdo http://soft.vub.ac.be/amop/ AmbientTalk (aca usan Java VM como base) Creo que viene gente de ese grupo al Esug de Argentina, era asi? Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/8 andres <[hidden email]> Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info: -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Fortier-2
1. Si OpenTalk ya lo tiene hecho, ¿es open source?
2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand para que pregunte si la clase está definida en el servidor (o en el originador de la llamada, depende de cómo se quiera organizar el asunto).
3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o algo así y dejaba el thread actual suspendido y le daba tiempo a otro de ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler, pensé que era Smalltalk Express, pero al parecer no era porque no encontré thisContext. ¿Alguien ha visto algo así?
Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría.
-- Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se me hace difícil.
Saludos, Guillermo. 2010/10/8 andres <[hidden email]> Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info: -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Desconozco la licencia de Opentalk o si está portado a Pharo; igual
pensé que ibas a implementar todo de cero, total no es complicado, un par de proxies nomás. Sobre lo que decís en 2) la verdad no te sigo, pero parece sencillo; deberás redefinir algún mensaje y serializar algún que otro compiled method. Y sobre #thisContext al menos en VW está y estoy casi seguro que en Squeak y Pharo también, así que dale con la implementación en Pharo. El lunes es feriado pero tengo que trabajar igual, así que seguro voy a poder testear tu implementación. Saludos, Andrés Guillermo Schwarz escribió: > 1. Si OpenTalk ya lo tiene hecho, ¿es open source? > > 2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand > para que pregunte si la clase está definida en el servidor (o en el > originador de la llamada, depende de cómo se quiera organizar el asunto). > > 3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o algo > así y dejaba el thread actual suspendido y le daba tiempo a otro de > ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler, pensé > que era Smalltalk Express, pero al parecer no era porque no encontré > thisContext. ¿Alguien ha visto algo así? > > Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría. > > Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se me > hace difícil. > > Saludos, > Guillermo. > > 2010/10/8 andres <[hidden email]> > >> Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info: >> 1. Si, cubierto por Opentalk. >> 2. Opentalk cubre esto parcialmente, creo que se podía trabajar con clases >> como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las dos >> imágenes puede haber versiones distintas de la misma clase es un problema. >> 3. No que yo sepa. >> >> El tema es que cuanto mas "transparente" te quieras volver para el >> programador, mas decisiones tenés que tomar a priori (que muchas veces no se >> pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de >> distribuir objetos por copia o por referencia es un mundo en si mismo. >> >> Saludos, >> Andrés >> >> Angel Java Lopez escribió: >> >>> Ah! Me olvide de preguntar: >>> >>> No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de Guillermo? >>> >>> Nos leemos! >>> >>> Angel "Java" Lopez >>> http://www.ajlopez.com >>> http://twitter.com/ajlopez >>> >>> 2010/10/8 andres <[hidden email]> >>> >>> Dale, la opción 3 suena piola. El requerimiento sería algo así como: >>>> "Implementar el mensaje #executeAt: anIpAddress port: aPort en Process >>>> para >>>> que pause la ejecución, se lleve el thread con los objetos en el scope a >>>> la >>>> otra imagen y retome la ejecución del punto de partida." Me sumo al >>>> programa >>>> de beta testers para cuando esté listo en un par de días. >>>> >>>> Saludos, >>>> Andrés >>>> >>>> >>>> Guillermo Schwarz escribió: >>>> >>>> Primero hay que ponerse de acuerdo en qué tipo de implementación vamos a >>>> >>>>> hacer: >>>>> >>>>> 1. Proxy que llame a un objeto remoto que ya existe en el destino >>>>> (similar a EJB). >>>>> 2. Proxy que vaya hasta el servidor y cree una instancia de una clase >>>>> que no existe, para lo cual se requiere que el destino le pregunte al >>>>> gatillador dónde está la definición de la clase, la cargue, la compile y >>>>> la instancie. >>>>> 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? >>>>> ¿Que corran en el servidor que se indique en duro? ¿Hacer un balanceador >>>>> de carga? >>>>> >>>>> Si los requerimientos no están claros se llegará a un engendro, pero si >>>>> están claros, las decisiones de diseño serán las obvias, podremos >>>>> implementar los prototipos, probarlos y no creo que sean más de un par >>>>> de días tenerlo funcionando. >>>>> >>>>> Saludos, >>>>> Guillermo. >>>>> >>>>> On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: >>>>> >>>>> 2010/10/8 Guillermo Schwarz <[hidden email]> >>>>>> ¿Y tú que parte harías? >>>>>> ¿Probarlo? >>>>>> ;-) >>>>>> -- >>>>>> Simplex Veri Sigillum >>>>>> Uy! - si necesitas beta testers avisa, yo >>>>>> tambien >>>>>> me prendo >>>>>> >>>>>> >>>>>> ;-) >>>>>> >>>>>> >>>>>> -- >>>>>> Callarum largo vivurum >>>>>> >>>>>> >>>>>> -- >>>>>> To post to this group, send email to [hidden email] >>>>>> To unsubscribe from this group, send email to clubSmalltalk >>>>>> +[hidden email] >>>>>> http://www.clubSmalltalk.org >>>>>> >>>>>> >>>>> -- >>>> To post to this group, send email to [hidden email] >>>> To unsubscribe from this group, send email to >>>> [hidden email]<clubSmalltalk%[hidden email]> >>>> <clubSmalltalk%[hidden email]<clubSmalltalk%[hidden email]> >>>> http://www.clubSmalltalk.org >>>> >>>> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email]<clubSmalltalk%[hidden email]> >> >> http://www.clubSmalltalk.org >> > > > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Oye, pero la idea no es hacerlo desde cero, sino tendría que hacer un Smalltalk desde cero. No tiene sentido.
La serialización de objetos ya existe, los sockets también, los proxies también. ¿Me hace falta algo aparte de juntar y pegar?
¿Alguien me puede recordar dónde están cada una de esas cosas? Tengo la memoria un poco empolvada, aparte de que no tengo mucha experiencia en Pharo. Saludos, Guillermo.
-- 2010/10/8 andres <[hidden email]> Desconozco la licencia de Opentalk o si está portado a Pharo; igual pensé que ibas a implementar todo de cero, total no es complicado, un par de proxies nomás. -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
Guillermo:
En Squeak tenes rSt (remote Smalltalk) para la 3.9 Es un buen punto de comienzo para lo que queres hacer. Seguramente eso te va a salvar unas horas de desarrollo y te va a dejar mas tiempo para el resto que es un poco más complicado. En Squeak tenes thisContext tambien. Ahh con #yield lo que haces es darle oportunidad de ejecutar a otros procesos con la misma prioridad que el actual, supongo que es mas o menos lo que decias. Como envidio como te vas a divertir jeje Saludos El día 8 de octubre de 2010 15:55, Guillermo Schwarz <[hidden email]> escribió: > 1. Si OpenTalk ya lo tiene hecho, ¿es open source? > 2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand > para que pregunte si la clase está definida en el servidor (o en el > originador de la llamada, depende de cómo se quiera organizar el asunto). > 3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o algo > así y dejaba el thread actual suspendido y le daba tiempo a otro de > ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler, pensé > que era Smalltalk Express, pero al parecer no era porque no encontré > thisContext. ¿Alguien ha visto algo así? > Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría. > Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se me > hace difícil. > Saludos, > Guillermo. > > 2010/10/8 andres <[hidden email]> >> >> Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info: >> 1. Si, cubierto por Opentalk. >> 2. Opentalk cubre esto parcialmente, creo que se podía trabajar con clases >> como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las dos >> imágenes puede haber versiones distintas de la misma clase es un problema. >> 3. No que yo sepa. >> >> El tema es que cuanto mas "transparente" te quieras volver para el >> programador, mas decisiones tenés que tomar a priori (que muchas veces no se >> pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de >> distribuir objetos por copia o por referencia es un mundo en si mismo. >> >> Saludos, >> Andrés >> >> Angel Java Lopez escribió: >>> >>> Ah! Me olvide de preguntar: >>> >>> No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de Guillermo? >>> >>> Nos leemos! >>> >>> Angel "Java" Lopez >>> http://www.ajlopez.com >>> http://twitter.com/ajlopez >>> >>> 2010/10/8 andres <[hidden email]> >>> >>>> Dale, la opción 3 suena piola. El requerimiento sería algo así como: >>>> "Implementar el mensaje #executeAt: anIpAddress port: aPort en Process >>>> para >>>> que pause la ejecución, se lleve el thread con los objetos en el scope a >>>> la >>>> otra imagen y retome la ejecución del punto de partida." Me sumo al >>>> programa >>>> de beta testers para cuando esté listo en un par de días. >>>> >>>> Saludos, >>>> Andrés >>>> >>>> >>>> Guillermo Schwarz escribió: >>>> >>>> Primero hay que ponerse de acuerdo en qué tipo de implementación vamos >>>> a >>>>> >>>>> hacer: >>>>> >>>>> 1. Proxy que llame a un objeto remoto que ya existe en el destino >>>>> (similar a EJB). >>>>> 2. Proxy que vaya hasta el servidor y cree una instancia de una clase >>>>> que no existe, para lo cual se requiere que el destino le pregunte al >>>>> gatillador dónde está la definición de la clase, la cargue, la compile >>>>> y >>>>> la instancie. >>>>> 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? >>>>> ¿Que corran en el servidor que se indique en duro? ¿Hacer un >>>>> balanceador >>>>> de carga? >>>>> >>>>> Si los requerimientos no están claros se llegará a un engendro, pero si >>>>> están claros, las decisiones de diseño serán las obvias, podremos >>>>> implementar los prototipos, probarlos y no creo que sean más de un par >>>>> de días tenerlo funcionando. >>>>> >>>>> Saludos, >>>>> Guillermo. >>>>> >>>>> On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: >>>>> >>>>>> 2010/10/8 Guillermo Schwarz <[hidden email]> >>>>>> ¿Y tú que parte harías? >>>>>> ¿Probarlo? >>>>>> ;-) >>>>>> -- >>>>>> Simplex Veri Sigillum >>>>>> Uy! - si necesitas beta testers avisa, yo >>>>>> tambien >>>>>> me prendo >>>>>> >>>>>> >>>>>> ;-) >>>>>> >>>>>> >>>>>> -- >>>>>> Callarum largo vivurum >>>>>> >>>>>> >>>>>> -- >>>>>> To post to this group, send email to [hidden email] >>>>>> To unsubscribe from this group, send email to clubSmalltalk >>>>>> +[hidden email] >>>>>> http://www.clubSmalltalk.org >>>>>> >>>>> >>>> -- >>>> To post to this group, send email to [hidden email] >>>> To unsubscribe from this group, send email to >>>> >>>> [hidden email]<clubSmalltalk%[hidden email]> >>>> >>>> http://www.clubSmalltalk.org >>>> >>> >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
El único problema es que Squeak no lo entiendo. Simplemente no puedo salir de los monitos animados y los mundos con herramientas para niños.
Saludos, Guillermo.
--
2010/10/8 GallegO <[hidden email]> Guillermo: -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Ehh todos dicen eso. Hay que darle un poquito de tiempo y la rompe.
Abrir un browser y trabajar 2 horas nomas. Aprenderse los shortcuts y un par de tonterias mas y ya te acostumbras. Saludos El día 8 de octubre de 2010 17:01, Guillermo Schwarz <[hidden email]> escribió: > El único problema es que Squeak no lo entiendo. Simplemente no puedo salir > de los monitos animados y los mundos con herramientas para niños. > Saludos, > Guillermo. > > 2010/10/8 GallegO <[hidden email]> >> >> Guillermo: >> >> En Squeak tenes rSt (remote Smalltalk) para la 3.9 >> >> Es un buen punto de comienzo para lo que queres hacer. Seguramente eso >> te va a salvar unas horas de desarrollo y te va a dejar mas tiempo >> para el resto que es un poco más complicado. >> >> En Squeak tenes thisContext tambien. Ahh con #yield lo que haces es >> darle oportunidad de ejecutar a otros procesos con la misma prioridad >> que el actual, supongo que es mas o menos lo que decias. >> >> Como envidio como te vas a divertir jeje >> >> >> Saludos >> >> El día 8 de octubre de 2010 15:55, Guillermo Schwarz >> <[hidden email]> escribió: >> > 1. Si OpenTalk ya lo tiene hecho, ¿es open source? >> > 2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand >> > para que pregunte si la clase está definida en el servidor (o en el >> > originador de la llamada, depende de cómo se quiera organizar el >> > asunto). >> > 3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o >> > algo >> > así y dejaba el thread actual suspendido y le daba tiempo a otro de >> > ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler, >> > pensé >> > que era Smalltalk Express, pero al parecer no era porque no encontré >> > thisContext. ¿Alguien ha visto algo así? >> > Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría. >> > Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se >> > me >> > hace difícil. >> > Saludos, >> > Guillermo. >> > >> > 2010/10/8 andres <[hidden email]> >> >> >> >> Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info: >> >> 1. Si, cubierto por Opentalk. >> >> 2. Opentalk cubre esto parcialmente, creo que se podía trabajar con >> >> clases >> >> como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las >> >> dos >> >> imágenes puede haber versiones distintas de la misma clase es un >> >> problema. >> >> 3. No que yo sepa. >> >> >> >> El tema es que cuanto mas "transparente" te quieras volver para el >> >> programador, mas decisiones tenés que tomar a priori (que muchas veces >> >> no se >> >> pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de >> >> distribuir objetos por copia o por referencia es un mundo en si mismo. >> >> >> >> Saludos, >> >> Andrés >> >> >> >> Angel Java Lopez escribió: >> >>> >> >>> Ah! Me olvide de preguntar: >> >>> >> >>> No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de >> >>> Guillermo? >> >>> >> >>> Nos leemos! >> >>> >> >>> Angel "Java" Lopez >> >>> http://www.ajlopez.com >> >>> http://twitter.com/ajlopez >> >>> >> >>> 2010/10/8 andres <[hidden email]> >> >>> >> >>>> Dale, la opción 3 suena piola. El requerimiento sería algo así como: >> >>>> "Implementar el mensaje #executeAt: anIpAddress port: aPort en >> >>>> Process >> >>>> para >> >>>> que pause la ejecución, se lleve el thread con los objetos en el >> >>>> scope a >> >>>> la >> >>>> otra imagen y retome la ejecución del punto de partida." Me sumo al >> >>>> programa >> >>>> de beta testers para cuando esté listo en un par de días. >> >>>> >> >>>> Saludos, >> >>>> Andrés >> >>>> >> >>>> >> >>>> Guillermo Schwarz escribió: >> >>>> >> >>>> Primero hay que ponerse de acuerdo en qué tipo de implementación >> >>>> vamos >> >>>> a >> >>>>> >> >>>>> hacer: >> >>>>> >> >>>>> 1. Proxy que llame a un objeto remoto que ya existe en el destino >> >>>>> (similar a EJB). >> >>>>> 2. Proxy que vaya hasta el servidor y cree una instancia de una >> >>>>> clase >> >>>>> que no existe, para lo cual se requiere que el destino le pregunte >> >>>>> al >> >>>>> gatillador dónde está la definición de la clase, la cargue, la >> >>>>> compile >> >>>>> y >> >>>>> la instancie. >> >>>>> 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? >> >>>>> ¿Que corran en el servidor que se indique en duro? ¿Hacer un >> >>>>> balanceador >> >>>>> de carga? >> >>>>> >> >>>>> Si los requerimientos no están claros se llegará a un engendro, pero >> >>>>> si >> >>>>> están claros, las decisiones de diseño serán las obvias, podremos >> >>>>> implementar los prototipos, probarlos y no creo que sean más de un >> >>>>> par >> >>>>> de días tenerlo funcionando. >> >>>>> >> >>>>> Saludos, >> >>>>> Guillermo. >> >>>>> >> >>>>> On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: >> >>>>> >> >>>>>> 2010/10/8 Guillermo Schwarz <[hidden email]> >> >>>>>> ¿Y tú que parte harías? >> >>>>>> ¿Probarlo? >> >>>>>> ;-) >> >>>>>> -- >> >>>>>> Simplex Veri Sigillum >> >>>>>> Uy! - si necesitas beta testers avisa, yo >> >>>>>> tambien >> >>>>>> me prendo >> >>>>>> >> >>>>>> >> >>>>>> ;-) >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Callarum largo vivurum >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> To post to this group, send email to [hidden email] >> >>>>>> To unsubscribe from this group, send email to clubSmalltalk >> >>>>>> +[hidden email] >> >>>>>> http://www.clubSmalltalk.org >> >>>>>> >> >>>>> >> >>>> -- >> >>>> To post to this group, send email to [hidden email] >> >>>> To unsubscribe from this group, send email to >> >>>> >> >>>> >> >>>> [hidden email]<clubSmalltalk%[hidden email]> >> >>>> >> >>>> http://www.clubSmalltalk.org >> >>>> >> >>> >> >> >> >> -- >> >> To post to this group, send email to [hidden email] >> >> To unsubscribe from this group, send email to >> >> [hidden email] >> >> >> >> http://www.clubSmalltalk.org >> > >> > >> > -- >> > Saludos cordiales, >> > >> > Guillermo Schwarz >> > Sun Certified Enterprise Architect >> > >> > -- >> > To post to this group, send email to [hidden email] >> > To unsubscribe from this group, send email to >> > [hidden email] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
El único problema es que Squeak no lo entiendo. Simplemente no puedo salir de los monitos animados y los mundos con herramientas para niños. Guille, Como es eso que te resulta muy complicado hacer <click-boton derecho> + <click - Exit World> pero te resulta trivial implementar una maquina virtual con objetos distribuidos?
O es que no te gusta la GUI de Squeak porque sos capaz de mandarle mensajes a los objetos modificando la memoria con un editor hexa? Ojo, nunca lo probe pero no es *tan* difícil tampoco - solo tenes que conocer el formato interno que le da la VM a cada objeto, y listo. Bueno, también jode un poquito el GC. Pero también es trivial: si lo único que hace el GC es mover objetos de un lado para otro.
En fin, si no podes usar el Squeak porque es para señoritas, no te queda otra que hacerlo todo de cero. Un par de semanitas te alcanza? Lo tendrás listo para la Smalltalks 2010? Tenes que ir; todos queremos conocer a groso de tu calibre.
Nos vemos pronto. - Pancho Orbis non sufficit To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
No, claramente no apunto a que implementes un Smalltalk nuevo; lo que
digo es que si ya usas un framework de distribución de objetos (tipo Opentalk o rSt) la cosa ya está casi resuelta. Igual la parte de distribución por referencia ya la tenés cocinada ("En el caso de usar proxy es trivial y liviano y si el mecanismo funciona para uno, funciona para todos" -muy interesante la última acotación-), sólo te falta resolver la distribución por copia. Respecto de las librerías me mataste, yo trabajo con VW no con Pharo :( Saludos! Andrés Guillermo Schwarz escribió: > Oye, pero la idea no es hacerlo desde cero, sino tendría que hacer un > Smalltalk desde cero. No tiene sentido. > > La serialización de objetos ya existe, los sockets también, los proxies > también. ¿Me hace falta algo aparte de juntar y pegar? > > ¿Alguien me puede recordar dónde están cada una de esas cosas? Tengo la > memoria un poco empolvada, aparte de que no tengo mucha experiencia en > Pharo. > > Saludos, > Guillermo. > > 2010/10/8 andres <[hidden email]> > >> Desconozco la licencia de Opentalk o si está portado a Pharo; igual pensé >> que ibas a implementar todo de cero, total no es complicado, un par de >> proxies nomás. >> Sobre lo que decís en 2) la verdad no te sigo, pero parece sencillo; >> deberás redefinir algún mensaje y serializar algún que otro compiled method. >> Y sobre #thisContext al menos en VW está y estoy casi seguro que en Squeak >> y Pharo también, así que dale con la implementación en Pharo. El lunes es >> feriado pero tengo que trabajar igual, así que seguro voy a poder testear tu >> implementación. >> >> >> Saludos, >> Andrés >> >> Guillermo Schwarz escribió: >> >>> 1. Si OpenTalk ya lo tiene hecho, ¿es open source? >>> >>> 2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand >>> para que pregunte si la clase está definida en el servidor (o en el >>> originador de la llamada, depende de cómo se quiera organizar el asunto). >>> >>> 3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o algo >>> así y dejaba el thread actual suspendido y le daba tiempo a otro de >>> ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler, >>> pensé >>> que era Smalltalk Express, pero al parecer no era porque no encontré >>> thisContext. ¿Alguien ha visto algo así? >>> >>> Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría. >>> >>> Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se me >>> hace difícil. >>> >>> Saludos, >>> Guillermo. >>> >>> 2010/10/8 andres <[hidden email]> >>> >>> Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info: >>>> 1. Si, cubierto por Opentalk. >>>> 2. Opentalk cubre esto parcialmente, creo que se podía trabajar con >>>> clases >>>> como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las dos >>>> imágenes puede haber versiones distintas de la misma clase es un >>>> problema. >>>> 3. No que yo sepa. >>>> >>>> El tema es que cuanto mas "transparente" te quieras volver para el >>>> programador, mas decisiones tenés que tomar a priori (que muchas veces no >>>> se >>>> pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de >>>> distribuir objetos por copia o por referencia es un mundo en si mismo. >>>> >>>> Saludos, >>>> Andrés >>>> >>>> Angel Java Lopez escribió: >>>> >>>> Ah! Me olvide de preguntar: >>>>> No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de >>>>> Guillermo? >>>>> >>>>> Nos leemos! >>>>> >>>>> Angel "Java" Lopez >>>>> http://www.ajlopez.com >>>>> http://twitter.com/ajlopez >>>>> >>>>> 2010/10/8 andres <[hidden email]> >>>>> >>>>> Dale, la opción 3 suena piola. El requerimiento sería algo así como: >>>>> >>>>>> "Implementar el mensaje #executeAt: anIpAddress port: aPort en Process >>>>>> para >>>>>> que pause la ejecución, se lleve el thread con los objetos en el scope >>>>>> a >>>>>> la >>>>>> otra imagen y retome la ejecución del punto de partida." Me sumo al >>>>>> programa >>>>>> de beta testers para cuando esté listo en un par de días. >>>>>> >>>>>> Saludos, >>>>>> Andrés >>>>>> >>>>>> >>>>>> Guillermo Schwarz escribió: >>>>>> >>>>>> Primero hay que ponerse de acuerdo en qué tipo de implementación vamos >>>>>> a >>>>>> >>>>>> hacer: >>>>>>> 1. Proxy que llame a un objeto remoto que ya existe en el destino >>>>>>> (similar a EJB). >>>>>>> 2. Proxy que vaya hasta el servidor y cree una instancia de una clase >>>>>>> que no existe, para lo cual se requiere que el destino le pregunte al >>>>>>> gatillador dónde está la definición de la clase, la cargue, la compile >>>>>>> y >>>>>>> la instancie. >>>>>>> 3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo? >>>>>>> ¿Que corran en el servidor que se indique en duro? ¿Hacer un >>>>>>> balanceador >>>>>>> de carga? >>>>>>> >>>>>>> Si los requerimientos no están claros se llegará a un engendro, pero >>>>>>> si >>>>>>> están claros, las decisiones de diseño serán las obvias, podremos >>>>>>> implementar los prototipos, probarlos y no creo que sean más de un par >>>>>>> de días tenerlo funcionando. >>>>>>> >>>>>>> Saludos, >>>>>>> Guillermo. >>>>>>> >>>>>>> On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote: >>>>>>> >>>>>>> 2010/10/8 Guillermo Schwarz <[hidden email]> >>>>>>> >>>>>>>> ¿Y tú que parte harías? >>>>>>>> ¿Probarlo? >>>>>>>> ;-) >>>>>>>> -- >>>>>>>> Simplex Veri Sigillum >>>>>>>> Uy! - si necesitas beta testers avisa, yo >>>>>>>> tambien >>>>>>>> me prendo >>>>>>>> >>>>>>>> >>>>>>>> ;-) >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Callarum largo vivurum >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> To post to this group, send email to [hidden email] >>>>>>>> To unsubscribe from this group, send email to clubSmalltalk >>>>>>>> +[hidden email] >>>>>>>> http://www.clubSmalltalk.org >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>> To post to this group, send email to [hidden email] >>>>>> To unsubscribe from this group, send email to >>>>>> [hidden email]<clubSmalltalk%[hidden email]> >>>>>> <clubSmalltalk%[hidden email]<clubSmalltalk%[hidden email]> >>>>>> <clubSmalltalk%[hidden email]<clubSmalltalk%[hidden email]> >>>>>> <clubSmalltalk%[hidden email]<clubSmalltalk%[hidden email]> >>>>>> http://www.clubSmalltalk.org >>>>>> >>>>>> >>>>>> -- >>>> To post to this group, send email to [hidden email] >>>> To unsubscribe from this group, send email to >>>> [hidden email]<clubSmalltalk%[hidden email]> >>>> <clubSmalltalk%[hidden email]<clubSmalltalk%[hidden email]> >>>> http://www.clubSmalltalk.org >>>> >>>> >>> >>> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email]<clubSmalltalk%[hidden email]> >> >> http://www.clubSmalltalk.org >> > > > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Francisco Garau
Bueno cada uno se acostumbra a diferentes cosas.
Squeak lo encuentro un enredo. Aparte de que acá en Chile nadie lo pesca, que yo sepa, supongo que porque se ve muy infantil. Alguna vez lo pude usar, pero cuando empezaron a desarrollar con Morphic me perdí, nunca lo entendí. Luego empezaron con el conejo 3D y ahí si que no entendí nada.
Lo de los objetos distribuidos lo hago hasta con macros de Excel (ja, es broma ;-) Aunque no tan broma si pensamos que DCOM+ es algo parecido... Y hay que ver que los DCOM sí que tienen reglas para el manejo de sus objetos que muchas veces ni ellos mismos las entienden bien.
Bueno unas preguntas pensando en que lo voy a implementar en Pharo: 1. ¿Cómo creo un ServerSocket? 2. ¿Cómo creo un Socket que se conecte a ese ServerSocket?
3. ¿Cómo implemento un protocolo sobre los sockets? ¿Hay algún ejemplo en alguna parte? 4. ¿Cóm tengo el equivalente de un ConcurrentQueue en Pharo? Esto es necesario porque en el caso de implementar EJBs, cada EJB tiene varias instancias, entonces cada una cuando se desocupa va saando de la cola y ejecutando.
Entonces la idea es que cada instancia de Pharo publica sus EJBs, básicamente ante un mensaje como listEjbs retorna la lista de clases publicadas. Cada clase publicada se peude instanciar según el número configurado de instancias o por cada petición creamos un nuevo EJB, eso lo podemos dejar configurable.
Entonces cada computador remoto puede conectarse a este servidor y ver la lista. Supongamos que el usuario lo hace interactivamente, simplemente tengo una GUI que me lista los servidores que tengo en la red y cuando abro uno, veo sus clases EJBs.(A todo esto todas las clases EJBs son stateless, las otras fueron un fracaso).
Luego cada clase tiene su propio protocolo, es decir, sus métodos, me parece la lista de métodos.Selecciono uno, ingreso los parámetros en un GUI que me muestra el número de cajas que corresponda al número de parámetros, y luego "send". Espero que el resultado me aparezca en la misma GUI.
Al llamar tengo que llamar un objeto local. Ese objeto local simplemente manda el mensaje a través del socket (serializo el mensaje). Esto llega a la cola en el servidor. Lo implementamos como una cola por EJB (cada EJB con su número de instancias). Hay un EJB scheduler que se encarga de tomar los EJBs que están "ready" y los pone a leer de la cola. O dicho de otra manera, llama a alguno de EJBs que estén desocupados con el método que deserializó.
ejb perform: aMessage selector withArguments: aMessage arguments ¿Qué ventaja tierne esto? No se queda pegado si un EJB es abusado (el resto del EJBs peude seguir ejecutando). En Smalltalk habría que tener cuidado de bajarle la prioridad al proceso si lleva más de 3 o 6 segundos ejecutando y hacerle un yield por fuera. Tengo entendido que uno peude poner un proceso de más alta prioridad a chequear esos temas.
Además no hay problemas raros como GC distribuido y cosas similares. Cuando acaba el request la referencia se suelta. Saludos, Guillermo.
--
2010/10/8 Francisco Garau <[hidden email]>
-- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |