Objetos Distribuidos

>
> Andres.
>
>
> 2010/10/19 Guillermo Schwarz <[hidden email]>:
>>
>>
>> 2010/10/19 Angel Java Lopez <[hidden email]>
>>>
>>> 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 BigInteg
>> er 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 DL
>> Ls.
>> 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. Smallt
>> alk 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 inte
>> resante,
>> pero considera que el mismo Alan Kay, al hacer Squeak, partió de o
>> tro
>> 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 <[hidden email]>
>>>>
>>>> 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 <[hidden email]>
>>>>>
>>>>> 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 sigu
>>>> e aplicando,
>>>> entonces las CPUs tendrán el doble de cores cada 18 meses (o c
>>>> ada 12 o 24).
>>>> Hasta el momento se está dando, pero supongo que el año 2030 c
>>>> uando 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 mu
>>>> cho 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 c
>>>> uenta que era
>>>> mucho más lento. En general si tienes un sistema distribuido t
>>>> e 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 se
>>>> rvicio. ¿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 c
>>>> ontrol 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 o
>>>> bjetos
>>>> 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ámbi
>>>> alo. 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 qu
>>>> e 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 h
>>>> oyo 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 <[hidden email]>
>>>>>>
>>>>>>>
>>>>>>> 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 represen
>>>>>> te? 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 s
>>>>>> e 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 s
>>>>>> iempre 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 preocu
>>>>>> pe 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 experienci
>>>>>> a 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 h
>>>>>> acerlo en
>>>>>> paralelo, si generalmente es al revés, la cola es para ser
>>>>>> ializarlos
>>>>>> (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 n
>>>>>> ivel 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 mant
>>>>>> endrí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 exi
>>>>>> ste"... ;-)
>>>>>>>
>>>>>>> 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 n
>>>>>> o. Puede que
>>>>>> algunos objetos ya estén acá o que realmente estén allá. E
>>>>>> n 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.goog
>>>>>> le.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 hash
>>>>>> ing 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 dis
>>>>>> co. 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úsq
>>>>>> ueda 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 p
>>>>>> ara 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 <[hidden email]>
>>>>>>>         Que rápido. Me parece que pasó menos de una semana.
>>>>>>>
>>>>>>>         Unas preguntas:
>>>>>>>
>>>>>>>         1. ¿Cómo publicas los objetos que reciben mensaj
>>>>>>> es remotos
>>>>>>>         para ser
>>>>>>>         usados por las máquinas remotas? ¿Existe un serv
>>>>>>> icio 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 mensaj
>>>>>>> e 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 so
>>>>>>> n siempre
>>>>>>>         serializados o
>>>>>>>         también se puede enviar un proxy de ellos (por e
>>>>>>> jemplo 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 pr
>>>>>>> otocolo 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 o
>>>>>>> tra máquina?
>>>>>>>         6. ¿Cómo implementarías map-reduce con AjTalk? S
>>>>>>> uponiendo 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 <[hidden email]>
>>>>>>>         >         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 qu
>>>>>>> e 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
>>>>>>> <[hidden email]>:
>>>>>>>         >         > 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
>>>>>>>         <[hidden email]>
>>>>>>>         >         >>
>>>>>>>         >         >> Che, si es esto a lo que Mariano se  
>>>>>>> referia, no
>>>>>>>         nos
>>>>>>>         >         olvidemos de
>>>>>>>         >         >> GemStone que hace no se, 25 años qu
>>>>>>> e 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
>>>>>>>         <[hidden email]>:
>>>>>>>         >         >> > 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
>>>>>>>         >         [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
>>>>>>>         >         >
>>>>>>>         >         > --
>>>>>>>         >         > 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
>>>>>>>         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  
>>>>>>> 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  
>>>>>>> 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 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
>>>>>
>>>>> --
>>>>> 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

> Comentario corto: Hace unos anios comence a escribir este tipo de pet
> project, en C#, porque no estaba claro que pasaba con un Java VM o JDK
> Abierto. Ahora esta el Harmony de Apache, que recuerde. Pero ya casi desde
> principios de siglo, tenemos Mono. No probe todo lo que escribo, pero un pet
> project bastante importante para mi, que esta siendo usado diaramente en dos
> proyectos de desarrollo, corre sin tocar nada, desde el compilado, en Ubuntu
> con Mono, y en OS/X de Mac con Mono.
>
> Y esta todo el codigo fuente de Mono para ese soporte.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
> 2010/10/19 Guillermo Schwarz <[hidden email]>
>>
>>>
>>>> Quizás lo que quiere Valluod es desligarse de una plataforma (C#) de la
>>>> que no tiene los fuentes ;-)
>>>
>>> Lo que?
>>
>> Me refería al codigo fuente de c#.
>>
>> Si el día de mañana sacan Windows 9 u 8 y sobre el corre solo .net 9 u 8,
>> pero tu vm no corre sobre el nuevo runtime, perdiste toda la inversión de
>> tiempo que hiciste.
>>
>> Mientras que si desarrollas sobre una plataforma open source, no importa
>> lo que cambien por debajo, siempre puedes adaptar tu plataforma porque
>> dispones del código fuente.
>>
>>
>>>
>>> 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

> Comentario corto: Hace unos anios comence a escribir este tipo de pet
> project, en C#, porque no estaba claro que pasaba con un Java VM o JDK
> Abierto. Ahora esta el Harmony de Apache, que recuerde. Pero ya casi
> desde principios de siglo, tenemos Mono. No probe todo lo que escribo,
> pero un pet project bastante importante para mi, que esta siendo usado
> diaramente en dos proyectos de desarrollo, corre sin tocar nada, desde
> el compilado, en Ubuntu con Mono, y en OS/X de Mac con Mono.
>
> Y esta todo el codigo fuente de Mono para ese soporte.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
> 2010/10/19 Guillermo Schwarz <[hidden email]>
>        
>                
>                         Quizás lo que quiere Valluod es desligarse de
>                         una plataforma (C#) de la que no tiene los
>                         fuentes ;-)
>                
>                 Lo que?
>        
>        
>         Me refería al codigo fuente de c#.
>        
>         Si el día de mañana sacan Windows 9 u 8 y sobre el corre
>         solo .net 9 u 8, pero tu vm no corre sobre el nuevo runtime,
>         perdiste toda la inversión de tiempo que hiciste.
>        
>         Mientras que si desarrollas sobre una plataforma open source,
>         no importa lo que cambien por debajo, siempre puedes adaptar
>         tu plataforma porque dispones del código fuente.
>        
>        
>        
>        
>                
>                 Andres.
>
>
>
> --
> 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

> Hola gente!
>
> Interesante el enlace de parallel, gracias Guillermo.
>
> Comentario rapido: el codigo de tarde de domingo, fue agregar
> transacciones a objetos, en AjTalk. Esta funcionando, pero todavia en
> revision. Me falta implementar la sintaxis con la que lo voy a usar,
> pero sera algo como:
>
> myObj := MyClass new asTransactionable.
>
> "tambien podria poner"
>
> MyClass transactionable: true.
>
> "y de ahi en mas los objetos creados de MyClass son transactionables".
>
> Transaction begin.
>
> "modifican los objetos, habra objetos transaccionables"
>
> Transaction commit. "o Transaction rollback"
>
> Si dos Process tratan de modificar la misma variable de instancia de
> myObj, uno dara exception. Me falta controlar las variables indexadas.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
> 2010/10/26 Guillermo Schwarz <[hidden email]>
>         Sí, bueno, yo veo que todo tiende a Java, a pesar de que los
>         lenguajes
>         funcionales (F#) parecen estar mejor implementados en .NET que
>         en la JVM
>         (Scala y Clojure).
>        
>         Y me gustó la idea de implementar EJBs en Smalltalk, por
>         alguna razón
>         imagino que es un buen vehículo conceptual que existan threads
>         con
>         transacciones en vez de threads con locks.
>        
>         Y de esa manera las bases de datos resuelven el tema de las
>         transacciones, el código en Smalltalk simplemente indica en
>         qué momento
>         gatillar el "commit".
>        
>         Entonces estará el problema de cómo hacer las transacciones a
>         la base de
>         datos si según recuerdo no existe una manera estándar como
>         JDBC para
>         acceeder a las BDR desde Smalltalk. Entonces me topé con
>         TOPLink, que al
>         parecer es sólo abierto en el caso de Java y con Glorp, que al
>         parecer
>         es el estándar hoy en día en el mundo Smalltalk:
>        
>         http://www.glorp.org/
>        
>         Entonces una vez implementada la persistencia mediante Glorp,
>         debiera
>         poder delimitar transacciones a través de EJBs y la ejecución
>         a través
>         de [] fork debiera ser trivial...
>        
>         Al menos conceptualmente me parece que la solución anda, no sé
>         tú. ¿Te
>         suena a que anda?
>        
>         ¿Porqué digo esto? Porque me topé con esto:
>         http://wiki.squeak.org/squeak/537
>        
>         Lo que me parece que estuvieran tratando de replicar son los
>         ambientes
>         Lisp distribuidos en los que funciona de manera trivial el
>         paralelismo
>         masivo porque en Lisp casi no hay nada compartido. Lograr eso
>         en
>         Smalltalk creo que es casi imposible, porque el lenguaje está
>         pensado
>         para que modifique el estado de los objetos en memoria. El
>         enfoque que
>         yo tengo es que sea responsabilidad del programador no hacer
>         ninguna
>         llamada a objetos en memoria, lo mismo que pasa con los EJBs
>         en Java.
>        
>         Ahora como estos EJBs están en Smalltalk en realidad debieran
>         llamarse
>         EOB (Enterprise OBjects).
>        
>         Saludos,
>         Guillermo.
>        
>        
>        
>         On Tue, 2010-10-19 at 18:26 -0300, Angel Java Lopez wrote:
>         > Comentario corto: Hace unos anios comence a escribir este
>         tipo de pet
>         > project, en C#, porque no estaba claro que pasaba con un
>         Java VM o JDK
>         > Abierto. Ahora esta el Harmony de Apache, que recuerde. Pero
>         ya casi
>         > desde principios de siglo, tenemos Mono. No probe todo lo
>         que escribo,
>         > pero un pet project bastante importante para mi, que esta
>         siendo usado
>         > diaramente en dos proyectos de desarrollo, corre sin tocar
>         nada, desde
>         > el compilado, en Ubuntu con Mono, y en OS/X de Mac con Mono.
>         >
>         > Y esta todo el codigo fuente de Mono para ese soporte.
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         > 2010/10/19 Guillermo Schwarz <[hidden email]>
>         >
>         >
>         >                         Quizás lo que quiere Valluod es
>         desligarse de
>         >                         una plataforma (C#) de la que no
>         tiene los
>         >                         fuentes ;-)
>         >
>         >                 Lo que?
>         >
>         >
>         >         Me refería al codigo fuente de c#.
>         >
>         >         Si el día de mañana sacan Windows 9 u 8 y sobre el
>         corre
>         >         solo .net 9 u 8, pero tu vm no corre sobre el nuevo
>         runtime,
>         >         perdiste toda la inversión de tiempo que hiciste.
>         >
>         >         Mientras que si desarrollas sobre una plataforma
>         open source,
>         >         no importa lo que cambien por debajo, siempre puedes
>         adaptar
>         >         tu plataforma porque dispones del código fuente.
>         >
>         >
>         >
>         >
>         >
>         >                 Andres.
>         >
>         >
>         >
>        
>         > --
>        
>         > 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 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 clubSmalltalk
> +[hidden email]
>  
> http://www.clubSmalltalk.org

> Hola gente!
>
>
>
> STM tiene otro “twist”: la concurrencia. Clojure y otros, están
> alineados a que haya elementos consumibles concurrentemente. Por un
> lado, como apuntabas en otro email, con datos inmutables. Clojure
> tiene toda una serie de estructuras que llaman “Persistent”, no
> confundir con persistencia en base de datos o similares. Por otro
> lado, tiene datos mutables, pero vigilados por STM, también para
> concurrencia.
>
>  
>
> Pongo Clojure como ejemplo. El tema a resolver: manejar la
> concurrencia sobre objetos mutables, sin tener que perder el pelo en
> el intento. Como ya discutimos, otra forma es manejar la concurrencia
> sin tener mutabilidad, tan afin a programación funcional.
>
>  
>
> Algo para leer:
>
> http://doc.akkasource.org/stm-scala
>
> donde aparece Scala (sobre Java) y Akka (excelente proyecto
> distribuido). Ahí hay algunos uses cases, discusión de persistent
> structures y demás.
>
> Algun experimento de STM que se abandono, pero interesante:
>
> http://channel9.msdn.com/Blogs/Charles/STMNET-Who-What-Why
>
>  
>
> Mi idea es reproducir eso en otros ámbitos (lo tengo escrito y
> publicado), y en particular, ahora, en AjTalk. Por eso también lo de
> distribuido. Concurrencia y paralelismo, tanto en la misma maquina,
> como en varias. Conseguir eso sobre una maquina con multiples core, o
> escalar hacia afuera con varias maquinas. Mis casos de uso todavía no
> necesitan transacciones, pero lo vi en Clojure y veo que lo usan. Y
> por lo que lei en GemStone, parece que lo usan, tengo que preguntar
> por aca algunos temas. Alguna vez llegara a mi un caso de uso para eso
> (de hecho, pregunte por aca como hacían para manejar la concurrencia
> sobre objetos en Smalltalk, no parece haber una forma, o no comentaron
> nada). Tengo otros casos de uso para distribuido, agentes, acceso
> a .NET o Java nativo, etc, que ya mencione por aca.
>
>  
>
> Casos de uso: escalabilidad por concurrencia, sobre dominios que no es
> importante grabar y tener persistencia al momento, como servicios
> usados en Farmville, Twitter, etc.. Pero no tengo un caso en concreto.
> Pero a lo que voy (mas hacia el final) no todo gira alrededor de una
> base de datos. Notable ejemplo: la imagen de Smalltalk. Tranquilamente
> puedo trabajar con todo un dominio reificado en la imagen, ya sea en
> memoria, en disco.
>
>  
>
> Entonces, por que ponerlo ahora, esto de objetos transaccionales? (de
> hecho, escribi por aca hace como 3 semanas, que no estaba alto en mi
> lista de prioridades) Porque me pareció un “proof of concept”
> interesante de otra idea: agregar conducta a objetos AjTalk mediante
> decoradores, tipo el objeto intermedio que comentaba Mariano. Hoy
> agrego decoradores para conseguir objetos transaccionales. Ayer, para
> tener objetos distribuidos remotos. Maniana, para conseguir objetos
> que persistan si no son usados o por otro criterio.
>
>  
>
> Persistencia en la base de datos, estará alguna vez, por si se corta
> la luz ;-)
>
> http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx
>
> (donde hay mas indicios para NO ocuparse de la base de datos ahora, en
> estos temas. El tema nos llevaría a NoSQL y otros temas, que se alejan
> de esta lista, pero en los que me parece que Smalltalk puede ir
> montándose tranquilamente, seguramente hay proyectos sobre eso)
>
>  
>
> Un tema que quería contestarle a Mariano: se imaginan una “maquina
> Smalltalk”, cuyo procesos estén siendo ejecutados en varias maquinas
> físicas, sin solución de continuidad, todos los procesadores, toda la
> memoria, como si fueran uno?
>
>  
>
> La persistencia estaría dada por la existencia de varias maquinas,
> quizás distribuidas: se cae una, otra tiene lo que falta, como en
> varias implementaciones de NoSql. Ver
>
> http://delicious.com/ajlopez/nosql
>
>  
>
> Otro punto mas: si tuviera un Sistema Pick, como ya mencione en otro
> thread, lo de objetos transaccionales bastaría, sin necesidad de base
> de datos.
>
>  
>
> Espero haber dejado varias ideas ligadas a Smalltalk, y no haberme ido
> demasiado por las ramas, para esta lista.
>
>  
>
> Nos leemos!
>
>  
>
> Angel “Java” Lopez
>
> http://www.ajlopez.com
>
> http://twitter.com/ajlopez
>
>  
>
>  
>
> De:[hidden email]
> [mailto:[hidden email]] En nombre de Guillermo Schwarz
> Enviado el: Wednesday, October 27, 2010 10:24 AM
> Para: [hidden email]
> Asunto: Re: [clubSmalltalk] Objetos Distribuidos
>
>
>  
>
> Ángel,
>
>  
>
>
> No me parece mal lo de STM, pero no veo la necesidad. (Alguna vez
> escuché la frase "es una solución en busca de un problema, en vez de
> un problema en busca de una solución", creo que en esta ocasión se
> ajusta perfecto al caso).
>
>  
>
>
> Primero los objetos deben ser durables, de otra manera ¿para qué
> modificarlos? Si son transientes son sólo parte de un mecanismo, no me
> interesa que lo que ve una persona o que modifica, lo pueda ver
> también otro. IMHO, no tiene senido, a menos que quieras que hagan
> dibujos en Paint de manera simultánea y luego se borren.
>
>
>  
>
>
> Parece más bien un caso particular de "escríbelo en la BD y luego
> bórralo de manera explícita". Si la disculpa para hacerlo como lo
> haces es que no quieres que se demore mucho (porque la BD es lenta) me
> parece que hay usar una BD más rápida.
>
>
>  
>
>
> En general si tienes objetos transientes, lo único que quieres es que
> no se toquen unos a otros, que tengan todo separado de manera que no
> haya "locking". Eso es lo que hace con los EJBs, todo separado hasta
> que se llega a la BD que tiene sus propios mecanismos de resolución y
> si investigas cóm lo hace, tierne más éxito si usa non locking
> algorithms.
>
>
>  
>
>
> ¿Qué estás tratando de resolver realmente? Porque hasta el momento
> aparte de que es interesante poder lograr lo que has hecho, me parece
> que cualqueir problema real que podría ser un caso de uso de usuario
> que podría requerir lo que estás haciendo se puede resolver de 20
> maneras diferentes con soluciones que ya están hechas y probadas. (No
> es por bajar el ánimo, eh? Es sólo tratar de hacer más fructífero el
> desarrollo).
>
>
>  
>
>
> Saludos,
>
>
> Guillermo.
>
>
>  
>
> 2010/10/27 Angel Java Lopez <[hidden email]>
>
> Hola gente!
>
> Guillermo, el ambito de aplicacion de lo que quiero hacer, es similar
> al de Software Transactional Memory, donde tambien se mencionan
> Transactional Objects, no a la de las bases de datos. Una comparacion
> de los dos ambitos, tomado de un proyecto/ejemplo en  .NET:
>
> http://weblogs.asp.net/ralfw/archive/2007/07/04/software-transactional-memory-ii-isolation-of-changes-to-transactional-objects.aspx
>
> Mis enlaces
> http://delicious.com/ajlopez/stm
>
>
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/27 Guillermo Schwarz <[hidden email]>
>
>          
>        
>         Hola Angel,
>        
>         creo que se debe aclarar los términos.
>        
>         En el mundo de las bases de datos relacionales las
>         transacciones
>         significan ACID: Atomic, Consistent, Isolated y Durable.
>        
>         En particular Atomic significa que o se hacen todas las
>         operaciones o no
>         se hace ninguna. ¿Cómo implementas eso? No sólo los objetos
>         "transaccionables" deben volver al estado en que estaban, sino
>         que todos
>         los qu ehayan sido modificados. Si un objeto no es durable,
>         debiera dar
>         lo mismosi se puede devolver a su estado anterior. Por ejemplo
>         un
>         socket, si ya envió algo por la red, imposible "desenviarlo".
>         Por eso en
>         los EJBs no está permitio conectarse a través de sockets ni
>         escibir
>         archivos.
>        
>         Luego lo de Consistent, no hay manera de hacerlo en Smalltalk
>         a menos
>         que modeláramos tablas relacionales en Smalltalk de modo que
>         cada tabla
>         fuera por ejemplo un Dictionary (PK -> registro completo).
>         Creo que esto
>         hasta el momento no existe.
>        
>         Luego lo de Isolated, creo que es lo que implementaste tú, una
>         de las
>         transacciones falla (y se podría ejecutar de nuevo) si trata
>         de
>         modificar un objeto que ha sido modificado en una transacción
>         que aún se
>         encuentra activa.
>        
>         Finalmente lo de Durable correspondería a que el Dictionary
>         que
>         representa cada tabla fuera persistente.
>        
>         No sé si te hace sentido.
>        
>         Saludos,
>         Guillermo.
>        
>        
>         On Tue, 2010-10-26 at 06:17 -0300, Angel Java Lopez wrote:
>         > Hola gente!
>         >
>         > Interesante el enlace de parallel, gracias Guillermo.
>         >
>         > Comentario rapido: el codigo de tarde de domingo, fue
>         agregar
>         > transacciones a objetos, en AjTalk. Esta funcionando, pero
>         todavia en
>         > revision. Me falta implementar la sintaxis con la que lo voy
>         a usar,
>         > pero sera algo como:
>         >
>         > myObj := MyClass new asTransactionable.
>         >
>         > "tambien podria poner"
>         >
>         > MyClass transactionable: true.
>         >
>         > "y de ahi en mas los objetos creados de MyClass son
>         transactionables".
>         >
>         > Transaction begin.
>         >
>         > "modifican los objetos, habra objetos transaccionables"
>         >
>         > Transaction commit. "o Transaction rollback"
>         >
>         > Si dos Process tratan de modificar la misma variable de
>         instancia de
>         > myObj, uno dara exception. Me falta controlar las variables
>         indexadas.
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         > 2010/10/26 Guillermo Schwarz <[hidden email]>
>         >         Sí, bueno, yo veo que todo tiende a Java, a pesar de
>         que los
>         >         lenguajes
>         >         funcionales (F#) parecen estar mejor implementados
>         en .NET que
>         >         en la JVM
>         >         (Scala y Clojure).
>         >
>         >         Y me gustó la idea de implementar EJBs en Smalltalk,
>         por
>         >         alguna razón
>         >         imagino que es un buen vehículo conceptual que
>         existan threads
>         >         con
>         >         transacciones en vez de threads con locks.
>         >
>         >         Y de esa manera las bases de datos resuelven el tema
>         de las
>         >         transacciones, el código en Smalltalk simplemente
>         indica en
>         >         qué momento
>         >         gatillar el "commit".
>         >
>         >         Entonces estará el problema de cómo hacer las
>         transacciones a
>         >         la base de
>         >         datos si según recuerdo no existe una manera
>         estándar como
>         >         JDBC para
>         >         acceeder a las BDR desde Smalltalk. Entonces me topé
>         con
>         >         TOPLink, que al
>         >         parecer es sólo abierto en el caso de Java y con
>         Glorp, que al
>         >         parecer
>         >         es el estándar hoy en día en el mundo Smalltalk:
>         >
>         >         http://www.glorp.org/
>         >
>         >         Entonces una vez implementada la persistencia
>         mediante Glorp,
>         >         debiera
>         >         poder delimitar transacciones a través de EJBs y la
>         ejecución
>         >         a través
>         >         de [] fork debiera ser trivial...
>         >
>         >         Al menos conceptualmente me parece que la solución
>         anda, no sé
>         >         tú. ¿Te
>         >         suena a que anda?
>         >
>         >         ¿Porqué digo esto? Porque me topé con esto:
>         >         http://wiki.squeak.org/squeak/537
>         >
>         >         Lo que me parece que estuvieran tratando de replicar
>         son los
>         >         ambientes
>         >         Lisp distribuidos en los que funciona de manera
>         trivial el
>         >         paralelismo
>         >         masivo porque en Lisp casi no hay nada compartido.
>         Lograr eso
>         >         en
>         >         Smalltalk creo que es casi imposible, porque el
>         lenguaje está
>         >         pensado
>         >         para que modifique el estado de los objetos en
>         memoria. El
>         >         enfoque que
>         >         yo tengo es que sea responsabilidad del programador
>         no hacer
>         >         ninguna
>         >         llamada a objetos en memoria, lo mismo que pasa con
>         los EJBs
>         >         en Java.
>         >
>         >         Ahora como estos EJBs están en Smalltalk en realidad
>         debieran
>         >         llamarse
>         >         EOB (Enterprise OBjects).
>         >
>         >         Saludos,
>         >         Guillermo.
>         >
>         >
>         >
>         >         On Tue, 2010-10-19 at 18:26 -0300, Angel Java Lopez
>         wrote:
>         >         > Comentario corto: Hace unos anios comence a
>         escribir este
>         >         tipo de pet
>         >         > project, en C#, porque no estaba claro que pasaba
>         con un
>         >         Java VM o JDK
>         >         > Abierto. Ahora esta el Harmony de Apache, que
>         recuerde. Pero
>         >         ya casi
>         >         > desde principios de siglo, tenemos Mono. No probe
>         todo lo
>         >         que escribo,
>         >         > pero un pet project bastante importante para mi,
>         que esta
>         >         siendo usado
>         >         > diaramente en dos proyectos de desarrollo, corre
>         sin tocar
>         >         nada, desde
>         >         > el compilado, en Ubuntu con Mono, y en OS/X de Mac
>         con Mono.
>         >         >
>         >         > Y esta todo el codigo fuente de Mono para ese
>         soporte.
>         >         >
>         >         > Nos leemos!
>         >         >
>         >         > Angel "Java" Lopez
>         >         > http://www.ajlopez.com
>         >         > http://twitter.com/ajlopez
>         >         >
>         >         > 2010/10/19 Guillermo Schwarz
>         <[hidden email]>
>         >         >
>         >         >
>         >         >                         Quizás lo que quiere
>         Valluod es
>         >         desligarse de
>         >         >                         una plataforma (C#) de la
>         que no
>         >         tiene los
>         >         >                         fuentes ;-)
>         >         >
>         >         >                 Lo que?
>         >         >
>         >         >
>         >         >         Me refería al codigo fuente de c#.
>         >         >
>         >         >         Si el día de mañana sacan Windows 9 u 8 y
>         sobre el
>         >         corre
>         >         >         solo .net 9 u 8, pero tu vm no corre sobre
>         el nuevo
>         >         runtime,
>         >         >         perdiste toda la inversión de tiempo que
>         hiciste.
>         >         >
>         >         >         Mientras que si desarrollas sobre una
>         plataforma
>         >         open source,
>         >         >         no importa lo que cambien por debajo,
>         siempre puedes
>         >         adaptar
>         >         >         tu plataforma porque dispones del código
>         fuente.
>         >         >
>         >         >
>         >         >
>         >         >
>         >         >
>         >         >                 Andres.
>         >         >
>         >         >
>         >         >
>         >
>         >         > --
>         >
>         >         > 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
>         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 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 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 clubSmalltalk
> +[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 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 clubSmalltalk
> +[hidden email]
>  
> http://www.clubSmalltalk.org

> Hola gente!
>
> Guillermo, muy interesante, pero creo que en alguna parte, nos vamos
> del tema de la lista.
>
> Asi, que comentarios solo sobre lo mas cercano a Smalltalk, que todo
> lo que comentas.
>
> Lo de mantener el valor de una variable en el thread, es lo que hacen
> varias implementaciones, como Clojure (y ejem... AjSharpure,
> tambien ;-), tema que ya habia enviado, como enlace, en alguno de
> estos threads. Apenas una punta en:
> http://david-mcneil.com/post/1439050822/clojure-dynamic-variables-and-java-threadlocals
> Descripto en mas alto nivel:
> http://clojure.org/concurrent_programming
>
> Parecido a lo que quiero hacer con transaccion:
> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dosync
> Pero opera solo sobre variables del tipo ref. En mi caso, en AjTalk,
> sobre objetos transaccionales. Y mi transaccion (sus datos: en que
> "tiempo" comenzo, si esta activa, etc...) esta en Thread Local.
>
> Con respecto a:
> Encuentro super raro lo que mandaste respecto de que se requiera tener
> en Java un modelo STM ya que en Java el memory model es tal que las
> variables no se comparten a menos que explícitamente se utilice
> "synchronized"...
>
>
> Hmmm... o sea que toda la gente que esta implementando STM en Java
> esta equivocada? :-) :-) Bueno, se lo voy a comentar a Rich Hickey, en
> cuanto me lo cruce ;-)...
>
> Lo que encuentro "super raro" es eso que las "variables no se
> comparten". Claro que se comparten en Java. Cualquiera puede ir a una
> variable accesible, desde dos threads. No hace falta poner
> "synchronized" para compartirlas.
>
> Volviendo a Smalltalk, quiero explicar por que no sigo tu "approach"
> sugerido. Yo quiero llegar, en memoria, en AjTalk (olvidemos base de
> datos) a un Isolation de Serialization, por lo menos. Si dos
> transacciones tocan el mismo slot (variable de instancia), una no
> prosigue. Por que? Porque si T1 trata de cambiar S1 de 100 a 200, y T2
> trata de cambiar al mismo S1 de 100 a 300, puede ser que T2 haya
> tomado la decision basandose en varios valores, que leyo hace un
> tiempo, tal vez, tambien leyo S1 y lo encontro en 100, hace un tiempo,
> y decidio sumarle 200, despues de un tiempo. Se puede proteger mejor a
> T2 si al leer S1 con 100, lo lockea. Pero eso implicaria que toda
> transaccion LOCKEE cada slot que va leyendo, cuando probablemente
> cambie solo algunos, u obligar al programador que ponga explicitamente
> que esta haciendo un getInstVarAt: . Y ese lockeo, tan agresivo y
> granular, al fin, conspiraria contra la concurrencia.
>
> Hmmm.. con respecto a tu synchronized... Por lo que entendi, solo
> serviria para la variable que declaras como sincronizada. Pero que
> pasa si esa variable es anInvoice, y en el bloque modificas algo que
> no es slot directo de anInvoice, sino que vas a una lista contenida en
> una variable de instancia de anInvoice, que contiene la lista de
> renglones, y le cambias esa lista de renglones, o el contenido de un
> renglon?
>
> En mi implementacion, los objetos del dominio, Invoice, Product,
> InvoiceProduct, etc... serian transaccionables (por poner un caso,
> supongo que en GemStone seria: todos esas clases las manejo en
> GemStone: hay que poner en algun momento un "fence" que diga cuales
> son los objetos que quiero transaccionar o no, cuales son las clases
> que manejo en GemStone y cuales no). O llegado el caso, podria hacer
> que todos los objetos sean transaccionales (dudo que lo necesite, pero
> puedo hacerlo).
>
> Un caso de uso: dos agentes (que trabajan en threads diferentes,
> procesando mensajes tipo Twitter) quieren modificar una lista de
> mensajes entrantes para un tema. En mi implementacion, tanto los
> agentes como la lista de mensajes, se declaran explicitamente, los
> primeros como agentes (y no simples objetos) y la lista de mensajes
> como transaccional (y no simple objeto, donde todos van y le pegan sin
> importar la concurrencia). De ahi que no me decante por un
> "sincronizame esta variable y hace tal block". Quiero que la lista de
> mensajes, sin que el programador tenga que recordar si tiene
> concurrencia de agentes o no, siempre funcione como transaccional
> dentro de una transaccion. El trabajo para el programador es: declarar
> la transaccion, no declarar ni acordarse cuales objetos tiene que
> "sincronizar" y cuales no. Lo mismo con agentes: se declaran desde el
> principio como agentes, y voila. Ahora tengo una explicacion corta en
> Anglish:
> http://ajlopez.wordpress.com/2010/10/23/agents-in-ajtalk-introduction/
>
> Les debo lo de objetos transaccionales.
>
> [Atencion: desde el principio de mi propuesta de transacciones (como
> supongo que debe pasar en GemStone), el Invoice digamos #12 (si es que
> queremos manejar Invoices desde mas de una transaccion, pongo Invoice
> como ejemplo, bien podria ser una lista de mensajes de Twitter o lo
> que sea que quiera implementar, y que pueda ser consultado, modificado
> concurrentemente), reside en memoria con identidad (no hay dos Invoice
> #12, digamos). Aclaro esto, porque en otras implementaciones, cuando
> un proceso/thread trabaja con el dominio, reificia Invoice #12 en
> memoria, desde posiblemente la base de datos, y tiene una copia en
> memoria de Invoice#12, mientras otro proceso/thread que justo tambien
> quiere trabajar con Invoice#12, se le DA OTRA REIFICACION de esa
> factura, al final, ambos hacen commit, y los conflictos se resuelven,
> no en la memoria, sino en el sistema de persistencia, 99% de los
> casos, la base de datos relacional. No es a estos casos a los que va
> apuntado mi intento de objetos transaccionales].
>
> En mi implementacion, vigilo los slots de los objetos transaccionales,
> en lugar de objetos/variables. Si en la transaccion T1 accedo al
> objeto O1 y leo el slot S1, me fijo si hay un valor asignado ya en T1,
> sino, tomo el valor que habia en S1 antes de iniciar T1. Podria
> mantener los valores cambiados por T1 en el thread actual, pero en mi
> implementacion quiero saber si hay otra T2 que modifico a S1 en O1, lo
> mas temprano posible (no en el commit). Asi que igual tendria que ver
> los valores de otros threads. Solo podria mantener los valores de S1
> en local thread, si difiriera la deteccion de conflictos hasta el
> commit. Pero hay sutilezas: una transaccion T1 puede committear sus
> valores, pero no puedo poner directamente esos valores en el lugar de
> S1 que no es local thread (el valor real, final, global, digamos). Por
> que? Porque puede haber transacciones activas que todavia estan
> interesadas en el valor que tiene S1 cuando comenzaron. A ver si doy
> ejemplo:
>
> Tiempo 0: S1 tiene 100 (pongamos notacion S1=100/Tiempo 0)
> Tiempo 1: T1 comienza
> Tiempo 2: S1 tiene 100 (es lo que ve el resto del sistema, con o sin
> transaccion)
> Tiempo 3: T2 comienza
> Tiempo 4: T1 cambia S1 a 200
> Tiempo 5: T1 commitea
> Tiempo 6: T2 consulta S1, que le damos? el valor de tiempo 5 (t1
> commiteado? S1=200) o el valor de antes de su comienzo (tiempo 2, S1 =
> 100)?
>
> En mi implementacion, a T2 se le da S1=200/Tiempo 2. T2 ve un
> "snapshop" del sistema al momento de iniciarse. Y quiero que sea asi:
> todas las decisiones de T2, deberia basarse en un "snapshop" de los
> objetos transaccionales que maneje: T2 no puede ver S1 en 100 en un
> momento, y S2 en 200 en otro momento de su vida (del lifetime de T2).
>
> Asi que Tiempo 5, cuando T1 committea, no puedo simplemente poner el
> valor GENERAL de S1 en 200 (en Clojure, se llamaria el valor root, en
> el codigo fuente de Clojure). Tengo que mantener S1=100/Tiempo 2 hasta
> que todas las transacciones interesadas en el valor al tiempo 2 se
> terminen. Queda algo como:
>
> S1=100/Tiempo 2
> S1=200/Tiempo 5
>
> Cuando todas las transacciones activas son con tiempo de inicio > 5, o
> no hay mas transacciones, paso a:
>
> S1=200/Tiempo 0  (el valor global, el final, en el objeto O1)
>
> y aqui no ha pasado nada, muchachos... ;-)
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/31 Guillermo Schwarz <[hidden email]>
>         Angel,
>        
>         Claro, la principal razón para querer tener transacciones es
>         tener
>         concurrencia, la atomicidad es un "second thought"... sin
>         embargo es el
>         "isolated" el que le da la oportunidad de ser concurrente sin
>         necesidad
>         de tener que terminar la primera transacción para empezar la
>         otra.
>        
>         En la práctica uno puede hacer las operaciones "locked" tan
>         pequeñas
>         como quiera para aumentar la concurrencia (ese es el "insight"
>         que
>         utiliza SQL). En otras palabras en vez de hacer "begin tx" =
>         "begin
>         lock" y "commit" = "end lock", se agarra cada operación de la
>         transacción y se hace que tome un "lock" el objeto de la BD
>         que está
>         tocando. Aún más, se puede hacer que toda la transacción
>         trabaje sobre
>         una copia de la BD y al final cuando se hace commit, se
>         reemplaza un
>         puntero con CAS o LL/SC.
>        
>         http://www.audiomulch.com/~rossb/code/lockfree/
>        
>         CAS tiene el problema del ABA así que supongo que no es
>         recomendable.
>         Acá se explica:
>        
>         http://www.audiomulch.com/~rossb/code/lockfree/
>        
>         Y también se da una solución: agregar un contador.
>        
>         CAS hace rato que viene implementada en la CPU X86, de modo
>         que se
>         podría considerar que es estándar. Pero al parecer tiene bugs:
>        
>         https://patchwork.kernel.org/patch/19429/
>        
>         No sé a ustedes pero la impresión que tengo es que tener bugs
>         a nivel de
>         la CPU es un "total turn-off". Sin embargo si tenemos un
>         proyecto ya
>         metido en esto lo único que queda es detectar en qué CPU
>         estamos
>         corriendo y aplicar un workaround en ese caso particular (que
>         podría ser
>         tomar objetos más grandes y utiliar locks más grandes).
>        
>         Se puede agregar:
>         http://phildawes.net/blog/2009/10/13/factor-compiler-adding-instruction/
>        
>         Extraño, no?
>        
>         Lo que mencionas de :
>        
>         > Algo para leer:
>         >
>         > http://doc.akkasource.org/stm-scala
>        
>        
>        
>         Se contradice un poco con lo que envié yo en algo que
>         considero
>         significativo. Lo que envié yo dice que STM a AI, mientras que
>         tu link
>         dice que es ACI.
>        
>         ¿Porqué?
>        
>         Dice ahí que cuando se hace commit de una transacción, la data
>         de la
>         transacción se comparte completa con las otras transacciones o
>         nada.
>         Para mí eso es Atomic, no Consistent. Consistent como mandé en
>         el link
>         significa que existe una metadata que fuerza determinadas
>         cosas como las
>         llaves foráneas, de manera que la data sigue siendo
>         consistente
>         independiente de las operaciones que haya hecho.
>        
>         Por default Smalltalk y cualquier lenguaje no tiene una
>         metadata que
>         fuerce las relaciones entre objetos (sí entre objetos y
>         clases, por
>         ejemplo un objeto pertenece sólo a una clase). Se podría
>         pensar que el
>         sistema de tipos en Java es una forma rudimentaria de
>         metadata, ya que
>         si tengo una función con un paŕametro de tipo String no puedo
>         pasarle un
>         número y viceversa. Pero las restricciones que puedo poner en
>         SQL son
>         mucho más fuertes, parecidas a lo que vendría a ser un sistema
>         de diseño
>         por contratos en Eiffel.
>        
>         http://eiffel.com/developers/presentations/dbc/partone/player.html?slide=
>        
>        
>         Encuentro super raro lo que mandaste respecto de que se
>         requiera tener
>         en Java un modelo STM ya que en Java el memory model es tal
>         que las
>         variables no se comparten a menos que explícitamente se
>         utilice
>         "synchronized", lo que se explica en:
>        
>         http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
>        
>         En resumen se podría decir que las variables son propias al
>         thread. Esto
>         lo he verificado independientemente muchas veces, se debe usar
>         synchronized. El equivalente en Smalltalk sería decir que
>         todas las
>         variables le preguntan al currentProcess (si tal pseudo
>         variable
>         existiera) cual es su valor y si retorna nil, entonces recién
>         le
>         pregunta a Smalltalk. ¿Qué te parecería esa implementación? El
>         único
>         problema que le veo es que nadie usa synchronized en
>         Smalltalk, pero
>         supongo que no sería difícil de implementar:
>        
>         Process>>synchronize: symbol toExecute: block
>                Smalltalk at: symbol put: (self at: symbol).
>                block value
>        
>         y se llamaría as:
>        
>         currentProcess synchronize: #variable toExecute: [...]
>        
>         Como sería muy verboso escribir eso, se podría crear un
>         método:
>        
>         Symbol>>synchronizeOn: block
>            currentProcess synchronize: self toExecute: block
>        
>         Que se invocaría así:
>        
>         #variable synchronizeOn: [...]
>        
>         Probablemente el cambio más grande sería cambiar el compilador
>         para que
>         reconozca currentProcess como una pseudovariable (y sepa a qué
>         objeto
>         asociarlo) y que las variables se busquen en currentProcess
>         antes que en
>         Smalltalk.
>        
>         ¿Qué importancia tiene esto? Que en Java toda la información
>         se maneja
>         en forma local en el thread, de modo que no se actualiza al
>         resto de los
>         threads a menos que explícitamente se ponga un
>         "synchronized" (que por
>         lo tanto es caro, porque cualquier otro thread verá el cambio
>         SSI hace
>         "synchronized" sobre el mismo objeto. Buen truco, ¿no? Pero
>         dado esto,
>         ¿no estamos a un paso de tener transacciones en memoria?
>         Synchronized
>         sería el equivalente a "commit", sólo faltaría implementar el
>         "rollback"
>         y da la casualidad que es mucho más fácil, simplemente el
>         valor que está
>         en el thread se "bota" y se queda con el valor global. Desde
>         el punto de
>         vista del thread basta con copiar el valor de la memoria
>         global al
>         thread.
>        
>         Por cierto se supone que el Double-checked locking fue
>         arreglado en Java
>         5 cambiando el memory model. Lo verifiqué y al menos en esa
>         versión
>         funciona si la variable es "volatile". (Lo mismo ocurre en
>         Microsoft C
>         por si acaso ;-).
>        
>         Lo chistoso del asunto es que esto resuelve el problema del
>         double
>         checked locking:
>        
>         public class MyFactory {
>          private static final MyFactory instance = new MyFactory();
>        
>          public static MyFactory getInstance() {
>            return instance;
>          }
>        
>          private MyFactory() {}
>         }
>        
>         La razón es que la clase no se va a instanciar 2 veces, por
>         ende el problema
>         está resuelto por el class loader. No olvidemos que el
>         problema original era que
>         queríamos ejecutar cierto código una sola vez y se nos ocurrió
>         usar synchronized.
>         En este caso ejecutamos sólo una vez pero porque Java decide
>         cargar clase una
>         sola vez.
>        
>         Es bastante interesante Multiverse (bueno es de codehouse.org,
>         qué se
>         podría esperar ;-) Al parecer la versión 0.6 no la sacaron en
>         Junio como
>         habían planeado. Mirando los "features" de esa versión parece
>         que tenían
>         planificado crear bugs en vez de features, ya que si miras lo
>         que están
>         planeando implementar no es hacer el código más limpio... pero
>         bueno, la
>         idea de STM en general creo que no es muy limpia. Preocupante
>         es eso de
>         agregar "delays". En mi experiencia cada vez que alguien
>         decide "colocar
>         delays para que el thread tenga más tiempo de ejecutar", es
>         porque
>         tenemos problemas serios de "race conditions" y "deadlocks".
>        
>         Si tengo "wait-free" y "block-free" data structures se acaban
>         los
>         live-locks y los dead-locks. No puedo tener un dead-lock si no
>         hago
>         lock. ¿Es obvio no?
>        
>         Doug Lea inventó algoritmos concurrentes en Java sin necesidad
>         de
>         redefinir el lenguaje ni la JVM:
>        
>         http://books.google.cl/books?id=-x1S4neCSOYC&pg=PA145&lpg=PA145&dq=doug
>         +lea+wait
>         +free&source=bl&ots=Dvhr8_Faw_&sig=ttJpnIRaYniMeFnuw8_wpjqmlW4&hl=es&ei=Zv3MTLOCNoOdlgeJ05CmBg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBkQ6AEwAA#v=onepage&q&f=false
>        
>         Por definición esos objetos podrían participar de algoritmos
>         distribuidos, con la ínica salvedad a mi parecer que las
>         estructuras de
>         datos no son (aun) distribuidas de modo que sería necesaria
>         que los
>         proxies hicieran llamadas remotas a donde se encuentran los
>         objetos
>         realmente (eso ya lo tienes hecho). Al interior de las JVM
>         donde esos
>         objetos residen podrían tener threads modificándolos en forma
>         concurrente sin problemas.
>        
>         Saludos,
>         Guillermo.
>        
>        
>         On Wed, 2010-10-27 at 10:59 -0300, Angel "Java" Lopez wrote:
>         > Hola gente!
>         >
>         >
>         >
>         > STM tiene otro “twist”: la concurrencia. Clojure y otros,
>         están
>         > alineados a que haya elementos consumibles concurrentemente.
>         Por un
>         > lado, como apuntabas en otro email, con datos inmutables.
>         Clojure
>         > tiene toda una serie de estructuras que llaman “Persistent”,
>         no
>         > confundir con persistencia en base de datos o similares. Por
>         otro
>         > lado, tiene datos mutables, pero vigilados por STM, también
>         para
>         > concurrencia.
>         >
>         >
>         >
>         > Pongo Clojure como ejemplo. El tema a resolver: manejar la
>         > concurrencia sobre objetos mutables, sin tener que perder el
>         pelo en
>         > el intento. Como ya discutimos, otra forma es manejar la
>         concurrencia
>         > sin tener mutabilidad, tan afin a programación funcional.
>         >
>         >
>         >
>         > Algo para leer:
>         >
>         > http://doc.akkasource.org/stm-scala
>         >
>         > donde aparece Scala (sobre Java) y Akka (excelente proyecto
>         > distribuido). Ahí hay algunos uses cases, discusión de
>         persistent
>         > structures y demás.
>         >
>         > Algun experimento de STM que se abandono, pero interesante:
>         >
>         > http://channel9.msdn.com/Blogs/Charles/STMNET-Who-What-Why
>         >
>         >
>         >
>         > Mi idea es reproducir eso en otros ámbitos (lo tengo escrito
>         y
>         > publicado), y en particular, ahora, en AjTalk. Por eso
>         también lo de
>         > distribuido. Concurrencia y paralelismo, tanto en la misma
>         maquina,
>         > como en varias. Conseguir eso sobre una maquina con
>         multiples core, o
>         > escalar hacia afuera con varias maquinas. Mis casos de uso
>         todavía no
>         > necesitan transacciones, pero lo vi en Clojure y veo que lo
>         usan. Y
>         > por lo que lei en GemStone, parece que lo usan, tengo que
>         preguntar
>         > por aca algunos temas. Alguna vez llegara a mi un caso de
>         uso para eso
>         > (de hecho, pregunte por aca como hacían para manejar la
>         concurrencia
>         > sobre objetos en Smalltalk, no parece haber una forma, o no
>         comentaron
>         > nada). Tengo otros casos de uso para distribuido, agentes,
>         acceso
>         > a .NET o Java nativo, etc, que ya mencione por aca.
>         >
>         >
>         >
>         > Casos de uso: escalabilidad por concurrencia, sobre dominios
>         que no es
>         > importante grabar y tener persistencia al momento, como
>         servicios
>         > usados en Farmville, Twitter, etc.. Pero no tengo un caso en
>         concreto.
>         > Pero a lo que voy (mas hacia el final) no todo gira
>         alrededor de una
>         > base de datos. Notable ejemplo: la imagen de Smalltalk.
>         Tranquilamente
>         > puedo trabajar con todo un dominio reificado en la imagen,
>         ya sea en
>         > memoria, en disco.
>         >
>         >
>         >
>         > Entonces, por que ponerlo ahora, esto de objetos
>         transaccionales? (de
>         > hecho, escribi por aca hace como 3 semanas, que no estaba
>         alto en mi
>         > lista de prioridades) Porque me pareció un “proof of
>         concept”
>         > interesante de otra idea: agregar conducta a objetos AjTalk
>         mediante
>         > decoradores, tipo el objeto intermedio que comentaba
>         Mariano. Hoy
>         > agrego decoradores para conseguir objetos transaccionales.
>         Ayer, para
>         > tener objetos distribuidos remotos. Maniana, para conseguir
>         objetos
>         > que persistan si no son usados o por otro criterio.
>         >
>         >
>         >
>         > Persistencia en la base de datos, estará alguna vez, por si
>         se corta
>         > la luz ;-)
>         >
>         >
>         http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx
>         >
>         > (donde hay mas indicios para NO ocuparse de la base de datos
>         ahora, en
>         > estos temas. El tema nos llevaría a NoSQL y otros temas, que
>         se alejan
>         > de esta lista, pero en los que me parece que Smalltalk puede
>         ir
>         > montándose tranquilamente, seguramente hay proyectos sobre
>         eso)
>         >
>         >
>         >
>         > Un tema que quería contestarle a Mariano: se imaginan una
>         “maquina
>         > Smalltalk”, cuyo procesos estén siendo ejecutados en varias
>         maquinas
>         > físicas, sin solución de continuidad, todos los
>         procesadores, toda la
>         > memoria, como si fueran uno?
>         >
>         >
>         >
>         > La persistencia estaría dada por la existencia de varias
>         maquinas,
>         > quizás distribuidas: se cae una, otra tiene lo que falta,
>         como en
>         > varias implementaciones de NoSql. Ver
>         >
>         > http://delicious.com/ajlopez/nosql
>         >
>         >
>         >
>         > Otro punto mas: si tuviera un Sistema Pick, como ya mencione
>         en otro
>         > thread, lo de objetos transaccionales bastaría, sin
>         necesidad de base
>         > de datos.
>         >
>         >
>         >
>         > Espero haber dejado varias ideas ligadas a Smalltalk, y no
>         haberme ido
>         > demasiado por las ramas, para esta lista.
>         >
>         >
>         >
>         > Nos leemos!
>         >
>         >
>         >
>         > Angel “Java” Lopez
>         >
>         > http://www.ajlopez.com
>         >
>         > http://twitter.com/ajlopez
>         >
>         >
>         >
>         >
>         >
>         > De:[hidden email]
>         > [mailto:[hidden email]] En nombre de
>         Guillermo Schwarz
>         > Enviado el: Wednesday, October 27, 2010 10:24 AM
>         > Para: [hidden email]
>         > Asunto: Re: [clubSmalltalk] Objetos Distribuidos
>         >
>         >
>         >
>         >
>         > Ángel,
>         >
>         >
>         >
>         >
>         > No me parece mal lo de STM, pero no veo la necesidad.
>         (Alguna vez
>         > escuché la frase "es una solución en busca de un problema,
>         en vez de
>         > un problema en busca de una solución", creo que en esta
>         ocasión se
>         > ajusta perfecto al caso).
>         >
>         >
>         >
>         >
>         > Primero los objetos deben ser durables, de otra manera ¿para
>         qué
>         > modificarlos? Si son transientes son sólo parte de un
>         mecanismo, no me
>         > interesa que lo que ve una persona o que modifica, lo pueda
>         ver
>         > también otro. IMHO, no tiene senido, a menos que quieras que
>         hagan
>         > dibujos en Paint de manera simultánea y luego se borren.
>         >
>         >
>         >
>         >
>         >
>         > Parece más bien un caso particular de "escríbelo en la BD y
>         luego
>         > bórralo de manera explícita". Si la disculpa para hacerlo
>         como lo
>         > haces es que no quieres que se demore mucho (porque la BD es
>         lenta) me
>         > parece que hay usar una BD más rápida.
>         >
>         >
>         >
>         >
>         >
>         > En general si tienes objetos transientes, lo único que
>         quieres es que
>         > no se toquen unos a otros, que tengan todo separado de
>         manera que no
>         > haya "locking". Eso es lo que hace con los EJBs, todo
>         separado hasta
>         > que se llega a la BD que tiene sus propios mecanismos de
>         resolución y
>         > si investigas cóm lo hace, tierne más éxito si usa non
>         locking
>         > algorithms.
>         >
>         >
>         >
>         >
>         >
>         > ¿Qué estás tratando de resolver realmente? Porque hasta el
>         momento
>         > aparte de que es interesante poder lograr lo que has hecho,
>         me parece
>         > que cualqueir problema real que podría ser un caso de uso de
>         usuario
>         > que podría requerir lo que estás haciendo se puede resolver
>         de 20
>         > maneras diferentes con soluciones que ya están hechas y
>         probadas. (No
>         > es por bajar el ánimo, eh? Es sólo tratar de hacer más
>         fructífero el
>         > desarrollo).
>         >
>         >
>         >
>         >
>         >
>         > Saludos,
>         >
>         >
>         > Guillermo.
>         >
>         >
>         >
>         >
>         > 2010/10/27 Angel Java Lopez <[hidden email]>
>         >
>         > Hola gente!
>         >
>         > Guillermo, el ambito de aplicacion de lo que quiero hacer,
>         es similar
>         > al de Software Transactional Memory, donde tambien se
>         mencionan
>         > Transactional Objects, no a la de las bases de datos. Una
>         comparacion
>         > de los dos ambitos, tomado de un proyecto/ejemplo en  .NET:
>         >
>         >
>         http://weblogs.asp.net/ralfw/archive/2007/07/04/software-transactional-memory-ii-isolation-of-changes-to-transactional-objects.aspx
>         >
>         > Mis enlaces
>         > http://delicious.com/ajlopez/stm
>         >
>         >
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         >
>         > 2010/10/27 Guillermo Schwarz <[hidden email]>
>         >
>         >
>         >
>         >         Hola Angel,
>         >
>         >         creo que se debe aclarar los términos.
>         >
>         >         En el mundo de las bases de datos relacionales las
>         >         transacciones
>         >         significan ACID: Atomic, Consistent, Isolated y
>         Durable.
>         >
>         >         En particular Atomic significa que o se hacen todas
>         las
>         >         operaciones o no
>         >         se hace ninguna. ¿Cómo implementas eso? No sólo los
>         objetos
>         >         "transaccionables" deben volver al estado en que
>         estaban, sino
>         >         que todos
>         >         los qu ehayan sido modificados. Si un objeto no es
>         durable,
>         >         debiera dar
>         >         lo mismosi se puede devolver a su estado anterior.
>         Por ejemplo
>         >         un
>         >         socket, si ya envió algo por la red, imposible
>         "desenviarlo".
>         >         Por eso en
>         >         los EJBs no está permitio conectarse a través de
>         sockets ni
>         >         escibir
>         >         archivos.
>         >
>         >         Luego lo de Consistent, no hay manera de hacerlo en
>         Smalltalk
>         >         a menos
>         >         que modeláramos tablas relacionales en Smalltalk de
>         modo que
>         >         cada tabla
>         >         fuera por ejemplo un Dictionary (PK -> registro
>         completo).
>         >         Creo que esto
>         >         hasta el momento no existe.
>         >
>         >         Luego lo de Isolated, creo que es lo que
>         implementaste tú, una
>         >         de las
>         >         transacciones falla (y se podría ejecutar de nuevo)
>         si trata
>         >         de
>         >         modificar un objeto que ha sido modificado en una
>         transacción
>         >         que aún se
>         >         encuentra activa.
>         >
>         >         Finalmente lo de Durable correspondería a que el
>         Dictionary
>         >         que
>         >         representa cada tabla fuera persistente.
>         >
>         >         No sé si te hace sentido.
>         >
>         >         Saludos,
>         >         Guillermo.
>         >
>         >
>         >         On Tue, 2010-10-26 at 06:17 -0300, Angel Java Lopez
>         wrote:
>         >         > Hola gente!
>         >         >
>         >         > Interesante el enlace de parallel, gracias
>         Guillermo.
>         >         >
>         >         > Comentario rapido: el codigo de tarde de domingo,
>         fue
>         >         agregar
>         >         > transacciones a objetos, en AjTalk. Esta
>         funcionando, pero
>         >         todavia en
>         >         > revision. Me falta implementar la sintaxis con la
>         que lo voy
>         >         a usar,
>         >         > pero sera algo como:
>         >         >
>         >         > myObj := MyClass new asTransactionable.
>         >         >
>         >         > "tambien podria poner"
>         >         >
>         >         > MyClass transactionable: true.
>         >         >
>         >         > "y de ahi en mas los objetos creados de MyClass
>         son
>         >         transactionables".
>         >         >
>         >         > Transaction begin.
>         >         >
>         >         > "modifican los objetos, habra objetos
>         transaccionables"
>         >         >
>         >         > Transaction commit. "o Transaction rollback"
>         >         >
>         >         > Si dos Process tratan de modificar la misma
>         variable de
>         >         instancia de
>         >         > myObj, uno dara exception. Me falta controlar las
>         variables
>         >         indexadas.
>         >         >
>         >         > Nos leemos!
>         >         >
>         >         > Angel "Java" Lopez
>         >         > http://www.ajlopez.com
>         >         > http://twitter.com/ajlopez
>         >         >
>         >         > 2010/10/26 Guillermo Schwarz
>         <[hidden email]>
>         >         >         Sí, bueno, yo veo que todo tiende a Java,
>         a pesar de
>         >         que los
>         >         >         lenguajes
>         >         >         funcionales (F#) parecen estar mejor
>         implementados
>         >         en .NET que
>         >         >         en la JVM
>         >         >         (Scala y Clojure).
>         >         >
>         >         >         Y me gustó la idea de implementar EJBs en
>         Smalltalk,
>         >         por
>         >         >         alguna razón
>         >         >         imagino que es un buen vehículo conceptual
>         que
>         >         existan threads
>         >         >         con
>         >         >         transacciones en vez de threads con locks.
>         >         >
>         >         >         Y de esa manera las bases de datos
>         resuelven el tema
>         >         de las
>         >         >         transacciones, el código en Smalltalk
>         simplemente
>         >         indica en
>         >         >         qué momento
>         >         >         gatillar el "commit".
>         >         >
>         >         >         Entonces estará el problema de cómo hacer
>         las
>         >         transacciones a
>         >         >         la base de
>         >         >         datos si según recuerdo no existe una
>         manera
>         >         estándar como
>         >         >         JDBC para
>         >         >         acceeder a las BDR desde Smalltalk.
>         Entonces me topé
>         >         con
>         >         >         TOPLink, que al
>         >         >         parecer es sólo abierto en el caso de Java
>         y con
>         >         Glorp, que al
>         >         >         parecer
>         >         >         es el estándar hoy en día en el mundo
>         Smalltalk:
>         >         >
>         >         >         http://www.glorp.org/
>         >         >
>         >         >         Entonces una vez implementada la
>         persistencia
>         >         mediante Glorp,
>         >         >         debiera
>         >         >         poder delimitar transacciones a través de
>         EJBs y la
>         >         ejecución
>         >         >         a través
>         >         >         de [] fork debiera ser trivial...
>         >         >
>         >         >         Al menos conceptualmente me parece que la
>         solución
>         >         anda, no sé
>         >         >         tú. ¿Te
>         >         >         suena a que anda?
>         >         >
>         >         >         ¿Porqué digo esto? Porque me topé con
>         esto:
>         >         >         http://wiki.squeak.org/squeak/537
>         >         >
>         >         >         Lo que me parece que estuvieran tratando
>         de replicar
>         >         son los
>         >         >         ambientes
>         >         >         Lisp distribuidos en los que funciona de
>         manera
>         >         trivial el
>         >         >         paralelismo
>         >         >         masivo porque en Lisp casi no hay nada
>         compartido.
>         >         Lograr eso
>         >         >         en
>         >         >         Smalltalk creo que es casi imposible,
>         porque el
>         >         lenguaje está
>         >         >         pensado
>         >         >         para que modifique el estado de los
>         objetos en
>         >         memoria. El
>         >         >         enfoque que
>         >         >         yo tengo es que sea responsabilidad del
>         programador
>         >         no hacer
>         >         >         ninguna
>         >         >         llamada a objetos en memoria, lo mismo que
>         pasa con
>         >         los EJBs
>         >         >         en Java.
>         >         >
>         >         >         Ahora como estos EJBs están en Smalltalk
>         en realidad
>         >         debieran
>         >         >         llamarse
>         >         >         EOB (Enterprise OBjects).
>         >         >
>         >         >         Saludos,
>         >         >         Guillermo.
>         >         >
>         >         >
>         >         >
>         >         >         On Tue, 2010-10-19 at 18:26 -0300, Angel
>         Java Lopez
>         >         wrote:
>         >         >         > Comentario corto: Hace unos anios
>         comence a
>         >         escribir este
>         >         >         tipo de pet
>         >         >         > project, en C#, porque no estaba claro
>         que pasaba
>         >         con un
>         >         >         Java VM o JDK
>         >         >         > Abierto. Ahora esta el Harmony de
>         Apache, que
>         >         recuerde. Pero
>         >         >         ya casi
>         >         >         > desde principios de siglo, tenemos Mono.
>         No probe
>         >         todo lo
>         >         >         que escribo,
>         >         >         > pero un pet project bastante importante
>         para mi,
>         >         que esta
>         >         >         siendo usado
>         >         >         > diaramente en dos proyectos de
>         desarrollo, corre
>         >         sin tocar
>         >         >         nada, desde
>         >         >         > el compilado, en Ubuntu con Mono, y en
>         OS/X de Mac
>         >         con Mono.
>         >         >         >
>         >         >         > Y esta todo el codigo fuente de Mono
>         para ese
>         >         soporte.
>         >         >         >
>         >         >         > Nos leemos!
>         >         >         >
>         >         >         > Angel "Java" Lopez
>         >         >         > http://www.ajlopez.com
>         >         >         > http://twitter.com/ajlopez
>         >         >         >
>         >         >         > 2010/10/19 Guillermo Schwarz
>         >         <[hidden email]>
>         >         >         >
>         >         >         >
>         >         >         >                         Quizás lo que
>         quiere
>         >         Valluod es
>         >         >         desligarse de
>         >         >         >                         una plataforma
>         (C#) de la
>         >         que no
>         >         >         tiene los
>         >         >         >                         fuentes ;-)
>         >         >         >
>         >         >         >                 Lo que?
>         >         >         >
>         >         >         >
>         >         >         >         Me refería al codigo fuente de
>         c#.
>         >         >         >
>         >         >         >         Si el día de mañana sacan
>         Windows 9 u 8 y
>         >         sobre el
>         >         >         corre
>         >         >         >         solo .net 9 u 8, pero tu vm no
>         corre sobre
>         >         el nuevo
>         >         >         runtime,
>         >         >         >         perdiste toda la inversión de
>         tiempo que
>         >         hiciste.
>         >         >         >
>         >         >         >         Mientras que si desarrollas
>         sobre una
>         >         plataforma
>         >         >         open source,
>         >         >         >         no importa lo que cambien por
>         debajo,
>         >         siempre puedes
>         >         >         adaptar
>         >         >         >         tu plataforma porque dispones
>         del código
>         >         fuente.
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >         >                 Andres.
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >
>         >         >         > --
>         >         >
>         >         >         > 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
>         >         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
>         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
>         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 clubSmalltalk
>         > +[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 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 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 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 clubSmalltalk
> +[hidden email]
>  
> http://www.clubSmalltalk.org

> Hola gente!
>
> Guillermo, muy interesante, pero creo que en alguna parte, nos vamos
> del tema de la lista.
>
> Asi, que comentarios solo sobre lo mas cercano a Smalltalk, que todo
> lo que comentas.
>
> Lo de mantener el valor de una variable en el thread, es lo que hacen
> varias implementaciones, como Clojure (y ejem... AjSharpure,
> tambien ;-), tema que ya habia enviado, como enlace, en alguno de
> estos threads. Apenas una punta en:
> http://david-mcneil.com/post/1439050822/clojure-dynamic-variables-and-java-threadlocals
> Descripto en mas alto nivel:
> http://clojure.org/concurrent_programming
>
> Parecido a lo que quiero hacer con transaccion:
> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dosync
> Pero opera solo sobre variables del tipo ref. En mi caso, en AjTalk,
> sobre objetos transaccionales. Y mi transaccion (sus datos: en que
> "tiempo" comenzo, si esta activa, etc...) esta en Thread Local.
>
> Con respecto a:
> Encuentro super raro lo que mandaste respecto de que se requiera tener
> en Java un modelo STM ya que en Java el memory model es tal que las
> variables no se comparten a menos que explícitamente se utilice
> "synchronized"...
>
>
> Hmmm... o sea que toda la gente que esta implementando STM en Java
> esta equivocada? :-) :-) Bueno, se lo voy a comentar a Rich Hickey, en
> cuanto me lo cruce ;-)...
>
> Lo que encuentro "super raro" es eso que las "variables no se
> comparten". Claro que se comparten en Java. Cualquiera puede ir a una
> variable accesible, desde dos threads. No hace falta poner
> "synchronized" para compartirlas.
>
> Volviendo a Smalltalk, quiero explicar por que no sigo tu "approach"
> sugerido. Yo quiero llegar, en memoria, en AjTalk (olvidemos base de
> datos) a un Isolation de Serialization, por lo menos. Si dos
> transacciones tocan el mismo slot (variable de instancia), una no
> prosigue. Por que? Porque si T1 trata de cambiar S1 de 100 a 200, y T2
> trata de cambiar al mismo S1 de 100 a 300, puede ser que T2 haya
> tomado la decision basandose en varios valores, que leyo hace un
> tiempo, tal vez, tambien leyo S1 y lo encontro en 100, hace un tiempo,
> y decidio sumarle 200, despues de un tiempo. Se puede proteger mejor a
> T2 si al leer S1 con 100, lo lockea. Pero eso implicaria que toda
> transaccion LOCKEE cada slot que va leyendo, cuando probablemente
> cambie solo algunos, u obligar al programador que ponga explicitamente
> que esta haciendo un getInstVarAt: . Y ese lockeo, tan agresivo y
> granular, al fin, conspiraria contra la concurrencia.
>
> Hmmm.. con respecto a tu synchronized... Por lo que entendi, solo
> serviria para la variable que declaras como sincronizada. Pero que
> pasa si esa variable es anInvoice, y en el bloque modificas algo que
> no es slot directo de anInvoice, sino que vas a una lista contenida en
> una variable de instancia de anInvoice, que contiene la lista de
> renglones, y le cambias esa lista de renglones, o el contenido de un
> renglon?
>
> En mi implementacion, los objetos del dominio, Invoice, Product,
> InvoiceProduct, etc... serian transaccionables (por poner un caso,
> supongo que en GemStone seria: todos esas clases las manejo en
> GemStone: hay que poner en algun momento un "fence" que diga cuales
> son los objetos que quiero transaccionar o no, cuales son las clases
> que manejo en GemStone y cuales no). O llegado el caso, podria hacer
> que todos los objetos sean transaccionales (dudo que lo necesite, pero
> puedo hacerlo).
>
> Un caso de uso: dos agentes (que trabajan en threads diferentes,
> procesando mensajes tipo Twitter) quieren modificar una lista de
> mensajes entrantes para un tema. En mi implementacion, tanto los
> agentes como la lista de mensajes, se declaran explicitamente, los
> primeros como agentes (y no simples objetos) y la lista de mensajes
> como transaccional (y no simple objeto, donde todos van y le pegan sin
> importar la concurrencia). De ahi que no me decante por un
> "sincronizame esta variable y hace tal block". Quiero que la lista de
> mensajes, sin que el programador tenga que recordar si tiene
> concurrencia de agentes o no, siempre funcione como transaccional
> dentro de una transaccion. El trabajo para el programador es: declarar
> la transaccion, no declarar ni acordarse cuales objetos tiene que
> "sincronizar" y cuales no. Lo mismo con agentes: se declaran desde el
> principio como agentes, y voila. Ahora tengo una explicacion corta en
> Anglish:
> http://ajlopez.wordpress.com/2010/10/23/agents-in-ajtalk-introduction/
>
> Les debo lo de objetos transaccionales.
>
> [Atencion: desde el principio de mi propuesta de transacciones (como
> supongo que debe pasar en GemStone), el Invoice digamos #12 (si es que
> queremos manejar Invoices desde mas de una transaccion, pongo Invoice
> como ejemplo, bien podria ser una lista de mensajes de Twitter o lo
> que sea que quiera implementar, y que pueda ser consultado, modificado
> concurrentemente), reside en memoria con identidad (no hay dos Invoice
> #12, digamos). Aclaro esto, porque en otras implementaciones, cuando
> un proceso/thread trabaja con el dominio, reificia Invoice #12 en
> memoria, desde posiblemente la base de datos, y tiene una copia en
> memoria de Invoice#12, mientras otro proceso/thread que justo tambien
> quiere trabajar con Invoice#12, se le DA OTRA REIFICACION de esa
> factura, al final, ambos hacen commit, y los conflictos se resuelven,
> no en la memoria, sino en el sistema de persistencia, 99% de los
> casos, la base de datos relacional. No es a estos casos a los que va
> apuntado mi intento de objetos transaccionales].
>
> En mi implementacion, vigilo los slots de los objetos transaccionales,
> en lugar de objetos/variables. Si en la transaccion T1 accedo al
> objeto O1 y leo el slot S1, me fijo si hay un valor asignado ya en T1,
> sino, tomo el valor que habia en S1 antes de iniciar T1. Podria
> mantener los valores cambiados por T1 en el thread actual, pero en mi
> implementacion quiero saber si hay otra T2 que modifico a S1 en O1, lo
> mas temprano posible (no en el commit). Asi que igual tendria que ver
> los valores de otros threads. Solo podria mantener los valores de S1
> en local thread, si difiriera la deteccion de conflictos hasta el
> commit. Pero hay sutilezas: una transaccion T1 puede committear sus
> valores, pero no puedo poner directamente esos valores en el lugar de
> S1 que no es local thread (el valor real, final, global, digamos). Por
> que? Porque puede haber transacciones activas que todavia estan
> interesadas en el valor que tiene S1 cuando comenzaron. A ver si doy
> ejemplo:
>
> Tiempo 0: S1 tiene 100 (pongamos notacion S1=100/Tiempo 0)
> Tiempo 1: T1 comienza
> Tiempo 2: S1 tiene 100 (es lo que ve el resto del sistema, con o sin
> transaccion)
> Tiempo 3: T2 comienza
> Tiempo 4: T1 cambia S1 a 200
> Tiempo 5: T1 commitea
> Tiempo 6: T2 consulta S1, que le damos? el valor de tiempo 5 (t1
> commiteado? S1=200) o el valor de antes de su comienzo (tiempo 2, S1 =
> 100)?
>
> En mi implementacion, a T2 se le da S1=200/Tiempo 2. T2 ve un
> "snapshop" del sistema al momento de iniciarse. Y quiero que sea asi:
> todas las decisiones de T2, deberia basarse en un "snapshop" de los
> objetos transaccionales que maneje: T2 no puede ver S1 en 100 en un
> momento, y S2 en 200 en otro momento de su vida (del lifetime de T2).
>
> Asi que Tiempo 5, cuando T1 committea, no puedo simplemente poner el
> valor GENERAL de S1 en 200 (en Clojure, se llamaria el valor root, en
> el codigo fuente de Clojure). Tengo que mantener S1=100/Tiempo 2 hasta
> que todas las transacciones interesadas en el valor al tiempo 2 se
> terminen. Queda algo como:
>
> S1=100/Tiempo 2
> S1=200/Tiempo 5
>
> Cuando todas las transacciones activas son con tiempo de inicio > 5, o
> no hay mas transacciones, paso a:
>
> S1=200/Tiempo 0  (el valor global, el final, en el objeto O1)
>
> y aqui no ha pasado nada, muchachos... ;-)
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/31 Guillermo Schwarz <[hidden email]>
>         Angel,
>        
>         Claro, la principal razón para querer tener transacciones es
>         tener
>         concurrencia, la atomicidad es un "second thought"... sin
>         embargo es el
>         "isolated" el que le da la oportunidad de ser concurrente sin
>         necesidad
>         de tener que terminar la primera transacción para empezar la
>         otra.
>        
>         En la práctica uno puede hacer las operaciones "locked" tan
>         pequeñas
>         como quiera para aumentar la concurrencia (ese es el "insight"
>         que
>         utiliza SQL). En otras palabras en vez de hacer "begin tx" =
>         "begin
>         lock" y "commit" = "end lock", se agarra cada operación de la
>         transacción y se hace que tome un "lock" el objeto de la BD
>         que está
>         tocando. Aún más, se puede hacer que toda la transacción
>         trabaje sobre
>         una copia de la BD y al final cuando se hace commit, se
>         reemplaza un
>         puntero con CAS o LL/SC.
>        
>         http://www.audiomulch.com/~rossb/code/lockfree/
>        
>         CAS tiene el problema del ABA así que supongo que no es
>         recomendable.
>         Acá se explica:
>        
>         http://www.audiomulch.com/~rossb/code/lockfree/
>        
>         Y también se da una solución: agregar un contador.
>        
>         CAS hace rato que viene implementada en la CPU X86, de modo
>         que se
>         podría considerar que es estándar. Pero al parecer tiene bugs:
>        
>         https://patchwork.kernel.org/patch/19429/
>        
>         No sé a ustedes pero la impresión que tengo es que tener bugs
>         a nivel de
>         la CPU es un "total turn-off". Sin embargo si tenemos un
>         proyecto ya
>         metido en esto lo único que queda es detectar en qué CPU
>         estamos
>         corriendo y aplicar un workaround en ese caso particular (que
>         podría ser
>         tomar objetos más grandes y utiliar locks más grandes).
>        
>         Se puede agregar:
>         http://phildawes.net/blog/2009/10/13/factor-compiler-adding-instruction/
>        
>         Extraño, no?
>        
>         Lo que mencionas de :
>        
>         > Algo para leer:
>         >
>         > http://doc.akkasource.org/stm-scala
>        
>        
>        
>         Se contradice un poco con lo que envié yo en algo que
>         considero
>         significativo. Lo que envié yo dice que STM a AI, mientras que
>         tu link
>         dice que es ACI.
>        
>         ¿Porqué?
>        
>         Dice ahí que cuando se hace commit de una transacción, la data
>         de la
>         transacción se comparte completa con las otras transacciones o
>         nada.
>         Para mí eso es Atomic, no Consistent. Consistent como mandé en
>         el link
>         significa que existe una metadata que fuerza determinadas
>         cosas como las
>         llaves foráneas, de manera que la data sigue siendo
>         consistente
>         independiente de las operaciones que haya hecho.
>        
>         Por default Smalltalk y cualquier lenguaje no tiene una
>         metadata que
>         fuerce las relaciones entre objetos (sí entre objetos y
>         clases, por
>         ejemplo un objeto pertenece sólo a una clase). Se podría
>         pensar que el
>         sistema de tipos en Java es una forma rudimentaria de
>         metadata, ya que
>         si tengo una función con un paŕametro de tipo String no puedo
>         pasarle un
>         número y viceversa. Pero las restricciones que puedo poner en
>         SQL son
>         mucho más fuertes, parecidas a lo que vendría a ser un sistema
>         de diseño
>         por contratos en Eiffel.
>        
>         http://eiffel.com/developers/presentations/dbc/partone/player.html?slide=
>        
>        
>         Encuentro super raro lo que mandaste respecto de que se
>         requiera tener
>         en Java un modelo STM ya que en Java el memory model es tal
>         que las
>         variables no se comparten a menos que explícitamente se
>         utilice
>         "synchronized", lo que se explica en:
>        
>         http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
>        
>         En resumen se podría decir que las variables son propias al
>         thread. Esto
>         lo he verificado independientemente muchas veces, se debe usar
>         synchronized. El equivalente en Smalltalk sería decir que
>         todas las
>         variables le preguntan al currentProcess (si tal pseudo
>         variable
>         existiera) cual es su valor y si retorna nil, entonces recién
>         le
>         pregunta a Smalltalk. ¿Qué te parecería esa implementación? El
>         único
>         problema que le veo es que nadie usa synchronized en
>         Smalltalk, pero
>         supongo que no sería difícil de implementar:
>        
>         Process>>synchronize: symbol toExecute: block
>                Smalltalk at: symbol put: (self at: symbol).
>                block value
>        
>         y se llamaría as:
>        
>         currentProcess synchronize: #variable toExecute: [...]
>        
>         Como sería muy verboso escribir eso, se podría crear un
>         método:
>        
>         Symbol>>synchronizeOn: block
>            currentProcess synchronize: self toExecute: block
>        
>         Que se invocaría así:
>        
>         #variable synchronizeOn: [...]
>        
>         Probablemente el cambio más grande sería cambiar el compilador
>         para que
>         reconozca currentProcess como una pseudovariable (y sepa a qué
>         objeto
>         asociarlo) y que las variables se busquen en currentProcess
>         antes que en
>         Smalltalk.
>        
>         ¿Qué importancia tiene esto? Que en Java toda la información
>         se maneja
>         en forma local en el thread, de modo que no se actualiza al
>         resto de los
>         threads a menos que explícitamente se ponga un
>         "synchronized" (que por
>         lo tanto es caro, porque cualquier otro thread verá el cambio
>         SSI hace
>         "synchronized" sobre el mismo objeto. Buen truco, ¿no? Pero
>         dado esto,
>         ¿no estamos a un paso de tener transacciones en memoria?
>         Synchronized
>         sería el equivalente a "commit", sólo faltaría implementar el
>         "rollback"
>         y da la casualidad que es mucho más fácil, simplemente el
>         valor que está
>         en el thread se "bota" y se queda con el valor global. Desde
>         el punto de
>         vista del thread basta con copiar el valor de la memoria
>         global al
>         thread.
>        
>         Por cierto se supone que el Double-checked locking fue
>         arreglado en Java
>         5 cambiando el memory model. Lo verifiqué y al menos en esa
>         versión
>         funciona si la variable es "volatile". (Lo mismo ocurre en
>         Microsoft C
>         por si acaso ;-).
>        
>         Lo chistoso del asunto es que esto resuelve el problema del
>         double
>         checked locking:
>        
>         public class MyFactory {
>          private static final MyFactory instance = new MyFactory();
>        
>          public static MyFactory getInstance() {
>            return instance;
>          }
>        
>          private MyFactory() {}
>         }
>        
>         La razón es que la clase no se va a instanciar 2 veces, por
>         ende el problema
>         está resuelto por el class loader. No olvidemos que el
>         problema original era que
>         queríamos ejecutar cierto código una sola vez y se nos ocurrió
>         usar synchronized.
>         En este caso ejecutamos sólo una vez pero porque Java decide
>         cargar clase una
>         sola vez.
>        
>         Es bastante interesante Multiverse (bueno es de codehouse.org,
>         qué se
>         podría esperar ;-) Al parecer la versión 0.6 no la sacaron en
>         Junio como
>         habían planeado. Mirando los "features" de esa versión parece
>         que tenían
>         planificado crear bugs en vez de features, ya que si miras lo
>         que están
>         planeando implementar no es hacer el código más limpio... pero
>         bueno, la
>         idea de STM en general creo que no es muy limpia. Preocupante
>         es eso de
>         agregar "delays". En mi experiencia cada vez que alguien
>         decide "colocar
>         delays para que el thread tenga más tiempo de ejecutar", es
>         porque
>         tenemos problemas serios de "race conditions" y "deadlocks".
>        
>         Si tengo "wait-free" y "block-free" data structures se acaban
>         los
>         live-locks y los dead-locks. No puedo tener un dead-lock si no
>         hago
>         lock. ¿Es obvio no?
>        
>         Doug Lea inventó algoritmos concurrentes en Java sin necesidad
>         de
>         redefinir el lenguaje ni la JVM:
>        
>         http://books.google.cl/books?id=-x1S4neCSOYC&pg=PA145&lpg=PA145&dq=doug
>         +lea+wait
>         +free&source=bl&ots=Dvhr8_Faw_&sig=ttJpnIRaYniMeFnuw8_wpjqmlW4&hl=es&ei=Zv3MTLOCNoOdlgeJ05CmBg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBkQ6AEwAA#v=onepage&q&f=false
>        
>         Por definición esos objetos podrían participar de algoritmos
>         distribuidos, con la ínica salvedad a mi parecer que las
>         estructuras de
>         datos no son (aun) distribuidas de modo que sería necesaria
>         que los
>         proxies hicieran llamadas remotas a donde se encuentran los
>         objetos
>         realmente (eso ya lo tienes hecho). Al interior de las JVM
>         donde esos
>         objetos residen podrían tener threads modificándolos en forma
>         concurrente sin problemas.
>        
>         Saludos,
>         Guillermo.
>        
>        
>         On Wed, 2010-10-27 at 10:59 -0300, Angel "Java" Lopez wrote:
>         > Hola gente!
>         >
>         >
>         >
>         > STM tiene otro “twist”: la concurrencia. Clojure y otros,
>         están
>         > alineados a que haya elementos consumibles concurrentemente.
>         Por un
>         > lado, como apuntabas en otro email, con datos inmutables.
>         Clojure
>         > tiene toda una serie de estructuras que llaman “Persistent”,
>         no
>         > confundir con persistencia en base de datos o similares. Por
>         otro
>         > lado, tiene datos mutables, pero vigilados por STM, también
>         para
>         > concurrencia.
>         >
>         >
>         >
>         > Pongo Clojure como ejemplo. El tema a resolver: manejar la
>         > concurrencia sobre objetos mutables, sin tener que perder el
>         pelo en
>         > el intento. Como ya discutimos, otra forma es manejar la
>         concurrencia
>         > sin tener mutabilidad, tan afin a programación funcional.
>         >
>         >
>         >
>         > Algo para leer:
>         >
>         > http://doc.akkasource.org/stm-scala
>         >
>         > donde aparece Scala (sobre Java) y Akka (excelente proyecto
>         > distribuido). Ahí hay algunos uses cases, discusión de
>         persistent
>         > structures y demás.
>         >
>         > Algun experimento de STM que se abandono, pero interesante:
>         >
>         > http://channel9.msdn.com/Blogs/Charles/STMNET-Who-What-Why
>         >
>         >
>         >
>         > Mi idea es reproducir eso en otros ámbitos (lo tengo escrito
>         y
>         > publicado), y en particular, ahora, en AjTalk. Por eso
>         también lo de
>         > distribuido. Concurrencia y paralelismo, tanto en la misma
>         maquina,
>         > como en varias. Conseguir eso sobre una maquina con
>         multiples core, o
>         > escalar hacia afuera con varias maquinas. Mis casos de uso
>         todavía no
>         > necesitan transacciones, pero lo vi en Clojure y veo que lo
>         usan. Y
>         > por lo que lei en GemStone, parece que lo usan, tengo que
>         preguntar
>         > por aca algunos temas. Alguna vez llegara a mi un caso de
>         uso para eso
>         > (de hecho, pregunte por aca como hacían para manejar la
>         concurrencia
>         > sobre objetos en Smalltalk, no parece haber una forma, o no
>         comentaron
>         > nada). Tengo otros casos de uso para distribuido, agentes,
>         acceso
>         > a .NET o Java nativo, etc, que ya mencione por aca.
>         >
>         >
>         >
>         > Casos de uso: escalabilidad por concurrencia, sobre dominios
>         que no es
>         > importante grabar y tener persistencia al momento, como
>         servicios
>         > usados en Farmville, Twitter, etc.. Pero no tengo un caso en
>         concreto.
>         > Pero a lo que voy (mas hacia el final) no todo gira
>         alrededor de una
>         > base de datos. Notable ejemplo: la imagen de Smalltalk.
>         Tranquilamente
>         > puedo trabajar con todo un dominio reificado en la imagen,
>         ya sea en
>         > memoria, en disco.
>         >
>         >
>         >
>         > Entonces, por que ponerlo ahora, esto de objetos
>         transaccionales? (de
>         > hecho, escribi por aca hace como 3 semanas, que no estaba
>         alto en mi
>         > lista de prioridades) Porque me pareció un “proof of
>         concept”
>         > interesante de otra idea: agregar conducta a objetos AjTalk
>         mediante
>         > decoradores, tipo el objeto intermedio que comentaba
>         Mariano. Hoy
>         > agrego decoradores para conseguir objetos transaccionales.
>         Ayer, para
>         > tener objetos distribuidos remotos. Maniana, para conseguir
>         objetos
>         > que persistan si no son usados o por otro criterio.
>         >
>         >
>         >
>         > Persistencia en la base de datos, estará alguna vez, por si
>         se corta
>         > la luz ;-)
>         >
>         >
>         http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx
>         >
>         > (donde hay mas indicios para NO ocuparse de la base de datos
>         ahora, en
>         > estos temas. El tema nos llevaría a NoSQL y otros temas, que
>         se alejan
>         > de esta lista, pero en los que me parece que Smalltalk puede
>         ir
>         > montándose tranquilamente, seguramente hay proyectos sobre
>         eso)
>         >
>         >
>         >
>         > Un tema que quería contestarle a Mariano: se imaginan una
>         “maquina
>         > Smalltalk”, cuyo procesos estén siendo ejecutados en varias
>         maquinas
>         > físicas, sin solución de continuidad, todos los
>         procesadores, toda la
>         > memoria, como si fueran uno?
>         >
>         >
>         >
>         > La persistencia estaría dada por la existencia de varias
>         maquinas,
>         > quizás distribuidas: se cae una, otra tiene lo que falta,
>         como en
>         > varias implementaciones de NoSql. Ver
>         >
>         > http://delicious.com/ajlopez/nosql
>         >
>         >
>         >
>         > Otro punto mas: si tuviera un Sistema Pick, como ya mencione
>         en otro
>         > thread, lo de objetos transaccionales bastaría, sin
>         necesidad de base
>         > de datos.
>         >
>         >
>         >
>         > Espero haber dejado varias ideas ligadas a Smalltalk, y no
>         haberme ido
>         > demasiado por las ramas, para esta lista.
>         >
>         >
>         >
>         > Nos leemos!
>         >
>         >
>         >
>         > Angel “Java” Lopez
>         >
>         > http://www.ajlopez.com
>         >
>         > http://twitter.com/ajlopez
>         >
>         >
>         >
>         >
>         >
>         > De:[hidden email]
>         > [mailto:[hidden email]] En nombre de
>         Guillermo Schwarz
>         > Enviado el: Wednesday, October 27, 2010 10:24 AM
>         > Para: [hidden email]
>         > Asunto: Re: [clubSmalltalk] Objetos Distribuidos
>         >
>         >
>         >
>         >
>         > Ángel,
>         >
>         >
>         >
>         >
>         > No me parece mal lo de STM, pero no veo la necesidad.
>         (Alguna vez
>         > escuché la frase "es una solución en busca de un problema,
>         en vez de
>         > un problema en busca de una solución", creo que en esta
>         ocasión se
>         > ajusta perfecto al caso).
>         >
>         >
>         >
>         >
>         > Primero los objetos deben ser durables, de otra manera ¿para
>         qué
>         > modificarlos? Si son transientes son sólo parte de un
>         mecanismo, no me
>         > interesa que lo que ve una persona o que modifica, lo pueda
>         ver
>         > también otro. IMHO, no tiene senido, a menos que quieras que
>         hagan
>         > dibujos en Paint de manera simultánea y luego se borren.
>         >
>         >
>         >
>         >
>         >
>         > Parece más bien un caso particular de "escríbelo en la BD y
>         luego
>         > bórralo de manera explícita". Si la disculpa para hacerlo
>         como lo
>         > haces es que no quieres que se demore mucho (porque la BD es
>         lenta) me
>         > parece que hay usar una BD más rápida.
>         >
>         >
>         >
>         >
>         >
>         > En general si tienes objetos transientes, lo único que
>         quieres es que
>         > no se toquen unos a otros, que tengan todo separado de
>         manera que no
>         > haya "locking". Eso es lo que hace con los EJBs, todo
>         separado hasta
>         > que se llega a la BD que tiene sus propios mecanismos de
>         resolución y
>         > si investigas cóm lo hace, tierne más éxito si usa non
>         locking
>         > algorithms.
>         >
>         >
>         >
>         >
>         >
>         > ¿Qué estás tratando de resolver realmente? Porque hasta el
>         momento
>         > aparte de que es interesante poder lograr lo que has hecho,
>         me parece
>         > que cualqueir problema real que podría ser un caso de uso de
>         usuario
>         > que podría requerir lo que estás haciendo se puede resolver
>         de 20
>         > maneras diferentes con soluciones que ya están hechas y
>         probadas. (No
>         > es por bajar el ánimo, eh? Es sólo tratar de hacer más
>         fructífero el
>         > desarrollo).
>         >
>         >
>         >
>         >
>         >
>         > Saludos,
>         >
>         >
>         > Guillermo.
>         >
>         >
>         >
>         >
>         > 2010/10/27 Angel Java Lopez <[hidden email]>
>         >
>         > Hola gente!
>         >
>         > Guillermo, el ambito de aplicacion de lo que quiero hacer,
>         es similar
>         > al de Software Transactional Memory, donde tambien se
>         mencionan
>         > Transactional Objects, no a la de las bases de datos. Una
>         comparacion
>         > de los dos ambitos, tomado de un proyecto/ejemplo en  .NET:
>         >
>         >
>         http://weblogs.asp.net/ralfw/archive/2007/07/04/software-transactional-memory-ii-isolation-of-changes-to-transactional-objects.aspx
>         >
>         > Mis enlaces
>         > http://delicious.com/ajlopez/stm
>         >
>         >
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         >
>         > 2010/10/27 Guillermo Schwarz <[hidden email]>
>         >
>         >
>         >
>         >         Hola Angel,
>         >
>         >         creo que se debe aclarar los términos.
>         >
>         >         En el mundo de las bases de datos relacionales las
>         >         transacciones
>         >         significan ACID: Atomic, Consistent, Isolated y
>         Durable.
>         >
>         >         En particular Atomic significa que o se hacen todas
>         las
>         >         operaciones o no
>         >         se hace ninguna. ¿Cómo implementas eso? No sólo los
>         objetos
>         >         "transaccionables" deben volver al estado en que
>         estaban, sino
>         >         que todos
>         >         los qu ehayan sido modificados. Si un objeto no es
>         durable,
>         >         debiera dar
>         >         lo mismosi se puede devolver a su estado anterior.
>         Por ejemplo
>         >         un
>         >         socket, si ya envió algo por la red, imposible
>         "desenviarlo".
>         >         Por eso en
>         >         los EJBs no está permitio conectarse a través de
>         sockets ni
>         >         escibir
>         >         archivos.
>         >
>         >         Luego lo de Consistent, no hay manera de hacerlo en
>         Smalltalk
>         >         a menos
>         >         que modeláramos tablas relacionales en Smalltalk de
>         modo que
>         >         cada tabla
>         >         fuera por ejemplo un Dictionary (PK -> registro
>         completo).
>         >         Creo que esto
>         >         hasta el momento no existe.
>         >
>         >         Luego lo de Isolated, creo que es lo que
>         implementaste tú, una
>         >         de las
>         >         transacciones falla (y se podría ejecutar de nuevo)
>         si trata
>         >         de
>         >         modificar un objeto que ha sido modificado en una
>         transacción
>         >         que aún se
>         >         encuentra activa.
>         >
>         >         Finalmente lo de Durable correspondería a que el
>         Dictionary
>         >         que
>         >         representa cada tabla fuera persistente.
>         >
>         >         No sé si te hace sentido.
>         >
>         >         Saludos,
>         >         Guillermo.
>         >
>         >
>         >         On Tue, 2010-10-26 at 06:17 -0300, Angel Java Lopez
>         wrote:
>         >         > Hola gente!
>         >         >
>         >         > Interesante el enlace de parallel, gracias
>         Guillermo.
>         >         >
>         >         > Comentario rapido: el codigo de tarde de domingo,
>         fue
>         >         agregar
>         >         > transacciones a objetos, en AjTalk. Esta
>         funcionando, pero
>         >         todavia en
>         >         > revision. Me falta implementar la sintaxis con la
>         que lo voy
>         >         a usar,
>         >         > pero sera algo como:
>         >         >
>         >         > myObj := MyClass new asTransactionable.
>         >         >
>         >         > "tambien podria poner"
>         >         >
>         >         > MyClass transactionable: true.
>         >         >
>         >         > "y de ahi en mas los objetos creados de MyClass
>         son
>         >         transactionables".
>         >         >
>         >         > Transaction begin.
>         >         >
>         >         > "modifican los objetos, habra objetos
>         transaccionables"
>         >         >
>         >         > Transaction commit. "o Transaction rollback"
>         >         >
>         >         > Si dos Process tratan de modificar la misma
>         variable de
>         >         instancia de
>         >         > myObj, uno dara exception. Me falta controlar las
>         variables
>         >         indexadas.
>         >         >
>         >         > Nos leemos!
>         >         >
>         >         > Angel "Java" Lopez
>         >         > http://www.ajlopez.com
>         >         > http://twitter.com/ajlopez
>         >         >
>         >         > 2010/10/26 Guillermo Schwarz
>         <[hidden email]>
>         >         >         Sí, bueno, yo veo que todo tiende a Java,
>         a pesar de
>         >         que los
>         >         >         lenguajes
>         >         >         funcionales (F#) parecen estar mejor
>         implementados
>         >         en .NET que
>         >         >         en la JVM
>         >         >         (Scala y Clojure).
>         >         >
>         >         >         Y me gustó la idea de implementar EJBs en
>         Smalltalk,
>         >         por
>         >         >         alguna razón
>         >         >         imagino que es un buen vehículo conceptual
>         que
>         >         existan threads
>         >         >         con
>         >         >         transacciones en vez de threads con locks.
>         >         >
>         >         >         Y de esa manera las bases de datos
>         resuelven el tema
>         >         de las
>         >         >         transacciones, el código en Smalltalk
>         simplemente
>         >         indica en
>         >         >         qué momento
>         >         >         gatillar el "commit".
>         >         >
>         >         >         Entonces estará el problema de cómo hacer
>         las
>         >         transacciones a
>         >         >         la base de
>         >         >         datos si según recuerdo no existe una
>         manera
>         >         estándar como
>         >         >         JDBC para
>         >         >         acceeder a las BDR desde Smalltalk.
>         Entonces me topé
>         >         con
>         >         >         TOPLink, que al
>         >         >         parecer es sólo abierto en el caso de Java
>         y con
>         >         Glorp, que al
>         >         >         parecer
>         >         >         es el estándar hoy en día en el mundo
>         Smalltalk:
>         >         >
>         >         >         http://www.glorp.org/
>         >         >
>         >         >         Entonces una vez implementada la
>         persistencia
>         >         mediante Glorp,
>         >         >         debiera
>         >         >         poder delimitar transacciones a través de
>         EJBs y la
>         >         ejecución
>         >         >         a través
>         >         >         de [] fork debiera ser trivial...
>         >         >
>         >         >         Al menos conceptualmente me parece que la
>         solución
>         >         anda, no sé
>         >         >         tú. ¿Te
>         >         >         suena a que anda?
>         >         >
>         >         >         ¿Porqué digo esto? Porque me topé con
>         esto:
>         >         >         http://wiki.squeak.org/squeak/537
>         >         >
>         >         >         Lo que me parece que estuvieran tratando
>         de replicar
>         >         son los
>         >         >         ambientes
>         >         >         Lisp distribuidos en los que funciona de
>         manera
>         >         trivial el
>         >         >         paralelismo
>         >         >         masivo porque en Lisp casi no hay nada
>         compartido.
>         >         Lograr eso
>         >         >         en
>         >         >         Smalltalk creo que es casi imposible,
>         porque el
>         >         lenguaje está
>         >         >         pensado
>         >         >         para que modifique el estado de los
>         objetos en
>         >         memoria. El
>         >         >         enfoque que
>         >         >         yo tengo es que sea responsabilidad del
>         programador
>         >         no hacer
>         >         >         ninguna
>         >         >         llamada a objetos en memoria, lo mismo que
>         pasa con
>         >         los EJBs
>         >         >         en Java.
>         >         >
>         >         >         Ahora como estos EJBs están en Smalltalk
>         en realidad
>         >         debieran
>         >         >         llamarse
>         >         >         EOB (Enterprise OBjects).
>         >         >
>         >         >         Saludos,
>         >         >         Guillermo.
>         >         >
>         >         >
>         >         >
>         >         >         On Tue, 2010-10-19 at 18:26 -0300, Angel
>         Java Lopez
>         >         wrote:
>         >         >         > Comentario corto: Hace unos anios
>         comence a
>         >         escribir este
>         >         >         tipo de pet
>         >         >         > project, en C#, porque no estaba claro
>         que pasaba
>         >         con un
>         >         >         Java VM o JDK
>         >         >         > Abierto. Ahora esta el Harmony de
>         Apache, que
>         >         recuerde. Pero
>         >         >         ya casi
>         >         >         > desde principios de siglo, tenemos Mono.
>         No probe
>         >         todo lo
>         >         >         que escribo,
>         >         >         > pero un pet project bastante importante
>         para mi,
>         >         que esta
>         >         >         siendo usado
>         >         >         > diaramente en dos proyectos de
>         desarrollo, corre
>         >         sin tocar
>         >         >         nada, desde
>         >         >         > el compilado, en Ubuntu con Mono, y en
>         OS/X de Mac
>         >         con Mono.
>         >         >         >
>         >         >         > Y esta todo el codigo fuente de Mono
>         para ese
>         >         soporte.
>         >         >         >
>         >         >         > Nos leemos!
>         >         >         >
>         >         >         > Angel "Java" Lopez
>         >         >         > http://www.ajlopez.com
>         >         >         > http://twitter.com/ajlopez
>         >         >         >
>         >         >         > 2010/10/19 Guillermo Schwarz
>         >         <[hidden email]>
>         >         >         >
>         >         >         >
>         >         >         >                         Quizás lo que
>         quiere
>         >         Valluod es
>         >         >         desligarse de
>         >         >         >                         una plataforma
>         (C#) de la
>         >         que no
>         >         >         tiene los
>         >         >         >                         fuentes ;-)
>         >         >         >
>         >         >         >                 Lo que?
>         >         >         >
>         >         >         >
>         >         >         >         Me refería al codigo fuente de
>         c#.
>         >         >         >
>         >         >         >         Si el día de mañana sacan
>         Windows 9 u 8 y
>         >         sobre el
>         >         >         corre
>         >         >         >         solo .net 9 u 8, pero tu vm no
>         corre sobre
>         >         el nuevo
>         >         >         runtime,
>         >         >         >         perdiste toda la inversión de
>         tiempo que
>         >         hiciste.
>         >         >         >
>         >         >         >         Mientras que si desarrollas
>         sobre una
>         >         plataforma
>         >         >         open source,
>         >         >         >         no importa lo que cambien por
>         debajo,
>         >         siempre puedes
>         >         >         adaptar
>         >         >         >         tu plataforma porque dispones
>         del código
>         >         fuente.
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >         >                 Andres.
>         >         >         >
>         >         >         >
>         >         >         >
>         >         >
>         >         >         > --
>         >         >
>         >         >         > 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
>         >         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
>         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
>         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 clubSmalltalk
>         > +[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 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 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 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 clubSmalltalk
> +[hidden email]
>  
> http://www.clubSmalltalk.org