DOCSLIB.ORG

Scripting Browsers with Glamour

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Scripting Browsers with Glamour Scripting Browsers with Glamour Masterarbeit der Philosophisch-naturwissenschaftlichen Fakultät der Universität Bern vorgelegt von Philipp Bunge April 2009 Leiter der Arbeit Prof. Dr. Oscar Nierstrasz Dr. Tudor Gîrba Lukas Renggli Institut für Informatik und angewandte Mathematik glam·our /'glæmər/ noun the attractive and exciting quality that makes a person, a job or a place seem special, often beacause of wealth or status. [Hornby, 2000] Copyright © 2009 by Philipp Bunge is thesis is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. See http://creativecommons.org/licenses/by-sa/3.0/ for more informa- tion. Figures 4.1(a), 4.2(a) and 4.3(a) are screenshots of products copyrighted by Microsoft, Apple and omas Leonard et al. respectively. e rst two were created by myself, the latter was retrieved under free license from: http://en.wikipedia.org/wiki/File: ROX-Filer.png Abstract Browsers are a crucial instrument to understand complex systems or models. Each problem domain is accompanied by an abundance of browsers that are created to help analyze and interpret the underlying elements. e issue with these browsers is that they are frequently rewritten from scratch, making them expensive to create and burdensome to maintain. While many frameworks exist to ease the development of user interfaces in general, they provide only limited support to simplifying the creation of browsers. In this thesis we present a dedicated model to describe browsers that equally emphasizes the control of navigation ow within the browser. Our approach is designed to support arbitrary domain models allowing researchers to quickly dene new browsers for their data. To validate our model we have implemented the framework Glamour which additionally offers a declarative language to simplify the denition of browsers. We have used Glamour to re-implement several existing browsers and to explore the creation of new browsers. v vi Acknowledgements First and foremost I thank Tudor Gîrba without whom this thesis would not have been possible. His unalterable condence, resolute support, and seemingly persistent aspiration have managed what they tried to achieve—that I am proud of the work I present in this thesis. Doru, you did much more than “just your job.” In equal measure, I wish to thank Lukas Renggli for his pervading support, both technical and general. Your door was always open to me when I had a question and I have learned a great amount from you. My sincerest gratitude goes to Prof. Oscar Nierstrasz. I must thank him not only—like many have done before me—for permitting me to write my thesis at the Software Com- position Group, but much more for the dedication and care he committed to me and my work, to the lectures he holds and to all of his students in general. It is this disposition that nurtured my motivation and interest for the eld of computer science from the rst lecture I had with him. My appreciation extends to the entire SCG (regardlessly of whether you supported me or encouraged me by questioning my work) and to my professors, tutors and colleagues from whom I have learned so much in the past years. I am deeply indebted to my friends. You know who you are and I would do you no justice by attempting to enumerate all of you. Without you I would not have studied, would not have nished, and—most importantly—would not have had such an incredibly enjoyable time doing either. To my parents, my sister, Rahel and my entire family, both here and abroad—I have no words that could express my appreciation for the love and unconditional support you have given me. Not only in my studies, but as long as I have known you. ank you. vii viii Contents 1. Introduction 1 1.1. A Historical Introduction to Browsers ................... 1 1.2. Challenges .................................. 4 1.3. Our Approach ................................ 5 1.4. Contributions ................................ 6 2. Tutorial on Glamour 7 2.1. Running example .............................. 7 2.2. Starting the Browser ............................ 8 2.3. Using Transmissions ............................ 8 2.4. Another Presentation ............................ 10 2.5. Multiple Origins .............................. 12 2.6. Ports ..................................... 13 2.7. Reusing Browsers .............................. 14 2.8. Actions ................................... 16 2.9. Multiple Presentations ........................... 17 2.10. Other Browsers ............................... 18 2.11. Tutorial Conclusion ............................. 19 3. Inside Glamour 21 3.1. Browsers, Panes and Transmissions ..................... 23 3.2. Presentations ................................ 25 3.3. Actions ................................... 26 3.4. Composition ................................ 26 3.5. Browser Implementations .......................... 28 3.6. Rendering .................................. 28 3.7. Smalltalk Implementation ......................... 29 3.8. Model Implementations .......................... 32 4. Constructing Common Browsers 33 4.1. Filesystem Navigation ............................ 33 4.2. Source Code Navigation .......................... 38 4.3. Software Dependency-Analysis ....................... 42 5. Related Work 47 5.1. Exposing Domain Objects ......................... 47 ix Contents 5.2. Software Composition ........................... 53 6. Conclusions 55 6.1. Our Goals Revisited ............................ 55 6.2. Flow based Browsers vs. Side-Effect based Browsers ........... 56 6.3. Declarative Scripting Language ....................... 57 6.4. Browser Notation .............................. 57 6.5. Future Work ................................. 58 6.6. Concluding Remarks ............................ 59 A. Installation 61 A.1. Glamour for VisualWorks Smalltalk .................... 61 A.2. Glamour for Pharo ............................. 62 B. Browser Notation 65 List of Figures 69 Bibliography 71 x Chapter 1 Introduction Browsers are important tools to understanding complex systems or models. Browsers allow us to interact with a system, to inspect its elements and to learn its structure. What distin- guishes browsers from other user interfaces is the structure of the underlying data and how it is mapped to the visual representation shown to the user. e models behind browsers can be seen as graphs. e nodes represent the entities that are apparent in the browser and the edges the relationships between these. In the case of a lesystem manager for example, the les and folders are the nodes of the browser and their hierarchical relationship—which can be queried using a set of messages on the objects—gives us the edges. What is interesting is that there is a variety of methods that can be used to represent a model in a user interface. Some browsers may decide to show a tree like structure, where nodes can be expanded and collapsed. Other browsers may show just one folder at a time, allowing the user to descend into subfolders and return to parent folders. Yet other browsers may use other methods to allow the user to interact with the objects. We dene methods by the navigation ow that they impose in a browser. Which navigation ow is most appropriate for a browser is specic to the application—certain browsers may favor specic types of interaction and different use-cases for the same model may require distinct navigational ows. 1.1. A Historical Introduction to Browsers When object-oriented systems were rst conceived, objects were thought of as self-contained processes, encapsulating all their required state as well as their behavior in single entity [Dahl and Nygaard, 1966]. In Smalltalk-76, this concept not only applied to the behavior of objects in solitude and their interaction in a larger system, but also in their responsibility to represent themselves to the user. In 1978, Daniel H. H. Ingalls described this as “the reactive principal,” stating that 1 Chapter 1. Introduction the salient feature of Smalltalk is that all objects are active, ready to perform in full capacity at any time. Nothing of this aliveness should be lost at the interface to the human user of the system. In other words, all components of the system must be able to present themselves to the user in an effective way, and must moreover present a set of simple tools for their meaningful alteration. [Ingalls, 1978] is concept related to the apparent disposition of “objects” in nature. An animal, plant or inert item simply represents itself, visually or otherwise, and does not require the interpre- tation of its inner processes by an outer entity to do so. is restriction however, proved too limiting for visually presenting the same objects within different scenarios or contexts. While working as a visiting scientist at the Xerox Palo Alto Research Center between 1978 and 1979, Trygve Reenskaug wished to use Smalltalk-76 as the basis for a system for production control in shipbuilding [Reenskaug, 1996a]. He needed to represent the production schedule in multiple ways—depending on its intended usage—and found the generic representation of the objects to be insufficient. As a result, he tore each of the original objects apart, separating the original into three objects: an object responsible for the information, one for presenting the information, and one for capturing input from the user viewing the information in order to manipulate it accordingly. is work would later be integrated into Smalltalk-80 [Goldberg and Robson, 1989] and become widely known as the Model-View-Controller (MVC)
Load more

