NLS / Augment Volunteer Assistance (I5)
Are you interested in getting involved with the NLS-Augment Restoration project? If so, there are plenty of different areas in which we currently need help. This page describes some of the technical tasks that we are looking for volunteers to assist us with. (HA)
Compile klh10 on gcc 4.x (HB)
For the most part, klh10 is working admirably well. However, unfortunately klh10 does not compile on current versions of gcc (4.x). It does compile on older versions of gcc (3.4.x), but recent Linux distributions are shipping with the newer version of gcc which presents a problem for people who don't have gcc 3.4.x installed. The goal of this task is to get klh10 to compile properly on a Linux/gcc 4.x environment. (HC)
Owner (I7)
Status (I8)
In progress (HE)
Summary (I9)
klh10 now compiles on gcc 4.1.1 on linux, with a patch that Alex has supplied. GCC has a built-in logf function which was causing trouble. The logf function can be disabled with "-fno-builtin-logf". There also appears to be a bug in gcc 4.x with ternary code generation. Alex is investigating. (HF)
Details (IA)
The patch contains the following changes: (I6)
- stdlib.h needs to be included if exit() is used since the implicit declaration doesn't match exit's real one. (HI)
- You can't use logf as a variable name since there is an internal logf() function. (HK)
- There is something going on with the ternary conditional operator in an assignment that results in requesting the address of the register variable, which won't work. Can be worked around with an if/else, but I'll see if I can find out more about this. (HM)
NLS on vanilla TOPS-20 (HN)
We want to make NLS available to the public in the form of a CD or downloadable tar.gz. In order to do this properly, we need to separate the concerns of TOPS-20 (owned by DEC) and NLS/Augment ("orphan work"). The goal of this task is to see if it is possible to build and run NLS on a vanilla TOPS-20 distribution. Panda is a good choice to start with because we can get help from Mark Crispin when we hit stumbling blocks. (HO)
Owner (IB)
Status (IC)
Summary (ID)
Details (IE)
Compile NLS from Source Code (HT)
The NLS source code is available within NLS, because it is fully self-hosting. We don't have directions on how to re-compile NLS from source however. This task involves working with RaylenePak to interview her for obtaining directions from her memory and verifying that we can do it. (HU)
Owner (IF)
Status (IG)
Summary (IH)
Details (II)
TOPS-20/klh10 "freezing" problem (HZ)
The klh10 emulator itself is not freezing, because the klh10 command parser and the klh10 escape character works. However, when I leave TOPS-20/klh10 running for days, the TOPS-20 system itself seems to hang or freeze, both in the console and with remote clients. I've been wondering if this is some problem with klh10 losing the execution context somehow, but it's a hard problem to track down. The goal of this task is determine the problem and fix it so that we can keep NLS running for long periods of time. Note that Doug Engelbart himself *does* have NLS running continually (using klh10) for months/years with no problems, so the problem may be either with the particular version of klh10 or else with the Linux port (Doug runs on a an old sparc). (I0)
Owner (IJ)
Status (IK)
Summary (IL)
Details (IM)
L10 Compiler on modern-day platform (K5)
Introduction (MI)
NLS was written in a language called L10. L10 was invented at SRI for the purpose of writing NLS. The only L10 implementation that we know about runs on a TOPS-20/PDP10 architecture. We currently are able to run NLS only by running an entire set of TOPS-20 disk images within a PDP10 emulator. While this is quite useful for preserving the exact environment in which later versions of NLS (and even later versions of Augment) can run, it does have some limitations. (MJ)
Benefits of L10 on a modern platform (MK)
There are a number of limitations that we have with NLS being able to run only on a TOPS-20 system. In contrast, there are a number of benefits that NLS would obtain if L10 were available on a modern platform. In particular: (ML)
- Learning curve for NLS users. Currently, someone trying to use NLS must tackle a learning curve for both NLS and TOPS-20. It would be nice if NLS were able to run directly on a modern operating system (Linux, Windows, Mac OS X etc). (MM)
- Emulator limitations. The best emulator we have for PDP10 is an emulator named klh10, written by Ken Harrenstien. While this emulator is an excellent piece of software and was quite an achievement in its own right, there are some limitations that affect how NLS can currently be used. One key limitation involves how network connections work in klh10 on Linux. Network connections from a client to the NLS system must currently go through an external network interface. Loopback does not work on Linux, and trying to send the connection from a client on the same machine through the external network interface does not work on Linux. This presents quite a problem for demoing NLS on a single laptop. Our current workaround is to either a) use two laptops or b) install NLS and klh10 into a VMWare image and connect to the VMWare image from another VMWare image (or from the host OS). (MN)
- Size of installation. The current version of NLS (which use TOPS-20 images) require ~3GB of disk space in order to run. That doesn't include the VMware image itself, which can push the total size up even higher. While that size fits on a DVD, it is too large to fit on a single CD. Also, the download bandwidth rate for many people is still too slow to download a file of that size in a reasonable period of time. (MO)
- Interoperatibility between L10 and other languages (C, Java, Perl, etc). Having an L10 compiler on a modern OS would allow the ability to create language bindings between L10 and modern languages. This would open up all kinds of interesting possibilities. (MP)
- Interoperability between NLS and other applications/systems. Being able to embed NLS into modern applications, or have NLS be able to control modern apps and systems is a very enticing idea. (MQ)
Objective of L10 Project (MR)
The primary objective of this project is to find a way to make L10 source code compile and execute on a modern platform (Linux for starters). A number of approachs to reach this objective exist, for example: (K6)
- Compile L10 into native code on Linux (K7)
- Compile L10 into Java byte code (K8)
- Transform L10 into C/Python/Ruby source code (K9)
- Write L10 bootstrapper code which can compile just enough L10 code for the original L10 compiler (written in L10) to compile itself (KA)
High-Level Tasks (MS)
- We have obtained a copy of what appears to be the source code of the L10 compiler (written in L10 itself). We need to completely understand what this code does, how it works, and what external dependencies it relies on. (password available on request). (MT)
- Read through the documentation of L10, which includes the original L10 Manual, Extensions to the L10 language, and the L10 Primitives doc. (password available on request) (MU)
- Write L10 bootstrapper program. (MV)
- Write abstraction layer which implements any platform-specific L10 code (calls to subsystem, file manipulation, user interaction, etc.) (MW)
- Use L10 bootstrapper to compile L10 compiler. (MX)
- Test L10 compiler with abstraction layer on NLS source code. (MY)