DOCSLIB.ORG

The Copyright Law of the United States (Title 17, U.S

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Copyright Law of the United States (Title 17, U.S NOTICE WARNING CONCERNING COPYRIGHT RESTRICTIONS: The copyright law of the United States (title 17, U.S. Code) governs the making of photocopies or other reproductions of copyrighted material. Any copying of this document without permission of its author may be prohibited by law. The Garnet Toolkit Reference Manuals: Support for Highly-Interactive, Graphical User Interfaces in Lisp Brad A. Myers, Dark) Giuse, Roger B. Dannenberg, Brad Vander Zanden, David Kosbie, Philippe Marchal, Ed Pervin, John A. Kolojejchick November 1989 CMU-CS-89-196 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Copyright © 1989 - Carnegie Mellon University This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976, Amendment 20, under contract F33615-87-C-1499, monitored by the Avionics Laboratory, Air Force Wright Aeronautical Laboratories, Aeronautical Systems Division (AFSC), Wright-Patterson AFB, Ohio 45433-6543. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the US Government. Abstract The Garnet User Interface Development Environment contains a comprehensive set of tools that make it significantly easier to design and implement highly-interactive, graphical, direct manipulation user interfaces. Garnet provides a high level of support, while still being Look-and-Feel independent and providing the applications with tremendous flexibility. The Garnet tools are organized into two layers. The toolkit layer provides an object-oriented, constraint-based graphical system that allows properties of graphical objects to be specified in a simple, declarative manner, and then maintained automatically by the system. The dynamic, interactive behavior of the objects can be specified separately by attaching high-level "interactor" objects to the graphics. The higher layer of Garnet includes an interface builder tool, called Lapidary, that allows the user interface designer to draw pictures of all graphical aspects of the user interface. The Garnet toolkit layer software is now available for distribution. It uses Common Lisp and the X window manager, and is therefore portable across a wide variety of platforms. This document contains an overview, tutorial and a full set of reference manuals for the Garnet Toolkit. 1U Overall Table of Contents Overview of the Garnet Toolkit 1 Introduction to the toolkit and overview of this technical report. Comprehensive Support for Graphical, Highly-Interactive User Interfaces: The Garnet User Interface Development Environment 13 Conference paper presenting an overview of the Garnet project. An On-line Tour through Garnet 33 A guided tour and tutorial of some of Garnet's features. KR Reference Manual; Constraint-Based Knowledge Representation 51 The object and constraint system in Garnet. Opal Reference Manual; The Garnet Graphical Object System 85 Support for graphical output. Interactors Reference Manual; Encapsulating Mouse and Keyboard Behaviors 127 Support for input from the user. Aggregadgets and Aggrelists Reference Manual 179 Convenient way to create composite objects. Garnet Gadgets Reference Manual 201 A set of pre-defined interaction techniques. Debugging Tools for Garnet; Reference Manual 223 Tools to help debug Garnet code. Garnet Demos 239 Descriptions of the demonstration programs provide with Garnet. A Sample Garnet Program 247 Code for a simple graphical editor that allows the user to create boxes connected by arrows. Global Index 261 An index to all the names and procedures in the entire Garnet Toolkit. Overview of the Garnet Toolkit Brad A. Myers November 1989 Abstract This article provides an overview of the Garnet Toolkit, and a guide to this technical report. Copyright © 1989 - Carnegie Mellon University This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976, Amendment 20, under contract F33615-87-C-1499, monitored by the Avionics Laboratory, Air Force Wright Aeronautical Laboratories, Aeronautical Systems Division (AFSC), Wright-Patterson AFB, Ohio 45433-6543. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the US Government. Table of Contents 1. Introduction 3 2. Important Features of Garnet 3 3. Coverage 4 4. How to Get Garnet 4 5. Directory Organization 5 6. Site Specific Changes 6 6.1. File names 6 6.2. Fonts 6 6.3. Keyboard Keys 6 7. How to compile Garnet 7 8. How to load Garnet 7 9. Overview of the Parts of Garnet 8 10. Overview of this Technical Report 8 11. What You Need To Know 8 12. Planned Future Extensions 9 Index 11 Section 2 Important Features of Garnet Page 3 L Introduction The Garnet research project in the School of Computer Science at Carnegie Mellon University is creating a comprehensive set of tools which make it significantly easier to create graphical, highly-interactive user interfaces. The lower levels of Garnet are called the *'Garnet Toolkit," and these provide mechanisms that allow programmers to code user interfaces much more easily. The higher level tools allow both programmers and non-programmers to create user interfaces by just drawing pictures of what the interface should look like. Garnet stands for Generating an Amalgam of Real-time, Novel Editors and Toolkits. Preliminary versions of the Garnet Toolkit have been used by a number of CMU and external sites for projects building graphical editors. We have now released the toolkit for general use. This document contains an overview, tutorial, and a full set of reference manuals for the Garnet Toolkit. The higher levels of Garnet will be released in the future. Garnet is written in Common Lisp for the X window manager. Therefore, Garnet is quite portable to various environments. Garnet is running on IBM RTs using CMU Common Lisp, and on Suns using Lucid Common Lisp, versions 2.1 and 3.0. Versions for Allegro Common Lisp, and VAXLisp on VMS VAXStations are planned. Currently, Garnet supports X/l 1 R2 or R3 using the standard CLX interface. Garnet does not use the standard Common Lisp Object System (CLOS) or any X toolkit. 2. Important Features of Garnet Garnet is being designed as part of a research project, so it contains a number of novel and unique features. These are described in the article on page 13. In summary, the important features of Garnet are: • The Garnet Toolkit ic <k signed to support the entire user interface of an application; both the contents of the application window and its menus and dialog boxes. For example, Garnet directly supports selecting graphical objects with the mouse, moving them around, and changing their size. • It is look-and-feel independent. Garnet allows the programmer to define a new graphical style, and use that throughout a system. Alternatively, a pre-defined or standard style can be used, if desired. • It is object-oriented. • It uses a prototype-instance object model instead of the more conventional class-instance model, so that the programmer can create a prototype of a part of the interface, and then create instances of it. If the prototype is changed, then the instances are updated automatically. Therefore, Garnet uses its own, custom object system (called KR), and does not use CLOS. • Constraints are integrated with the object system, so any slot (also called an "instance variable") of any object can contain a formula rather than a value. When a value that the formula references changes, the formula is re-evaluated automatically. Constraints can be used to keep lines attached to boxes, labels centered at the top of rectangles, etc. (see Figure 1). Constraints can also be used to keep application-specific values connected with the values of graphical objects, menus, scroll bars or gauges in the user interface. • Objects are automatically refreshed when they change. Pictures are displayed by creating graphical objects which are retained. If a slot of an object is changed, the system automatically redraws the object and any other objects that overlap it. Also, the system handles window refresh requests from X. Page 4 Garnet Toolkit How to Get Garnet Section 4 • The programmer specifies the handling of input from the user at a high level using abstract interactor objects. Typical user interface behaviors are encapsulated into a few different types of interactors, and the programmer need only supply a few parameters to get objects to respond to the mouse and keyboard in sophisticated ways. • There is built-in support for laying out objects in rows and columns, for example, for menus. • A number of gadgets (also called widgets or interaction techniques) are provided to help the programmer get started. These include menus, buttons, scroll bars, sliders, circular gauges, graphic selection, and arrows. • Garnet is designed to be efficient. Even though Garnet handles many aspects of the interface automatically, an important goal is that it execute quickly and not take too much memory. We are always working to improve the efficiency, but Garnet can currently handle dozens of constraints attached to objects that are being dragged with the mouse on IBM/RTs or Sun 3's. 3. Coverage Garnet is designed to handle interfaces containing a number of graphical objects (up to about 2000) which the user can manipulate with the mouse and keyboard. Garnet does not handle applications with a significant text editing component (except for strings that might be used as labels or fields of a table or dialogue box). Garnet is suitable for applications of the following kinds: • Conventional drawing programs such as Apple Macintosh MacDraw. • Icon manipulation programs like the Macintosh Finder (which allows users to manipulate files). • Box and arrow diagram editors like Apple Macintosh MacProject (which helps with project management). • Graphical Programming Languages where computer programs can be constructed using icons and other pictures (a common example is a flowchart).
Load more

Recommended publications
  • Flexichain: an Editable Sequence and Its Gap-Buffer Implementation
    Flexichain: An editable sequence and its gap-buffer implementation Robert Strandh (LaBRI∗), Matthieu Villeneuve, Tim Moore (LaBRI) 2004-04-05 Abstract Flexichain is an API for editable sequences. Its primary use is in end-user applications that edit sequences of objects such as text editors (characters), word processors (characters, paragraphs, sections, etc), score editors (notes, clusters, measures, etc), though it can also be used as a stack and a double- ended queue. We also describe an efficient implementation of the API in the form of a cir- cular gap buffer. Circularity avoids a common worst case in most implemen- tations, makes queue operations efficient, and makes worst-case performance twice as good as that of ordinary implementations 1 Introduction Editable sequences are useful, in particular in interactive applications such as text editors, word processors, score editors, and more. In such applications, it is highly likely that an editing operation is close to the previous one, measured as the dif- ference in positions in the sequence. This statistical behavior makes it feasible to implement the editable sequence as a gap buffer. The basic idea is to store objects in a vector that is usually longer than the number of elements stored in it. For a sequence of N elements where editing is required at ∗Laboratoire Bordelais de Recherche en Informatique, Bordeaux, France 1 index i, elements 0 through i are stored at the beginning of the vector, and elements i + 1 through N − 1 are stored at the end of the vector. When the vector is longer N, this storage leaves a gap.
    [Show full text]
  • ASDF 3, Or Why Lisp Is Now an Acceptable Scripting Language (Extended Version)
    ASDF 3, or Why Lisp is Now an Acceptable Scripting Language (Extended version) François-René Rideau Google [email protected] Abstract libraries, or network services; one can scale them into large, main- ASDF, the de facto standard build system for Common Lisp, has tainable and modular systems; and one can make those new ser- been vastly improved between 2009 and 2014. These and other im- vices available to other programs via the command-line as well as provements finally bring Common Lisp up to par with "scripting via network protocols, etc. languages" in terms of ease of writing and deploying portable code The last barrier to making that possible was the lack of a that can access and "glue" together functionality from the underly- portable way to build and deploy code so a same script can run ing system or external programs. "Scripts" can thus be written in unmodified for many users on one or many machines using one or Common Lisp, and take advantage of its expressive power, well- many different compilers. This was solved by ASDF 3. defined semantics, and efficient implementations. We describe the ASDF has been the de facto standard build system for portable most salient improvements in ASDF and how they enable previ- CL software since shortly after its release by Dan Barlow in 2002 ously difficult and portably impossible uses of the programming (Barlow 2004). The purpose of a build system is to enable divi- language. We discuss past and future challenges in improving this sion of labor in software development: source code is organized key piece of software infrastructure, and what approaches did or in separately-developed components that depend on other compo- didn’t work in bringing change to the Common Lisp community.
    [Show full text]
  • CS 131 (Eggert) Notes W 1 M Lec 1-10-17 Microsoft Interview Was This
    CS 131 (Eggert) Notes W 1 M Lec 1-10-17 • Microsoft interview was this exact same question! • This is one of the most famous problems in Computer Science • NOT the halting problem or P = NP, but rather a programming language problem • Solved by Donald Knuth, a Turing Award winner • Knuth was a Professor at Stanford, formerly at CalTech. • At CalTech, he decided to write a textbook to write about everything important about computer programming • 1962 and the field was still young! • CS 31 and 32 of the day and the last chapter would be about programming languages • Knuth is a world-class computer science researcher and he is OCD about writing the best possible book • NOT embarrassed to jump into calculus to explain why it runs efficiently. • Published by Addison-Wesley in 1969 (first class academic publisher) • The plates were all created by hand • Knuth wasn’t happy! • The book looked okay but he thought we should be doing something better. • Wrote a tool to help him generate the book. • When a job is NOT done well, you write a program to automate the repeated part. • TEX - source code that the TEX processor reads and generates something that looks nice on the screen. • Knuth found images for a book that were better than the Addison-Wesley ones did by hand Fundamental Algorithms is now done with TEX! • The TEX output is so good that now, CS professionals use TEX! • Word just isn’t good at this. • Knuth being a software engineer as well as an academic wanted to write this TEX program so that he could do his own book but other people could use the program as well.
    [Show full text]
  • 9 European Lisp Symposium
    Proceedings of the 9th European Lisp Symposium AGH University of Science and Technology, Kraków, Poland May 9 – 10, 2016 Irène Durand (ed.) ISBN-13: 978-2-9557474-0-7 Contents Preface v Message from the Programme Chair . vii Message from the Organizing Chair . viii Organization ix Programme Chair . xi Local Chair . xi Programme Committee . xi Organizing Committee . xi Sponsors . xii Invited Contributions xiii Program Proving with Coq – Pierre Castéran .........................1 Julia: to Lisp or Not to Lisp? – Stefan Karpinski .......................1 Lexical Closures and Complexity – Francis Sergeraert ...................2 Session I: Language design3 Refactoring Dynamic Languages Rafael Reia and António Menezes Leitão ..........................5 Type-Checking of Heterogeneous Sequences in Common Lisp Jim E. Newton, Akim Demaille and Didier Verna ..................... 13 A CLOS Protocol for Editor Buffers Robert Strandh ....................................... 21 Session II: Domain Specific Languages 29 Using Lisp Macro-Facilities for Transferable Statistical Tests Kay Hamacher ....................................... 31 A High-Performance Image Processing DSL for Heterogeneous Architectures Kai Selgrad, Alexander Lier, Jan Dörntlein, Oliver Reiche and Marc Stamminger .... 39 Session III: Implementation 47 A modern implementation of the LOOP macro Robert Strandh ....................................... 49 Source-to-Source Compilation via Submodules Tero Hasu and Matthew Flatt ............................... 57 Extending Software Transactional
    [Show full text]
  • A CLOS Protocol for Editor Buffers
    A CLOS Protocol for Editor Buffers Robert Strandh University of Bordeaux 351, Cours de la Libération Talence, France [email protected] ABSTRACT because a data structure with optimal asymptotic worst- Many applications and libraries contain a data structure for case complexity would be considered as having too much storing and editing text. Frequently, this data structure is overhead, both in terms of execution time, and in terms of chosen in a somewhat arbitrary way, without taking into memory requirements. account typical use cases and their consequence to perfor- For a text editor with advanced features such as keyboard mance. In this paper, we present a data structure in the macros, it is crucial to distinguish between two different con- form of a CLOS protocol that addresses these issues. In trol loops: particular, the protocol is divided into an edit protocol and • The innermost loop consists of inserting and deleting an update protocol, designed to be executed at different fre- 1 quencies. The update protocol is based on the concept of individual items in the buffer, and of moving one or time stamps allowing multiple views without any need for more cursors from one position to an adjacent posi- observers or similar techniques for informing the views of tion. changes to the model (i.e., the text buffer). • The outer loop consists of updating the views into the In addition to the protocol definition, we also present two buffer. Each view is typically an interval of less than different implementations of the definition. The main im- a hundred lines of the buffer.
    [Show full text]
  • The Copyright Law of the United States (Title 17, U.S
    NOTICE WARNING CONCERNING COPYRIGHT RESTRICTIONS: The copyright law of the United States (title 17, U.S. Code) governs the making of photocopies or other reproductions of copyrighted material. Any copying of this document without permission of its author may be prohibited by law. Hemlock User's Manual Robert A. MacLachlan BUI Chiles April 1989 CMU-CS-89-133 3 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 This is a revised version of Technical Report CMU-CS-87-158. Abstract This document describes the Hemlock text editor, as of version M3.0. Hemlock is a customizable, extensible text editor whose initial command set closely resembles that of ITS/TOPS-20 Emacs. Hemlock is written in CMU COMMON LISP and has been ported to other implementations. This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976 under contract F33615-87-C-1499 and monitored by the Avionics Laboratory, Air Force Wright Aeronautical Laboratories, Aeronautical Systems Division (AFSC), Wright-Patterson AFB, OHIO 45433-6543. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S. Government. INDEX 1 Table of Contents 1. Introduction 1 1.1. The Point and The Cursor 1 1.2. Notation 1 1.2.1. Characters 1 1.2.2. Commands 2 1.23. Hemlock Variables 2 1.3. Invoking Commands 2 13.1. Key Bindings 3 13.2. Extended Commands 3 1.4.
    [Show full text]
  • The Road to Perspective Are Often Badly Covered, If at All
    Coding with Lisp Coding with Lisp Developing Lisp code on a free software platform is no mean feat, and documentation, though available, is dispersed and comparison to solid, hefty common tools such as gcc, often too concise for users new to Lisp. In the second part of gdb and associated autobuild suite. There’s a lot to get used to here, and the implementation should be an accessible guide to this fl exible language, self-confessed well bonded with an IDE such as GNU Emacs. SLIME is a contemporary solution which really does this job, Lisp newbie Martin Howse assesses practical issues and and we’ll check out some integration issues, and outline further sources of Emacs enlightenment. It’s all implementations under GNU/Linux about identifying best of breed components, outlining solutions to common problems and setting the new user on the right course, so as to promote further growth. And as users do develop, further questions inevitably crop up, questions which online documentation is poorly equipped to handle. Packages and packaging from both a user and developer The Road To perspective are often badly covered, if at all. And whereas, in the world of C, everyday libraries are easy to identify, under Common Lisp this is far from the case. Efforts such as key SBCL (Steel Bank Common Lisp) developer and all round good Lisp guy, Dan Barlow’s cirCLe project, which aimed to neatly package implementation, IDE, documentation, libraries and packagingpackaging ttools,ools, wouldwould ccertainlyertainly mmakeake llifeife eeasierasier forfor tthehe nnewbie,ewbie, bbutut Graphical Common OpenMCL all play well here, with work in Lisp IDEs are a rare unfortunatelyunfortunately progressprogress doesdoes sseemeem ttoo hhaveave slowedslowed onon thisthis ffront.ront.
    [Show full text]
  • CMUCL User's Manual
    CMUCL User’s Manual Robert A. MacLachlan, Editor October 2010 20b CMUCL is a free, high-performance implementation of the Common Lisp programming lan- guage, which runs on most major Unix platforms. It mainly conforms to the ANSI Common Lisp Standard. CMUCL features a sophisticated native-code compiler, a foreign function interface, a graphical source-level debugger, an interface to the X11 Window System, and an Emacs-like edi- tor. Keywords: lisp, Common Lisp, manual, compiler, programming language implementation, pro- gramming environment This manual is based on CMU Technical Report CMU-CS-92-161, edited by Robert A. MacLachlan, dated July 1992. Contents 1 Introduction 1 1.1 Distribution and Support . 1 1.2 Command Line Options . 2 1.3 Credits . 3 2 Design Choices and Extensions 6 2.1 Data Types . 6 2.1.1 Integers . 6 2.1.2 Floats . 6 2.1.3 Extended Floats . 9 2.1.4 Characters . 10 2.1.5 Array Initialization . 10 2.1.6 Hash tables . 10 2.2 Default Interrupts for Lisp . 11 2.3 Implementation-Specific Packages . 12 2.4 Hierarchical Packages . 13 2.4.1 Introduction . 13 2.4.2 Relative Package Names . 13 2.4.3 Compatibility with ANSI Common Lisp . 14 2.5 Package Locks . 15 2.5.1 Rationale . 15 2.5.2 Disabling package locks . 16 2.6 The Editor . 16 2.7 Garbage Collection . 16 2.7.1 GC Parameters . 17 2.7.2 Generational GC . 18 2.7.3 Weak Pointers . 19 2.7.4 Finalization . 19 2.8 Describe . 19 2.9 The Inspector .
    [Show full text]
  • COMMON LISP: a Gentle Introduction to Symbolic Computation COMMON LISP: a Gentle Introduction to Symbolic Computation
    COMMON LISP: A Gentle Introduction to Symbolic Computation COMMON LISP: A Gentle Introduction to Symbolic Computation David S. Touretzky Carnegie Mellon University The Benjamin/Cummings Publishing Company,Inc. Redwood City, California • Fort Collins, Colorado • Menlo Park, California Reading, Massachusetts• New York • Don Mill, Ontario • Workingham, U.K. Amsterdam • Bonn • Sydney • Singapore • Tokyo • Madrid • San Juan Sponsoring Editor: Alan Apt Developmental Editor: Mark McCormick Production Coordinator: John Walker Copy Editor: Steven Sorenson Text and Cover Designer: Michael Rogondino Cover image selected by David S. Touretzky Cover: La Grande Vitesse, sculpture by Alexander Calder Copyright (c) 1990 by Symbolic Technology, Ltd. Published by The Benjamin/Cummings Publishing Company, Inc. This document may be redistributed in hardcopy form only, and only for educational purposes at no charge to the recipient. Redistribution in electronic form, such as on a web page or CD-ROM disk, is prohibited. All other rights are reserved. Any other use of this material is prohibited without the written permission of the copyright holder. The programs presented in this book have been included for their instructional value. They have been tested with care but are not guaranteed for any particular purpose. The publisher does not offer any warranties or representations, nor does it accept any liabilities with respect to the programs. Library of Congress Cataloging-in-Publication Data Touretzky, David S. Common LISP : a gentle introduction to symbolic computation / David S. Touretzky p. cm. Includes index. ISBN 0-8053-0492-4 1. COMMON LISP (Computer program language) I. Title. QA76.73.C28T68 1989 005.13'3±dc20 89-15180 CIP ISBN 0-8053-0492-4 ABCDEFGHIJK - DO - 8932109 The Benjamin/Cummings Publishing Company, Inc.
    [Show full text]
  • LISP As a Rapid Protyping Environment: the Chinese Tutor
    LISP as a Rapid Prototyping Environment: The Chinese Tutor Dario Giuse CMU-RI-TR-87-14 The Robotics Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213 June 1987 Copyright 0 1987 Carnegie Mellon University This research was sponsored by the Defense Advanced Research Projects Agency (DoD), ARPA Order No. 4976, monitored by the Air Force Avionics Laboratory under contract F33615-84-K-1520. The views and conclusions are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S. Gove mment. i Table of Contents 1. Introduction 1 2. The Chinese Tutor 2 2.1 Goals 2 2.2 Functionality 2 2.2.1 Interactive Dictionary 3 2.2.2 Online Documentation 3 2.2.3 Interactive Tutor 4 2.3 Notation 5 3. Implementation 7 3.1 The Tools 7 3.2 Knowledge Representation 7 3.3 The Program 8 3.4 Statistics about the Chinese Tutor 9 3.5 Development Time 10 3.6 Performance 10 4. Discussion 11 5. Future Work 12 5.1 Short-Term Developments 12 5.2 Long-Term Developments 12 iii List of Figures Figure 2-1 : A few entries in the dictionary 3 Figure 2-2: The frame that describes how to indicate pronunciation 4 Figure 2-3: A sample character description 5 Figure 3-1 : Two schemata from the variable portion of the database 8 Abstract Conventional wisdom has maintained that while LISP is suitable for the development of experimental software, it does not support production-quality systems well.
    [Show full text]
  • Emacs, Lisp, and Python Programming Information for Umaine COS 470
    Emacs, Lisp, and Python Programming Information for UMaine COS 470 Roy M. Turner Spring, 2021 (version 2021-01-23) Contents 1 Emacs 3 1.1 What is Emacs, anyway? ................................. 3 1.2 Installing Emacs ...................................... 4 1.3 Using Emacs ........................................ 4 1.3.1 Starting and quitting Emacs ........................... 4 1.3.2 Interrupting Emacs ................................. 5 1.3.3 Learning Emacs basics ............................... 5 1.3.4 Customizing Emacs ................................ 5 1.3.5 Editing Lisp files .................................. 8 1.3.6 Finding and installing Emacs packages ...................... 10 1.3.7 Useful modes and commands ........................... 10 2 Lisp 13 2.1 What is Lisp, anyway? ................................... 13 2.2 Installing Lisp ........................................ 14 2.2.1 Pre-packaged Lisp+Emacs ............................. 15 2.2.2 Installing the Lisp and Emacs separately ..................... 15 2.3 Using Lisp Within Emacs ................................. 16 2.3.1 Starting and quitting Lisp ............................. 16 2.3.2 Editing and evaluating functions ......................... 17 2.3.3 Loading functions into Lisp ............................ 17 2.3.4 I/O in Lisp ..................................... 18 2.3.5 Getting help .................................... 19 2.3.6 Debugging Lisp programs ............................. 20 2.4 Lisp libraries and packages ................................ 21 2.5 Resources
    [Show full text]
  • Flexichain: an Editable Sequence and Its Gap-Buffer Implementation
    Flexichain: An editable sequence and its gap-buffer implementation Robert Strandh (LaBRI∗), Matthieu Villeneuve, Timothy Moore (LaBRI) 2004-04-05 Abstract Flexichain is an API for editable sequences. Its primary use is in end-user applications that edit sequences of objects such as text editors (characters), word processors (characters, paragraphs, sections, etc), score editors (notes, clusters, measures, etc), though it can also be used as a stack and a double- ended queue. We also describe an efficient implementation of the API in the form of a cir- cular gap buffer. Circularity avoids a common worst case in most implemen- tations, makes queue operations efficient, and makes worst-case performance twice as good as that of ordinary implementations 1 Introduction Editable sequences are useful, in particular in interactive applications such as text editors, word processors, score editors, and more. In such applications, it is highly likely that an editing operation is close to the previous one, measured as the dif- ference in positions in the sequence. This statistical behavior makes it feasible to implement the editable sequence as a gap buffer[Fin91]. The basic idea is to store objects in a vector that is usually longer than the number of elements stored in it. For a sequence of N elements where editing is required at ∗Laboratoire Bordelais de Recherche en Informatique, Bordeaux, France 1 index i, elements 0 through i are stored at the beginning of the vector, and elements i + 1 through N − 1 are stored at the end of the vector. When the vector is longer N, this storage leaves a gap.
    [Show full text]