Recommended publications
  • Naked Objects: a Technique for Designing More Expressive Systems
    Naked objects: a technique for designing more expressive systems Richard Pawson Robert Matthews Computer Sciences Corporation NakedObjects.org and Computer Science Department, Tdnity College, Dublin, IE rpawson@csc;com ABSTRACT OOUIs provide a number of advantages to the user including Naked objects is an approach to systems design in which core reduced modality [6], and greater expressiveness for the user business objects show directly through to the user interface, and [10], and have become the norm for 'creative' applications such in which all interaction consists of invoking methods on those as drawing, computer aided design (CAD), page make-up and objects in the noun-verb style. One advantage of this approach multimedia editing. OOUIs are far less common in transactional is that it reaults in systems that arc more expressive from the business systems. This may be because the need for viewpoint of the user: they treat the user like a problem solver, expressiveness is less clear. It may also be because the not as merely a process-follower. Another advantage is that the underlying structure of most transactional business applications, 1:1 mapping between the user's representation and the comprising scripted procedures and data operations, does not underlying model means that it is possible to auto-generate the map well onto an OOUI. former from the latter, which yields benefits to the development Surprisingly, though, even where a transactional business process. The authors have designed a Java-based, open source system is based upon a true business object model, the core toolkit called Naked Objects which facilitates this style of business objects are typically hidden from the user.
    [Show full text]
  • Design Patterns Design Patterns
    Design Patterns CSC207 – Software Design Design Patterns • Design pattern: – A general description of the solution to a well- established problem using an arrangement of classes and objects. • Patterns describe the shape of code rather than the details. – There are lots of them in CSC 301 and 302. Loop patterns from first year • Loop pattern: – A general description of an algorithm for processing items in a collection. • All of you (hopefully) have some loop patterns in your heads. • You don’t really need to think about these any more; you just use them, and you should be able to discuss them with your fellow students. • Some first-year patterns: – Process List – Counted Loop – Accumulator – Sentinel Process list pattern • Purpose: to process every item in a collection where you don’t care about order or context; you don’t need to remember previous items. • Outline: • Example: • Other example: darken every pixel in a picture Counted loop pattern • Purpose: to process a range of indices in a collection. • Outline: • Example: • Other example: print indices of even-length string Accumulator pattern • Purpose: to accumulate information about items in a collection. • Outline: • Example: • Other examples: sum, min, accumulate a list of items meeting a particular criterion. Sentinel pattern • Purpose: to remove a condition in a loop guard. • Outline: • Example: Sentinel pattern, continued • Here is the code that Sentinal replaces; note that i != list.size() is evaluated every time through the loop, even though it is false only once. Design Pattern
    [Show full text]
  • Presentación De Powerpoint
    Software Architecture of Oviedoof University Modularity Science Computer of of Course 2018/2019 Jose E. Labra Gayo School Software Software School of Computer Science University of Oviedo Modularity Architecture Software Architecture of Oviedoof University Big Ball of Mud Modular decomposition Definitions Recommendations Modularity styles Layers Aspect Oriented decomposition Domain based decomposition Science Computer of of School Software Architecture Big Ball of Mud of Oviedoof Big Ball of Mud University Described by Foote & Yoder, 1997 Elements Lots of entities intertwined Constraints None Science Computer of of School Software Architecture Big Ball of Mud of Oviedoof Quality attributes (?) University Time-to-market Quick start It is possible to start without defining an architecture Incremental piecemeal methodology Solve problems on demand Cost Cheap solution for short-term projects Science Computer of of School Software Architecture Big Ball of Mud of Oviedoof Problems University High Maintenance costs Low flexibility at some given point At the beginning, it can be very flexible After some time, a change can be dramatic Inertia When the system becomes a Big Ball of Mud it is very difficult to convert it to another thing A few prestigious developers know where to touch Science Clean developers run away from these systems Computer of of School Software Architecture Big Ball of Mud of Oviedoof Some reasons University Throwaway code: You need an immediate fix for a small problem, a quick prototype or proof of concept When it is good
    [Show full text]
  • 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 >
    [Show full text]
  • Nested Class Modularity in Squeak/Smalltalk
    Springer, Nested Class Modularity in Squeak/Smalltalk Nested Class Modularity in Squeak/Smalltalk Modularität mit geschachtelten Klassen in Squeak/Smalltalk by Matthias Springer A thesis submitted to the Hasso Plattner Institute at the University of Potsdam, Germany in partial fulfillment of the requirements for the degree of Master of Science in ITSystems Engineering Supervisor Prof. Dr. Robert Hirschfeld Software Architecture Group Hasso Plattner Institute University of Potsdam, Germany August 17, 2015 Abstract We present the concept, the implementation, and an evaluation of Matriona, a module system for and written in Squeak/Smalltalk. Matriona is inspired by Newspeak and based on class nesting: classes are members of other classes, similarly to class instance variables. Top-level classes (modules) are globals and nested classes can be accessed using message sends to the corresponding enclosing class. Class nesting effec- tively establishes a global and hierarchical namespace, and allows for modular decomposition, resulting in better understandability, if applied properly. Classes can be parameterized, allowing for external configuration of classes, a form of dependency management. Furthermore, parameterized classes go hand in hand with mixin modularity. Mixins are a form of inter-class code reuse and based on single inheritance. We show how Matriona can be used to solve the problem of duplicate classes in different modules, to provide a versioning and dependency management mech- anism, and to improve understandability through hierarchical decomposition. v Zusammenfassung Diese Arbeit beschreibt das Konzept, die Implementierung und die Evaluierung von Matriona, einem Modulsystem für und entwickelt in Squeak/Smalltalk. Ma- triona ist an Newspeak angelehnt und basiert auf geschachtelten Klassen: Klassen, die, wie zum Beispiel auch klassenseitige Instanzvariablen, zu anderen Klassen gehören.
    [Show full text]
  • Reflection in Smalltalk
    Louvain School of Engineering (EPL) rev. 2012-07-03 Computing Science Engineering Department (INGI) . Reflection and Context-Oriented Programming (R+COP)with 2nd practical session ANSWERS Reflection in Smalltalk .This. session is a hopefully gentle introduction to Smalltalk’s meta-object protocol. You can use the tools of the Smalltalk environment to find answers to all questions. In particular: • Use the System Browser to navigate through classes, their methods and their hierarchies. The class browser also gives you valuable information on the overriding of methods and you can use the right-click menu on any method to explore senders and implementors of any messages used inside the method body. • Use the Finder tool to search for methods implementing a particular message. • Use the Inspector for individual objects, and evaluate expressions in the context of the inspected object. • Select an expression in any browser and use the right-click menu to browse all implementors or senders of the method. This session starts the exploration of reflection in Smalltalk by considering class instantiation, class inheritance, and the interaction between these two concepts. The second part of the session focuses on structural and behavioural reflection. Smalltalk Kernel: Instantiation Relationship 1. What is the class of 1984? Which message can you send to obtain the class of an object? Apply this message to 1984 and inspect the result. Inside the inspector, what do you conclude from evaluating and printing the result of self inside the lower-right text pane? The message that retrieves the class of an instance is class. If you inspect the result of 1984 class, you will obtain an inspector window with a SmallInteger class as window title and self bound to SmallInteger, as you can check by printing self.
    [Show full text]
  • A Project to Model-Driven Development with Naked Objects and Domain-Driven Design
    Elihu: A Project to Model-Driven Development with Naked Objects and Domain-Driven Design Samuel Alves Soares1 and Mariela Ines´ Cortes´ 2 1Federal Institute of Education, Science and Technology of Ceara,´ Taua,´ Ceara,´ Brazil 2State University of Ceara,´ Fortaleza, Ceara,´ Brazil Keywords: Model Driven Development, Naked Objects, Domain Driven Design, Domain Patterns, Design Patterns. Abstract: The model-driven development is a approach to creating software through well-defined models containing the information needed to generate the application. However, the software modeling in this approach requires the definition of application infrastructure artifacts in the model, such as user interface technologies and data persistence scheme, in order to transform modeling in final application. This makes the modeling complex, difficult to understand and maintain since new artifacts need to be added, failing to keep the focus on application business domain. To resolve this problem, we propose the Elihu project, a solution based on Naked Objects Pattern, Domain-Driven Design and software design patterns where the developer models just business objects and their characteristics related to the application domain. The full application is generated based on these software patterns and a Naked Objects Pattern framework is responsible for the application infrastructure code and the display of objects to users. The proposed solution benefits the creation of less complex models, that support evolution and modification of requirements along the development and the generation of full applications without manual intervention in the generated code. 1 INTRODUCTION 2006). On the other hand, the ambiguous nature of models and information redundancy along different The focus on the problem domain is pointed views of the same object make it difficult to maintain out as the ideal approach to the development of and make it difficult to adopt the MDD in the industry computer systems (Pawson, 2004).
    [Show full text]
  • Xcode Chapter.Indd
    Chapter 1 Xcode Many computer books use Chapter 1 to cover introductory material. Xcode Tools Sensei is not one of those books. I want you to start learning immediately. After reading this chapter you’ll know how to create a project, add files to your project, edit source code, model data, read developer documentation, configure the compiler, and build your project into a working Mac OS X program. Creating a Project Every program you write with Xcode requires a project, no matter how small the program is. An Xcode project contains your program’s source code files and other files Xcode needs to build a working program, such as Interface Builder nib files. To create an Xcode project, choose File > New Project, and the Project Assistant window opens. Xcode has the following project categories: n Action n Application n Audio Units n Bundle n Command-Line Utility n Dynamic Library n External Build System n Framework n J2EE n Java n Kernel Extension n Standard Apple Plug-Ins n Static Library I will go into greater detail on the types of projects shortly, but most of you will be making application projects. After choosing the type of project you want to make, click the Next button. Tell Xcode the name of your project and where you want to store it, then click the Finish button. Congratulations! You’ve created an Xcode project. What Xcode includes in a project depends on the type of project you create. Xcode includes the following files for a Cocoa application: n An Objective C source code file, main.m.
    [Show full text]
  • Pawson Thesis.Pdf
    Naked objects A thesis submitted to the University of Dublin, Trinity College for the degree of Doctor of Philosophy Richard Pawson, Department of Computer Science, Trinity College, Dublin June 2004 1 Foreword by Trygve Reenskaug (Author’s note: Prof. Reenskaug was the external examiner for this thesis. One of the pioneers of object-oriented programming, he is best known as the inventor of the Model- View-Controller pattern. After the thesis was accepted, he generously agreed to write a foreword to the electronically-published version.) The world’s shipbuilding industry went through a heavy modernization program through the nineteen fifties and sixties. My colleague Kjell Kveim invented a control unit for the numerical control of machine tools such as flame cutters. The first unit was installed at the Stord shipyard in 1960 and opened the field for integrated computer aided design and manufacturing. The matching design system, Autokon, was first deployed at the Stord Yard in 1963. Autokon was subsequently adopted by most major shipyards around the world and was still in use by the late nineties. The purpose of Autokon was to empower the ship’s designers. It had a central database holding important information about the shape of the hull, the position of frames and decks, and the shapes of the parts. There was a language that permitted the designers to specify parts in shipbuilding terminology. There was a designer programming facility so that they could specify families of similar parts. Autokon was developed in close collaboration between shipbuilders and scientists. We considered ourselves as tool builders; the success criterion was that the tools should be handy, practicable, serviceable and useful.
    [Show full text]
  • Pharo by Example
    Portland State University PDXScholar Computer Science Faculty Publications and Computer Science Presentations 2009 Pharo by Example Andrew P. Black Portland State University, [email protected] Stéphane Ducasse Oscar Nierstrasz University of Berne Damien Pollet University of Lille Damien Cassou See next page for additional authors Let us know how access to this document benefits ouy . Follow this and additional works at: http://pdxscholar.library.pdx.edu/compsci_fac Citation Details Black, Andrew, et al. Pharo by example. 2009. This Book is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. For more information, please contact [email protected]. Authors Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker This book is available at PDXScholar: http://pdxscholar.library.pdx.edu/compsci_fac/108 Pharo by Example Andrew P. Black Stéphane Ducasse Oscar Nierstrasz Damien Pollet with Damien Cassou and Marcus Denker Version of 2009-10-28 ii This book is available as a free download from http://PharoByExample.org. Copyright © 2007, 2008, 2009 by Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz and Damien Pollet. The contents of this book are protected under Creative Commons Attribution-ShareAlike 3.0 Unported license. You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).
    [Show full text]
  • Domain-Driven Design Using Naked Objects
    Extracted from: Domain-Driven Design Using Naked Objects This PDF file contains pages extracted from Domain-Driven Design, published by the Pragmatic Bookshelf. For more information or to purchase a paperback or PDF copy, please visit http://www.pragprog.com. Note: This extract contains some colored text (particularly in code listing). This is available only in online versions of the books. The printed versions are black and white. Pagination might vary between the online and printer versions; the content is otherwise identical. Copyright © 2009 The Pragmatic Programmers, LLC. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Many of the designations used by manufacturers and sellers to distinguish their prod- ucts are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragprog.com Copyright © 2009 Dan Haywood.
    [Show full text]
  • Slidedeck Moderne Kommandozeilen Werkzeuge @ GPN18
    Moderne Kommandozeilen Werkzeuge Version 1.3 JETZT MIT NOCH MEHR TOOLS !!!11elf11!!! #GPN18 @LEYRER Alles, was zum Zeitpunkt unserer Geburt bereits vorhanden war, wird als Bestandteil der natürlichen Ordnung empfunden. Alles, was in der Zeit zwischen dem fünfzehnten und fünfunddreißigsten Lebensjahr erfunden wurde, ist aufregend, revolutionär und fördert vielleicht sogar die eigene Karriere. Alles, was nach unserem 35. Geburtstag erfunden wurde, verstößt gegen die natürliche Ordnung der Welt und wird abgelehnt. “I've come up with a set of rules that describe our reactions to technologies: 1.Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2.Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3.Anything invented after you're thirty-five is against the natural order of things.” Douglas Adams, The Salmon of Doubt Plan Historie / Abgrenzung HTTPie / jq systemd aria2c dig icdiff / colordiff tracepath / mtr / oping ripgrep / fd / z iproute2 exa tmux fzf zsh pv / progress ranger Eure Vorschläge The UNIX philosophy Doug McIlroy, Bell System Technical Journal 1978 http://emulator.pdp-11.org.ru/misc/1978.07_- _Bell_System_Technical_Journal.pdf The UNIX philosophy Erstelle Programme so, dass sie eine Aufgabe richtig erfüllen. Wenn es eine neue Aufgabe gibt, beginne ein neues Programm anstatt das andere zu verkomplizieren. The UNIX philosophy Gehe davon aus, dass die Ausgaben eines Programms die Eingabe eines anderen sein können, selbst wenn Du dieses noch nicht kennst.
    [Show full text]