Service Manuals, User Guides, Schematic Diagrams or docs for : xerox xde XDEPaper
<< Back | HomeMost service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.
Image preview - the first page of the document
>> Download XDEPaper documenatation <<
Text preview - extract from the document
The Mesa Programming Environment
Richard E. Sweet
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
1. Introduction 2. History and Philosophy
People everywhere are developing multi-window, Much of the early history and design motivation
integrated programming environments for their favorite behind the Mesa language project was reported in Early
computers and languages. This paper describes the Mesa Experience with Mesa [Geschke77]. This section deals
programming facilities of the Xerox Development with the history and design goals of the programmer's
Environment (XDE). It is interesting for several reasons. environment that grew up around the language. This
It has existed in something similar to its current form for paper principally concerns the facilities on individual
about 5 years. It has more than 500 users, many programmers' workstations, although a good bit of their
interacting with it 8 or more hours a day. Several million power comes from being part of a larger network
lines of code have been written by these users, including environment. In addition to the workstations, this
large, multi-author systems. network contains a number of server machines. Some
Previous papers have dealt with the Mesa language servers are used for central storage of files, some for
[Geschke77, Mitchell79], the operating system [Redell79, printing, some for communications with the outside
Lampson80] and the processor architecture on which it world, and some provide small specialized services. The
runs [Johnsson82, Sweet82]. This paper describes the individual workstation, nonetheless, provides the majority
programming environment: the user illusion, the set of of a programmer's computing power.
programming tools, and the facilities available for
augmenting the environment. Section 2 gives a short 2.1 Chronology
history of the environment, including some of our
original design goals. Section 3 describes the current Mesa was first implemented on the Alto [Thacker79]
state of the user interface and discusses a few of the in 1976. The development environment was the Alto
schemes that were tried and discarded. Section 4 operating system [Lampson79] whose user interface was
describes some of the program development tools the Executive, a BCPL program that operated much like
available and discusses how features of the language have the time-sharing executives of the day. When one
influenced their design, and indeed influenced what tools invoked a tool, such as the compiler, it ran in the entire
are in the set. Section 5 describes other tools that, machine (along with pieces of the operating system), and
although valuable to the programming task, are largely when it was finished, the Executive was reloaded to
language independent. Section 6 talks about how easy process the next command. There were provisions for
it is to make additions to the system, and gives examples chaining together commands by means of disk files with
of user additions-some that modify the environment distinguished names.
and some that simply provide new tools. Section 7 The Mesa debugger was patterned after the BCPL
discusses what we feel are major successes and what we debugger to the extent that it used the same world swap
feel needs to be done in the future. principle. When the debugger was invoked, the contents
of memory were written to a disk file, the client outload
file, and then memory was loaded from another file, the
debugger outload file. The net result was that you were
Permission to copy without fee all or part of this material is granted now running inside the debugger and could examine and
provided that the copies are not made or distributed for direct modify the client world by reading and writing the client
commercial advantage, the ACM copyright notice and the title of the outload file. The debugger had the ability to set
publication and its date appear, and notice is given that copying is by breakpoints and to display program data in a format
permission of the Association for Computing Machinery. To copy determined by the type of the data. It had a crude ability
otherwise, or to republish, requires a fee and/or specific permission.
to call procedures in the client code. The debugger had
multiple windows patterned after those of Smalltalk
[Kay76]. One, a typescript window, was used for
◦ Jabse Service Manual Search 2024 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo