Known problems with the Envision prototype can be divided into four classes: fixable deviations from spec, deviations from spec that are unfixable or very difficult to fix, desirable extensions to the spec, and possible performance optimizations.

Fixable problems

[still too numerous to itemize here]

Non-trivial and unfixable problems

If you try to halt a running coprocessor function with ctrl-C, it appears to work and gives you a scheme error break. However, if you then try to issue another command to the coprocessor, the connection turns out to be dead and scheme will crash.

Do not kill a window with the mouse while the coprocessor is executing something (including receiving compiled code for a newly defined function). This will cause the coprocessor to crash. We understand what's wrong but haven't fixed it yet.

Catch all floating point errors. The current implementation checks beforehand for the most common types of problems: blatantly unacceptable things like divide by zero. But we don't catch more subtle problems such as underflow. It might be possible to catch the error signals provided by the C math library, but we haven't looked at the details of what would be required.

Desirable extensions

Install on IBM AIX. We tried this over summer 1997 and ran into major problems with the Scheme48 socket code not working.

Add more operations for binary file I/O.

Allow URL's to be opened in the same way as files and/or provide an operation to asychronously get the contents of a URL and save as a local file.

Allow 3D domains, e.g. for storing histograms of values in RGB color space.

Provide operations to coerce a sheet with real (integer) domain and/or codomain to a sheet with integer (real) domain and/or codomain, by writing a new header but sharing the same storage area. (This is easy: we just haven't done it yet.)

Modern graphical user front-end, replacing emacs and catching mouse (as well as kbd) inputs.

Shadow the Scheme functions for opening and closing ascii streams, so as to maintain a list of open connections.

A value such as a colormap index or a string of bit settings (for edge maps, for speaking to devices) is really not a number, but rather some sort of semi-symbolic value. There should be a special type for these values. And only such values, not numbers, should support operations such as setting and shifting bits.

Allow functions compiled into C to be dumped into multiple files, rather than all into one file, so that dumping to C could be done incrementally.

Allow scan forms to take extra arguments, which would be passed to the scanner functions. This would allow parameterized scanners.

Possible optimizations

A variety of changes might make the compiled and/or interpreted code faster. We are waiting for initial timing numbers to assess which of these might be worthwhile.

Add rules for converting forms like (if (if A B #f) C) to (if A (if B C)).

Add an opcode like point-coordinate, but taking an argument which is a constant integer, for when the second input is a literal constant. (This happens, for example, in expansion of vector operations by the compiler and in similar user-written code.)

Add opcodes like set-sheet, set-integer, ... which do not remove their input from the top of the stack. This would save one instruction in the (fairly common) case where a value is saved in a variable for later use and then immediately used.

The C structures used by the coprocessor to represent points contain the dimension of the points. Many functions (e.g. all user-defined code) knows the dimension of a point without inspecting it. The exceptions probably could be told the dimension. This would make points about 20% smaller.

Add 32-bit precision to the current suite of precision options (8-bit, 16-bit, 24-bit).

Because C does not define the length of long and short integers, portable implementations of 16-to-32-bit sheets needs to be done in a paranoid way which is probably wasting both space and access time. Ideally, we should use the C preprocessor to check the lengths of longs and shorts, and replace the paranoid code with more straightforward methods for the (very large percentage of) C implementations in which shorts are 16-bit and longs are 32-bit.

Factor the codomain scaling and offset out of linear combinations of sheet-refs and sample-refs, with a common sheet.

Add a version of sheets with floating point values. This is only sensible if the sheet is small, e.g. a convolution mask. That is, space efficiency is sacrificed but running time is reduced because scaling and offset are not required.


Ownership, Maintenance and Disclaimers

Manual Top Page

Last modified