No, claramente no apunto a que implementes un Smalltalk nuevo; lo que
digo es que si ya usas un framework de distribución de objetos (tipo
Opentalk o rSt) la cosa ya está casi resuelta. Igual la parte de
distribución por referencia ya la tenés cocinada ("En el caso de usar
proxy es trivial y liviano y si el mecanismo funciona para uno, funciona
para todos" -muy interesante la última acotación-), sólo te falta
resolver la distribución por copia.
Respecto de las librerías me mataste, yo trabajo con VW no con Pharo :(
Saludos!
Andrés
Guillermo Schwarz escribió:
Oye, pero la idea no es hacerlo desde cero, sino tendría que hacer un
Smalltalk desde cero. No tiene sentido.
La serialización de objetos ya existe, los sockets también, los proxies
también. ¿Me hace falta algo aparte de juntar y pegar?
¿Alguien me puede recordar dónde están cada una de esas cosas? Tengo la
memoria un poco empolvada, aparte de que no tengo mucha experiencia en
Pharo.
Saludos,
Guillermo.
2010/10/8 andres <[email protected]>
Desconozco la licencia de Opentalk o si está portado a Pharo; igual pensé
que ibas a implementar todo de cero, total no es complicado, un par de
proxies nomás.
Sobre lo que decís en 2) la verdad no te sigo, pero parece sencillo;
deberás redefinir algún mensaje y serializar algún que otro compiled method.
Y sobre #thisContext al menos en VW está y estoy casi seguro que en Squeak
y Pharo también, así que dale con la implementación en Pharo. El lunes es
feriado pero tengo que trabajar igual, así que seguro voy a poder testear tu
implementación.
Saludos,
Andrés
Guillermo Schwarz escribió:
1. Si OpenTalk ya lo tiene hecho, ¿es open source?
2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand
para que pregunte si la clase está definida en el servidor (o en el
originador de la llamada, depende de cómo se quiera organizar el asunto).
3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o algo
así y dejaba el thread actual suspendido y le daba tiempo a otro de
ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler,
pensé
que era Smalltalk Express, pero al parecer no era porque no encontré
thisContext. ¿Alguien ha visto algo así?
Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría.
Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se me
hace difícil.
Saludos,
Guillermo.
2010/10/8 andres <[email protected]>
Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info:
1. Si, cubierto por Opentalk.
2. Opentalk cubre esto parcialmente, creo que se podía trabajar con
clases
como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las dos
imágenes puede haber versiones distintas de la misma clase es un
problema.
3. No que yo sepa.
El tema es que cuanto mas "transparente" te quieras volver para el
programador, mas decisiones tenés que tomar a priori (que muchas veces no
se
pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de
distribuir objetos por copia o por referencia es un mundo en si mismo.
Saludos,
Andrés
Angel Java Lopez escribió:
Ah! Me olvide de preguntar:
No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de
Guillermo?
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
2010/10/8 andres <[email protected]>
Dale, la opción 3 suena piola. El requerimiento sería algo así como:
"Implementar el mensaje #executeAt: anIpAddress port: aPort en Process
para
que pause la ejecución, se lleve el thread con los objetos en el scope
a
la
otra imagen y retome la ejecución del punto de partida." Me sumo al
programa
de beta testers para cuando esté listo en un par de días.
Saludos,
Andrés
Guillermo Schwarz escribió:
Primero hay que ponerse de acuerdo en qué tipo de implementación vamos
a
hacer:
1. Proxy que llame a un objeto remoto que ya existe en el destino
(similar a EJB).
2. Proxy que vaya hasta el servidor y cree una instancia de una clase
que no existe, para lo cual se requiere que el destino le pregunte al
gatillador dónde está la definición de la clase, la cargue, la compile
y
la instancie.
3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo?
¿Que corran en el servidor que se indique en duro? ¿Hacer un
balanceador
de carga?
Si los requerimientos no están claros se llegará a un engendro, pero
si
están claros, las decisiones de diseño serán las obvias, podremos
implementar los prototipos, probarlos y no creo que sean más de un par
de días tenerlo funcionando.
Saludos,
Guillermo.
On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote:
2010/10/8 Guillermo Schwarz <[email protected]>
¿Y tú que parte harías?
¿Probarlo?
;-)
--
Simplex Veri Sigillum
Uy! - si necesitas beta testers avisa, yo
tambien
me prendo
;-)
--
Callarum largo vivurum
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to clubSmalltalk
[email protected]
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]<clubsmalltalk%[email protected]>
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
