DOCSLIB.ORG

Mesa Programming Language Manual, Version 5

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Mesa Language Manual Version 5.0 April 1979 Mesa Language Manual by James G. Mitchell William Maybury Richard Sweet Version 5.0 April 1979 CSL-79-3 The Mesa language is one component of a programming system intended for developing and maintaining a wide range of systems and applications programs. Mesa supports the development of systems composed of separate modules with controlled sharing of information among them. The language includes facilities for user-defined data types, strong compile­ time checking of both types and interfaces, procedure and coroutine control mechanisms, and control structures for dealing with concurrency and exceptional conditions. XEROX PALO ALTO RESEARCH CENTER SYSTEMS DEVELOPMENT DEPARTMENT 3333 Coyote Hill Road I Palo Alto I California 94304 © Copyright 1979 by Xerox Corporation CONTENTS CHAPTER 1. INTRODUCTION 1 1.1. Syntax notation 2 CHAPTER 2. BASIC DATA TYPES AND EXPRESSIONS 4 2.1. A slice of Mesa code 4 2.1.1. Basic lexical structure 5 2.2. Simple declarations 6 2.3. The fundamental operations. ~. =. and # 6 2.4. Basic types 7 2.4.1. The numeric types INTEGER and CARDINAL 7 2.4.1.1. Numeric literals 8 2.4.2. Type BOOLEAN 8 2.4.3. Type CHARACTER 9 2.4.4. The numeric types LONG INTEGER and LONG CARDINAL 9 2.4.5. Type REAL 10 2.4.6. Relations among basic types 10 2.5. Expressions 11 2.5.1. Numeric operators 12 2.5.1.1. Domains of the numeric operators 13 2.5.1.2. The operator LONG 14 2.5.1.3. CHARACTER operators 15 2.5.2. Relational operators 15 2.5.3. BOOLEAN operators 16 2.5.4. Assignment expressions 17 2.5.5. Operator precedence 17 2.6. Initializing yariables in declarations 17 2.6.1. Compile-time constants 18 2.7.l\lore general declarations 19 CHAPTER 3. COMMON CONSTRUCTED DATA TYPES 20 3.1. The element types 22 3.1.1. Enumerated types 22 3.1.2. Subrange types 24 3.1.2.1. Subranges of numeric types 26 3.1.2.2. Range assertions 26 3.2. Arrays 27 3.2.1. Declaration of arrays 29 3.2.2. Array constructors 30 3.3. Records 31 3.3.1. Field lists 31 3.3.2. Declaration of records 32 3.3.3. Qualified references 34 3.3.4. Record Constructors 35 3.3.5. Default field values 36 3.3.6. Extractors 38 3.4. Pointers 39 3.4.1. Constructing pointer types 41 3.4.2. Pointer operations 42 3.4.3. Long Pointers 43 3.4.4. Automatic dereferencing 44 3.5. Type determination 45 3.5.1. Type conversion 46 3-.5.2. Balancing 47 3.5.3. Free conformance 48 3.6. Determination of representation 49 CHAPTER 4. ORDINARY STATEMENTS 51 4.1 . .\ssignment statements 51 4.1.1. Assignment expressions 52 4.2. IF statements 52 4.2.1. IF expressions 53 4.3. SELECT statements 54 4.3.1. Forms and options for SELECT 54 4.3.2. The NUL.L statement 56 4.3.3. SELECT expressions 56 4.4. Blocks 57 4.4.1. GOTO statements ·57 4.4.2. OPEN clauses 59 4.5. Loop statements 61 4.5.1. Loop control 62 4.5.2. GOTOS, LOOPS, EXITS, and loops 64 CHAPTERS. P~OCEDURES 67 5.1. Procedure types 69 5.1.1, Procedure values and compatibility 70 5.2. Procedure calls 71 5.2.1. Arguments and parameters 72 5.2.2. Termination and results 72 5.3. Procedure bodies ' 73 5.3.1. RETURN statements 74 5.4. A package of procedures 75 5.4:1. The example· 77 5.4.2. Invoking procedures in other modules 78 5.5. Nested procedures 78 5.5.1. Scopes defined by procedures 79 5.6. Inline procedures 80 CHAPTER 6. STRINGS, ARRAY DESCRIPTORS, RELATIVE POINTERS, 82 . AND VARIANT RECORD.S 6.1. Strings 82 6.1.1. String literals and string expressions 83 ·6.1.2. Declaring strings 84 6.1.3. Long strings 85 6.2. Array descriptors 85 6.2.1. Array descriptor types 85 6.2.2. Long descriptors 87 6.3. Base and relative pointers 88 6.3.1. Syntax for base and relative pointers 88 6.3.2. A relative pointer example 89 6.3.3. Relative pointer types 90 6.3.4. Relative array descriRtors 91 6.4. Yariant records - 92 6.4.1. Declaring variant records 93 6A2. Bound variant types 95 ii 6.4.3. Accessing entire variant parts. and variant constructors 96 6.4.4. Accessing components ohariants 97 CHAPTER 7. MODULES, PROGRAMS, AND CONFIGURATIONS lOl 7.1. Intcrfaces lOl 7.2. The fundamentals of !\lcsa modules lO4 7.2.1. Including modules: the DIRECTORY clause lO5 7.2.1.1. Enumerating items from an included module: the USING clause lO6 7.2.2. Accessing items from an included module lO6 7.2.2.1. Qualification lO6 7.2.2.2. OPEN clauses 107 7.2.3. Scopes for identifiers in a module 108 7.2.4. Implications of recompiling included modules 109 7.3. DEFINITIONS modules 110 7.3.1. Interface variables III 7.3.2. Default fields in interfaces 112 7.3.3. Inline procedures in interfaces 113 7.3.4. Usage hints for inline procedures in interfaces 114 7.4. PROGRAM modules: IMPORTS and EXPORTS 114 7.4.1. IMPORTS, interface types, and interface records 115 7.4.2. Importing program modules 116 7.4.3. Exporting interfaces and program modules 116 7.4.4. IMPORTS in DEFINITIONS modules 116 7.5. Controlling module interfaces: PUBLIC and PRIVATE 117 7.5.1. Access attributes in declarations 117 7.5.1.1. Declared names 118 7.5.1.2. Names specified in field lists 118 7.5.1.3. Names for variant parts and for tags in variant records 118 7.5.2. Access attributes in TYPE definitions 119 7.5.3. Default global access 120 7.5.4. Accessing the PRIVATE predefined symbols of other modules 120 7.6. The Mesa configuration language. an introductory example 120 7.6.1. Lexicon: a module implementing LexiconDefs 121 7.6.2. LexiconClient: a client module 123 7.6.3. Binding, loading, and nmning a configuration: an overview 123 7.6.4. A configuration description for running LexiconClient 124 7.7. C/Mcsa: syntax and semantics 125 7.7.1. IMPORTS, EXPORTS, and DIRECTORY in C/Mesa 126 7.7.2. Explicit naming, IMPORTS, and EXPORTS 126 7.7.3. Default names for interfaces and instances 127 7.7.4. Multiple exported interfaces from a single component 128 7.7.5. Multiple components implementing a single interface 129 7.7.6. Nested (local) configurations 130 7.8. Loading modules and configurations: NEW and START 131 7.8.1. The NEW operation for making copies of modules 131 7.8.2. How the loader binds interfaces 132 7.8.3. STARTing, STOPping. and RESTARTing module instances 132 7.8.4. Loading and starting configurations 133 CHAPTER 8. SIGNALLING AND SIGNAL DATA TYPES 134 8.1. Declaring and generating SIGNALS and ERRORS 134 8.1.1. ERROR in expressions . 136 8.2. Control of generated signals 136 8.2.1. Preparing to catch signals: catch phrases 137 iii 8.2.2. The scope ohariables in catch phrases 138 8.2.3. Catching signals 139 8.2.4. RETRY and CONTINUE in·catch phrases 141 8.2.5. Resuming from a catch phrase: RESUME 141 8.3. Signals within signals 142 CHAPTER 9. PORTSANDCONTROLSTRUCTURES 144 9.1. Syntax and an example of PORTS 145 9.2. Creating and starting coroutines 146 9.2.1. The CONNECT statement 147 9.2.2. Low-level actions for a PORT call 148 9.2.3. Control faults and linkage faults 149 9.2.4. Saving arguments during faults 150 9.3. RESPONDING PORTS 151 CHAPTER 10. PROCESSES AND CONCURRENCY 152 10.1. Concurrent execution. FORK and JOIN 152 10.1.1. A process example 152 10.1.2. Process language constructs 153 10.2. Monitors 154 10.2.1. An overview of monitors 155 10.2.2. Monitor locks 156 10.2.3. Declaring monitor modules, ENTRY and INTERNAL procedures 156 10.2.4. Interfaces to monitors 157 10.2.5. Interactions of processes and monitors 158 10.3. Condition variables 158 10.3.1. Wait, notifY,-and broadcast 158 10.3.2. Timeouts 161 10.4. More about monitors 161 10.4.1. The LOCKS clause 161 10.4.2. Monitored records 162 10.4.3. Monitors and module instances 162 10.4.4. Multi-module monitors 163 10.4.5. Object monitors 165 10.4.6. Explicit declaration of monitor locks 166 10.4.7. Inline ENTRY procedures 166 10.5. Signals 166 10.5.1. Signals and processes 166 10.5.2. Signals and monitors 166 10.6. Initialization 168 APPENDICES A. Pronouncing Mesa 169 B. Programming Conventions 170 B.l. Names 170 B.2. Layout ' 170 B.3. Spaces 171 C. Alto/Mesa Machine Dependencies 172 C.1. Numeric limits 172 C.2. AltoDefs 172 C.3. ASCII character set and ordering of character values 173 C.4. Alto/Mesa STRING procedures 174 iv D. Binder Extensions 175 Dol. Code packing 175 D.Ll. Syntax 175 D.1.2. Restrictions 176 D.2. External links 176 D.2.1. Syntax 176 D.2.2. Restrictions 177 E. Mesa Resen'cd Words 178 F. Collccted Grammar 179 INDEX 185 \' Preface 'Ibis document describes the Mesa programming language, Its approach is tutorial, and it is intended to bc read somewhat as a textbook.
Recommended publications
  • Configuring UNIX-Specific Settings: Creating Symbolic Links : Snap

    Configuring UNIX-Specific Settings: Creating Symbolic Links : Snap

    Configuring UNIX-specific settings: Creating symbolic links Snap Creator Framework NetApp September 23, 2021 This PDF was generated from https://docs.netapp.com/us-en/snap-creator- framework/installation/task_creating_symbolic_links_for_domino_plug_in_on_linux_and_solaris_hosts.ht ml on September 23, 2021. Always check docs.netapp.com for the latest. Table of Contents Configuring UNIX-specific settings: Creating symbolic links . 1 Creating symbolic links for the Domino plug-in on Linux and Solaris hosts. 1 Creating symbolic links for the Domino plug-in on AIX hosts. 2 Configuring UNIX-specific settings: Creating symbolic links If you are going to install the Snap Creator Agent on a UNIX operating system (AIX, Linux, and Solaris), for the IBM Domino plug-in to work properly, three symbolic links (symlinks) must be created to link to Domino’s shared object files. Installation procedures vary slightly depending on the operating system. Refer to the appropriate procedure for your operating system. Domino does not support the HP-UX operating system. Creating symbolic links for the Domino plug-in on Linux and Solaris hosts You need to perform this procedure if you want to create symbolic links for the Domino plug-in on Linux and Solaris hosts. You should not copy and paste commands directly from this document; errors (such as incorrectly transferred characters caused by line breaks and hard returns) might result. Copy and paste the commands into a text editor, verify the commands, and then enter them in the CLI console. The paths provided in the following steps refer to the 32-bit systems; 64-bit systems must create simlinks to /usr/lib64 instead of /usr/lib.
  • Types and Programming Languages by Benjamin C

    Types and Programming Languages by Benjamin C

    < Free Open Study > . .Types and Programming Languages by Benjamin C. Pierce ISBN:0262162091 The MIT Press © 2002 (623 pages) This thorough type-systems reference examines theory, pragmatics, implementation, and more Table of Contents Types and Programming Languages Preface Chapter 1 - Introduction Chapter 2 - Mathematical Preliminaries Part I - Untyped Systems Chapter 3 - Untyped Arithmetic Expressions Chapter 4 - An ML Implementation of Arithmetic Expressions Chapter 5 - The Untyped Lambda-Calculus Chapter 6 - Nameless Representation of Terms Chapter 7 - An ML Implementation of the Lambda-Calculus Part II - Simple Types Chapter 8 - Typed Arithmetic Expressions Chapter 9 - Simply Typed Lambda-Calculus Chapter 10 - An ML Implementation of Simple Types Chapter 11 - Simple Extensions Chapter 12 - Normalization Chapter 13 - References Chapter 14 - Exceptions Part III - Subtyping Chapter 15 - Subtyping Chapter 16 - Metatheory of Subtyping Chapter 17 - An ML Implementation of Subtyping Chapter 18 - Case Study: Imperative Objects Chapter 19 - Case Study: Featherweight Java Part IV - Recursive Types Chapter 20 - Recursive Types Chapter 21 - Metatheory of Recursive Types Part V - Polymorphism Chapter 22 - Type Reconstruction Chapter 23 - Universal Types Chapter 24 - Existential Types Chapter 25 - An ML Implementation of System F Chapter 26 - Bounded Quantification Chapter 27 - Case Study: Imperative Objects, Redux Chapter 28 - Metatheory of Bounded Quantification Part VI - Higher-Order Systems Chapter 29 - Type Operators and Kinding Chapter 30 - Higher-Order Polymorphism Chapter 31 - Higher-Order Subtyping Chapter 32 - Case Study: Purely Functional Objects Part VII - Appendices Appendix A - Solutions to Selected Exercises Appendix B - Notational Conventions References Index List of Figures < Free Open Study > < Free Open Study > Back Cover A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute.
  • Cisco Telepresence ISDN Link API Reference Guide (IL1.1)

    Cisco Telepresence ISDN Link API Reference Guide (IL1.1)

    Cisco TelePresence ISDN Link API Reference Guide Software version IL1.1 FEBRUARY 2013 CIS CO TELEPRESENCE ISDN LINK API REFERENCE guide D14953.02 ISDN Link API Referenec Guide IL1.1, February 2013. Copyright © 2013 Cisco Systems, Inc. All rights reserved. 1 Cisco TelePresence ISDN Link API Reference Guide ToC - HiddenWhat’s in this guide? Table of Contents text The top menu bar and the entries in the Table of Introduction ........................................................................... 4 Description of the xConfiguration commands ......................17 Contents are all hyperlinks, just click on them to go to the topic. About this guide ...................................................................... 5 Description of the xConfiguration commands ...................... 18 User documentation overview.............................................. 5 We recommend you visit our web site regularly for Technical specification ......................................................... 5 Description of the xCommand commands .......................... 44 updated versions of the user documentation. Support and software download .......................................... 5 Description of the xCommand commands ........................... 45 What’s new in this version ...................................................... 6 Go to:http://www.cisco.com/go/isdnlink-docs Description of the xStatus commands ................................ 48 Automatic pairing mode ....................................................... 6 Description of the
  • Technical Data Specifications & Capacities

    Technical Data Specifications & Capacities

    5669 (supersedes 5581)-0114-L9 1 Technical Data Specifications & Capacities Crawler Crane 300 Ton (272.16 metric ton) CAUTION: This material is supplied for reference use only. Operator must refer to in-cab Crane Rating Manual and Operator's Manual to determine allowable crane lifting capacities and assembly and operating procedures. Link‐Belt Cranes 348 HYLAB 5 5669 (supersedes 5581)-0114-L9 348 HYLAB 5 Link‐Belt Cranes 5669 (supersedes 5581)-0114-L9 Table Of Contents Upper Structure ............................................................................ 1 Frame .................................................................................... 1 Engine ................................................................................... 1 Hydraulic System .......................................................................... 1 Load Hoist Drums ......................................................................... 1 Optional Front-Mounted Third Hoist Drum................................................... 2 Boom Hoist Drum .......................................................................... 2 Boom Hoist System ........................................................................ 2 Swing System ............................................................................. 2 Counterweight ............................................................................ 2 Operator's Cab ............................................................................ 2 Rated Capacity Limiter System .............................................................
  • Unix/Linux Command Reference

    Unix/Linux Command Reference

    Unix/Linux Command Reference .com File Commands System Info ls – directory listing date – show the current date and time ls -al – formatted listing with hidden files cal – show this month's calendar cd dir - change directory to dir uptime – show current uptime cd – change to home w – display who is online pwd – show current directory whoami – who you are logged in as mkdir dir – create a directory dir finger user – display information about user rm file – delete file uname -a – show kernel information rm -r dir – delete directory dir cat /proc/cpuinfo – cpu information rm -f file – force remove file cat /proc/meminfo – memory information rm -rf dir – force remove directory dir * man command – show the manual for command cp file1 file2 – copy file1 to file2 df – show disk usage cp -r dir1 dir2 – copy dir1 to dir2; create dir2 if it du – show directory space usage doesn't exist free – show memory and swap usage mv file1 file2 – rename or move file1 to file2 whereis app – show possible locations of app if file2 is an existing directory, moves file1 into which app – show which app will be run by default directory file2 ln -s file link – create symbolic link link to file Compression touch file – create or update file tar cf file.tar files – create a tar named cat > file – places standard input into file file.tar containing files more file – output the contents of file tar xf file.tar – extract the files from file.tar head file – output the first 10 lines of file tar czf file.tar.gz files – create a tar with tail file – output the last 10 lines
  • The Development of Smalltalk Topic Paper #7

    The Development of Smalltalk Topic Paper #7

    The Development of Smalltalk Topic Paper #7 Alex Laird Max Earn Peer CS-3210-01 Reviewer On Time/Format 1 2/4/09 Survey of Programming Languages Correct 5 Spring 2009 Clear 2 Computer Science, (319) 360-8771 Concise 2 [email protected] Grading Rubric Grading Total 10 pts ABSTRACT Dynamically typed languages are easier on the compiler because This paper describes the development of the Smalltalk it has to make fewer passes and the brunt of checking is done on programming language. the syntax of the code. Compilation of Smalltalk is just-in-time compilation, also known Keywords as dynamic translation. It means that upon compilation, Smalltalk code is translated into byte code that is interpreted upon usage and Development, Smalltalk, Programming, Language at that point the interpreter converts the code to machine language and the code is executed. Dynamic translations work very well 1. INTRODUCTION with dynamic typing. Smalltalk, yet another programming language originally developed for educational purposes and now having a much 5. IMPLEMENTATIONS broader horizon, first appeared publically in the computing Smalltalk has been implemented in numerous ways and has been industry in 1980 as a dynamically-typed object-oriented language the influence of many future languages such as Java, Python, based largely on message-passing in Simula and Lisp. Object-C, and Ruby, just to name a few. Athena is a Smalltalk scripting engine for Java. Little Smalltalk 2. EARLY HISTORY was the first interpreter of the programming language to be used Development for Smalltalk started in 1969, but the language outside of the Xerox PARC.
  • The Cedar Programming Environment: a Midterm Report and Examination

    The Cedar Programming Environment: a Midterm Report and Examination

    The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman t CSL-83-11 June 1984 [P83-00012] © Copyright 1984 Xerox Corporation. All rights reserved. CR Categories and Subject Descriptors: D.2_6 [Software Engineering]: Programming environments. Additional Keywords and Phrases: integrated programming environment, experimental programming, display oriented user interface, strongly typed programming language environment, personal computing. t The author's present address is: Sun Microsystems, Inc., 2550 Garcia Avenue, Mountain View, Ca. 94043. The work described here was performed while employed by Xerox Corporation. XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 1 Abstract: This collection of papers comprises a report on Cedar, a state-of-the-art programming system. Cedar combines in a single integrated environment: high-quality graphics, a sophisticated editor and document preparation facility, and a variety of tools for the programmer to use in the construction and debugging of his programs. The Cedar Programming Language is a strongly-typed, compiler-oriented language of the Pascal family. What is especially interesting about the Ce~ar project is that it is one of the few examples where an interactive, experimental programming environment has been built for this kind of language. In the past, such environments have been confined to dynamically typed languages like Lisp and Smalltalk. The first paper, "The Roots of Cedar," describes the conditions in 1978 in the Xerox Palo Alto Research Center's Computer Science Laboratory that led us to embark on the Cedar project and helped to define its objectives and goals.
  • MVC Revival on the Web

    MVC Revival on the Web

    MVC Revival on the Web Janko Mivšek [email protected] @mivsek @aidaweb ESUG 2013 Motivation 30 years of Smalltalk, 30 years of MVC 34 years exa!tly, sin!e "#$# %ot in JavaScri&t MVC frameworks 'or Sin(le)*age and +ealtime web a&&s ,e Smalltalkers s-ould respe!t and revive our &earls better Contents MVC e &lained %istory /sa(e in !.rrent JavaScri&t frameworks /sa(e in Smalltalk C.rrent and f.t.re MVC in 0ida/Web MVC Explained events Ar!hite!tural desi(n &attern - Model for domain s&e!ifi! data and logi! View updates Controller ) View for &resentation to t-e .ser ) Controller for intera!tions wit- t-e .ser UI and .&datin( domain model Domain changes Main benefit: actions observing ) se&aration of !on!erns Model MVC based on Observer pattern subscribe ) 3bserver looks at observee Observer changed - 3bservee is not aware of t-at s u 4e&enden!y me!-anism2 B t n - 3bserver is de&endent on 3bservee state e observing v - 3bservee m.st re&ort state !-an(es to 3bserver E b - *.b/S.b Event 6.s de!ou&les 3bservee from u S / 3bserver to &reserve its .nawarnes of observation b u changed P Observee Main benefit: (Observable) ) se&aration of !on!erns Multiple observers subscribe - M.lti&le observers of t-e same 3bservee Observer changed - 7n MVC an 3bservee is View and 3bservee is domain Model, t-erefore2 s u B t - many views of t-e same model n e observing v - many a&&s E b - many .sers u S / - mix of all t-ree !ases b u Observee changed P (Observable) Example: Counter demo in Aida/Web M.lti.ser realtime web !ounter exam&le -ttp://demo.aidaweb.si – !li!k Realtime on t-e left – !li!k De!rease or In!rease to c-an(e counter – !ounter is c-an(ed on all ot-er8s browsers History of MVC (1) 7nvented by 9rygve +eenska.g w-en -e worked in "#$:1$# wit- Alan ;ay's group on <ero *arc on Smalltalk and Dynabook – 'inal term Model)View)Controller !oined 10.
  • Hitachi Command Suite Dynamic Link Manager (For Windows®) User Guide

    Hitachi Command Suite Dynamic Link Manager (For Windows®) User Guide

    Hitachi Command Suite Dynamic Link Manager (for Windows®) 8.6.4 User Guide This document describes how to use the Hitachi Dynamic Link Manager for Windows. The document is intended for storage administrators who use Hitachi Dynamic Link Manager to operate and manage storage systems. Administrators should have knowledge of Windows and its management functionality, storage system management functionality, cluster software functionality, and volume management software functionality. MK-92DLM129-45 April 2019 © 2014, 2019 Hitachi, Ltd. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including copying and recording, or stored in a database or retrieval system for commercial purposes without the express written permission of Hitachi, Ltd., or Hitachi Vantara Corporation (collectively "Hitachi"). Licensee may make copies of the Materials provided that any such copy is: (i) created as an essential step in utilization of the Software as licensed and is used in no other manner; or (ii) used for archival purposes. Licensee may not make any other copies of the Materials. "Materials" mean text, data, photographs, graphics, audio, video and documents. Hitachi reserves the right to make changes to this Material at any time without notice and assumes no responsibility for its use. The Materials contain the most current information available at the time of publication. Some of the features described in the Materials might not be currently available. Refer to the most recent product announcement for information about feature and product availability, or contact Hitachi Vantara Corporation at https://support.hitachivantara.com/en_us/contact-us.html.
  • Dynamic Object-Oriented Programming with Smalltalk

    Dynamic Object-Oriented Programming with Smalltalk

    Dynamic Object-Oriented Programming with Smalltalk 1. Introduction Prof. O. Nierstrasz Autumn Semester 2009 LECTURE TITLE What is surprising about Smalltalk > Everything is an object > Everything happens by sending messages > All the source code is there all the time > You can't lose code > You can change everything > You can change things without restarting the system > The Debugger is your Friend © Oscar Nierstrasz 2 ST — Introduction Why Smalltalk? > Pure object-oriented language and environment — “Everything is an object” > Origin of many innovations in OO development — RDD, IDE, MVC, XUnit … > Improves on many of its successors — Fully interactive and dynamic © Oscar Nierstrasz 1.3 ST — Introduction What is Smalltalk? > Pure OO language — Single inheritance — Dynamically typed > Language and environment — Guiding principle: “Everything is an Object” — Class browser, debugger, inspector, … — Mature class library and tools > Virtual machine — Objects exist in a persistent image [+ changes] — Incremental compilation © Oscar Nierstrasz 1.4 ST — Introduction Smalltalk vs. C++ vs. Java Smalltalk C++ Java Object model Pure Hybrid Hybrid Garbage collection Automatic Manual Automatic Inheritance Single Multiple Single Types Dynamic Static Static Reflection Fully reflective Introspection Introspection Semaphores, Some libraries Monitors Concurrency Monitors Categories, Namespaces Packages Modules namespaces © Oscar Nierstrasz 1.5 ST — Introduction Smalltalk: a State of Mind > Small and uniform language — Syntax fits on one sheet of paper >
  • UNIX/Linux Server – Red Hat 1

    UNIX/Linux Server – Red Hat 1

    EXEMPTION TEST INFORMATION FORM CIST 2432 – UNIX/Linux Server – Red Hat 1 A currently enrolled or accepted program student may receive course credit by passing the CIST 2432 exemption examination administered by the Gwinnett Technical College Assessment Center. The policy regarding Experiential Credit and Credit by Examination is in the College catalog. The examination must be completed prior to registration for the class for which the student is seeking credit by examination. Students may not request exemption tests for courses in which they have been enrolled nor may they take an exemption test more than once. The CIST 2432 exemption examination will cover these competencies: 1. UNIX/Linux Server Installation Process, Software Packages and Kernel Building 2. Manage Run Levels 3. UNIX/Linux Server Users and Groups 4. UNIX/Linux Server Security Permissions 5. UNIX/Linux Server File System 6. UNIX/Linux Server Memory and Process Management 7. UNIX/Linux Server System Log Files 8. UNIX/Linux Server Boot Process 9. UNIX/Linux Server System Configuration Files 10. UNIX/Linux Server File Backup and Restore 11. UNIX/Linux Server Compression 12. UNIX/Linux Server Fault Tolerance 13. UNIX/Linux Server Printing A student needs to score an 80% or higher on the CIST 2432 exemption examination to receive exemption credit. A student may want to review the below Red Hat textbook before taking the exemption exam: Product Name: Red Hat System Administration I Workbook (Guide) – English. Product Code: RH124-EN-SG-H. The Workbook uses a Product Code instead of an ISBN Number. In order to obtain your student guide, you must access the below link and create a Student account: https://www.gilmore.ca/redhat/registeruser.aspx?fcfca7159e743576c6d3a252fe1dfe1e.
  • As We May Communicate Carson Reynolds Department of Technical Communication University of Washington

    As We May Communicate Carson Reynolds Department of Technical Communication University of Washington

    As We May Communicate Carson Reynolds Department of Technical Communication University of Washington Abstract The purpose of this article is to critique and reshape one of the fundamental paradigms of Human-Computer Interaction: the workspace. This treatise argues that the concept of a workspace—as an interaction metaphor—has certain intrinsic defects. As an alternative, a new interaction model, the communication space is offered in the hope that it will bring user interfaces closer to the ideal of human-computer symbiosis. Keywords: Workspace, Communication Space, Human-Computer Interaction Our computer systems and corresponding interfaces have come quite a long way in recent years. We no longer patiently punch cards or type obscure and unintelligible commands to interact with our computers. However, out current graphical user interfaces, for all of their advantages, still have shortcomings. It is the purpose of this paper to attempt to deduce these flaws by carefully examining our earliest and most basic formulation of what a computer should be: a workspace. The History of the Workspace The modern computerized workspace has its beginning in Vannevar Bush’s landmark article, “As We May Think.” Bush presented the MEMEX: his vision of an ideal workspace for researchers and scholars that was capable of retrieving and managing information. Bush thought that machines capable of manipulating information could transform the way that humans think. What did Bush’s idealized workspace involve? It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On top are slanting translucent screens, on which material can be projected for convenient reading.