Vector vol. 23 Nos. 1&2 Contents Editorial Stephen Taylor 2 Sustaining Members News

Drunk in Charge

There are only two types of code, Untested Code and Part-Tested Code. There is no Fully-Tested Code, and there is never enough vodka.

Errors in code fall into three types:

1. errors that work, but produce the wrong answer; e.g. two items are added rather than subtracted;

2. errors that cause the code to crash; e.g. dividing by zero;

3. errors that trigger error trapping; e.g. dividing by zero under error trapping.

CONTINUE workspaces only result from the second, and then only ever under runtime Dyalog APL.

Hunting the Snark

Just like out-of-date comments in the code, I lied. There is also a fourth type, the System Error (SYSERROR). Unlike CONTINUE workspaces, the developer’s version of Dyalog supports them.

aplcore is the name of the file on disk containing the snapshot of the core memory used by Dyalog APL, at the point the interrupter discovered the system error.

A developer can cause APLCOREs by incorrect calls using ⎕NA or OLE links etc., to external features. Bugs in the interrupter can also result in a SYSERROR. (Dyalog would like to know about the latter. In particular, they would like to know how to reproduce the SYSERROR with the minimum of code.)

Since it cannot be trapped, or directly recovered from, it is often very hard to discover exactly where in the code the SYSERROR was triggered. It may, however, be possible to extract data from the APLCORE workspace, although sometimes this in turn results in another Boojum.

Fit the First – The Landing

The first problem that we (the APL developers) have with the CONTINUE workspace is: How do I get hold of it? Because unlike “real programmers” (the Bellman and crew don’t eat quiche or Beaver but do run dyalog.exe), the “real users” only ever use dyalogrt.exe. So for us, the CONTINUE workspace normally appears on someone else’s PC.

I gave up expecting users to send me their CONTINUE workspaces merely because I asked them to. They will do so only if their jobs (not mine) depend on them doing so.

The question becomes “How do we make the CONTINUE workspace into a homing pigeon or boomerang?” (Fade up Charlie Drake singing “My boomerang won’t come back”.)

The Star Wars Guide to the Galaxy

(In which Darth Vader and the Vogons meet Dr Doolittle and Arthur Dent, and they all get their Blue Peter Badges.)

The APL developer has the basic PushMePullYou choice of the “tractor beam” or the “bulldozer” approach:

• The tractor beam (driven by “Darth Vader, developer from hell”) locks onto a CONTINUE workspace floating out there in the network of space but within range, and pulls it into the Death Star.

• The bulldozer (driven by the Vogon user acting as a sub-contractor), pushes the CONTINUE workspace across the network (over Arthur Dent’s house) into the arms of the patiently waiting (property) developer Zaphod Beeblebrox.

I prefer the tractor-beam approach. The application workspace need know nothing about the developer, it needs no general error trapping, and it has to do nothing. It is powerless to stop itself being dragged into the clutches of the Evil Empire. It also works on APLCOREs.

Alternatively, you have to build the bulldozer (or Vogon Constructor fleet) into every workspace, setting up complex Snark traps in the hope you won’t catch a Boojum.

The main drawback to the tractor-beam approach is that the target must be in range. That is to say, the CONTINUE workspace must be visible (readable) by you, Darth Vader, across the network, and at a known location. Whereas, the Vogons, in their bulldozer, need know only Arthur Dent’s home planet address; i.e. your PC’s IP address or name on the network.

A third alternative is the “here is one I made earlier” Blue Peter approach. The workspace at start-up, before normal processing, looks for an existing (earlier) CONTINUE workspace and, if found, sends it across the internet back home. This has the advantages of both the tractor beam (no error trapping required) and the bulldozer (can work from an unknown location), but the downside that you only receive the CONTINUE workspace the next time that user runs the system. Like the tractor beam, it also can work with APLCOREs.

A Joint Spanish Inquisition/KGB Production

You may threaten its life with a railway-share;
You may charm it with smiles and the comfy chair.

The developer, having got the poor defenceless CONTINUE workspace into his grubby hands, is now able to )XLOAD it into the development APL environment, and, using all the tools of the inquisitor, can extract all the information (who, what, how, when, where, etc.) contained within. (Film: Think Marathon Man, Dustin Hoffman, Laurence Olivier. Oh no – not the dentist’s chair!)

The two most important pieces of information contained in the CONTINUE workspace can be found in ⎕DM and ⎕SI. However, if you have used the bulldozer, you may need to defuse the error trapping – before the booby trap blows up in your face. You can then safely cut the stack back to the Snark.

Other useful information about the (real) user and their environment is, available from:

⎕AN

⎕WSID

GetCommandLine

⎕WG 'AplVersion'

Knowing the IP address, the version of Microsoft Word and the operating system version etc., would also be nice. But from the )XLOADed workspace can be read only information about the developer’s environment on your PC, not the user’s runtime environment on his PC.

So I suggest, again in true Blue Peter fashion, that you get this information using the “Here’s one I made earlier” approach…

Go back in your time machine, and either:

• Following the error triggering the error trap, before starting up your bulldozer, save all the information you need;

or do as I do and:

• Get your workspace’s start-up function to save all the environment information you can lay your hands on into a global variable.

Then, when your tractor beam captures a workspace, it already has this information nicely stored away. (This is also true even if your Boojum has turned into an APLCORE.)

Directory: issues
issues -> Protecting the rights of the child in the context of migration
issues -> Submission for the Office of the High Commissioner for Human Rights (ohchr) report to the General Assembly on the protection of migrants (res 68/179) June 2014
issues -> Human rights and access to water
issues -> October/November 2015 Teacher's Guide Table of Contents
issues -> Suhakam’s input for the office of the high commissioner for human rights (ohchr)’s study on children’s right to health – human rights council resolution 19/37
issues -> Office of the United Nations High Commissioner
issues -> The right of persons with disabilities to social protection
issues -> Human rights of persons with disabilities
issues -> Study related to discrimination against women in law and in practice in political and public life, including during times of political transitions
issues -> Super bowl boosts tv set sales millennials most likely to buy

Download 0.53 Mb.

Share with your friends: