Hi guys,
I have a working code in Pharo but in GemStone I get an error: a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task. I have a WATask subclass where at certain point I do: comp := MyComponent new. self call: comp That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.
I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread. Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...
Anyway....any ideas of what the problem could be? Thanks in advance, Mariano http://marianopeck.wordpress.com |
hey Mariano,
Which versions of gemstone and seaside are you running? Johan On 09 Jun 2014, at 22:51, Mariano Martinez Peck <[hidden email]> wrote: > Hi guys, > > I have a working code in Pharo but in GemStone I get an error: > > a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task. > > I have a WATask subclass where at certain point I do: > > comp := MyComponent new. > self call: comp > > That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem. > > I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread. > > Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19... > > Anyway....any ideas of what the problem could be? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com |
Seaside 3.0.9 and GemStone 3.1.0.4. Was this already reported and fixed? On Mon, Jun 9, 2014 at 5:52 PM, Johan Brichau <[hidden email]> wrote: hey Mariano, Mariano http://marianopeck.wordpress.com |
In reply to this post by Mariano Martinez Peck
Mariano, IIRC, in Otto's case we discovered that had some "oddly" constructed blocks on the stack ... a close reading of the stack showed that when the continuation was reified on the stack, a frame (the one with the WATask method) was missing ...
Otto resolved the problem by rewriting his method a bit[1] ... so there is a bug out there, but we have not been able to get a sample into the lab, where we can dissect it and come up with a solution ...
In the sequence of three messages starting here[2], I describe some things to do and some suspicions of mine based on studying Otto's stack ... a stack would help me determine if your bug is in the same ballpark as Otto's...
Dale On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
Dale, how can I share with you a "stack" ? Thanks, On Mon, Jun 9, 2014 at 7:48 PM, Dale Henrichs <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com |
So, it has been a long, long time since I have logged onto my Amazon instance to check on my Gemstone instance. The good news is that my application is stable and running without intervention.
However, I backed up my repository today, and deleted old tran logs. When I tried to run gemtools.sh, I could not get the launcher to come up. First, I get this silly error
$ sh gemtools.sh $ Could not open display `(null)'. and when I do this: export DISPLAY=mylocalipaddress:0 Squeak comes up running the Pharo image but no windows display on my local machine. I recently upgraded to Mavericks. Do I have to do something to get the X11 host support to work? Larry |
In reply to this post by Mariano Martinez Peck
Mariano, If you have a GemTools debugger up on the continuation, there is a `copy stack` menu item that brings up an Information Required and the stack can be copied from that ... if a continuation was not created then you should find a stack in the gem log file ... there might be a stack in the gem log file no matter what ...
Dale On Mon, Jun 9, 2014 at 4:24 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
In reply to this post by Larry Kellogg
Larry, I love it that GemStone keeps chugging away:) It does sound like you need to get X running first ... I upgraded my mac to mavericks a while back, but I don't remember if I had to explicitly get X or not ... seems that I did ...
Dale On Mon, Jun 9, 2014 at 5:05 PM, Lawrence Kellogg <[hidden email]> wrote:
|
On Jun 9, 2014, at 8:20 PM, Dale Henrichs <[hidden email]> wrote:
Dale, Oh, it’s amazing, Gemstone just keeps running, week after week, month after month, and I use it ever day. I never managed to find the time to upgrade my repository, so I’m back on 2.4.4.1, IIRC. Still, www.practicemusic.com has been stable for me. I’m bummed that I never figured out how to make any money for all of the hundreds of hours I spent building the site and the iPhone app. I would be a happy camper if I could convince another company to let me build a system using Gemstone and Seaside. I think the new licensing terms are amazing and should not be an impediment to adopting the technology, if I read the pricing correctly. Sigh. Why are so many bad tools used instead?
It appears that X11 is no longer included in OS X! http://support.apple.com/kb/ht5293 Whose ideas was that? I got gem tools to work by installing XQuartz. Whew. Thanks for the help. Best, Larry
|
Administrator
|
>> Why are so many bad tools used instead? Flies.
On Mon, Jun 9, 2014 at 5:37 PM, Lawrence Kellogg <[hidden email]> wrote:
|
On Jun 9, 2014, at 9:41 PM, Richard Sargent <[hidden email]> wrote:
Do you mean files? I hate files. Larry
|
In reply to this post by Mariano Martinez Peck
Mariano, From within a component itself it looks like the "standard pattern" is put a `self call:` inside a wait: block like the following: chooseFrom: aCollection
"Choose an item from the given aCollection. Answer the selected item." ^ self wait: [ :cc | self chooseFrom: aCollection onAnswer: cc ] The wait: wraps the call: in a seasideSuspendFlowDo: which implements the partial continuation mechanism, so I'd guess that GemStone is getting confused by that ...
I'm trying to remember if nested continuations are "supposed to work" or not ... I seem to remember some old test code that tested for this a regularly blew up ... don't recall if this was the exact case or not ...
Have you tried wrapping with a wait: already? Dale On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
On Tue, Jun 10, 2014 at 11:50 PM, Dale Henrichs <[hidden email]> wrote:
mmm this is the first time ever I would need to deal with #wait: ...
Dale, I am confused. WAComponent >> #call: aComponent "Pass control from the receiver to aComponent. The receiver will be temporarily replaced with aComponent. Code can return from here later on by sending #answer: to aComponent."
^ self wait: [ :cc | self call: aComponent onAnswer: cc ] So the #call: already wraps the stuff in a #wait: so why would I need to wrap the #call: send with another #wait: ?
Thanks...I need to get this working in gemstone :(
Mariano http://marianopeck.wordpress.com |
I'm going blind --- the #call;OnAnswer: is wrapped not the call:)... Never mInd.. On Wed, Jun 11, 2014 at 9:40 AM, Mariano Martinez Peck <[hidden email]> wrote:
|
In reply to this post by Mariano Martinez Peck
On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:
Okay, now that I'm focussing on this problem:) The fact that you have two unique instances of #visitTask: _is_ diagnostic.... Is it possible that the method was recompiled at some point in time?
Hmm, in my image when I inspect the visitTask: method I get this: . -> aGsNMethod
(class)@ -> GsNMethod (oop)@ -> 231635201 (invariant)@ -> true debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...
iFields1@ -> 13511760954786561 inClass@ -> WATaskVisitor selector@ -> 22092384 1@ -> 11648
2@ -> 105544526464784 3@ -> 12958305600 4@ -> 132192 5@ -> 55834642352
6@ -> WAPainterVisitor 7@ -> 132208 8@ -> 60129544128 9@ -> 84632912
10@ -> 26306545120 11@ -> 1553472491356928 12@ -> 60129675200 13@ -> 9264
14@ -> 12885099953 15@ -> #'WARenderNotification'->WARenderNotification 16@ -> anExecBlock
17@ -> anExecBlock 18@ -> 22092386 19@ -> 22092128 20@ -> 261120
... and it is size 20. so I think I'd like to see the values of the fields in both of the methods that you are seeing ... In the mean time, I will start working on getting a "normal continuation" under the inspector and then see if I can trivially reproduce your problem ...
Dale |
Before I go too far, I'm curious if this is related to the problem that you've discussed on the Seaside list? In that thread I recall that you claimed the problem existed in both Pharo and GemStone ... if that is true then it isn't a unique problem to GemStone and not a bug per se... Dale On Wed, Jun 11, 2014 at 11:09 AM, Dale Henrichs <[hidden email]> wrote:
|
In reply to this post by Dale Henrichs-3
Regarding the different sizes. The compiled method itself shows up as size 20 (as in previous mail) and here's the method context from a live stack (of size 29 ... note that the oops are the same):
-------------------- . -> aGsNMethod .. -> WATaskVisitor>>visitTask: @5 line 5 (class)@ -> GsNMethod (oop)@ -> 231635201 debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...
iFields1@ -> 13511760954786561 inClass@ -> WATaskVisitor selector@ -> 22092384 1@ -> 11648 2@ -> 105544526464784 3@ -> 12958305600
4@ -> 132192 5@ -> 55834642352 6@ -> WAPainterVisitor 7@ -> 132208 8@ -> 60129544128 9@ -> 84632912
10@ -> 26306545120 11@ -> 1553472491356928 12@ -> 60129675200 13@ -> 9264 14@ -> 12885099953 15@ -> #'WARenderNotification'->WARenderNotification
16@ -> anExecBlock 17@ -> anExecBlock1 18@ -> nil 19@ -> aGsNativeCode 20@ -> 0 21@ -> 22092386
22@ -> WATaskErrorFunctionalTest 23@ -> aGsNativeCode 24@ -> 0 25@ -> 22092128 26@ -> ExecBlock 27@ -> aGsNativeCode
28@ -> 0 29@ -> 261120 and here's the block context from within the visitTask: method (of size 8): [] in ExecBlock0(WATaskVisitor)>>visitTask: @2 line 4aGsNMethod/
-------------------- . -> aGsNMethod .. -> [] in ExecBlock0(WATaskVisitor)>>visitTask: @2 line 4 (class)@ -> GsNMethod (oop)@ -> 250091265
debugInfo@ -> anArray( 805306624, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotification... iFields1@ -> 15762598695796992 inClass@ -> aGsNMethod
selector@ -> 29216 1@ -> 14568529071472 2@ -> 1610483264 3@ -> 8589936576 4@ -> 131744 5@ -> WATaskErrorFunctionalTest
6@ -> aGsNativeCode 7@ -> 0 8@ -> 1825664 The oop in this case is the oop of the "block"... So in looking at your stack trace only the visitTask: block is on the stack and the visitTask: method itself is not on the stack ... so that is why you are getting the error ...
To get this info, I am simply running the WATaskErrorFunctional test and in this case both the block and the method are on the stack ... Soooooo, if you could provide me with the code for a component that reproduces the problem, I'll be able to make progress on finding a solution ...
I will make a couple of stabs at trying to build such a component, but you are much closer to the real problem than I am ... I'm guessing that the problem is somehow related to details of the block structure on the stack, since Otto was able to reformulate his method to make the problem "go away" ...
Dale On Wed, Jun 11, 2014 at 11:09 AM, Dale Henrichs <[hidden email]> wrote:
|
On Wed, Jun 11, 2014 at 3:53 PM, Dale Henrichs <[hidden email]> wrote:
OK..... you are right, it was my bad.
Exactly!!!! I only have the block of the #visitTask, and not the compiled method, and yes this is the cause of why I am seeing this error.
I am trying to investigate which is the cause and I already got an isolated case. But... I can confirm you this is related to having sub-tasks. Right now my failing scenario was this:
1) XXX's #go calls a subtask ZZZ 2) When ZZZ finished, XXX's #go calls a component TTT. That last call from XXX's #go to component TTT is what fails. What is interesting, however, is that if I remove step 1, that is, the call to the subtask ZZZ, then it works perfect. So it has to do for sure with the fact of calling a subtask from within a task.
Here it is. It is very very simple and it reproduces the problem. To test it...somewhere do a "call:TestMainTask new". Something to note is that subtask is STORED as instVar in maintask and MainTask does implement #children with it. This is to solve the other issue you saw related to task calling tasks: https://code.google.com/p/seaside/issues/detail?id=744 and yes, I was having this problem in both Pharo and GemStone.
Let me know how it goes.
Mariano http://marianopeck.wordpress.com TestsTasks-MarianoMartinezPeck.1.mcz (1K) Download Attachment |
Mariano
I have hooked up your tasks and got a stack[1] that is not quite exactly matching the one that you sent earlier, but it does have the `19. [] in ExecBlock(WATaskVisitor)>>visitTask: @2 line 4` on the stack without the parent method ... so this is probably close enough to work with ... the continuation/vm expert is on vacation this week, but I've got a couple of things that I will try, now that I've got my hands on this... Dale [1] 1. WAGemStoneProductionErrorHandler(WAErrorHandler)>>saveExceptionContinuation: @10 line 7 2. WAGemStoneProductionErrorHandler>>handleDefault: @2 line 3 3. WAGemStoneProductionErrorHandler(WAErrorHandler)>>handleError: @2 line 2 4. WAGemStoneProductionErrorHandler(WAErrorHandler)>>handleGemStoneException: @4 line 4 5. WAGemStoneProductionErrorHandler(WAHtmlHaltAndErrorHandler)>>handleException: @2 line 2 6. [] in WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 5 7. WAGemStoneProductionErrorHandler(ExecBlock)>>on:do: @3 line 42 8. [] in WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 8 9. [] in ExecBlock>>on:do: @4 line 49 10. WAGsInvalidCallbackContext(AbstractException)>>_executeHandler: @3 line 8 11. WAGsInvalidCallbackContext(AbstractException)>>_signalWith: @1 line 1 12. WAGsInvalidCallbackContext(AbstractException)>>signal: @3 line 7 13. WAGsInvalidCallbackContext class(AbstractException class)>>signal: @3 line 4 14. GRGemStonePlatform>>seasideSuspendFlowDo: @5 line 4 15. TestMainTask(WAComponent)>>wait: @3 line 3 16. TestMainTask(WAComponent)>>call: @2 line 4 17. TestMainTask>>go @6 line 4 18. TestMainTask(WATask)>>execute @2 line 7 19. [] in ExecBlock(WATaskVisitor)>>visitTask: @2 line 4 20. ExecBlock>>on:do: @3 line 42 21. GsNMethod class>>_noopReturnTos @1 line 1 22. TestSubTask(WATask)>>accept: @2 line 2 23. WATaskVisitor(WAVisitor)>>visit: @2 line 2 24. WAVisiblePresenterGuide(WAPresenterGuide)>>visitPainter: @3 line 2 25. WAVisiblePresenterGuide(WAPainterVisitor)>>visitPresenter: @2 line 2 26. WAVisiblePresenterGuide>>visitPresenter: @2 line 2 27. WAVisiblePresenterGuide(WAPainterVisitor)>>visitComponent: @2 line 2 28. WAVisiblePresenterGuide(WAPainterVisitor)>>visitTask: @2 line 2 29. TestSubTask(WATask)>>accept: @2 line 2 30. WAVisiblePresenterGuide>>visitDecoration: @6 line 4 31. WAAnswerHandler(WADecoration)>>accept: @2 line 2 32. WAVisiblePresenterGuide(WAPainterVisitor)>>visitDecorationsOfComponent: @3 line 2 33. TestSubTask(WAComponent)>>acceptDecorated: @2 line 2 34. WAVisiblePresenterGuide(WAPresenterGuide)>>visit: @2 line 2 35. [] in WAVisiblePresenterGuide>>visitPresenter: @2 line 3 36. [] in TestMainTask(WAPresenter)>>childrenDo: @11 line 8 37. Array(Collection)>>do: @5 line 10 38. TestMainTask(WAPresenter)>>childrenDo: @3 line 2 39. WAVisiblePresenterGuide>>visitPresenter: @3 line 3 40. WAVisiblePresenterGuide(WAPainterVisitor)>>visitComponent: @2 line 2 41. WAVisiblePresenterGuide(WAPainterVisitor)>>visitTask: @2 line 2 42. TestMainTask(WATask)>>accept: @2 line 2 43. WAVisiblePresenterGuide(WAPainterVisitor)>>visitDecorationsOfComponent: @3 line 2 44. TestMainTask(WAComponent)>>acceptDecorated: @2 line 2 45. WAVisiblePresenterGuide(WAPresenterGuide)>>visit: @2 line 2 46. [] in WAVisiblePresenterGuide>>visitPresenter: @2 line 3 47. [] in TestMainComponent(WAPresenter)>>childrenDo: @11 line 8 48. Array(Collection)>>do: @5 line 10 49. TestMainComponent(WAPresenter)>>childrenDo: @3 line 2 50. WAVisiblePresenterGuide>>visitPresenter: @3 line 3 51. WAVisiblePresenterGuide(WAPainterVisitor)>>visitComponent: @2 line 2 52. TestMainComponent(WAComponent)>>accept: @2 line 2 53. WAVisiblePresenterGuide>>visitDecoration: @6 line 4 54. WAToolDecoration(WADecoration)>>accept: @2 line 2 55. WAVisiblePresenterGuide(WAPainterVisitor)>>visitDecorationsOfComponent: @3 line 2 56. TestMainComponent(WAComponent)>>acceptDecorated: @2 line 2 57. WAVisiblePresenterGuide(WAPresenterGuide)>>visit: @2 line 2 58. WAVisiblePresenterGuide(WAVisitor)>>start: @2 line 2 59. WAInitialRenderLoopContinuation>>prepareRoot: @9 line 5 60. WAInitialRenderLoopContinuation>>basicPerformAction @7 line 5 61. [] in WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>performAction @2 line 2 62. WAInitialRenderLoopContinuation(ExecBlock)>>onException:do: @2 line 66 63. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @5 line 47 64. WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 3 65. [] in ExecBlock(WARenderLoopContinuation)>>withNotificationHandlerDo: @2 line 20 66. ExecBlock>>on:do: @3 line 42 67. WAInitialRenderLoopContinuation(WARenderLoopContinuation)>>withNotificationHandlerDo: @8 line 21 68. WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>performAction @2 line 2 69. WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>handleFiltered: @2 line 2 70. [] in WAInitialRenderLoopContinuation(WARequestHandler)>>handle: @3 line 4 71. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @3 line 42 72. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 73. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 74. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 75. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 76. WAInitialRenderLoopContinuation(WARequestHandler)>>handle: @2 line 4 77. [] in WAInitialRenderLoopContinuation(WASessionContinuation)>>handle: @2 line 5 78. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @3 line 42 79. WAInitialRenderLoopContinuation(WASessionContinuation)>>withUnregisteredHandlerDo: @2 line 3 80. WAInitialRenderLoopContinuation(WASessionContinuation)>>handle: @4 line 5 81. WASession>>start @6 line 2 82. [] in WASession>>handleFiltered: @2 line 15 83. WAMergedRequestFields>>at:ifAbsent: @3 line 6 84. WASession>>handleFiltered: @16 line 14 85. [] in WASession(WARequestHandler)>>handle: @3 line 4 86. WASession(ExecBlock)>>on:do: @3 line 42 87. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 88. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 89. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 90. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 91. WASession(WARequestHandler)>>handle: @2 line 4 92. WASession>>handle: @10 line 11 93. WAApplication(WARegistry)>>dispatch:to:key: @4 line 6 94. WAApplication(WARegistry)>>handle:registering: @4 line 7 95. WAApplication>>handleDefault: @3 line 2 96. WAApplication(WARegistry)>>handleFiltered: @7 line 6 97. WAApplication>>handleFiltered: @10 line 8 98. WAExceptionFilter(WARequestFilter)>>handleFiltered: @3 line 4 99. [] in WAExceptionFilter>>handleFiltered: @2 line 7 100. WAExceptionFilter(ExecBlock)>>on:do: @3 line 42 101. WACurrentExceptionHandler class(WADynamicVariable class)>>use:during: @2 line 4 102. [] in WAExceptionFilter>>handleFiltered: @2 line 6 103. WAExceptionFilter(ExecBlock)>>onException:do: @2 line 66 104. WAExceptionFilter(ExecBlock)>>on:do: @5 line 47 105. WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 3 106. WAExceptionFilter>>handleFiltered: @5 line 4 107. [] in WAApplication(WARequestHandler)>>handle: @3 line 4 108. WAApplication(ExecBlock)>>on:do: @3 line 42 109. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 110. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 111. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 112. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 113. WAApplication(WARequestHandler)>>handle: @2 line 4 114. WADispatcher>>handleFiltered:named: @3 line 5 115. WADispatcher>>handleFiltered: @8 line 6 116. [] in WADispatcher(WARequestHandler)>>handle: @3 line 4 117. WADispatcher(ExecBlock)>>on:do: @3 line 42 118. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 119. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 120. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 121. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 122. WADispatcher(WARequestHandler)>>handle: @2 line 4 123. WADispatcher>>handleFiltered:named: @3 line 5 124. WADispatcher>>handleFiltered: @8 line 6 125. [] in WADispatcher(WARequestHandler)>>handle: @3 line 4 126. WADispatcher(ExecBlock)>>on:do: @3 line 42 127. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 128. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 129. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 130. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 131. WADispatcher(WARequestHandler)>>handle: @2 line 4 132. [] in WAGsZincAdaptor(WAServerAdaptor)>>handleRequest: @3 line 4 133. WAGsZincAdaptor(ExecBlock)>>on:do: @3 line 42 134. WAGsZincAdaptor(WAServerAdaptor)>>handleRequest: @2 line 5 135. WAGsZincAdaptor(WAServerAdaptor)>>handle: @2 line 4 136. [] in WAGsZincAdaptor(WAServerAdaptor)>>process: @2 line 6 137. WAGsZincAdaptor(ExecBlock)>>ensure: @2 line 12 138. WAGsZincAdaptor(WAServerAdaptor)>>process: @4 line 7 139. [] in WAGsZincAdaptor>>process: @2 line 6 140. [] in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @2 line 11 141. GRGemStonePlatform(ExecBlock)>>on:do: @3 line 42 142. [] in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @11 line 12 143. GRGemStonePlatform(ExecBlock)>>ensure: @2 line 12 144. TransientRecursionLock>>critical: @11 line 12 145. GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @3 line 5 146. [] in GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @6 line 9 147. GRGemStonePlatform(ExecBlock)>>on:do: @3 line 42 148. GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @2 line 17 149. WAGsZincAdaptor>>process: @3 line 4 150. ZnSeasideServerAdaptorDelegate>>handleRequest: @3 line 4 151. [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateAndDelegateRequest: @7 line 12 152. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateRequest:do: @4 line 6 153. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateAndDelegateRequest: @2 line 8 154. [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequestProtected: @2 line 5 155. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42 156. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequestProtected: @2 line 6 157. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequest: @5 line 9 158. ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeOneRequestResponseOn: @6 line 10 159. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @2 line 10 160. [] in ZnCurrentServer class(DynamicVariable class)>>value:during: @3 line 9 161. ZnCurrentServer class(ExecBlock)>>ensure: @2 line 12 162. ZnCurrentServer class(DynamicVariable class)>>value:during: @6 line 10 163. ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @4 line 8 164. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 12 165. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42 166. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 13 167. ZnManagingMultiThreadedServer(ExecBlock)>>ensure: @2 line 12 168. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 15 169. [] in ExecBlock>>ifCurtailed: @2 line 6 170. ExecBlock>>ensure: @2 line 12 171. ZnManagingMultiThreadedServer(ExecBlock)>>ifCurtailed: @3 line 8 172. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 18 173. GsProcess>>_start @7 line 16 174. UndefinedObject(GsNMethod class)>>_gsReturnToC @1 line 1 |
In reply to this post by Dale Henrichs-3
Mariano, I ran my tests in 3.2, but this should "work" in 3.1 as well ...Today might be your luck day ... I made the following change to GRGemStonePlatform>>callbackMarker and your example with nested tasks is "working": callbackMarker | level aFrame visitTaskMethod | visitTaskMethod := WATaskVisitor compiledMethodAt: #'visitTask:'. level := 1. [ (aFrame := GsProcess _frameContentsAt: level) ~~ nil ] whileTrue: [ (((aFrame at: 10) isKindOf: WACallback) or: [ (aFrame at: 1) homeMethod == visitTaskMethod ]) ifTrue: [ ^ aFrame at: 1 ]. level := level + 1 ]. ^ nil On Mon, Jun 9, 2014 at 3:48 PM, Dale Henrichs <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |