FAQ for gbeta


 

This is a list of Frequently Asked Questions for gbeta, both the language and the environment.

I'll put more questions & answers in here as soon as they get frequent ;-), hence: Don't hesitate to tell me when you think something is missing!


Q1: Why can't I run my existing BETA program under gbeta?

A: There are some low-level differences between the Mjolner BETA System implementation of BETA and the gbeta implementation which makes it impossible to run Mjolner BETA code directly with gbeta. Check out the compatibility section for details. A future release will contain a slightly adapted version of the Mjolner basic libraries that will work with gbeta. Even then, however, support for calling external code (such as compiled C) is probably not ready, and lots of the libraries of the Mjolner BETA System use externals, e.g. to create BETA-bindings for GUI APIs.


Q2: Why doesn't gbeta discover my source code changes?

A: During an interactive session, e.g. under Emacs, it is possible and often relevant to change the source code of the program being interpreted, but gbeta will not notice the changes, and the color coding in the source code window will still correspond to the original program, as when the interpretation started. It probably looks as if the colored block is an arbitrary part of the source code, and not the currently executing imperative. Even killing and restarting the interpretation does not solve the problem.

This is because gbeta reads the source code at startup, then builds an internal representation of the program, an abstract syntax tree, and then decorates this abstract syntax tree with static analysis information and executes. It never looks at the text files after the startup phase.

To refresh gbeta's picture of the program, quit the session and start a new one. In Emacs you should kill the gbeta interactive buffer (C-xk) and execute the M-x gbeta command from the main source code buffer again: the debugger framework of Emacs, which is used for the gbeta Emacs integration, does not support running the "debugger" (here: gbeta) more than once in a given buffer.


Q3: Why doesn't it work to finish a for-imperative?

A: When single-stepping through a piece of code like:

(# i: @integer
do something;
   (for 200000 repeat 1->i for);
   something_else
#)

it is tempting to skip all those iterations of the for-imperative, because single-stepping them is not likely to reveal any new information. If you haven't stepped into the for-imperative yet, the next command will execute all of it in one go. But if you have already stepped into the body of the for-imperative, you have to do something else.

This looks like a job for finish, but since finish only executes to the end of the current block of imperatives, it just executes one of the many iterations of the for-imperative. We still have to press [ENTER] 200000 times. Moreover, "finish 2" will execute to the end of the enclosing do-part, but we might want to single-step into something_else.

The solution is to put a temporary breakpoint after the for-imperative. In Emacs you can this by clicking on for and selecting the "Tmp. Brk. After" entry in the Gud menu.


Q4: How do I get a list of breakpoints?

A: The currently installed breakpoints can be printed with the command "show breakpoints" (possibly abbreviated to something like "sh b"). To view the associated source code, when running under Emacs, double-click near the end of the line specifying the source code file and position for the breakpoint in question.


Other sources

If you cannot find an answer to your question here, there are a few other possibilities. For questions about the language, consider the general BETA FAQ. Except for a few, small changes, the language gbeta is a backwards compatible superset of the traditional BETA language. Consequently, a large number of questions about gbeta could as well be seen as questions about BETA.

For questions about the practical usage of and interaction with the current gbeta implementation, check out the section "Getting Started".

 


Signed by: eernst@cs.auc.dk. Last Modified: 3-Jul-01