>> Mensaje subliminal para mi, etc... > Asumo que Valloud lo está haciendo desde cero. No deja de ser interesante, > pero considera que el mismo Alan Kay, al hacer Squeak, partió de otro > Smalltalk. Lo mismo pasa en C, en Pascal, etc. Parten de un gcc que funciona > en una plataforma y hacen que genere código para otra palataforma, no parten > desde el assembly language...
> Quizás lo que quiere Valluod es desligarse de una plataforma (C#) de la que > no tiene los fuentes ;-) Lo que? Andres. 2010/10/19 Guillermo Schwarz <[email protected]>: > > > 2010/10/19 Angel Java Lopez <[email protected]> >> >> Hola gente! >> >> Por lo que vi, las primitivas se identifican por numero. >> >> En algunos Smalltalk no se podian extender, en otros si, pero habia que >> ponerse de acuerdo en el nro. de primitiva que iba ha poner. > > Sí, pero el número es sólo un identificador. Da lo mismo si es un nombre y > de hecho creo que es más limpio que sea un nombre. >> >> Por lo que vi, no se si en todos los Smalltalk, un metodo puede tener una >> primitiva, y solo si la primitiva falla (o no se, no esta, lo que sea), se >> ejecuta el codigo que le sigue. > > Claro, pero eso es consecuencia de que Smalltalk no tiene tipos en los > parámetros, de modo que puedo llamar una primitiva con un BigInteger en vez > de un SmallInteger y se va a caer, entonces es más cómodo colocar en el > mismo método el código que maneja esos casos de borde, pero sería más > elegante usar excepciones. >> >> Corrijanme en cualquiera de esos puntos. > > Creo que va bien. ;-) >> >> Un objeto nativo puede ser cualquier cosa, no hay que darle un numero. Un >> programador que ponga en un metodo una llamada a >> >> @System.IO.File exists: 'myFile.txt' >> >> no tiene que declarar la primitiva, por nro, ni nada. Uso lo que esta en >> la class library "de abajo". > > Claro. Inicialmente Smalltalk llamaba algunas primitivas y eso era todo. > Pero leugo Smalltalk en la realidad debe llamar DLLs, .so y cosas así. Lo > que hiciste me da la idea que cubre todo eso, aunque en Visual Smalltalk > además se podía crear SLL en Smalltalk que se comportaban como DLLs. > En otras palabras, era como crear tus propias primitivas en Smalltalk. >> >> Y tanto Java como .NET, tienen la capacidad de cargar, en demanda, nuevos >> tipos. > > Yep. Y usando classloaders puedes reemplazar lso tipos antiguos. Eso es lo > que permite que Tomcat por ejemplo cargue un WAR que contiene redeficiones > de clases que están en un WAR anterior sin bajar el Tomcat. Smalltalk hace > algo parecido cuando redefines una clase, siplemetne la clase queda viviendo > pero sin nombre (ya no es referenciada por Smalltalk SystemDicitonary), la > nueva la reemplaza, ya que las clases son objetos y Smalltalk es simplemente > un SystemDicitonary que contiene las referencias de las variables a sus > respectivos objetos. > De esta manera implementar el mecanismo de Tomcar para aislar el código de 2 > wars no debiera ser más que instanciar varios SystemDictioanries. ;-) > >> >> Con lo que cualquier programador puede aprovechar una libreria. Por >> ejemplo, maese Gregoris podria aprovechar una libreria sobre OpenGL, probada >> en diferentes ambitos, posiblemente que mas estabilidad, ejemplos mas >> claros, y soporte, que acceder directamente a la API original. >> >> Eso es lo que veo de diferencia. En el siglo pasado, escribia un mini >> interprete, con primitivas extensibles (el programador podria agregar que >> era la primitiva digamos 117). Pero desde que hay librerias de clases, no >> veo la necesidad de ir por ese camino. >> >> Como siempre, todo esto es <MensajeSubliminalParaElBuenoDeValloud>usen una >> class library y VM existente para armar un >> Smalltalk</MensajeSubliminalParaElBuenoDeValloud> ;-);-) >> > Asumo que Valloud lo está haciendo desde cero. No deja de ser interesante, > pero considera que el mismo Alan Kay, al hacer Squeak, partió de otro > Smalltalk. Lo mismo pasa en C, en Pascal, etc. Parten de un gcc que funciona > en una plataforma y hacen que genere código para otra palataforma, no parten > desde el assembly language... > Quizás lo que quiere Valluod es desligarse de una plataforma (C#) de la que > no tiene los fuentes ;-) > >> >> Ah, la autoreferencia es para no luchar por un nombre, no tener colision >> de nombres con otro proyecto existente. Aun asi, debo tener alguna colision, >> en el AjLogo con otro proyecto... snif ... ;-) ;-) > > Otro que es autorefrente y que le ha ido bien con eso es Linux, de modo que > puede que te vaya igual que él ;-) >> >> Nos leemos! >> >> Angel "Java" Lopez >> http://www.ajlopez.com >> http://twitter.com/ajlopez >> >> 2010/10/19 Guillermo Schwarz <[email protected]> >>> >>> Una pregunta, ¿porqué crees que es diferente una llamada a una primitiva >>> en Smalltalk que una llamada a "objetos nativos" an AjTalk? >>> Bonito nombre AjTalk, un poco autoreferente, pero está bien ;-) >>> >>> >>> Saludos, >>> Guillermo. >>> >>> 2010/10/19 Angel Java Lopez <[email protected]> >>>> >>>> Hola gente! >>>> >>>> Guillermo, interesante.... A ver: >>>> >>>> No necesite publicar todavia un objeto por nombre. Si fuera necesario, >>>> lo pondria en los globales de, digamo, el nodo M2, y desde M1 pondria: >>>> >>>> myRemetoObject := hostM1 evaluate: 'PublishedObject asRemote'. >>>> >>>> asRemote como primitiva: Hmmm.. no, no es precisamente una primitiva. A >>>> ver, en AjTalk, tengo bytecodes. Y tengo llamadas a objetos nativos de >>>> .NET. >>>> Si ven el pastie que envie, el asRemote es una llamada a objeto nativo. No >>>> tengo cosas como primitiva 24, o algo asi. Los bytecodes no se pueden >>>> invocar directamente. Y todo extension (tener "nuevas primitivas") viene en >>>> realidad de llamar a tipos y objetos nativos. Por ejemplo, si quisiera >>>> implementar una libreria de clases de acceso a base de datos, las >>>> escribiria >>>> llamando en sus metodos, a tipos y clases del namespace System.Data en .NET >>>> (si lo tendria que reimplementar en Java, lo mismo, pero usando tipos y >>>> objetos de java.sql y relacionados). >>>> >>>> definicion del objeto en M2 segun clase en M1: si, el objeto del ejemplo >>>> que puse en el mail, se define en M1. Pero no habria problema en usar un >>>> objeto de M2 que estuviera definido en M2, y no en M1. Solo es cuestion de >>>> que el programador sepa que quiere hacer. >>>> >>>> objetos inmutables: estoy experimentando con eso, en AjLisp, y >>>> AjSharpure (con estructuras trees, listas que cuando se modifican, en >>>> realidad producen un nuevo objeto, y el original queda igual) un Clojure >>>> reimplementado en .NET. No necesite todavia eso en AjTalk. >>>> >>>> en paralelo: ciertamente, tener una cola en el agente, permite sacarse >>>> de encima el tema de multithreading sobre un objeto. Donde esta el >>>> paralelismo? En el consumidor del agente. El objeto que envia un mensaje al >>>> agente, puede "seguir su camino". Es programar tipo "tell, don't ask". >>> >>> "Tell, don't ask" se refiere a decirle a un objeto "haz esto" y él verá y >>> resolverá cómo usando polimorfismo. La estrategia "ask" sería por el >>> contrario preguntarle al objeto de qué tipo es y en qué estado está y leugo >>> decirle exactamente lo que debe hacer. >>>> >>>> Cada parte de un algoritmo le pasa trabajo a otro, pero sigue luego en >>>> lo suyo. Por ejemplo, en AjSharp y otros, tengo algoritmos geneticos donde >>>> cada parte hace lo suyo, y produce trabajo para otros. Por ejemplo, un >>>> mutador produce mutantes, y los pasa a otro agente. Un seleccionador >>>> colecciona individuos, y selecciona los que mejor evaluacion obtuviero. Y >>>> asi. La idea es implementar ese caso de uso, en algun momento, en AjTalk. >>>> Y >>>> si tengo distribuidos, puedo tener poblaciones de individuos evolucionando, >>>> en distintas maquinas. De vez en cuando, los mejores individuos pasan a >>>> otras maquinas. Cada parte/agente no es paralela: es serial, atiende un >>>> mensaje por vez. Pero el conjunto es paralelo. Recuerdo ahora un mensaje >>>> (no >>>> recuerdo de quien, disculpen, Richarte era?) mostrando presentacion con >>>> Smalltalk multicore. Mi impresion es que multicore tiene un tope: quiero >>>> pensar mas en multi-machine. >>> >>> 100% de acuerdo. Lo que dicen los fanáticos de la ley de Moore es que >>> como las CPUs se estancaron el año 2005 y la ley de Moore sigue aplicando, >>> entonces las CPUs tendrán el doble de cores cada 18 meses (o cada 12 o 24). >>> Hasta el momento se está dando, pero supongo que el año 2030 cuando tengamos >>> 1024 cores podremos estar seguros. Yo tampoco creo mucho en esto, me produce >>> desconfianza porque lo mismo pasó con Solaris que iba a ser mucho más rápido >>> que Sun OS porque el kernel iba a funcionar de manera paralela en muchas >>> CPUs al mismo tiempo, y en la práctica al usarlo uno se daba cuenta que era >>> mucho más lento. En general si tienes un sistema distribuido te conviene que >>> la BD esté en una máquina, los EJBs en otra y la parte web en otra. Incluso >>> te conviene que la parte estática de la parte web esté en otra, y eso es hoy >>> en día un negocio, porque hay empresas que proporcionan ese servicio. ¿Debe >>> funcionar no te parece? >>> Respecto de cortar el paralelismo en el agente usando colas, estoy de >>> acuerdo, es una implemntación simple que te permite tener un control en caso >>> de que el programador no sea muy vivo. Pero ahora supongamos que el >>> programador lo único que hace es hacer una operación en la BD y no deja nada >>> en memoria. En ese caso puedes asumir que los "agentes" son inmutables y >>> simplemente dejar que operen en paralelo (es lo que hace el ejb container >>> con los ejbs). La base de datos por su parte resuelve todo con >>> transacciones, ya que no serviería de mucho que un thread vea que sacó >>> dinero y nunca nadie más vea que ese dinero fue retirado, no sé si se >>> entiende, se requiere que haya algo de objetos compartidos en la BD, pero se >>> hace una distinción clara entre los objetos inmutables y los objetos >>> mutables y compartidos. >>>> >>>> viaje de los objetos: me parece mas claro que el programador sepa que >>>> quiere que viaje o no. Es para evitar el "location transparency". Quiero >>>> que >>>> el programador sepa que esta haciendo viajar un objeto o no, y decida el. >>>> Solo que le pongo como default: se serializa. >>> >>> Yo asumo que el programador no sabe, porque en general le importa solo >>> resolver el problema de negocio, lo de ejecutar de manera distribuida es un >>> problema de ingeneiría que es ortogonal al problema de negocio. Al menos por >>> eso a J2EE le ha ido tan bien. >>>> >>>> con el tema de exportar o no una clase: si al nodo M2 remoto, envio un >>>> objeto, y ese objeto es de una clase que NO esta definida en M2, me parece >>>> costoso actuar por exception, volver a M1, y decirle que tiene que enviar >>>> la >>>> clase que falta. >>> >>> En XP dicen primero pruébalo y si es muy lento, entonces cámbialo. En >>> ingeniría tendemos a planificar que todo sea muy rápido, pero si todo etá >>> super optimizado, se vuelve lento. Sólo hay que optmizar lo que probadamente >>> es muy lento. >>> >>>> >>>> El camino que voy a seguir es exportar explicitamente desde M1, >>>> preguntando primero si ya estaba definida en M2. Ademas, no siempre M2 >>>> conoce a M1. M1 conoce a M2, pero no necesariamente hay una forma desde M2 >>>> de pedirle cosas a M1. >>> >>> No entiendo cóm podría ser esto así como dices. Me parece un hoyo de >>> seguridad que no se conozcan de antemano, o al menos, que se puedan >>> presentar y erstablecer una relación de confianza. >>>> >>>> Por que .NET en vez de Java? Hmmm... deberia contestar con un post, >>>> parece un tema alejado de esta lista, no quiero que me tiren de la oreja! >>>> ;-) >>>> >>>> De paso: creo que tengo resuelto el tema de objetos transaccionales: >>>> comenzar una transaccion, cambiar slots (variables de instancia/clase), y >>>> si >>>> hay rollback, volver esos slots a lo original, y si hay dos transacciones >>>> tocando el mismo slot, una triunfa y otra da error. Pero sera tema, >>>> supongo, >>>> de programacion de fin de semana, por ahora. >>>> >>>> Nos leemos! >>>> >>>> Angel "Java" Lopez >>>> http://www.ajlopez.com >>>> http://twitter.com/ajlopez >>>> >>>> >>>> 2010/10/18 Guillermo Schwarz <[email protected]> >>>>> >>>>> > >>>>> > rectRemoto := host evaluate: 'rectEnM2 asRemote'. >>>>> > >>>>> > queda en la variable local rectRemoto un proxy al objeto Rectangle >>>>> > rectEnM2 que quedo en M2. >>>>> >>>>> Qué fácil de usar. >>>>> >>>>> Sería aún más fácil si hubiera un Publisher tal que: >>>>> >>>>> publisher := Publisher new. >>>>> publisher publish: anObject. >>>>> >>>>> Dejara ese objeto publicado, la lo cual bastaría con que: >>>>> >>>>> Publisher>>publish: anObject >>>>> host evaluate: anObject + ' asRemote' >>>>> >>>>> >>>>> ¿Cómo convierto <<anObject>> en un símbolo que lo represente? Se me >>>>> olvidó... >>>>> >>>>> > Cualquier mensaje >>>>> > >>>>> > rectRemoto width: 10. >>>>> > >>>>> > se envia a M2 y se EJECUTA en M2. >>>>> > >>>>> > Si hago desde M1: >>>>> > >>>>> > rectCopia := host evaluate: 'rectEnM2'. >>>>> > >>>>> > viaja serializado el rectangulo y queda una copia en M1, que se >>>>> > invoca >>>>> > en M1 y asi. >>>>> > >>>>> > Guillermo, vamos a tus preguntas: >>>>> > 1. Los publico evaluando algo en M2 y aplicando el mensaje que tienen >>>>> > todos los Object (ver el pastie que envie >>>>> > http://pastie.org/1213856 >>>>> > como se define el mensaje asRemote); >>>>> >>>>> AsRemote es una primitiva en tu sistema... >>>>> >>>>> > Entonces, si desde M2 a M1 quiero enviar un resultado serializado, >>>>> > implemente devuelvo >>>>> > >>>>> > result >>>>> > >>>>> > Si quiero enviar el objeto resultado pero como "objeto clavado en >>>>> > M2", >>>>> > devuelvo >>>>> > >>>>> > result asRemote >>>>> >>>>> Pero el objeto fue definido íntegramente en M1, ¿no? >>>>> >>>>> Porque no creo que sea muy agradable que el código de M1 se comporte >>>>> diferente dependiendo del código que ejecuta en M2. >>>>> >>>>> En otras palabras, defino todo mi código en M1, y desde ahí mando >>>>> objetos a ejecutar a todas las máquinas que quiera, pero siempre la >>>>> definición que vale es la que está en M1. >>>>> >>>>> De modo que el result asRemote lo programé en M1 para que el objeto se >>>>> quede en M2... (preferiría que el programador no se preocupe de esa >>>>> cosas, tal como pasa con los EJBs). >>>>> > >>>>> > Es decision del programar si lo hace de una forma u otra. >>>>> > >>>>> > 2. Si llega un mensaje a un objeto cuando esta procesando otro, es lo >>>>> > mismo que hago cuando estoy en local, con objetos locales y >>>>> > "threads" (no tengo un full Process class implementado todavia): si >>>>> > dos "threads" acceden al mismo objeto, es cuestion del programador no >>>>> > hacer nada o poner algun lockeo. >>>>> >>>>> En los EJBs está prohibido el lockeo, porque la experiencia dice que un >>>>> programador en la "enterprise" no sabe usar locks, y si sabe, luego >>>>> llega otro programador de la "enterprise" y se pisa lo que hizo el >>>>> primero... ;-) >>>>> >>>>> En otras palabras es el contenedor EJB (un objeto que funciona como >>>>> registro de qué EJBs hay y cuáles están ejecutando) el que se encarga >>>>> de >>>>> coordinar ya no los lockeos, sino que las transacciones, es un nivel >>>>> más >>>>> alto de abstracción. >>>>> >>>>> > Volviendo entonces al caso distribuido. Cuando desde M1 invoco a >>>>> > rectRemoto en M2, se ejecuta en M2, de la misma forma: si en M2 hay >>>>> > varios accediendo a ese objeto (que es local en M2, y remoto en M1), >>>>> > es lo mismo que pasa en cualquier Smalltalk, creo: es cuestion de >>>>> > programar si quiero contemplar ese caso o no. >>>>> >>>>> En Lisp se resuelve haciendo que los objetos sean inmutables. Da la >>>>> casualidad de que en el caso de los stateless session beans, también. >>>>> > >>>>> > Como quiero tener cada vez mas proceso distribuido, y en paralelo >>>>> > (distribuido o no), he agregado a AjTalk el concepto de "agente" (lo >>>>> > podria haber llamado actor, por ahora quedo asi). >>>>> >>>>> No está mal el nombre. >>>>> >>>>> > Por ejemplo: >>>>> > >>>>> > Object agent: #MyAgent >>>>> > >>>>> > Es como una clase, pero cuando crea objetos, los crea normales, con >>>>> > un >>>>> > cambio: se cambio el proceso de enviarle un mensaje. Cuando: >>>>> > >>>>> > myAgent := MyAgent new. >>>>> > myAgent haceAlgoCuandoPuedas: usandoEsteArreglo >>>>> > >>>>> > cuando envio ese mensaje, lo coloco en una cola. El agente va >>>>> > procesando en paralelo mensajes de esa cola. >>>>> >>>>> ¡¡¡En paralelo!!! Que rara la idea de usar una cola para hacerlo en >>>>> paralelo, si generalmente es al revés, la cola es para serializarlos >>>>> (en >>>>> el sentido de terminar uno para empezar el otro). >>>>> >>>>> > Tranquilamente combinar distribuido y agentes. Desde M1 con host >>>>> > apuntando a M2, puedo hacer: >>>>> > >>>>> > myRemoteAgent := host evaluate: 'MyAgente new asRemote' >>>>> > >>>>> En Smalltalk un objeto inmutable es aquel que no tiene métodos >>>>> mutadores. De modo que como es casi imposible saber si un método va a >>>>> mutar un objeto o no, creo que la única solución sería a nivel de la VM >>>>> detectar el cambio y si el objeto va a cambiar, entonces generar una >>>>> copia... >>>>> >>>>> Si la copia es por thread (o por Process) entonces se mantendría una >>>>> vista consistente del mundo en ese thread. >>>>> >>>>> > 3. En el pastie que envie, esta el codigo de como hago la >>>>> > exportacion. >>>>> > Es >>>>> > >>>>> > host export: ClaseEnM1 >>>>> > >>>>> > Lo que hago es enviar el string que define a la clase, y se ejecuta >>>>> > en >>>>> > M2. Si esa clase deriva de otra que NO esta en M2, es responsabilidad >>>>> > del programador (todavia, estoy pensando alternativas), haber hecho >>>>> > antes: >>>>> > >>>>> > host export: ClaseEnM1 superclass >>>>> >>>>> Pero es fácil. Si se cae el compilador, que tenga un hook que diga >>>>> askFor: clase que no encuentra... al nodo que contiene todas las clases >>>>> (o bien al nodo que hizo la petición). >>>>> > >>>>> > No hay forma de saber (todavia) si en M2 YA esta esa clase o no. >>>>> >>>>> Si se cae la ejecución con un error que dice "clase no existe"... ;-) >>>>> > >>>>> > 4. Los parametros que paso al objeto remoto, son serializados (saca >>>>> > una copia que se reifica del otro lado). Si desde M1 hago >>>>> > >>>>> > objetoRemotoEnM2 haceDunga: obj1 yMasDunga: obj2 >>>>> > >>>>> > tanto obj1 como obj2 se serializan. Si quisiera que no viajaran, >>>>> > deberia poner (tengo que testear, no tengo un caso ahora): >>>>> > >>>>> > objetoRemotoEnM2 haceDunga: obj1 asRemote yMasDunga: obj2 asRemote >>>>> > >>>>> Claro, pero preferiría que cada objeto decida si viaja o no. Puede que >>>>> algunos objetos ya estén acá o que realmente estén allá. En EJBs se usa >>>>> el concepto de JNDI para saber dónde están los objetos. >>>>> >>>>> JNDI es básicamente un servicio como DNS que dice www.google.com es >>>>> 182.123.45.67, pero en este caso le dices el nombre del EJB y te dice >>>>> en >>>>> qué máquina está. >>>>> >>>>> > 5. Queria seguir los pasos sugeridos por Mariano. Por explorar ese >>>>> > tema. Podria usarse, como presenta Mariano en su charla, para cuando >>>>> > hay poca memoria. >>>>> >>>>> Buena idea y bastante general. >>>>> >>>>> > Otra que se me ocurre, es para implementar todo un dominio de >>>>> > objetos >>>>> > en memoria, de forma transaparente. Por temas de limite de memoria, >>>>> > necesitaria no tener todos al mismo tiempo en memoria. Los cambios a >>>>> > los objetos en memoria, podria ir serializandolos, a un archivo de >>>>> > cambios binario. >>>>> >>>>> Prefiero una BD o algo maś simple: jdbm, un tabala de hashing en disco. >>>>> >>>>> > Tengo algunas ideas de implementacion, pero implica usar el objeto >>>>> > intermedio que comento Mariano. Yo veo a ese objeto intermedio como >>>>> > una celda en lo que era un Object Table. Quisiera ponerle ahi lo >>>>> > minimo, y como explique en otro email, que esa "celda"/Objeto >>>>> > intermedio apunte al real, o a un decorador del real (para poner mas >>>>> > conducta como la que sugeria Mariano, pero no toda en la celda, >>>>> > objeto >>>>> > intermedio). >>>>> >>>>> Supongo que basta con poner la llave del hashmap para que lo encuentre >>>>> en el disco. >>>>> > >>>>> > Pero aclaro: esto de serializar lo no usado, es ortogonal a lo de >>>>> > distribuido. >>>>> >>>>> Claro. Yo partiría al revés: Todo es no usado. Todo al disco. De esa >>>>> manera te aseguras que si tienes una implementación rápida como jdbm >>>>> (10 >>>>> ms por consulta) con eso basta. >>>>> >>>>> Obviamente siempre hay cosas que uno quiere mantener en memoria, la >>>>> clase String por ejmplo, o el mecanismo que va a buscar al jdbm. Además >>>>> por cada operación remota no quieres hacer más de una búsqueda en jdbm, >>>>> debes tener eso en consideración. >>>>> >>>>> Ahora bien, yo hablo de apicaicones de negocios que siempre van a la bd >>>>> y por ende 10 ms no es nada, es sólo ejecutar otro SQL. >>>>> >>>>> Pero en un compilador eso sería desastroso. >>>>> >>>>> > Era para local, un experimento para seguir las ideas de Mariano y su >>>>> > equipo (pregunto, enlace del equipo? blog? otras publicaciones?) >>>>> > >>>>> > 6. No vi en detalle MapReduce, solo algo hace dos anios, jugando con >>>>> > MPI (Message Passing Interface), en un cluster. Pero apenas para >>>>> > hacer >>>>> > una demo y calcular algo. Si lo hiciera con AjTalk... hmmm... a ver >>>>> > seria algo como: >>>>> > >>>>> > myLocalAgent := MyLocalAgent new. "recibira los resultados" >>>>> > >>>>> > "y por cada hostN, haria" >>>>> > >>>>> > hostN export: MyWorkerClass. >>>>> > >>>>> > myRemoteWorker := hostN evaluate: 'MyWorkerClass new'. >>>>> > myRemoteWorker process: thisDataPartN sendingResultTo: myLocalAgent >>>>> > asRemote "para que no vaya serializado y el local agent siga aca, en >>>>> > M0, digamos" >>>>> >>>>> Sí, se ve simple. Habría que tener unas cuantas máquinas para probarlo, >>>>> algunas que se caen, un protocolo que defina cuanto se espera a una >>>>> máquina que se demora (yo no esperaría nada, mandaría las consultas que >>>>> no han llegado a las máquinas que se van desocupando). Eso es fácil de >>>>> hacer. >>>>> >>>>> Lo único que no me gusta es C#. ¿Porqué no usar Java? >>>>> > >>>>> > Se entendio? Cualquier cosa, me preguntan. >>>>> > >>>>> > Nos leemos! >>>>> > >>>>> > Angel "Java" Lopez >>>>> > http://www.ajlopez.com >>>>> > http://twitter.com/ajlopez >>>>> > >>>>> > >>>>> > 2010/10/17 Guillermo Schwarz <[email protected]> >>>>> > Que rápido. Me parece que pasó menos de una semana. >>>>> > >>>>> > Unas preguntas: >>>>> > >>>>> > 1. ¿Cómo publicas los objetos que reciben mensajes remotos >>>>> > para ser >>>>> > usados por las máquinas remotas? ¿Existe un servicio básico >>>>> > que indica >>>>> > cuáles son etos objetos y los mensajes que están dispuestos a >>>>> > recibir? >>>>> > 2. ¿Usas colas de mensajes? ¿Cómo haces en caso de que llegue >>>>> > un mensaje >>>>> > a un objeto cuando aún está ejecutando el mensaje anterior? >>>>> > 3. Cuando declaras una clase en M1 y la exportas a M2, >>>>> > ¿recompilas la >>>>> > clase en M2 o simplemente envías el objeto compilado? >>>>> > 4. Los objetos que son pasados como parámetro son siempre >>>>> > serializados o >>>>> > también se puede enviar un proxy de ellos (por ejemplo podría >>>>> > ser "ob >>>>> > asProxy") de modo que automáticamente se cree un proxy de ese >>>>> > objeto en >>>>> > M2 apuntando al objeto en M1. En EJB eso se puede hacer >>>>> > aunque >>>>> > es una >>>>> > mala práctica, porque luego es natural que el protocolo de >>>>> > comunicación >>>>> > se vuelva "chatty". >>>>> > 5. ¿Porqué quieres los objetos que no se han usado se >>>>> > serialicen? >>>>> > ¿Quedan vivos los resultados que se enviaron a otra máquina? >>>>> > 6. ¿Cómo implementarías map-reduce con AjTalk? Suponiendo que >>>>> > tengo un >>>>> > arreglo de proxies en M0 donde cada elemento del arreglo >>>>> > tiene >>>>> > un proxy >>>>> > a M1, M2, ... M10 (supogamos que son 10 máquinas) y que cada >>>>> > petición se >>>>> > hace de manera asíncrona (cuando la respuesta se recibe se >>>>> > ejecuta un >>>>> > bloque). ¿Consideras eso implementable? >>>>> > >>>>> > Tengo entendido que en Squeak existe un ambiente distribuido >>>>> > de objetos >>>>> > llamado Croquet. Y bueno en Open Cobalt, que al parecer es un >>>>> > mundo >>>>> > virtual construido sobre Croquet, se puede hacer mundos 3D >>>>> > sobre los que >>>>> > se puede ejecutar aplicaciones Windows y compartirlas con >>>>> > otros >>>>> > usuarios... >>>>> > >>>>> > http://en.wikipedia.org/wiki/Open_Cobalt >>>>> > >>>>> > Según recuerdo la gran idea de Croquet es que en vez de >>>>> > enviar >>>>> > los >>>>> > objetos para ejecutar de manera remota, se puede enviar "la >>>>> > computación" >>>>> > para ejecutarla localmente y de esa manera obtener un mejor >>>>> > desempeño. >>>>> > >>>>> > Saludos, >>>>> > Guillermo. >>>>> > >>>>> > >>>>> > On Sun, 2010-10-17 at 17:44 -0300, Angel Java Lopez wrote: >>>>> > > Hola gente! >>>>> > > >>>>> > > Ya tengo objetos distribuidos en mi pet project AjTalk: >>>>> > > >>>>> > > http://pastie.org/1213856 >>>>> > > >>>>> > > Puedo comunicar N maquinas, cada una puede ser cliente o >>>>> > servidora de >>>>> > > otra maquina. >>>>> > > Puedo declarar una clase en maquina M1, y exportarla a M2. >>>>> > > Puedo ejecutar texto definido en M1, en la maquina M2. >>>>> > > Puedo evaluar texto definido en M1, en la maquina M2, y >>>>> > serializar >>>>> > > (como copia) el resultado calculado en M2, para que viaje y >>>>> > se >>>>> > > reifique en M1. >>>>> > > Puedo evaluar texto definido en M1, en la maquina M2, y >>>>> > pedirle que >>>>> > > devuelva el proxy que apunta a ese objeto que queda en M2. >>>>> > > Usando el proxy en M1, como un objeto mas, puedo enviar >>>>> > mensajes al >>>>> > > objeto remoto que todavia reside en M2. >>>>> > > >>>>> > > Hay que mejorar puntos, pero la "base esta" ;-) >>>>> > > >>>>> > > Proximos pasos: investigar la idea de "objeto intermedio" >>>>> > de >>>>> > Mariano, >>>>> > > implementarlo, implementar que los objetos que no se usan >>>>> > desde un >>>>> > > tiempo se serializen, implementar transacciones de objetos >>>>> > como la >>>>> > > describi en otro thread... pero tengo que ver en que orden, >>>>> > que >>>>> > > tiempo. >>>>> > > >>>>> > > Nos leemos! >>>>> > > >>>>> > > Angel "Java" Lopez >>>>> > > http://www.ajlopez.com >>>>> > > http://twitter.com/ajlopez >>>>> > > >>>>> > > >>>>> > > 2010/10/11 Andres Valloud <[email protected]> >>>>> > > Ah, para clarificar. >>>>> > > >>>>> > > >> Che, si es esto >>>>> > > >>>>> > > esto = "tener proxies y mandar mensajes remotos a >>>>> > objetos sin >>>>> > > perder >>>>> > > la identidad del objeto", por ejemplo... >>>>> > > >>>>> > > >> a lo que Mariano se referia, no nos olvidemos de >>>>> > > >> GemStone que hace no se, 25 años que esta con su >>>>> > base de >>>>> > > objetos >>>>> > > >> (esencialmente se puede ver como una imagen >>>>> > compartida >>>>> > > entre N otras >>>>> > > >> imagenes, con transacciones). Si eso >>>>> > > >>>>> > > >>>>> > > eso = "resolver el problema de distribucion de >>>>> > mensajes a >>>>> > > objetos >>>>> > > distribuidos de manera razonablemente general, como >>>>> > por >>>>> > > ejemplo lo >>>>> > > hace GemStone"... >>>>> > > >>>>> > > >> es lo que aca se describio como >>>>> > > >> "trivial", desde ya que de ninguna manera es >>>>> > trivial ese >>>>> > > problema. >>>>> > > >> Trivial podra ser una primera aproximacion a la >>>>> > > serializacion, pero >>>>> > > >> literalmente "objetos distribuidos" asi como en >>>>> > GemStone, >>>>> > > ni ahi. >>>>> > > >>>>> > > >>>>> > > Andres. >>>>> > > >>>>> > > >>>>> > > >>>>> > > 2010/10/11 Angel Java Lopez >>>>> > <[email protected]>: >>>>> > > > Hola gente! >>>>> > > > >>>>> > > > Ah! Yo, por lo menos, nunca mencione GemStone >>>>> > (que >>>>> > alguien >>>>> > > bueno de Sugar >>>>> > > > (Smalltalk Users Group de Argentina) me comento >>>>> > en >>>>> > los >>>>> > > noventa, el bueno de >>>>> > > > Leandro Caniglia, recuerdo su implementacion en >>>>> > Luchetti, >>>>> > > que recuerde). >>>>> > > > >>>>> > > > Lo que me gustaria (tengo codigo, pero no tengo >>>>> > test, asi >>>>> > > que nada de >>>>> > > > publicado ahora), es: >>>>> > > > >>>>> > > > anObject msg: par1 .... >>>>> > > > >>>>> > > > y anObject sea un proxy local, que deriva a un >>>>> > objeto >>>>> > > residente en otra >>>>> > > > maquina ese mensaje. El programador puede haberlo >>>>> > creado >>>>> > > local (como para >>>>> > > > probar su algoritmo en una sola maquina) o puede >>>>> > haberlo >>>>> > > creado en otro nodo >>>>> > > > de una red. En los casos de uso que tengo en >>>>> > mente, el >>>>> > > programador sabe que >>>>> > > > hay un costo en eso, asi que no esta conversando >>>>> > con esos >>>>> > > objetos a cada >>>>> > > > milisegundo. Es mas: te doy una tarea, despues, >>>>> > llegado el >>>>> > > caso, en algun >>>>> > > > momento, por otro canal, recibire una respuesta. >>>>> > > > >>>>> > > > Tambien quiero implementar: >>>>> > > > >>>>> > > > anObject msg: par1 ... >>>>> > > > >>>>> > > > y que anObject por abajo, derive el mensaje a >>>>> > uno, >>>>> > a todos, >>>>> > > o a algunos de >>>>> > > > otros objetos, remotos o locales. >>>>> > > > >>>>> > > > Y algo ortogonal a todo eso, que tengo >>>>> > implementando, pero >>>>> > > tendria que >>>>> > > > unirlo con lo de remoting: >>>>> > > > >>>>> > > > anObject msg: par1 ... >>>>> > > > >>>>> > > > que anObject reciba el mensaje, y lo atienda en >>>>> > su >>>>> > propio >>>>> > > thread. Recibe el >>>>> > > > mensaje, lo coloca en una cola en memoria, y lo >>>>> > atiende en >>>>> > > su propio thread, >>>>> > > > cuando este disponible. El objeto que envie el >>>>> > mensaje sigue >>>>> > > su camino. Esto >>>>> > > > permite implementar algoritmos en paralelo, sin >>>>> > el >>>>> > tema "te >>>>> > > envio algo, y te >>>>> > > > espero a que termines para seguir yo". >>>>> > > > >>>>> > > > Interesante el paper que enviaste, lo conocia, >>>>> > pero no lo >>>>> > > recordaba. Ya lo >>>>> > > > mando a twitter. >>>>> > > > >>>>> > > > No entendi si "si es esto a lo que Mariano se >>>>> > referia", y >>>>> > > "Si eso es lo que >>>>> > > > aca", digo, no entendi "si esto" en la primera >>>>> > frase se >>>>> > > refiere a lo mismo a >>>>> > > > lo que se refiere "si eso", en la segunda. >>>>> > > > >>>>> > > > Nos leemos! >>>>> > > > >>>>> > > > Angel "Java" Lopez >>>>> > > > http://www.ajlopez.com >>>>> > > > http://twitter.com/ajlopez >>>>> > > > >>>>> > > > 2010/10/11 Andres Valloud >>>>> > <[email protected]> >>>>> > > >> >>>>> > > >> Che, si es esto a lo que Mariano se referia, no >>>>> > nos >>>>> > > olvidemos de >>>>> > > >> GemStone que hace no se, 25 años que esta con su >>>>> > base de >>>>> > > objetos >>>>> > > >> (esencialmente se puede ver como una imagen >>>>> > compartida >>>>> > > entre N otras >>>>> > > >> imagenes, con transacciones). Si eso es lo que >>>>> > aca se >>>>> > > describio como >>>>> > > >> "trivial", desde ya que de ninguna manera es >>>>> > trivial ese >>>>> > > problema. >>>>> > > >> Trivial podra ser una primera aproximacion a la >>>>> > > serializacion, pero >>>>> > > >> literalmente "objetos distribuidos" asi como en >>>>> > GemStone, >>>>> > > ni ahi. >>>>> > > >> >>>>> > > >> Ah, hablando de esto, hace poco encontre este >>>>> > articulo que >>>>> > > me parecio >>>>> > > >> interesante. >>>>> > > >> >>>>> > > >> http://www.rgoarchitects.com/Files/fallacies.pdf >>>>> > > >> >>>>> > > >> 2010/10/11 Angel Java Lopez >>>>> > <[email protected]>: >>>>> > > >> > Hola gente! >>>>> > > >> > >>>>> > > >> > Interesante la discusion del Thread "Blog", >>>>> > pero tambien >>>>> > > algo se fue por >>>>> > > >> > las >>>>> > > >> > ramas... Cambio de titulo en este mensaje. >>>>> > > >> > >>>>> > > >> > Estuve agregando objetos distribuidos a mi pet >>>>> > project >>>>> > > [1], quedo algo >>>>> > > >> > asi: >>>>> > > >> > >>>>> > > >> > http://pastie.org/1213856 >>>>> > > >> > >>>>> > > >> > Tengan encuenta que no tengo libreria de >>>>> > clases >>>>> > de base, >>>>> > > asi que tengo >>>>> > > >> > que >>>>> > > >> > comenzar desde nil subclass:... ';-) >>>>> > > >> > >>>>> > > >> > Puedo: >>>>> > > >> > >>>>> > > >> > - Levantar un servidor (tecnologia >>>>> > Remoting .NET), en >>>>> > > nodo A. >>>>> > > >> > - Levantar un cliente remoto a ese servidor, >>>>> > en >>>>> > nodo B. >>>>> > > >> > - Definir una clase en nodo B. >>>>> > > >> > - Exportar su definicion de B a nodo A. >>>>> > > >> > - Ejecutar desde nodo B algo en nodo A. >>>>> > > >> > - Evaluar en nodo A y devolver el objeto >>>>> > serializado >>>>> > > (contemplando >>>>> > > >> > grafos >>>>> > > >> > con ciclos, repeticion de objetos, etc..) a B. >>>>> > > >> > >>>>> > > >> > Me falta evaluar en nodo A y que el resultado >>>>> > quede en A, >>>>> > > viajando a B >>>>> > > >> > una >>>>> > > >> > especie de proxy, de tal manera que invocando >>>>> > a >>>>> > ese >>>>> > > objeto en B, se >>>>> > > >> > ejecute >>>>> > > >> > el mensaje en nodo A. >>>>> > > >> > >>>>> > > >> > Mi idea es que si B devuelve un objeto a A, >>>>> > ese >>>>> > resultado >>>>> > > viaja >>>>> > > >> > completo. >>>>> > > >> > Sino, definiria algo como >>>>> > > >> > >>>>> > > >> > ^host asProxy: result. >>>>> > > >> > >>>>> > > >> > Tendria que escribir post, pero por ahora, >>>>> > tengo esto >>>>> > > para mostrar. >>>>> > > >> > >>>>> > > >> > [1] http://code.google.com/p/ajtalk >>>>> > > >> > >>>>> > > >> > Nos leemos! >>>>> > > >> > >>>>> > > >> > Angel "Java" Lopez >>>>> > > >> > http://www.ajlopez.com >>>>> > > >> > http://twitter.com/ajlopez >>>>> > > >> > >>>>> > > >> > >>>>> > > >> > >>>>> > > >> > -- >>>>> > > >> > To post to this group, send email to >>>>> > > [email protected] >>>>> > > >> > To unsubscribe from this group, send email to >>>>> > > >> > [email protected] >>>>> > > >> > >>>>> > > >> > 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 >>>>> > > > >>>>> > > > -- >>>>> > > > To post to this group, send email to >>>>> > > [email protected] >>>>> > > > To unsubscribe from this group, send email to >>>>> > > > [email protected] >>>>> > > > >>>>> > > > http://www.clubSmalltalk.org >>>>> > > >>>>> > > -- >>>>> > > To post to this group, send email to >>>>> > > [email protected] >>>>> > > To unsubscribe from this group, send email to >>>>> > clubSmalltalk >>>>> > > [email protected] >>>>> > > >>>>> > > http://www.clubSmalltalk.org >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > > -- >>>>> > > To post to this group, send email to >>>>> > [email protected] >>>>> > > To unsubscribe from this group, send email to clubSmalltalk >>>>> > > [email protected] >>>>> > > >>>>> > > http://www.clubSmalltalk.org >>>>> > >>>>> > -- >>>>> > >>>>> > Simplex Veri Sigillum >>>>> > >>>>> > -- >>>>> > >>>>> > To post to this group, send email to >>>>> > [email protected] >>>>> > To unsubscribe from this group, send email to clubSmalltalk >>>>> > [email protected] >>>>> > >>>>> > http://www.clubSmalltalk.org >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > To post to this group, send email to [email protected] >>>>> > To unsubscribe from this group, send email to clubSmalltalk >>>>> > [email protected] >>>>> > >>>>> > http://www.clubSmalltalk.org >>>>> >>>>> -- >>>>> Simplex Veri Sigillum >>>>> >>>>> -- >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> >>>>> 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 >>> >>> >>> -- >>> 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 >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
