Un problema menos ver: http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_thread/thread/5eac804cefcb8a9a#
ahora estoy viendo lo que el ensure se ejecuta más de una vez (parece ser lo correcto solo habria que compensarlo en el codigo del seaside) cheers, Sebastian On Aug 22, 12:42 pm, Sebastian <[EMAIL PROTECTED]> wrote: > On Aug 22, 10:10 am, GallegO <[EMAIL PROTECTED]> wrote:> Hola: > > > En un momento tuvimos algunos problemas que no eran tales con la > > implementación de Continuation de Dolphin. > > Luego de darle muchas vueltas deducimos que estaba bien lo que hacían > > (esas copias que te huelen mal también nos olían mal a nosotros). Eso lo > > implementó la gente de ObjectArts. Puede que para esa implementación > > haya que modificar en algún método la implementación de Seaside, pero me > > parece un poco power ir por el lado de modificar los Continuations. > > Podes terminar peor que después de una botella de whisky :P. > > Si, totalmente. > > > Vos decis que no anda de la misma forma que en Squeak y VW?, eso es lo > > que entiendo. > > Para no empeorar la confusion vamos paso a paso. No es que *quiera* > modificar las Continuations. > Lo primero que quiero es exponer cualquier diferencia de > comportamiento entre las continuations de Dolphin y Squeak o > VisualWorks. Eso si es que realmente hay esas diferencias. Esto es lo > primero. > Teniendo eso claro, o sea cuales son y por qué se dan entonces > estaremos en condiciones mínimas de pensar qué hacer en Dolphin. > Lo mejor que podría pasar es que se revele un bug (o bien algo > considerado feature pase a clasificar como bug por tomar como > referenca Squeak y VW). Si se revela lo publicamos con tests en la > lista Dolphin y vemos que reacción hay. > Mi idea es hacerlo en los 3: squeak vw y dolphin y publicar el codigo > de los tests así no hay pérdidas de tiempo en discusiones sobre como > debería ser ya que este tema fácilmente genera mucha confusión. > > > > > Por otro lado, y ya habiendo olvidado bastante de Seaside, habia una > > forma de que al darle al back button te expiraba esa acción por lo que > > sería imposible ejecutar nuevamente esa página. Esto te funciona mal? No > > deberías implementar así las transacciones/excepciones? > > Claro vos te referís a la transaction del propio seaside para prevenir > el backbutton en acciones de la app que son irreversibles. > Aclaro: las transacciones que yo digo no son del workflow de la app. > Son, en cambio, de la odb (los commits) y están a nivel del request > así: > > 1. BlahSession>>incomingRequest: aRequest > ... > ^ monitor > critical: [self responseForRequest: aRequest] > ifError: [ :error | self errorHandler internalError: error ]. > > 2. BlahSession>>responseForRequest: aRequest > currentRequest := aRequest. > ^ self withEscapeContinuation: [ > WACurrentSession > use: self > during: [ > self withErrorHandler: [ > self performRequest: aRequest ] ] ] > > 3. BlahSession>>withEscapeContinuation: aBlock > | response | > > ^ self database execute: > [response := super withEscapeContinuation: aBlock. > response ifNil: [ODBCannotLockObject signal: 'Re-signalled > from > ODBSession']. > response status = '500' ifTrue: [ODBSInternalError signal]. > response] > > por lo que toda la parte de flujo, los componentes etc etc se > resuelven dentro del #responseForRequest del paso 2 que se ejecuta > dentro del super withEscapeContinuation: que ves en el codigo que puse > en 3. > > > Tenes ya algún workspace para probar el mal funcionamiento? > > No. Ahora estoy laburando sobre la app pero a la noche me voy a tomar > un rato para hacerlo. Mientras voy pensando para ordenar ideas porque > no se que diferencia de comportamiento buscar entre dolphin y los > otros como para priorizar tratar de exponerla. > Si se te ocurre algo cualquier aporte is most welcome. Hasta ahora > tenemos el tema del bloque ensure: que parecería comportarse > correctamente pero sorprende porque se ejecuta una cantidad de veces > que no es intuitiva. Sin embargo Esteban al portar tuvo el problema de > que no retornaban el valor del bloque evaluado en #critical:ifError: > (motivo de su post en dolphin). Si el squeak and/or VW llegaran a > hacerlo diferente o diferente cantidad de veces ya sería un primer > test a desarrollar. > El otro que se me ocurrió es el que devuelva el valor del bloque > evaluado, problema al que Esteban le encontró un workarround pero con > continuations en el medio no me atrevo a decir que es absolutamente > equivalente a los autores seaside (en squeak y vw el bloque se evalua > en un fork y en el workarround en el activeProcess). > > > Buena pregunta lo del thisContext, no es tan directo de caminar como VW > > o Squeak. Desde un browser menú Method>Browse other>containingText > > "thisContext" ahí te sale #topFrame, de donde ves cómo se usan las > > instancias de StackFrame. > > Fijate Object>>shouldNotImplement como esta implementado, ahí ves un > > pequeño eslabón en la cadena. > > > Saludos > > GallegO > > Lo de #topFrame lo habia visto pero lo del #shouldNotImplement no. > Gracias por la referencia. Lo había visto porque en una imagen aparte > hice un approach naive de implementar la continuation igual a squeak > sin usar el stackframe copier de dolphin (no tengo pruebas aun pero > sospecho que la forma de copiar del squeak compensa algo incluso > pareciendo quiza menos rigurosa, me parecio mas shallow que el > stackframe copier). > En esa prueba falle miserablemente cuando me topé con que no encajan > exactamente el concepto de stackframe usado por dolphin con el de > methodcontext squeak/vw. No obstante se parecen mucho pero tengo que > reconocer que esto del stack frame son tierras nuevas para mi. > > En cuanto tenga algo publico, > > Saludos, > > Sebastian > > > Sebastian escribió: > > > > Vi que la clase Continuation en VisualWorks inicializa igualita a > > > Squeak en cambio en Dolphin es bien diferente. > > > > Entonces pregunta básica rebobinando.. > > > > Que posibilidades hay de implementar la continuation también igual en > > > Dolphin? > > > > Además de ser lo que el/los autores hicieron, mi nariz me dice que en > > > esa forma de copiar esta la clave. > > > > Sebastian > > > PD: El thisContext de Dolphin retorna un numero en lugar de una > > > instancia de methodContext como VW y Squeak. Como hago para obtener el > > > methodContext que corresponde a thisContext? > > > > On Aug 21, 8:51 pm, Sebastian <[EMAIL PROTECTED]> wrote: > > > >> El problea más grave es que acciones ejecutan más veces que lo que > > >> deberían. Si bien el uso de la odb reveló el problema, este > > >> comportamiento puede traer problemas impredecibles para aplicaciones > > >> Seaside. > > > >> Aún en la versión 2.8a1 eam 529 e se pueden ver cosas como esta: > > >> (extraido de un logueo al transcript) > > > >> Free clients: 4 > > >> Get odb client: 52791 from process HTTPConnection>>interact > > >> Return odb client: 52791 from process HTTPConnection>>interact > > >> Return odb client: 52791 from process Copy of 349:Copy of > > >> 340:HTTPConnection>>interact > > >> Redundant return! (mutex violation?) > > > >> el numero de client es el hash de la odb en el pool. El pool como > > >> decia antes esta protegido por un semaforo for mutual exclusion y el > > >> get y el return se ejecutan dentro de un critical para que justamente > > >> este garantizado que dos procesos no puedan tomar un mismo cliente. > > >> Nota: el "Get odb..." se imprime despues que terminó el critical. > > > >> El proceso que es copia del 349 y que viene de la EscapeContinuation > > >> no deberia haber tomado la odb. > > > >> Es plausible que no la haya tomado y la conozca porque "behind the > > >> scenes" la continuation se la copió (cosa que no se como confirmar). > > >> Si este fuera el caso entonces estaría más claro como funciona el bug > > >> de ejecutar cosas dos veces. Para un escenario como este hago la > > >> siguiente pregunta: > > >> será que las continuations de Squeak hacen algo para compensar esa > > >> doble ejecución? (quizá en la forma de copiar el proceso?) > > >> idem VW? (ya lo estoy probando a ver que tal) > > >> será que el cógo original de #critical:ifError:, que evalúa el bloque > > >> en un fork y espera el resultado, no hace eso justamente como parte de > > >> la compensación? > > > >> Voy a estar haciendo algo de codigo para poner esto en evidencia y ver > > >> si hace lo mismo VW > > > >> saludos, > > > >> Sebastian > > > >> On Aug 21, 4:06 pm, Sebastian <[EMAIL PROTECTED]> wrote: > > > >>> Ah bueno! eso explica un montón de cosas. Incluída la copia del > > >>> semaforo en un estado anterior y que permite ejecutar la accion > > >>> protegida cuando deberia frenarse. No es loco porque justamente > > >>> continuations es ir para atras y para adelante en el tiempo. Esto se > > >>> esta pareciendo peligrosamente a los expedientes X de la computacion. > > >>> Concretamente eso explica el doble returnClient: y doble commit: a la > > >>> transacción. > > >>> Voy a digerir un poco todo esto > > > >>> gracias totales por la referencia Esteban > > > >>> Sebastian > > > >>> On Aug 21, 3:28 pm, "Esteban A. Maringolo" <[EMAIL PROTECTED]> > > >>> wrote: > > > >>>> Sebastián: > > > >>>> Podes tratar de revivir el thread: > > >>>> <http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_thr...> > > > >>>> Suerte :-| > > > >>>> Esteban A. Maringolo > > > >>>> 2008/8/21 Sebastian <[EMAIL PROTECTED]>: > > > >>>>> Hola gente, > > > >>>>> estoy atras de un problema un tanto inusual por decir algo. > > >>>>> Mi objetivo es usar Seaside en dolphin workers y que la sesión wrapee > > >>>>> con una transacción la respuesta del request (los porqués de esto son > > >>>>> un poquillo off-topic pero el que quiera ver una referencia puede ver > > >>>>> OmniSupport en squeaksource.com). Quedaría (simplificando el exception > > >>>>> handling) algo así: > > > >>>>> BlahSession>>withEscapeContinuation: aBlock > > >>>>> | response | > > > >>>>> ^ self database commit: > > >>>>> [response := super withEscapeContinuation: aBlock. > > >>>>> response ifNil: [ODBCannotLockObject signal: > > >>>>> 'Re-signalled from > > >>>>> ODBSession']. > > >>>>> response status = '500' ifTrue: [ODBSInternalError > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
