Implement GRPlatform >> #thisContext on GemStone

[marschall]

We now have a #thisContext method for dialects that do not have a thisContext variable.

In order to get the tests running and the #stackDepth method working we need the following API:

• #sender: Answer the context that sent the that created the receiver. Can either be a block or or method context. Is nil for the topmost stack frame.

In order to get WAPharoWalkback to work we need the following API:

• #receiver: Answer the receiver object of the message receiver. Can be a block object.
• #printStringLimitedTo:
• #tempAt: Answer the temporary variable at the given index.

We used to send #tempScopedNames but that seems to be gone.
We used to send more messages but this seems to be the only part of the Pharo context API that is guaranteed to work.

There are references to thisContext in methods named evaluate that read something like

evaluate
	"GemStone does not have a thisContext variable..."

	^input evaluateInContext: self object symbolList: GsSession currentSession symbolList

I left out what we need for continuations since they're going to be different for GemStone anyway.

Since they are GemStone specific anyway I don't know how much replacing these makes sense.

[jbrichau]

Hi @dalehenrich,
Just a gentle question on this issue if it is possible to expect this sometime in the near future in Grease? Just to determine how to proceed with Seaside 3.4

[dalehenrich]

Are you waiting for me to do the implementation?

[jbrichau]

Oh, I thought @marschall told me you had an idea on how to do that. I just assumed this was discussed at ESUG. If this was not the case, I'm curious to hear your thoughts on how to approach this in GemStone.

[dalehenrich]

I think there was only one spot where ‘thisContext’ was being used so a method wasn’t needed ... If there is more than one spot then the method can be added ... with regards to continuations ‘thisContext’ isn’t the only reason we don’t have a common implementation

[jbrichau]

Ok, I took some time to read up on the issue and figure out why this idea exists and what your response to my previous question actually means :)
As I understand it, a thisContext method would be useful in WAGemStoneInspector and WAObjectLogInspector, so I agree it's not really needed as the impact on the code is rather limited.

Just to give it a try, I tried implementing the thisContext method as follows, but that did not satisfy the test at this time. By inspecting the resulting object, I do think the implementation is correct, but the test uses object identity to compare the resulting context objects and I have the impression the different invocations of GsProcess fromLevel: 1 result in different instances being created, which is not what thisContext does in Pharo.

thisContext
   ^ (GsContext fromLevel: 1) sender sender

So... @marschall... do we need object identity comparison? @dalehenrich: does that sound correct to you?

[marschall]

@jbrichau I don't think we need the object identity, I just needed to write a minimal test and I wanted to express the contract of #sender, if you can come up with a better test, feel free to change the test

[jbrichau]

TODO: Need to move GsContext class from Seaside-GemStone-Core to Grease.

[jbrichau]

For Grease 1.4.0, I only moved GsContext from Seaside to Grease. We can take it from there but I don't want to keep us from releasing Seaside at this time.