Hi guys...I am having a different behavior in GemStone than in Pharo.
I am using a subclass of ProcessLocalVariable where I use #value: and #value to store/retrieve some stuff that belongs to the current process being executed. Before digging deeper...let me ask...should this work? Or there is something strange in GemStone? Thanks, Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
I'm not that familiar with the implementation of ProcessLocalVariable ... is it exception-based or does it associate the variables with a process? What "different" bahavior are you seeing? I guess that means that at least I'm not aware of anything that should behave differently .... I do wonder if you are seeing this different behavior in a GemTools session or topaz or during Seaside operation? .... if exceptions are making their way up to GemTools via Gci, then there is some potential for process oddities but just potential .... no smoking guns ... if the process locals are associated with continuations, then things can get a little more complicated and the possibility of bugs increase:) Dale From: "Mariano Martinez Peck" <[hidden email]> _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Fri, Nov 22, 2013 at 6:55 PM, Dale K. Henrichs <[hidden email]> wrote:
The latter. Class comment of ProcessSpecificVariable says: "There are two kinds of process-specific variables: process-local (state available
for read and write in all methods inside the process), and dynamic variables (implementing dynamic scope)."
I have MyWebSession (subclass of WASession). Upong user login, I set a some data into a subclass of ProcessSpecificVariable.
Pseudo-Example MySession >> login ... "after login..." dict := Dictionary with .. "a dict with data" MySubclassOfProcessSpecificVariable value: dict.
And then at some point later in seaside, from anyware I can do: myDict := MySubclassOfProcessSpecificVariable value and access the data... So the difference is that in Pharo, the above line MySubclassOfProcessSpecificVariable value answers the dict, while in Gemstone answers nil.
This is during a GemToools session. I will try with topaz... Thanks,
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Dale, Of course, the nil I get is the one from #default: value "Answer the current value for this variable in the current context."
^Processor activeProcess environmentAt: self ifAbsent: [self default]. So maybe I am getting different processes instances for the #value: and the #value ... while in Pharo it is the same...
Question: is there a way to inspect or print to transcript from gemstone to the GemTools? I mean...say I want to do some Transcript show: in the code that is running or some inspect, and I want that they are seen in the transcript / ide of GemTools. Is that possible?
Thanks! On Fri, Nov 22, 2013 at 7:17 PM, Mariano Martinez Peck <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
From: "Mariano Martinez Peck" <[hidden email]>Yes. Especially when Seaside is involved ... there a number of forked processes along the way in GemStone that may match exactly what's happening in Pharo ... Yes, Transcript exists GemTools and it is attached to the Transcript window that is open when you login ... use it just like you would in Pharo ... If you are running without GemTools, the Transcript output is routed to the gem log ... all Transcript interaction is also recorded in the ObjectLog so you have a "permanent" record of your Transcript output from the very beginning:) Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Fri, Nov 22, 2013 at 8:07 PM, Dale K. Henrichs <[hidden email]> wrote:
really???? mmm then something strange is happening in my image.....I have a piece of code running in the server...I put some: Transcript show: 'xxx'; cr.
and nothing appears in my gemstools (in the transcript of the gemtools).... I thoguht the code might now be passing over there (quite strange), but I put a self halt just after the transcript and it halted!! yet nothing is printed...
Other stuff ARE printed in the transcript...so this is weird. I want to check the identityHash of the process in which I do the value: and the #value but I need a transcript for that...ok...I can write it to a file in the meanwhile...
Thanks!
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Fri, Nov 22, 2013 at 8:16 PM, Mariano Martinez Peck <[hidden email]> wrote:
even more funny...after halted, I can debug it in GemClient and if I do a 'do-it' to the Transcript show that was before the halt, IT DOES GET printed!!
why the hell it is not printed in the real time? no clue...
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
From: "Mariano Martinez Peck" <[hidden email]>Yes that is strange ... The Transcript logging works through the use of exceptions, so if you happen to have some odd exception handlers on your stack above the Transcript show, they might be interfering with things ... Check in the object log ... the object log output should be logged to the object log before attempting to write to transcript ... You can just inspect `ObjectLogEntry objectLog`... _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
From: "Mariano Martinez Peck" <[hidden email]>When you 'do-it' you are running the Transcript expression in a different process stack ... my money is on a exception handler interfering ...
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Fri, Nov 22, 2013 at 8:28 PM, Dale K. Henrichs <[hidden email]> wrote:
Ok, thanks!
Ahhhh good point there :) mmmm probably we have some on: Error do: but I cannot image much more than that. I guess that I can even if I would know which is the exception class you use for the transaction, I might not have the chance to halt it (to see which on:do: is the problematic) because me might not send anything to the exception object....
So...coming back to the problem.... writing some flags on files (since transcript was not working) it looked like even in the first time, the original #value answered fine (not nil). But for some reason, when the debugger comes (or the seaside error handler), the process is indeed different (and the env) and hence I get a nil.
In Pharo it has another behavior but I imagine this is how contexts/processor/debugger is implemented. Anyway.....it is time to refactor my app code so that not to rely/assume that ProcessLocalVariable will always be same. I will store that elsewhere.
Thanks!
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |