Workspace Variables

The new ObjectStudio release is not too far away. (If you want to know more about the date, you should talk to Arden Thomas (ProductManager)).

Some changes I’d like to get in the next release are changes to the Workspace.

I’ve always liked the VisualWorks Workspace, where you don’t have to declare variables and can create Workspace Variables.

What are Workspace Variables? Well, a Workspace Variables is just like any other variable, except that it is defined in the context of the current Workspace. This way you can get always the content of the variable, if you use the same Workspace.

So you assign something to a variable, that you haven’t declared. The Compiler now asks, what kind of variable it is. If you define it as a Workspace Variable, you can use that variable like any other global, except that it’s local to the workspace.

We use that a lot for database testing. Logon and store the database connection in a Workspace Variable. All subsequent calls can use this variable now. Another Workspace doesn’t have access, so you can use the same script and just change the logon parameters and keep the rest of the script the same.

While we were at it, we made some more changes to the Workspace.

You get now the same feedback from the compiler, like you do with the VisualWorks Workspace. Any SyntaxError is now shown in the OS8 Workspace.

This makes it so much easier to share scripts between OS8 and VW. Of course, we still use the OS8 compiler for our Workspace, so you get the very same behavior as before. We’ve just added a little more comfort.

Andreas
———————————————
Quis Custodiet Ipsos Custodes?

PS: if the feature doesn’t make it into the next release (it has to pass review first) and you’re still interested, please let us know and we send you the code.

Debugging a “Freeze”

Just this week I was struggling with a customer problem, that “froze” the entire application. The debugger was of no use, since it was part of the test case to reproduce the problem. On the bright side, I knew exatly, which method was called, that finally caused the “freeze”. Unfortunately, the “freeze” happened only under very vertain circumstances. All other calls to this method where fine and did not cause the problem.

What was so different from the test case, to all the other calls?

I wanted to see the call stack and check for differences there.
How can you do that, when the application doesn’t respond any more?
In VW and OS8, you can get the entire call stack.
Here is the code, I’ve inserted into the method:

’>>>>>>>>>>>>>>>>>>>>>>>>>>>>>’ out.
Processor activeProcess name out.
(CraftedSmalltalk.DebuggerService shortStackFor: thisContext ofSize: 50) out.
’>>>>>>>>>>>>>>>>>>>>>>>>>>>>>’ out.

This code, plus logging the transcript output to a file, helped me to identify the differences in the call stack. I found a possible workaround and I’m sure we’ll find a good solution for the problem.

Andreas
———————————————
Quis Custodiet Ipsos Custodes?