Warm Booting, Netboot

Total Page:16

File Type:pdf, Size:1020Kb

Warm Booting,� Netboot Site Operations IntroductiontoSiteOperationsandAdministration This document provides information for Site Administrators, people who set up ("configure") and maintain sites with one or more Symbolics computers. Typically, theSiteAdministratorisresponsibleforthefollowingtasks: • Installing new releases of Genera software, and any layeredproducts used at the site. • Choosing a network addressing scheme. Each computer needs a unique network address. All Symbolics computers run Chaosnet, and each Symbolics computer needs a Chaosnet address. Some sites also use IP/TCP or DECnet protocols; if so, the computers there need Internet or DECnet addresses as well as Chaosnet addresses. • Choosing a configuration for the site. In a site with more than one computer, you need to decide how to distribute responsibility among them. Most sites des ignate one Symbolics machine as a server; this machine might be a namespace server, file server, and mail server. Users of the other computers store their files on the server, which means you need only do backups on one machine, in stead of on several. If you have a printer, you need to decide which computer will be the print server. Large sites might designate several machines to be servers. • Configuring the software to reflect the site itself. The namespace database de scribes the site and the computers, networks, printers, and users in it. You need tokeepthenamespacedatabasecurrentwiththeconfigurationofyoursite. • Customizing worlds for various purposes. Sometimes it is useful for a site to have different worlds running on Symbolics machines for different purposes. For example, a server machine requires a world with the server software in it. Oth ermachinesrequireworldswithsitespecificcustomizationsandapplications. • Backing up files to tape. As in other computing environments, it is important to establisharegularscheduleforcopyingthecontentsofdiskstotape. • Serving as a liason with Symbolics Customer Service (for example, sending "crash data" mail to Symbolics at CUSTOMERREPORTS@STONY [email protected]). Note: Genera software installation procedures and site configuration information are documented in the Software Installation Guide for each new release of the Genera software. For software installation information about layered products, see thedocumentationthatisshippedwitheachlayeredproduct. Page 422 This document contains reference information about tools and techniques for Site Administrators. Because this is a reference document (and because each site is different), you will not need to master all of the information provided here. Only portionsofthisdocumentwillberelevanttoyou,andtoyoursite’sneeds. Inparticular,thisdocumentincludesthefollowinginformation: BootingtheSymbolicsMachine When you boot the Lisp machine, you bring up a "world". The world is your Lisp environment. A Lisp world can reside either on the local disk of the machine you wish to boot, or on a remote machine (called a net boot server). This section describes cold booting, warm booting, netboot ing,andautobooting. SettingUpandMaintainingtheNamespaceDatabase The Site Administrator sets up and maintains the namespace databaseby registering new hosts, printers, and users, and otherwise updating the namespace database so that it "knows about" any changes to your site’s configuration.This section describes how to edit the namespacedatabase, andthesemanticsoftheinformationstoredinit. Making,Distributing,andUsingWorlds When a new release of Genera is available, the Site Administrator needs to make new worlds for the site to use. The new world must contain both the new Genera software and information about the site itself. This section describes how to make new worlds, and how to distribute them amongcomputersatthesite. TheFrontEndProcessor When you boot a Symbolics computer, you communicate with the Front End Processor (the FEP). This section describes how to use the FEP commands,andgivesotherinformationabouttheFEP. TheLispMachineFileSystem(LMFS) All Symbolics computers use Lisp Machine File System (LMFS) files and directories. This section provides information about utilizing your disk to maximize the space available for LMFS files (by using LMFS partitions). This section also describes the procedures for backing up, dumping, reloading,andretrievingfiles(andsystems)inLMFS. UsingtheTapeFacilities Symbolics supports different tape formats for different purposes. This section describes how to know which format to use for a given purpose, and how to use the tools for writing the contents of a disk to magnetic tape. SymbolicsStoreandForwardMailer The Mailer is a program that provides mail forwarding and delivery ser vices to users at a site. The Mailer is distinct from Zmail, which is a user program for reading and composing mail. The Mailer program runs on a Symbolics machine designated as a mail server. This section de scribes how the Mailer works, and how to perform administrative tasks suchassettingupmailinglists. Page 423 InternetDomainNames The Internet Domain Names system is a collection of specifications and procedures which implement the DOMAIN protocol, which is commonly used on the ARPA Internet. The DOMAIN protocol deals extensively with naming, and it distributes the responsibility of maintaining naming information across a set of administrative bodies. This section describes theSymbolicsimplementationoftheDOMAINprotocol. SymbolicsDialnet Symbolics Dialnet supports the international dial network, meaning that it enables communication over the telephone lines. Dialnet is primarily usedformailtransfer. Note that several other documents contain important related information. We par ticularlyrecommendthefollowingsections: • For an introduction to the anatomy of a Symbolics computer, including the FEP and other parts of the machine, see the section "Workbook: Overview of the Ma chine". • For introductory information on networks, using server machines, and how the namespace database describes the network configuration, see the section "Con ceptsofSymbolicsNetworks". • For reference information on network addressing, see the section "Network Ad dressing". • For information on choosing a network addressing scheme, see the section "ChoosingaNetworkAddressingScheme". BootingtheSymbolicsMachine You give commands to the FEP in order to boot the Symbolics machine. When you boot, you bring up a "world". The world is your Lisp environment. A Lisp world can reside either on the local disk of the machine you wishto boot, or on a remote machine (called a netboot server). FEP commands to boot a world can be entered manually (at the FEP Command: prompt), or executed from within a file (using the BootFEPcommand). BootFileTypes Boot files always have the extension .boot. Three types of boot files exist. Each bootfiletypehasaninitialdefaultfilename(providedbytheFEP): boot.boot This type of file contains commands for booting a specific Lisp world. It’s useful to have several boot files, especially if your site uses various world loads, some of which may have special programsloadedintotheirenvironment. Page 424 Boot files can incorporate either the FEP Netboot command (to netboot from a remote host) or the FEP command Load World (tobootaworldfromthelocaldisk). Note: Always press RETURN at the end of a boot file beforesav ingit. hello.boot This type of file contains commands for both scanning FEP overlay (flod) files, and initializing the local machine’s hard ware tables. More information is available about the FEP over lay(flod)files. • Seethesection"Overlay(Flod)FilesandtheFEP". • Seethesection"ScanningtheOverlay(Flod)Files". autoboot.boot This type of file combines the functions of boot.boot and hello.boot files. It contains commands for scanning the FEP overlay (flod) files, for initializing the hardware tables on the local machine, and for booting a specific Lisp world. See the section"Autobooting". ContentsofHello.BootFilesandBoot.BootFiles This section briefly describes the philosophy of which FEP commands belong in the Hello.boot file and which belong in the Boot.boot file on both 3600family and Ivorybasedmachines. Hello.boot File This file should contain anything that holds constant for this machine, regardless of the world you are running. For example, this includes your flod files, your pag ingfiles,yournetworkaddress,andsoon. First, this file must scan all the flods from which you want to usecommands. This includesthelisp,loaders,info,anddebugflods. Next, the file should include the Initialize Hardware Tables command, so that any errors it encounters will be seen early in the booting process. (This command is completely optional in Ivorybased machines. It is automatically invoked by the Ivory FEP when needed, but errors it signals may be less clear when automatically invoked.) Then, the Hello.boot file should declare any paging files you always want to use; this saves you having to manually Add Paging Files, or to say the same in your boot file. Do not declare any "spare" paging you want to save for an emergency, because Load World automatically uses all declared paging files, and thus the spare paging file would not be available in case of an emergency. It is harmless to declare pagingfiles that do not exist (for example, one you might delete every now and then to make room for Copy World); nonexistent ones give a warning, but are notused. Page 425 Ivory machines only: Starting with Genera 8.1, the hello.boot file for an Ivory machine should contain twolines: HelloInnn HelloLocal(or
Recommended publications
  • Genera Workbook Using This Book Preface This Is the Document To
    Genera Workbook Using This Book Preface This is the document to read when you’re ready to sit down at your Symbol- ics computer. It teaches you the initial skills you need to use the Genera system effectively. We present concepts you need to know, as well as providing exercises andactivitiesthatturnthoseconceptsintopracticalskills. The material covered in the first group of chapters in this workbook is a pre- requisite for all Symbolics Education Services Courses. However, you can com plete the second and third sections after taking your first course. Practicing the material helpsyou learn it faster. Bring this workbook to all courses you take with Symbolics. We expect that you have used a computer before; we do not expect that you have used a Symbolics computer before. You need to learn this material whether or not you are a programmer. This is not a programming textbook. We make no assumptions about your programming background or future; this work bookisforbothprogrammersandnonprogrammers. Every time we use a term for the first time, we put it in italics. If you see a term you don’t recognize, be sure to check the glossary at the end of the work book. This workbook uses Symbolics documentation conventions and a few of its own. If you see a word or phrase enclosed in brackets, like [Help], it is a menu item.We use two different conventions withrespect to Symbolics keyboard keys: in text,thekeylabelledHELPlookslikethis: HELP butinexamplesitlookslikethis: <HELP> todifferentiateitasasinglekeystrokefromthetextaroundit. It is very important to have a Symbolics computer available so that you can work through the hands-on activities, called walk-throughs.
    [Show full text]
  • Getting Started Computing at the Al Lab by Christopher C. Stacy Abstract
    MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLI..IGENCE LABORATORY WORKING PAPER 235 7 September 1982 Getting Started Computing at the Al Lab by Christopher C. Stacy Abstract This document describes the computing facilities at the M.I.T. Artificial Intelligence Laboratory, and explains how to get started using them. It is intended as an orientation document for newcomers to the lab, and will be updated by the author from time to time. A.I. Laboratory Working Papers are produced for internal circulation. and may contain information that is, for example, too preliminary or too detailed for formal publication. It is not intended that they should be considered papers to which reference can be made in the literature. a MASACHUSETS INSTITUTE OF TECHNOLOGY 1982 Getting Started Table of Contents Page i Table of Contents 1. Introduction 1 1.1. Lisp Machines 2 1.2. Timesharing 3 1.3. Other Computers 3 1.3.1. Field Engineering 3 1.3.2. Vision and Robotics 3 1.3.3. Music 4 1,3.4. Altos 4 1.4. Output Peripherals 4 1.5. Other Machines 5 1.6. Terminals 5 2. Networks 7 2.1. The ARPAnet 7 2.2. The Chaosnet 7 2.3. Services 8 2.3.1. TELNET/SUPDUP 8 2.3.2. FTP 8 2.4. Mail 9 2.4.1. Processing Mail 9 2.4.2. Ettiquette 9 2.5. Mailing Lists 10 2.5.1. BBoards 11 2.6. Finger/Inquire 11 2.7. TIPs and TACs 12 2.7.1. ARPAnet TAC 12 2.7.2. Chaosnet TIP 13 3.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Programming Languages As Operating Systems (Or Revenge of the Son of the Lisp Machine)
    Programming Languages as Operating Systems (or Revenge of the Son of the Lisp Machine) Matthew Flatt Robert Bruce Findler Shriram Krishnamurthi Matthias Felleisen Department of Computer Science∗ Rice University Houston, Texas 77005-1892 Abstract reclaim the program’s resources—even though the program and DrScheme share a single virtual machine. The MrEd virtual machine serves both as the implementa- To address this problem, MrEd provides a small set of tion platform for the DrScheme programming environment, new language constructs. These constructs allow a program- and as the underlying Scheme engine for executing expres- running program, such as DrScheme, to run nested programs sions and programs entered into DrScheme’s read-eval-print directly on the MrEd virtual machine without sacrificing loop. We describe the key elements of the MrEd virtual control over the nested programs. As a result, DrScheme machine for building a programming environment, and we can execute a copy of DrScheme that is executing its own step through the implementation of a miniature version of copy of DrScheme (see Figure 1). The inner and middle DrScheme in MrEd. More generally, we show how MrEd de- DrSchemes cannot interfere with the operation of the outer fines a high-level operating system for graphical programs. DrScheme, and the middle DrScheme cannot interfere with the outer DrScheme’s control over the inner DrScheme. 1 MrEd: A Scheme Machine In this paper, we describe the key elements of the MrEd virtual machine, and we step through the implementation The DrScheme programming environment [10] provides stu- of a miniature version of DrScheme in MrEd.
    [Show full text]
  • Performance Comparison of the Window Systems of Two LISP Machines
    A Performance Comparison of the Window Systems of Two LISP Machines Ramin Zabih Raj Jain Massachusetts Institute o fTechnology Digital Equipment Corp. Department ofEE & CS 77 Reed Road (HLO2-3/N03) Cambridge, MA 02139 Hudson, MA 01749 We chose total elapsed time as our performance metric. EXTENDED ABSTRACT Elapsed time is also referred to as response time. We ran 1000 We have constructed a workload for comparing window trials ofour workload on a 3600 running Release 5 software with 1 system performance of different computers. It consists of key Megabyte of physical memory and on a CADR running release 4.5 operations that window systems should universally provide. We software with 386 Kbytes of memory. The results of our tests are have used this workload to measure the performance of a the reported in Table 1. Using the p2 algorithm [2],we also calculated Symbolics ZetaLisp window system on two Lisp Machines, the the fifth and ninety-fifth percentiles for the results. In addition, 3600 [3,4] and the CADR [ 1 ]. we have listed the median and the mean. The workload consists of repeating a sequence of operations Table 1: Time in milliseconds is shown as tl/t2,where t I is time (which we call a run) many times. Each run starts by creating a for 3600, t2 is the time for CADR. test window, and proceeds to perform various operations on the window in the order below. Finally, the test window is deleted. Operation 95_.....% 5% Median Mean The details of the operations performed in an individual run of the CREATE 60/70 10/40 20/50 21.8/48.5 workload follow.
    [Show full text]
  • Symbolics Architecture
    Symbolics Architecture David A. Moon Symbolics, Inc. W hat is an architecture? In com- languages, user interface, and operating This architecture puter systems, an architecture system. System architecture defines the rapid is a specification of an inter- product that people actually use; the other enables face. To be dignified by the name architec- levels of architecture define the mecha- development and ture, an interface should be designed for a nism underneath that implements it. Sys- long lifespan and should connect system tem architecture is implemented by soft- efficient execution of components maintained by different orga- ware; hardware only sets bounds on what large, ambitious nizations. Often an architecture is part ofa is possible. System architecture defines the product definition and defines character- motivation for most of the design choices applications. An istics on which purchasers of that product at the other levels ofarchitecture. This sec- rely, but this is not true of everything that tion is an overview of Symbolics system unconventional design is called an architecture. An architecture is architecture. avoids trading off more formal than an internal interface be- The Symbolics system presents itself to tween closely-related system components, the user through a high-resolution bitmap safety for speed. and has farther-reaching effects on system display. In addition to text and graphics, characteristics and performance. the display contains presentations of ob- A computer system typically contains jects. The user operates on the objects by many levels and types ofarchitecture. This manipulating the presentations with a article discusses three architectures de- mouse. The display includes a continuous- fined in Symbolics computers: ly updated reminder of the mouse com- (1) System architecture-defines how mands applicable to the current context.
    [Show full text]
  • Design of an Ethernet Monitor and Protocol Analyzer Gwenna S
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1990 Design of an Ethernet monitor and protocol analyzer Gwenna S. Jacobson Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Hardware Systems Commons Recommended Citation Jacobson, Gwenna S., "Design of an Ethernet monitor and protocol analyzer" (1990). Retrospective Theses and Dissertations. 16878. https://lib.dr.iastate.edu/rtd/16878 This Thesis is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Design of an Ethernet monitor and protocol analyzer by Gwenna S. Jacobson A Thesis Submitted to the Graduate Faculty in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE Department: Electrical Engineering and Computer Engineering Major: Computer Engineering Signatures have been redacted for privacy Iowa State University Ames, Iowa 1990 11 TABLE OF CONTENTS ACKNOWLEDGEMENTS VIll 1. INTRODUCTION ... 1 2. MONITORING TECHNIQUES 3 2.1 C en t ralized ~Ioni tor 3 2.1.1 Probe Monitor 3 2.1.2 Spy Monitor. 3 2.2 Distributed Monitor 4 2.3 Hybrid l\Ionitor ... 4 3. NETWORK PROTOCOLS .5 3.1 OSlo 5 3.1.1 Physical Layer. 6 3.1.2 Data Link Layer 6 3.1.3 Network Layer 8 3.1.4 Transport Layer. 11 3.1.5 Session Layer .
    [Show full text]
  • The Lisp Machine: Noble Experiment Or Fabulous Failure?
    THE LISP MACHINE: NOBLE EXPERIMENT OR FABULOUS FAILURE? P. T. Withington Symbolics, Inc. The “Lisp Machine”, a custom computer oriented programming, integrated pro- work-station designed specifically for the gramming environments, computer music, execution of Lisp, has been an important integrated-circuit design, and of course part of the Lisp tradition for 20 years. Artificial Intelligence (AI). Recently, the Lisp Machine has been depre- cated in view of the demise of many Lisp But, Lisp’s purity did not come without a Machine vendors, the swing towards stan- price. The choice by many languages to dardization, and the advances that reduced expose implementational limitations is often instruction set (RISC) architectures have a choice of efficiency. The speed of the brought. But rumors of its death are greatly normal case is optimized at the risk of the exaggerated. abnormal case going undetected. Lisp, on the other hand, guarantees the unusual as Unlike most commercial computer lan- well as the usual will be dealt with uni- guages, Lisp has always been a language of formly. It must always be on its guard: ideals. Its roots are in the theory of lambda- every operation must be checked for excep- calculus. Whereas other languages burden tions. As a consequence, Lisp on conven- the programmer with implementational gaps tional machines has historically been pon- in their abstractions, Lisp has always had the derous to work with. aim of supporting complete abstractions.1 This idealistic bent of Lisp has led to it often In the early 1970’s several groups of being the language of choice for computer- researchers utilized two novel hardware oriented research in universities and indus- technologies to improve the efficiency of try.
    [Show full text]
  • Free As in Freedom (2.0): Richard Stallman and the Free Software Revolution
    Free as in Freedom (2.0): Richard Stallman and the Free Software Revolution Sam Williams Second edition revisions by Richard M. Stallman i This is Free as in Freedom 2.0: Richard Stallman and the Free Soft- ware Revolution, a revision of Free as in Freedom: Richard Stallman's Crusade for Free Software. Copyright c 2002, 2010 Sam Williams Copyright c 2010 Richard M. Stallman Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License." Published by the Free Software Foundation 51 Franklin St., Fifth Floor Boston, MA 02110-1335 USA ISBN: 9780983159216 The cover photograph of Richard Stallman is by Peter Hinely. The PDP-10 photograph in Chapter 7 is by Rodney Brooks. The photo- graph of St. IGNUcius in Chapter 8 is by Stian Eikeland. Contents Foreword by Richard M. Stallmanv Preface by Sam Williams vii 1 For Want of a Printer1 2 2001: A Hacker's Odyssey 13 3 A Portrait of the Hacker as a Young Man 25 4 Impeach God 37 5 Puddle of Freedom 59 6 The Emacs Commune 77 7 A Stark Moral Choice 89 8 St. Ignucius 109 9 The GNU General Public License 123 10 GNU/Linux 145 iii iv CONTENTS 11 Open Source 159 12 A Brief Journey through Hacker Hell 175 13 Continuing the Fight 181 Epilogue from Sam Williams: Crushing Loneliness 193 Appendix A { Hack, Hackers, and Hacking 209 Appendix B { GNU Free Documentation License 217 Foreword by Richard M.
    [Show full text]
  • Edition with Romkey, April 16, 1986 (PDF)
    PC/IP User's Guide MASSACHUSETTS INSTITUTE OF TECHNOLOGY Laboratory For Computer Science Network programs based on the DoD Internet Protocol for the mM Personal Computer PC/~ release or March, 1986; document updated Aprill4, 1986 by: Jerome H. Saltzer John L. Romkey .• Copyright 1984, 1985, 1986 by the Massachusetts Institute or Technology Permission to use, copy, modlt'y, and distribute these programs and their documentation ror any purpose and without ree ls hereby granted, provided that this copyright and permission notice appear on all copies and supporting documentation, the name or M.I.T. not be used in advertising or publlclty pertalnlng to dlstrlbutlon or the programs without written prior permission, and notice be glven in supporting documentation that copying and distribution ls by permlsslon or M.I.T. M.I.T. makes no representations about the suitablllty or this software for any purpose. It is provided "as ls" without express or Implied warranty. - ii - CREDITS The PC/IP packages are bullt on the work of many people in the TCP/IP community, both at M.I.T. and elsewhere. Following are some of the people who directly helped in the creation of the packages. Network environment-John L. Romkey Terminal emulator and customizer-David A. Bridgham Inltlal TFTP-Kari D. Wright Inltlal telnet-Louls J. Konopelskl Teinet model-David D. Clark Tasking package-Larry W. Allen Development system-Christopher J. Terman Development environment-Wayne C. Gramlich Administrative Assistant-Muriel Webber October 3, 1985. This document is in cover .mss - iii- - iv Table of Contents 1. Overview of PC/IP network programs 1 1.1.
    [Show full text]
  • A Lisp Oriented Architecture by John W.F
    A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1994 © John W.F. McClain, 1994 The author hereby grants to MIT permission to reproduce and to distribute copies of this thesis document in whole or in part. Signature of Author ...... ;......................... .............. Department of Electrical Engineering and Computer Science August 5th, 1994 Certified by....... ......... ... ...... Th nas F. Knight Jr. Principal Research Scientist 1,,IA £ . Thesis Supervisor Accepted by ....................... 3Frederic R. Morgenthaler Chairman, Depattee, on Graduate Students J 'FROM e ;; "N MfLIT oARIES ..- A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science on August 5th, 1994, in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering Abstract In this thesis I describe LOOP, a new architecture for the efficient execution of pro- grams written in Lisp like languages. LOOP allows Lisp programs to run at high speed without sacrificing safety or ease of programming. LOOP is a 64 bit, long in- struction word architecture with support for generic arithmetic, 64 bit tagged IEEE floats, low cost fine grained read and write barriers, and fast traps. I make estimates for how much these Lisp specific features cost and how much they may speed up the execution of programs written in Lisp.
    [Show full text]
  • CLX — Common LISP X Interface
    CLX Common LISP X Interface 1988, 1989 Texas Instruments Incorporated Permission is granted to any individual or institution to use, copy, modify and distribute this document, provided that this complete copyright and permission notice is maintained, intact, in all copies and supporting documentation. Texas Instruments Incorporated makes no representations about the suitability of this document or the software described herein for any purpose. It is provided ”as is” without express or implied warranty. CLX Programmer’s Reference i ACKNOWLEDGMENTS Primary Interface Author: Robert W. Scheifler MIT Laboratory for Computer Science 545 Technology Square, Room 418 Cambridge, MA 02139 [email protected] Primary Implementation Author: LaMott Oren Texas Instruments PO Box 655474, MS 238 Dallas, TX 75265 [email protected] Design Contributors: Dan Cerys, BBN Scott Fahlman, CMU Kerry Kimbrough, Texas Instruments Chris Lindblad, MIT Rob MacLachlan, CMU Mike McMahon, Symbolics David Moon, Symbolics LaMott Oren, Texas Instruments Daniel Weinreb, Symbolics John Wroclawski, MIT Richard Zippel, Symbolics Documentation Contributors: Keith Cessna, Texas Instruments Kerry Kimbrough, Texas Instruments Mike Myjak LaMott Oren, Texas Instruments Dan Stenger, Texas Instruments The X Window System is a trademark of MIT. UNIX is a trademark of AT&T Bell Laboratories. ULTRIX, ULTRIX–32, ULTRIX–32m, ULTRIX–32w, and VAX/VMS are trademarks of Digital Equipment Corporation. ii CLX Programmer’s Reference CONTENTS Section Title 1 INTRODUCTION TO CLX 2 DISPLAYS 3 SCREENS 4 WINDOWS AND PIXMAPS 5 GRAPHICS CONTEXTS 6 GRAPHIC OPERATIONS 7 IMAGES 8 FONTS AND CHARACTERS 9 COLORS 10 CURSORS 11 ATOMS, PROPERTIES, AND SELECTIONS 12 EVENTS AND INPUT 13 RESOURCES 14 CONTROL FUNCTIONS 15 EXTENSIONS 16 ERRORS A PROTOCOL VS.
    [Show full text]