DOCSLIB.ORG

Morphr – a Morphic GUI in Ruby C I T a M R O F N I F O T N E M T R a P E D E H T T a E C N E I C S R E T U P M

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

DEGREE PROJECT 2004:PM03 s c i t a m e h t a M d n a s MorphR – a Morphic GUI in Ruby c i t a m r o f n I f o t n e m t r a p e D e h t t a e c n e i c S r e t u p m o Kerstin Lyngfelt C f o n o i s i v i D DEGREE PROJECT University of Trollhättan ⋅ Uddevalla Department of Informatics and Mathematics Degree project for master degree in Software engineering MorphR – a Morphic GUI in Ruby Kerstin Lyngfelt Examiner: Lektor Robert Feldt Department of Computer Science Supervisor: Richard Torkar Department of Computer Science Trollhättan, 2004 2004:PM03 i EXAMENSARBETE MorphR – a Morphic GUI in Ruby Kerstin Lyngfelt Sammanfattning Grafiska användargränssnitt har alltid varit en utmaning att bygga för programvaru- utvecklare. Design mönster har utvecklats för att hjälpa till i det arbetet och ett av dessa mönster är Model-View-Controller (MVC). Även om MVC är det mest använda design mönstret vid användargränssnitts utveckling kan MVC anses lite stelt och har vissa begränsningar. Därför har modifierade versioner av MVC använts vid utvecklandet av grafiska ramverk. Vi kommer att titta på både MVC mönstret och på hur bland andra Morphic, Ion och AppKit har designat sina ramverk utifrån MVC. Målet med analysen är att designa och implementera ett modernt, flexibelt vektorbaserat ramverk i Ruby och använda OpenGL som grafikhanterare. Vi kommer också att titta på hur man kan använda teman för att olika grafiska presentationer av en applikation. Utgivare: Högskolan Trollhättan ⋅ Uddevalla, Institutionen för Informatik och Matematik Box 957, 461 29 Trollhättan Tel: 0520-47 50 00 Fax: 0520-47 50 99 Examinator: Lektor Robert Feldt Handledare: Richard Torkar, HTU Huvudämne: Programvaruteknik Språk: Engelska Nivå: Fördjupningsnivå 2 Poäng: 10 Rapportnr: 2004:PM03 Datum: 2004-05-21 Nyckelord: GUI framework, GUI design ii MorphR – A Morphic GUI in Ruby Innehållsförteckning Sammanfattning .............................................................................................................. ii 1. Introduction .................................................................................................................4 2. Background .................................................................................................................5 2.1. Ruby ...........................................................................................................................................................5 2.2. OpenGL ......................................................................................................................................................5 2.3. Themes .......................................................................................................................................................6 2.4. Model-View-Controller ..............................................................................................................................6 2.5. Morphic ......................................................................................................................................................6 2.6. Ion...............................................................................................................................................................7 2.7. Avalon and XAML.....................................................................................................................................7 3. Method ........................................................................................................................8 4. Analysis of GUI design alternatives............................................................................8 4.1. Design of MVC ..........................................................................................................................................8 4.2. Design of Morphic......................................................................................................................................8 4.3. Design of AppKit........................................................................................................................................9 4.4. Design of Ion ..............................................................................................................................................9 5. Design of MorphR.....................................................................................................10 6. Results.......................................................................................................................11 6.1. Design.......................................................................................................................................................11 6.2. Morphs......................................................................................................................................................11 6.3. Timers.......................................................................................................................................................11 6.4. Themes .....................................................................................................................................................11 7. Discussion .................................................................................................................12 8. Future Work ..............................................................................................................12 9. Conclusion.................................................................................................................12 10. Acknowledgements.................................................................................................12 11. References...............................................................................................................12 3 MorphR – A Morphic GUI in Ruby MorphR – A Morphic GUI in Ruby Kerstin Lyngfelt Department of Computer Science University of Trollhättan/Uddevalla [email protected] Abstract Controller (MVC) pattern is one of the most used patterns in GUI frameworks. Building Graphical User Interfaces (GUI) has GUIs have always been hard to implement due to always been a challenge for software engineers. Many the complexity [2] when text and pictures are used patterns have been developed to help software together to present and visualize the application to the engineers in their work, some patterns with longer users. There is also interaction from the users through lifetime than others. One pattern that has been used the mouse and the keyboard that has to be handled by since the late 1970s is the Model-View-Controller the GUI. (MVC). The MVC pattern has limitations and therefore Technology changes rapidly and with no signs of a modifications to the MVC pattern have been made to slow down, Moore’s law [3] is still valid. GUIs can use suit different purposes. In this study, which aims to more powerful technology, have increased capacity and design and implement a modern, flexible, easily contain more functionality than earlier, which creates extendible vector-based GUI for a dynamic increased GUI requirements from the users at the same programming language, both the MVC pattern and pace as the technology development. other design options like Morphic and Ion were Despite all problems, a picture is still better suited analyzed. This paper initially looks at how MVC has to cross language barriers, so there is much gain in been implemented in different GUI frameworks and finding a method that works for its purpose when it furthermore takes the first step in applying said design comes to GUIs. There have been a number of in a flexible implementation in Ruby. It will also look recommendations on how a user interface should be at how to use themes in order to provide different designed and implemented. graphical options of the same application. A GUI is easier to understand if the user is familiar to the look and feel of it [4]. One way to customize a 1. Introduction GUI is to use themes like in e.g. the Linux window manager KDE [5]. Themes are a way to give a united Mankind has been communicating through pictures impression of the components in an application with long before writing existed [1]. A picture does not have coloring and shaping. to be related to language or country, but is international When it comes to handling graphics, different as few other communication forms. Since approaches are to be considered. In this paper focus communication and interaction between countries have has been on a few different types of GUI approaches. increased, due to improved global communications The traditional Model-View-Controller (MVC), a networks, graphics is an important source of design pattern that separates the model from the view information. and control of it [6] is often used as a base while Even though computer applications have been building GUIs. Morphic [7], the graphical framework around for decades, a GUI is still hard to build in an of Squeak [8] uses a slightly different implementation easy and unified way. For instance standards and of the MVC pattern, while Ion implements the MVC recommendations are not suited for every purpose and pattern using OpenGL as back-end. there are almost as many recommendations as there are This paper aims to design and implement a flexible developers. Design patterns are one way to streamline GUI framework, called MorphR, by using the high- software and reuse experience. The Model-View- level programming language Ruby [9] combined with the low-level graphical
Recommended publications
  • A Morphic Based Live Programming Graphical User Interface Implemented in Python

    A Morphic Based Live Programming Graphical User Interface Implemented in Python

    Final Thesis PyMorphic - a Morphic based Live Programming Graphical User Interface implemented in Python by Anders Osterholm¨ LIU-KOGVET-D--06/12--SE 23th August 2006 PyMorphic - a Morphic based Live Programming Graphical User Interface implemented in Python Final Thesis performed at Human Centered Systems division in the Department of Computer and Information Science at Link¨oping University by Anders Osterholm¨ LIU-KOGVET-D--06/12--SE 23th August 2006 Examiner: Dr. Mikael Kindborg Department of Computer and Information Science at Link¨oping University Abstract Programming is a very complex activity that has many simultaneous learn- ing elements. The area of Live-programming offers possibilities for enhanc- ing programming work by speeding up the feedback loop and providing means for reducing the cognitive load on the working memory during the task. This could allow for better education for novice programmers. In this work a number of systems with a shared aim of providing educational tools for scholars from compulsory level to undergraduate college were studied. The common approach in the majority of the tools was to use program ab- stractions like tangible morphs, playing cards, capsules for code segments, and visual stories. For the user these abstractions and tools offer better focus on the constructive and creative side of programming because they relieve the user from the cumbersome work of writing program code, but they also sacrifice some of the expressiveness of a low-level language. A Live programming system, called PyMorphic, based on the Morphic model was built in the Python programming language. Two different so- lutions, based on the Wx toolkit for Python, were constructed and evalu- ated.
  • Ercatons and Organic Programming: Say Good-Bye to Planned Economy

    Ercatons and Organic Programming: Say Good-Bye to Planned Economy

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Dagstuhl Research Online Publication Server Ercatons and Organic Programming: Say Good-Bye to Planned Economy Oliver Imbusch, Falk Langhammer and Guido von Walter Living Pages Research GmbH Kolosseumstrasse 1a, 80469 Munich, Germany {flabes|falk|guido}@livis.com ABSTRACT 1. Motivation Organic programming (OP) is our proposed and already We are going to present an alternative way to develop soft- emerging programming model which overcomes some of ware. We followed this idea starting from some general the limitations of current practice in software development observations all the way down to a reference implementa- in general and of object-oriented programming (OOP) in tion which was then used in projects of sufficient size. This particular. Ercatons provide an implementation of the makes us trust into the initial idea to the point that we may model. In some respects, OP is less than a (new) program- now be obsessed by it. Let us start by sharing some of the ming language, in others, it is more. An “ercato machine” general observations. implements the ideas discussed and has been used to vali- We start with this trivial anecdote. date the concepts described here. “One morning, we noticed some workers tile our office's Organic programming is centered around the concept of a backyard. The day before, piles of square tiles had been true “Thing”. A thing in an executing software system is delivered and the workers now seemed to make good prog- bound to behave the way an autonomous object does in our ress covering the backyard's middle section.
  • Feihong Hsu 217 S

    Feihong Hsu 217 S

    Feihong Hsu 217 S. Leavitt St., #1S Chicago, IL 60612 Cell: 847.219.6000, Home: 312.738.3179 [email protected] www.cs.uic.edu/~fhsu EDUCATION: University of Illinois at Chicago Expected graduation in May 2004 Master of Science in Computer Science GPA: 4.80/5.00 University of Illinois at Urbana-Champaign Graduated December 2000 Bachelor of Science in Mathematics & Computer Science GPA: 3.78/4.00 Courses : Software Engineering, Database Systems, User Interface Design, Computer Networks, Object-Oriented Languages & Environments, Computer Architecture, Numerical Methods, Combinatorial Algorithms, Programming Languages & Compilers, Artificial Intelligence EXPERIENCE: Teaching Assistant , Introduction to Programming , August 2002-December 2003 University of Illinois at Chicago, Computer Science Department http://logos.cs.uic.edu/102 • Teach up to 30 students in weekly lab sections (C/C++/Java). • Develop online material, quizzes, lab assignments. Assist in writing exam problems. • Proposed and implemented new hands-on approach to labs, causing students to become visibly more engaged in the material. • Designed assignment in which students programmed an image manipulation application which included convolution and distortion filters. Teaching Assistant , Computer Literacy , January 2004-Present University of Illinois at Chicago, Computer Science Department http://wiggins.cs.uic.edu/cs100 • Most duties are similar to above. • Propose course topics and determine direction of the course Research Assistant , Team Engineering Collaboratory (TEC) , May 2000-December 2001 University of Illinois at Urbana-Champaign, Speech Communications Department http://www.spcomm.uiuc.edu/Projects/TECLAB/ • Continued development of Blanche, a modeling and simulation environment for the study of social networks. • Managed two undergrad programmers. Maintained project web page and distributions.
  • Nordic ID Morphic User Manual

    Nordic ID Morphic User Manual

    Nordic ID Morphic User Manual Nordic ID International Headquarters Phone: +358 2 727 7700 Myllyojankatu 2A Fax: +358 2 727 7720 FI-24100 SALO Email: [email protected] FINLAND www.nordicid.com Table of Contents 3.3 Stylus and Touch Screen............................ 20 3.3.1 Input Panel: Soft Keyboard ................ 21 (i) A few words of caution..................................... 4 3.4 Rebooting your Nordic ID Morphic ............ 21 3.4.1 Soft-resetting your device................... 21 (ii) Trademarks......................................................... 4 3.4.2 Hard-resetting your device ................. 22 (iii) Safety precautions .......................................... 5 3.5 Registry ......................................................... 22 Laser beam ........................................................... 5 3.6 Non-volatile Storage.................................... 23 Note of caution about the laser beam in 3.7 Control Panel................................................ 23 European languages............................................ 6 3.7.1 Accessing Control Panel..................... 24 3.7.2 Opening Applet .................................... 24 Battery.................................................................... 7 3.7.3 Closing Applet ...................................... 24 Wall charger.......................................................... 8 3.7.4 Closing Control Panel ......................... 24 Medical devices.................................................... 8 3.8 Control Panel Applets
  • Dynamic, Instance-Based, Object-Oriented Programming in Max/Msp Using Open Sound Control Message Delegation

    Dynamic, Instance-Based, Object-Oriented Programming in Max/Msp Using Open Sound Control Message Delegation

    Proceedings of the International Computer Music Conference 2011, University of Huddersfield, UK, 31 July - 5 August 2011 DYNAMIC, INSTANCE-BASED, OBJECT-ORIENTED PROGRAMMING IN MAX/MSP USING OPEN SOUND CONTROL MESSAGE DELEGATION Adrian Freed John MacCallum Andrew Schmeder CNMAT CNMAT CNMAT Dept. of Music Dept. of Music Dept. of Music UC Berkeley, CA 94709 UC Berkeley, CA 94709 UC Berkeley, CA 94709 [email protected] [email protected] [email protected] ABSTRACT oriented programming in Max–presumably because of the hegemony of statically-typed class-based object- A new media programming style is introduced that oriented programming invented in Simula (1962) and brings efficient run-time polymorphism, functional and still active in Objective-C, C++ and Java. instance-based object-oriented programming to Max/MSP and related visual dataflow languages. In 2007 the first author developed a suite of Max/MSP Examples are presented to illustrate new, unusual and patches, called “o.” (pronounced “Oh dot”). These were effective applications of the approach of using OSC specifically designed to exploit generic programming messages for object representations and data flow for (pioneered in Ada in 1980) to simplify and teach gesture method delegation. signal processing in physical computing contexts. This early prototype explored the use of OSC (Sections 2-3 1. INTRODUCTION of this paper), ad-hoc polymorphism and delegation Open Sound Control (OSC) was originally designed as a (Sections 4 and 6) for dynamic class-less object- message-passing format to facilitate exchange of control orientated programming (OOP) based on his experience parameters between programs on different computers developing music programs in prototype-based OOP across a network.
  • Pharo Morphic Application Framework

    Pharo Morphic Application Framework

    Pharo Morphic Application Framework [email protected] Abstract The purpose of this framework is to have a comprehensive Pharo Application hierarchy to easily construct an enterprise ready application, that is scalable and built out as modules that link together. Morphic View Framework: Simplify creating Morphic UI with creating views from Components/ Parts / Modular UI construction: Create multiple pieces of independent views and compose it into one composite application view easily with: • Specs based View Construction • Simple Morphic View • Panels Composition: Complex GUI • API for: View attributes initializations intervention in intermediate steps • SupervisoryController aka MVP Presenter • Locale based translation integrated • LoggerManager to easily plugin Toothpick logger • Configuration based constants from external properties file / defaults code based.. • Named Prototype to optimize space/ time complexities as well as extension to dependency injection • Keyboard Event Handler at view level • Mouse Listener at a view level • Flexible Explicit View Construction Additionally incorporate existing/create standard frameworks, possibly as plugins or independent package, for: • Evolve a UI Builder that is a simple drag n drop capability of widgets • Complete RPC capabilites over XMLRPC for various purposes vis: • a JDBC connector along with an example complimentary Groovy Server backend / Groovy Client code References: 1. Various Smalltalk implementations: MVC architecture leading to the SupervisoryController architecture of MVP. 2. Spring Framework 3. General Enterprise Application Architecture patterns Motivation: Smalltalk is a beautiful and enjoyable language. Morphic is a wonderful but most under exploited UI framework that has immense potential to exponentially grow with contribution from the world of developers. Enterprise developers today are not experts, but casual programmers who depend on existing frameworks, patterns to adapt quickly.
  • Static and Runtime API Usage Analysis on .NET Diplomarbeit

    Static and Runtime API Usage Analysis on .NET Diplomarbeit

    Fachbereich 4: Informatik Static and Runtime API Usage Analysis on .NET Diplomarbeit zur Erlangung des Grades eines Diplom-Informatikers im Studiengang Informatik vorgelegt von Rufus Linke Erstgutachter: Prof. Dr. Ralf Lämmel Institut für Informatik, AG Softwaresprachen Zweitgutachter: Dipl. Math. Ekaterina Pek Institut für Informatik, AG Softwaresprachen Koblenz, im März 2011 IchERKLÄRUNG versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Ja Nein Mit der Einstellung der Arbeit in die Bibliothek bin ich einver- standen. Der Veröffentlichung dieser Arbeit im Internet stimme ich zu. ........................................................................................ (Ort, Datum) (Unterschrift) TheABSTRACT reuse of existing software libraries and frameworks, commonly referenced by their API, has generally been established in modern software development. But as software evolves, so do APIs and thus various reasons for an existing project to migrate from one API to another can occur. To support research on such API migration, this work gathers fundamental API usage data from real world projects. Such data can be helpful to identify the most significant aspects of an API and those that need to be treated cautiously when performing transformations. The present work uses a corpus of 18 manually selected and mature open-source soft- ware projects for this purpose. The analysis methods are driven by both static and dy- namic approaches. A bytecode-based process statically analyzes the structure of a soft- ware to discover its external API feature usages. Then, a dynamic analysis takes advan- tage of instrumentation to collect data about the execution of the static feature references as well as additional information that is only available at runtime like the type of the receiver object of a virtual method call.
  • The Road to Live Programming: Insights from the Practice

    The Road to Live Programming: Insights from the Practice

    The Road to Live Programming: Insights From the Practice Juraj Kubelka Romain Robbes Alexandre Bergel Pleiad @ DCC, University of Chile SwSE @ Free University of Pleiad @ DCC, University of Chile Santiago, Chile Bozen-Bolzano Santiago, Chile Bozen-Bolzano, Italy ABSTRACT with LIVE 2013 being the most popular workshop at ICSE 2013 [5] Live Programming environments allow programmers to get feed- (see Section 2 for background on Live Programming). back instantly while changing software. Liveness is gaining atten- While some see Live Programming as “the future of program- tion among industrial and open-source communities; several IDEs ming”, some of its proponents have more concrete and immediate offer high degrees of liveness. While several studies looked athow issues. Microsoft Research’s Sean McDirmid [6] wrote: “The biggest programmers work during software evolution tasks, none of them challenge instead is live programming’s usefulness: how can its consider live environments. We conduct such a study based on an feedback significantly improve programmer performance?” analysis of 17 programming sessions of practitioners using Pharo, While the full vision of Live Programming is yet to be imple- a mature Live Programming environment. The study is comple- mented and made available at scale to practitioners, many elements mented by a survey and subsequent analysis of 16 programming of it are in use on a daily basis in some developer communities. sessions in additional languages, e.g., JavaScript. We document the In particular, many of the Live Programming concepts have been approaches taken by developers during their work. We find that present for decades in the Smalltalk and Lisp development environ- some liveness features are extensively used, and have an impact on ments; Smalltalk and Lisp feature high degrees of liveness.
  • Programming in Lua, Second Edition by Roberto Ierusalimschy

    Programming in Lua, Second Edition by Roberto Ierusalimschy

    Programming ROBERTO IERUSALIMSCHY in Lua 2nd edition Lua.org Last update: Wed Jan 13 12:07:33 UTC 2010 Programming in Lua Property of Ian Bloss <[email protected]> Property of Ian Bloss <[email protected]> Programming in Lua Second Edition Roberto Ierusalimschy PUC-Rio, Brazil Lua.org Rio de Janeiro Property of Ian Bloss <[email protected]> Programming in Lua, Second Edition by Roberto Ierusalimschy ISBN 85-903798-2-5 Copyright c 2006, 2003 by Roberto Ierusalimschy. All rights reserved. The author can be contacted at [email protected]. Book cover and illustrations by Dimaquina. Lua logo design by Alexandre Nako. Typesetting by the author using LATEX. Although the author used his best efforts preparing this book, he assumes no responsibility for errors or omissions, or for any damage that may result from the use of the information presented here. All product names mentioned in this book are trademarks of their respective owners. CIP – Biblioteca do Departamento de Informatica,´ PUC-Rio Ierusalimschy, Roberto I22 Programming in Lua / Roberto Ierusalimschy. – 2nd ed. – Rio de Janeiro, 2006. xviii, 308 p. : 25 cm. Includes index. ISBN 85-903798-2-5 1. Lua (Programming language). I. Title. 005.133 – dc20 Property of Ian Bloss <[email protected]> to Ida, Noemi, and Ana Lucia Property of Ian Bloss <[email protected]> Property of Ian Bloss <[email protected]> Contents Preface xiii I The Language 1 1 Getting Started 3 1.1 Chunks 4 1.2 Some Lexical Conventions 5 1.3 Global Variables 6 1.4 The Stand-Alone Interpreter 7 2 Types and Values
  • The Self-4.0 User Interface: Manifesting a System-Wide Vision of Concreteness, Uniformity, and Flexibility

    The Self-4.0 User Interface: Manifesting a System-Wide Vision of Concreteness, Uniformity, and Flexibility

    The Self-4.0 User Interface: Manifesting a System-wide Vision of Concreteness, Uniformity, and Flexibility Randall B. Smith, John Maloney†, and David Ungar Sun Microsystems Laboratories 2550 Casey Ave. MTV29-116 Mountain View, CA 94043 [email protected], [email protected], [email protected] Abstract ming systems seem pretty awkward and abstruse by comparison. Manipulating programs is hard, while manipulating Of course it would be a difficult and dubious objects in the physical world is often easy. Several attributes of the physical world help make it compre- effort to literally replicate the physical world in the hensible and manipulable: concreteness, uniformity, computer. But embodying key elements of our physi- and flexibility. The Self programming system cal reality might bring benefits to the computing attempts to apply these attributes to the world within experience. The rise of object-oriented programming the computer. The semantics of the language, the may be viewed as the outcome of an effort to allow efficiency and fidelity of its implementation, and the computers to more directly model physical systems. architecture of its user interface conspire to make the experience of constructing programs in Self immedi- However, even object-oriented programming sys- ate and tangible. We describe the mechanisms used tems don’t really give you anything like that real- to achieve this goal, and illustrate those mechanisms world sense of obvious straightforwardness, that within the context of an extended programming task. sense of immediacy. We believe something more can be found by reexamining the essence of physical sys- tems. I. Introduction Three important characteristics of physical reality that are not truly present in most program- There is a satisfying directness in working ming systems, even object-oriented ones, are con- with physical objects.
  • Comparative Programming Languages CM20253

    Comparative Programming Languages CM20253

    We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily
  • The Evolution of Lua

    The Evolution of Lua

    The Evolution of Lua Roberto Ierusalimschy Luiz Henrique de Figueiredo Waldemar Celes Department of Computer Science, IMPA–Instituto Nacional de Department of Computer Science, PUC-Rio, Rio de Janeiro, Brazil Matematica´ Pura e Aplicada, Brazil PUC-Rio, Rio de Janeiro, Brazil [email protected] [email protected] [email protected] Abstract ing languages offer associative arrays, in no other language We report on the birth and evolution of Lua and discuss how do associative arrays play such a central role. Lua tables it moved from a simple configuration language to a versatile, provide simple and efficient implementations for modules, widely used language that supports extensible semantics, prototype-based objects, class-based objects, records, arrays, anonymous functions, full lexical scoping, proper tail calls, sets, bags, lists, and many other data structures [28]. and coroutines. In this paper, we report on the birth and evolution of Lua. We discuss how Lua moved from a simple configuration Categories and Subject Descriptors K.2 [HISTORY OF language to a powerful (but still simple) language that sup- COMPUTING]: Software; D.3 [PROGRAMMING LAN- ports extensible semantics, anonymous functions, full lexical GUAGES] scoping, proper tail calls, and coroutines. In §2 we give an overview of the main concepts in Lua, which we use in the 1. Introduction other sections to discuss how Lua has evolved. In §3 we re- late the prehistory of Lua, that is, the setting that led to its Lua is a scripting language born in 1993 at PUC-Rio, the creation. In §4 we relate how Lua was born, what its original Pontifical Catholic University of Rio de Janeiro in Brazil.