sourcedoc: zzzWriteup D6

hide references

zzzWriteup D6




ZZZ, Our Working Version of ZigZagÆ


[This assumes some prior knowledge of ZigZag. It is NOT AN INTRODUCTION, but covers details of the current implementation that are likely to change.]

(c)2003 Theodor Holm Nelson

Project XanaduÆ and Operation ZigZagÆ

"Xanadu" and "ZigZag" are registered software trademarks. Trademark is also claimed for "Angeltext" and "VLIT".

"ZZstructure," "zzspace", "zzcell" are not trademarked.

Whether to trademark "Nuzzl" is undecided.

===(For firing-up details, please read latest draft of "Quickstart ZigZag Instructions".)

===(For Nuzzl details, please read latest draft of NuzzlWriteup.)











 3D with OpenGL: ZZOGL







I designed ZigZag essentially between 1982 and 1986. It was not implemented for over a decade, however, because of the question of how to handle connections efficiently. When an efficient method became clear, Andrew Pam was able quickly to create a first implementation (Azz). There have been a couple of other implementaions, Gzz and Ezz, which will not be discussed here.

Since December 2001, Jeremy Smith (of Yorkshire, England) has been adapting the original code (Andrew's Azz), moving it into C with Python additions. He has also programmed the Nuzzl language, discussed in another document.

The robustness and excellence of Andrew's code has been proven time and again. In this writeup there is no room to cite the contributions of others; that will wait for a fuller paper or book. I must, however, thank Marlene Mallicoat for her organizational and spiritual support.


This version is called Zzz (generally pronounced Zee-zee-zee-- since the English are able to say "ZZTop," it is no great violence to ask them to say it the American way, but it's not a big issue).

We are creating a new computer universe, intended to work seamlessly with desktop computers, mobile phones, and backup servers.

ZigZag (version Zzz) is not a product. It is a prototype put together to show some basic capabilities in a number of areas, especially user programmability of windows which show contents of the user's files.

Operation ZigZag is a business venture (a sole proprietorship with developer participation).

Zzz is in C and Python. It was developed under Windows; we intend to port it to Linux and Macintosh (OSX). To run Zzz on any of these machines, the user must have Python installed.

The size of the Zzz executable is about 400k.

It may help to have a recent graphics card, which may speed up the OpenGL.


Zzz differs from Azz in that it has more aspects, properties and features. These include a number of new aspects--


A number of additional operations have been added to Azz. (Discussed below.)


The user's space is divided into multiple sections or "slices" of the space. This allows essentially infinite contents to be stored and brought in in different combinations. (Discussed below.)


Python is a popular general-purpose programming language. It is accessible in ZigZag. This allows you to create new ZigZag operations for any purpose in Python. (Discussed below.)

=3D with OpenGL: ZZOGL

OpenGL is a system for presenting 3D on screens. "ZZogl" is a method of arranging data for the OpenGL processor, as a system of tokens represented by ZigZag cells. (Discussed below.)


Nuzzl is a programming language which takes cell contents as arguments and puts results out as contents. (Discussed below.)


A number of additional operations have been added to those of the original Azz. The following operations are now included in Zzz:


Currently we have two dimension wheels, the full wheel and DimsCasual, which is much shorter.


Left-curly followed by a direction ({ arrowkey takes you to the designated end of the designated rank.


Hit the #SEARCH key (cell 290), or a clone of it.

A window will pop up to receive the string string (case insensitive). When you close it, this search string will appear in a cell next to the #SEARCH key in d.1.

All databases currently in RAM will now be searched, and below your search string will appear clones of all the cells containing the string.


We have no explicit "Print" instruction. However, Zzz can generate HTML pages from cells, and these can be printed.

First you enter the output filename in cell 246 (which is at the bottom from Home and to the right), normally "htmlout.htm".

You put the green cursor on the start panhandle (upper left corner of the cells), then position the blue cursor to the far right, and mark (with M) the cell that marks the lowest panhandle to do.

Then press Ctrl+P and it will output to the filename in cell 246; beware, it erases the old file without warning (for now).

If it cannot find the blue cursor down and to the right (and it will keep going until it can't find any more! but it won't get in a loop), or a marked cell in the same domain, it will complain and do nothing further.

    [LATER: the Zzz engine can respond to HTTP requests, including those with KBLANG STRINGS. This allows ZigZag to be a Web server.]


To undo the last operation, press ctrl-u.

This undoes the last operation. However, the cursors are not affected.

"REDO" is not currently working.

Details if you're interested:

The undo stack is to be found in the Menu area.

Each cell contains Python code sufficient to undo one structure-changing operation.

===Programmability in Python

Python is a popular general-purpose programming language that is highly regarded. (Eric Raymond has said it is the best programming language for beginners; Mark Miller says it is one of the two languages that he considers well-structured.)

It is accessible in ZigZag in various ways. This makes ZigZag easily extensible in Python. This allows you to create new ZigZag operations for any purpose in Python.

(We are not committed to Python in the long run, but it is a great convenience at the moment.)


Certain Python rules apply in Nuzzl routines. Python variable naming (fairly loose) applies. We also use Python numerical conventions (for instance, an integer divided by an integer is an integer, e.g. 5/2=2, whereas 5/2.0=2.5.)


The user's space is divided into multiple sections, or "slices", of the space.

Like conventional files, they may be moved in and out independently. This allows essentially infinite contents to be stored and brought in in different combinations.

Unlike conventional files, however, the different sections may have arbitrary individual cell interconnections.

This is discussed further below.


The following operations may or may not be included by the time you read this. (We are pleased to acknowledge the Gzz project's choices of keys.)

Swap cursors (~)

Swap cells (%)-- exchanges the cells in dimension x and y only.

Move left green cursor to same accursed cell as right blue cursor.

Move right blue cursor to same accursed cell as left green cursor.

Import from gzz.0603 [WE HOPE REAL SOON]

Export to gzz.0603 [WE HOPE REAL SOON]



Slices are sections of content which may be activated independently. Slices are stored on disk in text format (textslices). When activated and present in RAM, a slice is kept in a hash database.

Users may create slices with any names, but connecting to them is not presently defined the way it should be.


Two slices are built into the system. They are the System Slice (containing the key cells supplied by the system) and the User Slice.

These are presently called s.0, or Slice 0 (the system itself) and s.00, or Slice 00, holds the user's settings.

[THESE NAMES WILL BE BE CHANGED TO "s.system" (the system slice) and s.0 (the user slice).]

This distinction is rather like the way it was on the old Macintosh-- we had "Extensions" (the actual code packages of Macintosh applications) and "Preferences" (the user's settings, which could be thrown away without disabling the system).

In the case of Zzz, the plan is to continually change and upgrade s.system (presently called s.00) but leave all the user's connections to the system valid by keeping them on s.0 (presently called s.00).


We use hash databases, which associate a key with a value and reply instantaneously (as distinct from linked lists, which will be increasingly delayed with long lists.

The contents of a cell are represented by a key-value pair as follows: key cellID => contents of cell


    17 => 'snerd'

A link between cell 20 and cell 21 on d.1 is represented by two key-value pairs:

    20+d.1 => 21

    21+d.1 => 20

These are called halif-links. Two half-links represent a link, but the link is a conceptual unit; the half-links are simply the implementation hack that makes them possible.


We are storing slices on disk in textfiles representing the key-value pairs as in the hash databases.


Everything was so much easier when we had only one database at a time.

We have now put in the infrastructure for multiple databases, which vastly extends the power of the system. Unfortunately the precise interface logic is still somewhat clumsy. We apologize for any inconvenience.


Different databases are combined by opening them at the same time and making links between them.



A list of the current databases in the current directory is to be found next to #databases in the Menu. This is automatically maintained.

When the system fires up, it looks in the directory and lists all the files ending in ".db" on a rank in d.2 next to "Available". These are the names of databases.

If you execute one of these cells, the slices is brought into memory, and its name shown on the list of slices currently in memory and its name shown on the list of current slices.


Go to #NewSlice on the Menu. The cell next to it is the current "new slice", defaulting to 00 .DB. Change this to the name of the new slice you wish to create, ending in ".db".


The system assumes that you are making a cell in the database whose name is the current suffix, next to cell #CurrentSuffix on the menu.

In order to make a cell in another database, you must change that cell.


In the prototype, "g" and "G" would take the respective cursors to the only Home cell there was. Now, however, there is a Home cell in every database.

If you type "g" or "G" by itself, it goes to the Home in database 0.db.

=EVENTUAL SLICE METHODS (already designed)

I have designed various ways of combining slices but we have no timetable for implementing them. They are--

    - Half-links, where the normal database pointers are allowed to cross database boundaries, leaving an unrequited link on either side. This is a bad idea for various reasons but is the present method.

    - Marshmallows [not yet implemented] A marshmallow (by analogy with marshmallows toasted on the end of a stick) is a substitute cell automatically put in as a cap or tip when two slices are separated and deleted when the slices are reunited. The two halves of a link each become tipped with a marshmallow, preventing other connection at that location.

    - [not yet implemented] Deep Slices, where cells in one slice can automatically slide between cells in another slice. (This is sufficiently complex, more to explain than to implement, that it has been repeatedly deferred.)

===3D with OpenGL: ZZOGL

OpenGL is a system for presenting 3D on screens. Usually it operates on scene lists. We have created a system for organizing scene lists in ZZcells, called "ZZogl" (ZigZag OpenGL).

In keeping with the minimalist notion of ZigZag, the ZZogl representation of graphics is extremely simple.

[PIC: ZZogl master list, display list]

ZZogl represents each object to be displayed (vunit) as a system of ZigZag cells. The OpenGL processor goes down the list of vunits each time it refreshes the presentation.

To display a Vunit by OpenGL, ZZogl takes the parameters of the vunit from various dimensions linked to the Vunit's maincell. If the Vunit's maincell is a clone, ZZogl takes any missing values from its master cell.

===ZZogl Details

The OpenGL processor needs a list of items to show (the display list).

The user (or a program) produces this displayable list by cloning the items from a master list of vunits. These may be cloned as many times as needed to make a graphical scene of many objects. The clones are placed in display lists which the ZZogl processor cycles through.

=The Master Vunit List

We start with a master list of items which may be displayed (viewable units or vunits).

The ZZogl Master List is a list in d.2 of the types of OpenGL vunits that ZZogl can display. Currently these are only



In order to create a display list, you clone as many of these vunits as desired in the final scene, and put them onto--

=ZZogl Display Lists

A ZZogl Display List is a list of the vunits currently to be displayed. For each vunit to appear in a scene, there must be a clone from the master list onto the display list.

A ZZogl display list is a list of vunit clones on d.2. The list may start anywhere in zzspace.

The display list must be a corner list, with a handle -d.1 connecting to the first item to be displayed.

[PIC: Display Lists as Corner Lists]

More than one display list may be made part of a scene. This allows different processes to concentrate on creating different parts of a scene.

Each display list is a corner list. The user may give any name to a display list. The name is displayed on the handle of the corner list.

The display lists are all to be found at a central cell on the menu.

=Display Central

The cell #DispCentral is where the ZZogl display lists come together.

The different display lists are placed there as clones of corner lists.

>> [PIC: Display Central; Clones of Corner Lists]

=Current ZZogl Dimensions

A vunit has a number of graphical control cells

Vunit parameters

Each Vunit (Viewable Unit) is generated from a clone on a display list to be found at Display Central. In turn, each vunit clone connects to the master list of possible vunits.

Each vunit is controlled by a set of control cells containing the different parameters of the vunit. Each vunit may have its own parameters. These are put on the graphical attribute dimensions.

The parameters of a vunit are taken from the attributes of its maincell (the clone from the master list). Any specific parameter which is not present on the vunit is taken from the master itself. When the Vunit is displayed by OpenGL, ZZogl takes the parameters of the vunit from various dimensions along the clone. However, if the clone does not have these values, it takes the values from the master.

=Key Details of Vunits

[pic: Vunit and its dimensions and control cells]

The following are the dimensions currently implemented. (The number of dimensions for a ZZogl vunit is potentially infinite: in the future we might create graphics in which an object has any number of possible attributes.)


We give every vunit 3D coordinates called




These are the three-dimensional coordinates of the vunit in "box space" or "board space", the three-dimensional space being looked at currently. They are the positions of the upper-left-hand corner of the object.





These specify the size of the object in box space, or the set of coordinates





These specify the color of the object in RGB color components. The color of the vunit is the blend of the color components in the three cells to be found on ga.Red, ga.Green and ga.Blue. Each ranges from 0 to 1.


    White = R, G, B all equal to 1.

    Black = R, G, B all equal to 0.

    Shades of grey = R = G = B.

===Windows on Textfiles: Treffles

The Xanadu model has always defined documents as collages of text content stored elsewhere.

In ZigZag we are following this model. The first step is to look at the contents of external files.

A Trefel (Text REFerential cELL), also spelled treffle, is a unit which shows a span of content from an external file.

Treffles may be viewed in various ways. A Flying Treffle is one which may be seen in 3D, as through OpenGL.


We are currently working with flying treffles in ZZogl, which show as rectangles. These we call TrefRectangles.

The maincell of a Treftangle is a clone of the master vunit, on the ZZogl list, called


The control cells of a flying Trefle Rectangle are on dimensions as follows:


    The path at which to find the file to be viewed.

    tref.file [should be tref.filename]

The name of the file to be viewed.


The ordinal position of the first character to be shown.


The length of the span of text to be shown.

tref.text [should be tref.content]

The content returned from the file.


The size of the font to be displayed.

[pic: Flying Treffle format]


Nuzzl is a programming language which takes cell contents as arguments and puts results out as contents.

For more information on Nuzzl, see "Nuzzl, A Cellular Programming Language" (nuzzlWriteup Dx, where "x" is the latest version number).


Angeltext is an approach to presenting text in billowing format, as presented in

Several different possible designs exist, handling the text either as separate slats or as texture maps on rounded surfaces.


Currently we use BerkeleyDB. This has several problems having to do with reliability and distribution.

- BerkeleyDB version 2 allows free redistribution, but is extremely buggy.

- BerkeleyDB 2.7.7 is far more reliable but we have no right to redistribute it. However, each user may download it free.

[MAY CHANGE BEFORE 27 AUG] For these convoluted reasons we are furnishing BerkeleyDB version 2, with instructions for downloading version 2.7.7.


Note: This is a glossary only for the present discussion, not as a general introduction to ZigZag. Much larger glossaries are available in the document "ZZmain", which has unfortunately not been updated lately.


    system of 3D text presentation in which lines of text may be made larger and smaller in perspective, by various different mechanisms.


    cell contents identical to some other cell, through the ZigZag cloning method (along d.clone).

control cell

    cell which contains contents controlling something, especially parameters of an OpenGL vunit.

flob (or hyperflob)

    object viewed in 3D space, as generated by a vunit.

flying cell

    ZigZag cell shown as flying in 3D space in OpenGL.

flying trefel, flying treffle

    treffle which flies in OpenGL or other 3D system.


    see "flob".


    a section of ZigZag data.


    Nu [New] ZigZag Language, a specific system for writing programs with operands in cells.


    line of text in Angeltext (comparable to slats in Venetian blinds).

trefel, treffle

    Text REFerential cELl, a cell showing a span of contents of an external textfile.


    rectangular treffle (in OpenGL).


    VOLatile operAND, a type of cell created by a Nuzzl operation and destroyed when a new operation is carried out.


    cell cluster (zzcule) generating a viewable unit in OpenGL (flob or hyperflob).


    non-trademarked term for ZigZag structure.


    ZigZag for OpenGL.


Function Cell no.

What editor to use 49

Text size in flying windows 311

ZZogl Master list 301

Display list 302

Main dimension list 48

List of slices in memory 225

Current suffix (where next cell goes) 222

HTMLprose 245

Search 290

========== ========== ========= ==========

** The terms "Xanadu(R)" and "ZigZag(R)"are software trademarks of Ted Nelson for both idealistic and commercial purposes.





There are no documents that refer to this sourcedoc.