Smalltalk Solutions 2008 Report, ESUG 2008 Report, VAS Report

Total Page:16

File Type:pdf, Size:1020Kb

Smalltalk Solutions 2008 Report, ESUG 2008 Report, VAS Report Smalltalk Conferences between June and September 2008 1 Smalltalk Conferences between June and September 2008 This document contains my reports of • the Smalltalk Solutions conference in Reno June 18 - 21, 2008 • the ESUG conference in Amsterdam, August 25 - 29, 2008 (and brief info of the Camp Smalltalk 23rd - 24th and Seaside Sprint 29th - 31st) • the VASmalltalk User Group conference in Frankfurt, September 23, 2008 I have combined my three conference reports into a single document. They follow in the order in which conferences occurred. An initial section ‘Shared Keynotes’ gives two talks that were given at both ESUG and Smalltalk Solutions. Style ‘I’ or ‘my’ refers to Niall Ross; speakers (other than myself) are referred to by name or in the third person. A question asked in or after a talk is prefixed by ‘Q.’ (sometimes I name the questioner; often I was too busy noting their question). A question not beginning with ‘Q.’ is a rhetorical question asked by the speaker (or is just my way of summarising their meaning). Author’s Disclaimer and Acknowledgements These reports give my personal view. No view of any other person or organisation with which I am connected is expressed or implied. The talk descriptions were typed while I was trying to keep up with and understand what the speakers were saying, so may contain errors of fact or clarity. I apologise for any inaccuracies, and to any participants whose names or affiliations I failed to note down. If anyone spots errors or omissions, email me and corrections may be made. My thanks to the conference organisers and the speakers whose work gave me something to report. Shared Keynotes Gilad’s talk on Newspeak and Georg’s talk on Bach were given at both Smalltalk Solutions and ESUG. A single write-up combining material and questions from both conferences tells the story better than two write-ups. How to find the Bach house in Cöthen, Georg Heeg (This combines the talks Georg gave at Smalltalk Solutions and at ESUG. Questions asked and answers given at either venue are included. Strictly, Georg’s talk was not billed as a keynote in either conference, but it presents Smalltalk in a context of much wider interest, so I think it is worth highlighting here.) Dinosaur bones have been found in Cöthen, and evidence of stone age occupation. More recently it was the capital of the independent state of Anhalt in Germany; there are city records going back 900 years. It was also the location of the second largest ESUG (in 2004, eclipsed only by this year in Amsterdam). 2 Shared Keynotes Johan Sebastian Bach worked for 7 years in Cöthen, during which time he wrote ‘The Well-Tempered Clavier’ among many other works: Georg played us an excerpt from the 10th piece. Prince Leopold of Anhalt was the reason Bach lived in Cöthen for many years. (Unlike those princes who just had parties every day and spent all their money) he was very musical, invited Bach to the city, founded societies for the study of the German language and so on. Even during his lifetime, Bach began to lose popularity and only 100 years later did the superb quality of his music begin to be recognised. Thus there are many open questions about his life, including where he lived in Cöthen. Today the city wants to improve its tourist trade by finding all it can about Bach’s time there. Their first question was, ‘Where did he live?’ They got EU funding for a suitably long-winded title (Feasibility study for ....) and asked for bidders; Georg Heeg won. The bidding started in 23 March 2006; Georg Heeg completed the task on 15th February of this year. They did it in 4 phases as an agile project. They knew from the start that if they used the same approach as all the historians had tried - looking for a piece of paper with an address on it - they would fail: if such a paper existed, it would have been found. Instead, they intended to use exclusion as their proof method (c.f. the computer proof of the four-colour problem). Phase 1 was drill down to brainstorm and identify key issues. Phase 2 was locating, scanning and OCRing all the old material they could find in archives, libraries, old bookshops, eBay. 736 documents in gothic, latin and handwriting fonts were scanned. For example, they copied all the city property records for 100 years. Phase 3 built the semantic network. There were two existing semantic network products written in Smalltalk. K- Infinity (see my ESUG reports in 2001 and 2002) is used by the police, publishers, etc. It had no interface to word. Atlas TI is an analysis tool for non-numeric data, but is not extensible (it easily could be but the company only sell the packaged software). Neither of these could be fitted exactly to their problem without some work. They therefore created a specific semantic network solution GHBachNets. It provided direct connections between the automatic procedures and the human decisions. The UI was a web browser, using Seaside on VW and GemStone. Two phone calls to Monty improved performance from hours to seconds. The coder and researcher worked closely so UI ideas were implemented quickly. The first thing they discovered was that the 18th century public treasurer was either a fraudster or very bad at arithmetic; they suspect the former but cannot pursue it as he’s been dead for over 2 centuries. They also found lots of simple writing errors. To do the searching, they went back to Thorsten’s JavaSpektrum tree implementation, porting it from VW to GemStone. They soon realised that a semantic network concept of an idea or a Notion (Begriff in German) was naturally a class so they made it a subclass of ClassDescription (at first of Behavior but they found they needed the Shared Keynotes 3 subclass’ abilities as well). Thus Notion (Begriff) is a sister class to Class and Metaclass (only Smalltalk can do this!). Special Notions are Values and Relations between two or more Notions. GemStone does not allow this extension of its metaclass so they had a mapping from a description of a network to the real network in VW. Next they needed TemporalObjects. “Bach lived in this house” is not useful information without knowing from when to when he lived there. They created a time framework that could handle vague and precise dates and historical ways of dating. For hundreds of years, tax registers showed who owned a house and how much they had paid (but not where the house was located). They had old maps to locate things and they had a princely homage accession record which was a few years too early, but useful because it lists who rented as well as who owned. Thus they had a tax register of householders in 1710, and in 1765, and of those houses with the right to brew beer (most useful data - and doubtless a much-prized right at the time, too :-). He showed one page of the thick one-per-year book of which they handled 100 years-worth of books. Georg showed some of this information in an Excel table for a single home: house built in 1738, first tax record in 1741, relationships, graphics, etc. All this was imported from Excel via COM connect (the VW7.6. implementation was driven by this project’s needs). Cöthen was in the postal system. Bach wrote from Cöthen to the city of Erfurt (120 miles, which cost 2 groschen which was about 10 dollars in those days); Georg showed a copy of the letter. As was typical for that time, it listed the title, profession and position of recipient and sender in great detail, but not the street address let alone a house number. Half of the houses in Cöthen were owned by the Prince and rented; the rest were owned mostly by their residents. They swiftly concluded that Bach neither owned a house nor rented from the Prince; those records are complete. The oldest city map dates from 1730, seven years after Bach left (and conveniently is oriented north, not always the case in those days). By comparing with Google earth, you can see that streets today are very similar to what they were then. A second map of 1778 also showed little change and was easier to work with. While Bach lived in Cöthen, the city was enlarged and its walls rebuilt to enclose a larger area. They started to build the new city wall on 24th February 1719. We know that Bach must have had a spacious home. He had a big family and students lived with him, and he needed four big waggons for his goods when he moved (this useful fact is recorded in a humble newspaper of the time). They looked at all the houses that had been proposed. They also looked for any other homes that could fit. The first candidate (Burgstasse 11) was built in 1721 (too late) and was too small (luckily, as it has now been knocked down and is a space between two very modern houses). The second was simply too small. A third one, Holzmark 12, is mentioned in a list of 1855 with the names Bach and Erhardt. However it had six or seven families living in several apartments 4 Shared Keynotes within it - not at all ideal for music practice all the time. Stifstrasse 11 has a sign ‘probable Bach home’ and famous historians have backed the claim but it is not so; the project systematically proved their arguments were wrong, and were a classic case of historians quoting each other so that an ‘astonishing’ document found by one such historian was in fact already well known and not persuasive.
Recommended publications
  • Application-Level Virtual Memory for Object-Oriented Systems Mariano Martinez Peck
    Application-Level Virtual Memory for Object-Oriented Systems Mariano Martinez Peck To cite this version: Mariano Martinez Peck. Application-Level Virtual Memory for Object-Oriented Systems. Program- ming Languages [cs.PL]. Université des Sciences et Technologie de Lille - Lille I, 2012. English. tel-00764991 HAL Id: tel-00764991 https://tel.archives-ouvertes.fr/tel-00764991 Submitted on 26 Dec 2012 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. N° d’ordre : 40886 THESE présentée en vue d’obtenir le grade de DOCTEUR en Spécialité : informatique par Mariano MARTINEZ PECK DOCTORAT DELIVRE CONJOINTEMENT PAR MINES DOUAI ET L’UNIVERSITE DE LILLE 1 Titre de la thèse : Application-Level Virtual Memory for Object-Oriented Systems Soutenue le 29/10/2012 à 10h devant le jury d’examen : Président Jean-Bernard STEFANI (Directeur de recherche – INRIA Grenoble- Rhône-Alpes) Directeur de thèse Stéphane DUCASSE (Directeur de recherche – INRIA Lille) Rapporteur Robert HIRSCHFELD (Professeur – Hasso-Plattner-Institut, Universität Potsdam, Allemagne) Rapporteur Christophe DONY (Professeur – Université Montpellier 2) Examinateur Roel WUYTS (Professeur – IMEC & Katholieke Universiteit Leuven, Belgique) co-Encadrant Noury BOURAQADI (Maître-Assistant – Mines de Douai) co-Encadrant Marcus DENKER (Chargé de recherche – INRIA Lille) co-Encadrant Luc FABRESSE (Maître-Assistant – Mines de Douai) Laboratoire(s) d’accueil : Dépt.
    [Show full text]
  • Liste Von Programmiersprachen
    www.sf-ag.com Liste von Programmiersprachen A (1) A (21) AMOS BASIC (2) A# (22) AMPL (3) A+ (23) Angel Script (4) ABAP (24) ANSYS Parametric Design Language (5) Action (25) APL (6) Action Script (26) App Inventor (7) Action Oberon (27) Applied Type System (8) ACUCOBOL (28) Apple Script (9) Ada (29) Arden-Syntax (10) ADbasic (30) ARLA (11) Adenine (31) ASIC (12) Agilent VEE (32) Atlas Transformatikon Language (13) AIMMS (33) Autocoder (14) Aldor (34) Auto Hotkey (15) Alef (35) Autolt (16) Aleph (36) AutoLISP (17) ALGOL (ALGOL 60, ALGOL W, ALGOL 68) (37) Automatically Programmed Tools (APT) (18) Alice (38) Avenue (19) AML (39) awk (awk, gawk, mawk, nawk) (20) Amiga BASIC B (1) B (9) Bean Shell (2) B-0 (10) Befunge (3) BANCStar (11) Beta (Programmiersprache) (4) BASIC, siehe auch Liste der BASIC-Dialekte (12) BLISS (Programmiersprache) (5) Basic Calculator (13) Blitz Basic (6) Batch (14) Boo (7) Bash (15) Brainfuck, Branfuck2D (8) Basic Combined Programming Language (BCPL) Stichworte: Hochsprachenliste Letzte Änderung: 27.07.2016 / TS C:\Users\Goose\Downloads\Softwareentwicklung\Hochsprachenliste.doc Seite 1 von 7 www.sf-ag.com C (1) C (20) Cluster (2) C++ (21) Co-array Fortran (3) C-- (22) COBOL (4) C# (23) Cobra (5) C/AL (24) Coffee Script (6) Caml, siehe Objective CAML (25) COMAL (7) Ceylon (26) Cω (8) C for graphics (27) COMIT (9) Chef (28) Common Lisp (10) CHILL (29) Component Pascal (11) Chuck (Programmiersprache) (30) Comskee (12) CL (31) CONZEPT 16 (13) Clarion (32) CPL (14) Clean (33) CURL (15) Clipper (34) Curry (16) CLIPS (35)
    [Show full text]
  • THE FUTURE of SCREENS from James Stanton a Little Bit About Me
    THE FUTURE OF SCREENS From james stanton A little bit about me. Hi I am James (Mckenzie) Stanton Thinker / Designer / Engineer / Director / Executive / Artist / Human / Practitioner / Gardner / Builder / and much more... Born in Essex, United Kingdom and survived a few hair raising moments and learnt digital from the ground up. Ok enough of the pleasantries I have been working in the design field since 1999 from the Falmouth School of Art and onwards to the RCA, and many companies. Ok. less about me and more about what I have seen… Today we are going to cover - SCREENS CONCEPTS - DIGITAL TRANSFORMATION - WHY ASSETS LIBRARIES - CODE LIBRARIES - COST EFFECTIVE SOLUTION FOR IMPLEMENTATION I know, I know, I know. That's all good and well, but what does this all mean to a company like mine? We are about to see a massive change in consumer behavior so let's get ready. DIGITAL TRANSFORMATION AS A USP Getting this correct will change your company forever. DIGITAL TRANSFORMATION USP-01 Digital transformation (DT) – the use of technology to radically improve performance or reach of enterprises – is becoming a hot topic for companies across the globe. VERY DIGITAL CHANGING NOT VERY DIGITAL DIGITAL TRANSFORMATION USP-02 Companies face common pressures from customers, employees and competitors to begin or speed up their digital transformation. However they are transforming at different paces with different results. VERY DIGITAL CHANGING NOT VERY DIGITAL DIGITAL TRANSFORMATION USP-03 Successful digital transformation comes not from implementing new technologies but from transforming your organisation to take advantage of the possibilities that new technologies provide.
    [Show full text]
  • A Metacircular Architecture for Runtime Optimisation Persistence Clément Béra
    Sista: a Metacircular Architecture for Runtime Optimisation Persistence Clément Béra To cite this version: Clément Béra. Sista: a Metacircular Architecture for Runtime Optimisation Persistence. Program- ming Languages [cs.PL]. Université de Lille 1, 2017. English. tel-01634137 HAL Id: tel-01634137 https://hal.inria.fr/tel-01634137 Submitted on 13 Nov 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Universit´edes Sciences et Technologies de Lille { Lille 1 D´epartement de formation doctorale en informatique Ecole´ doctorale SPI Lille UFR IEEA Sista: a Metacircular Architecture for Runtime Optimisation Persistence THESE` pr´esent´eeet soutenue publiquement le 15 Septembre 2017 pour l'obtention du Doctorat de l'Universit´edes Sciences et Technologies de Lille (sp´ecialit´einformatique) par Cl´ement B´era Composition du jury Pr´esident: Theo D'Hondt Rapporteur : Ga¨elThomas, Laurence Tratt Examinateur : Elisa Gonzalez Boix Directeur de th`ese: St´ephaneDucasse Co-Encadreur de th`ese: Marcus Denker Laboratoire d'Informatique Fondamentale de Lille | UMR USTL/CNRS 8022 INRIA Lille - Nord Europe Numero´ d’ordre: XXXXX i Acknowledgments I would like to thank my thesis supervisors Stéphane Ducasse and Marcus Denker for allowing me to do a Ph.D at the RMoD group, as well as helping and supporting me during the three years of my Ph.D.
    [Show full text]
  • The Future: the Story of Squeak, a Practical Smalltalk Written in Itself
    Back to the future: the story of Squeak, a practical Smalltalk written in itself Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [Also published in OOPSLA ’97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming, 1997, pp. 318-326.] VPRI Technical Report TR-1997-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 Back to the Future The Story of Squeak, A Practical Smalltalk Written in Itself by Dan Ingalls Ted Kaehler John Maloney Scott Wallace Alan Kay at Apple Computer while doing this work, now at Walt Disney Imagineering 1401 Flower Street P.O. Box 25020 Glendale, CA 91221 [email protected] Abstract Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks. Other noteworthy aspects of Squeak include: a compact object format that typically requires only a single word of overhead per object; a simple yet efficient incremental garbage collector for 32-bit direct pointers; efficient bulk- mutation of objects; extensions of BitBlt to handle color of any depth and anti-aliased image rotation and scaling; and real-time sound and music synthesis written entirely in Smalltalk. Overview Squeak is a modern implementation of Smalltalk-80 that is available for free via the Internet, at http://www.research.apple.com/research/proj/learning_concepts/squeak/ and other sites. It includes platform-independent support for color, sound, and image processing.
    [Show full text]
  • A World of Active Objects for Work and Play: the First Ten Years of Lively
    A World of Active Objects for Work and Play The First Ten Years of Lively Daniel Ingalls Tim Felgentreff Robert Hirschfeld Y Combinator Research Hasso Plattner Institute Hasso Plattner Institute, Potsdam, San Francisco, CA, USA Potsdam, Germany Germany [email protected] [email protected] [email protected] Robert Krahn Jens Lincke Marko Roder¨ Y Combinator Research Hasso Plattner Institute Y Combinator Research San Francisco, CA, USA Potsdam, Germany San Francisco, CA, USA [email protected] [email protected] [email protected] Antero Taivalsaari Tommi Mikkonen Nokia Technologies Tampere University of Technology Tampere, Finland Tampere, Finland [email protected] tommi.mikkonen@tut.fi Abstract Keywords Web programming, Software as a Service, Live The Lively Kernel and the Lively Web represent a continu- Object System, Lively Kernel, Lively Web, Lively, JavaScript, ing effort to realize a creative computing environment in the Morphic context of the World Wide Web. We refer to that evolving system simply as Lively. Lively is a live object computing 1. Live Object Systems environment implemented using JavaScript and other tech- Lively [12] is a live object system which provides a web niques available inside the browser. When first built in 2006, programming and authoring system to its users. By live ob- it was a grand accomplishment to have created such a sys- jects we mean entities that can usually be seen, touched, and tem that would run in any web browser and that could be moved and that will react in a manner prescribed by some set saved and loaded simply as a web page.
    [Show full text]
  • Tinlizzie Wysiwiki and Wikiphone: Alternative Approaches to Asynchronous and Synchronous Collaboration on the Web
    TinLizzie WysiWiki and WikiPhone: Alternative approaches to asynchronous and synchronous collaboration on the Web Yoshiki Oshima, Takashi Yamamiya, Scott Wallace, and Andreas Raab [Also published in the Proc. of the 5th International Conf. on Creating, Connecting, and Collaborating through Computing (C5 2007)] VPRI Technical Report TR-2007-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 TinLizzie WysiWiki and WikiPhone: Alternative approaches to asynchronous and synchronous collaboration on the Web Yoshiki Ohshimay Takashi Yamamiyay [email protected] [email protected] Scott Wallacey Andreas Raabz [email protected] [email protected] yViewpoints Research Institute zQwaq, Inc. 1209 Grand Central Ave. 460 S California Ave #304 Glendale, CA 91202 Palo Alto, CA 94306 Abstract they exhibit possible future directions for collaboration on the Web. This paper presents TinLizzie WysiWiki and WikiPhone, two systems which explore new approaches to media-rich end-user collaboration on the World Wide Web. 1 Introduction TinLizzie WysiWiki enables authoring of interactive, media-rich documents, containing graphical objects bear- The World Wide Web, or Web, has been very successful. ing user-defined scripts, on the Web. In TinLizzie WysiWiki, It seems nowadays to dictate not only many end-users' be- a user manipulates text and active objects in a WYSIWYG havior, but also the mindsets of researchers and software graphical editor in a manner similar to Squeak eToys. vendors; the perception is that a new system should run A notable aspect of TinLizzie WysiWiki is that it allows in web browsers to be successful. As a consequence, im- both synchronous and asynchronous collaboration among provement in the overall user experience in applications has multiple users.
    [Show full text]
  • IADIS Conference Template
    www.seipub.org/ie Information Engineering (IE) Volume 3, 2014 Performance and Quality Evaluation of jQuery Javascript Framework Andreas Gizas, Sotiris P. Christodoulou, Tzanetos Pomonis HPCLab, Computer Engineering & Informatics Dept., University of Patras Rion, Patras Received Jun 10, 2013; Revised Jun 21, 2013; Accepted Mar 12, 2014; Published Jun 12, 2014 © 2014 Science and Engineering Publishing Company Abstract devices. Mobile web is the name of this new field of The scope of this work is to provide a thorough web applications and JavaScript is expected to play a methodology for quality and performance evaluation of the major role in its development with the evolution of most popular JavaScript framework, the jQuery Framework, new devices and standards (ex. iPhone, Android) or as by taking into account well established software quality the heart of cross platform applications (like factors and performance tests. The JavaScript programming phonegap.com). There are also proposals for language is widely used for web programming and employing JavaScript in server-side applications increasingly, for general purpose of computing. Since the (Server-Side JavaScript Reference v1.2). growth of its popularity and the beginning of web 2.0 era, many JavaScript frameworks have become available for Due to the plethora of applications that JavaScript programming rich client-side interactions in web serves and the variety of programming needs, applications. The jQuery project and its community serve frameworks have been created in order to help both today as a major part of web programmers. The main programmers and end-users. These frameworks aim to outcome of this work is to highlight the pros and cons of be a useful tool for simplifying JavaScript code jQuery in various areas of interest and signify which and development and repeat blocks of code by using just a where the weak points of its code are.
    [Show full text]
  • 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.
    [Show full text]
  • Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007
    Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007 Michael Haupt1, Robert Hirschfeld1, and Marcus Denker2 1 Software Architecture Group Hasso-Plattner-Institut University of Potsdam, Germany 2 Software Composition Group Institute of Computer Science and Applied Mathematics University of Berne, Switzerland michael.haupt,hirschfeld @hpi.uni-potsdam.de, [email protected] { } Abstract. This position paper proposes the exploitation of type feed- back mechanisms, or more precisely, polymorphic inline caches, for purely interpreting implementations of object-oriented programming languages. Using Squeak’s virtual machine as an example, polymorphic inline caches are discussed as an alternative to global caching. An implementation proposal for polymorphic inline caches in the Squeak virtual machine is presented, and possible future applications for online optimization are outlined. 1 Introduction Bytecode interpreters are small in size and comparatively easy to implement, but generally execute programs much less efficiently than just-in-time (JIT) compilers. Techniques like threaded interpretation [9, 11, 2] focus on speeding up bytecode interpretation itself, and caching [4, 5, 1] improves the performance of message sends—the most common operation in object-oriented software [7]. It is interesting to observe that, while threading mechanisms are used natu- rally to a varying degree in bytecode interpreter implementations, such systems usually employ only global caching to speed up dynamic method dispatch. A global cache is clearly beneficial with respect to overall performance. Still, it does not provide optimal support for polymorphic message send sites, and it does not allow for exploiting type information (we provide details on these issues in the following section). In our opinion, the employment of polymorphic inline caches (PICs) [5] instead can provide means for achieving significant speedups in bytecode interpreters while exhibiting only a moderate increase in memory footprint and implementation complexity.
    [Show full text]
  • A Tour of the Squeak Object Engine
    A Tour of the Squeak Object Engine A Tour of the Squeak Object Engine Tim Rowledge, [email protected] Introduction This chapter is intended to explain some basics of how a Virtual Machine (VM) works, why a VM is useful, what it does for the Squeak programmer and user, and how the Squeak VM might develop in the future. What is a Virtual Machine and why do we need one? A Virtual Machine provides us with a pretense of being a machine other than the actual hardware in use. Using one allows systems that behave differently than the host hardware to run as if on hardware designed for them. The term Object Engine is less commonly used but is a useful concept that includes the lowest system areas of the langauge environment running on the VM. Since there is often some flux in the definition of which components are within the actual VM and which are part of the supported environment, Object Engine is useful as a more inclusive term. The term Virtual Machine is used in several ways. When IBM refer to VM/CMS they are referring to a way of making a mainframe behave as if it is many machines, so that programs can assume they have total control even though they do not. Intel provide a somewhat similar facility in the x86 architecture(?), referred to as Virtual Mode. This sort of VM is a complete hardware simulation, often supported at the lowest level by the hardware. Another sort of VM is the emulator - SoftWindows for the Mac, Acorn's !PC, Linux's WINE are good examples - where another machine and/or OS is simulated to allow a Mac user to run Windows programs, an Acorn RiscPC or a Linux machine to run Windows98 programs and so on.
    [Show full text]
  • Sindarin: a Versatile Scripting API for the Pharo Debugger
    Sindarin: A Versatile Scripting API for the Pharo Debugger Thomas Dupriez Guillermo Polito Steven Costiou Univ. Lille, CNRS, Centrale Lille, CNRS - UMR 9189 - CRIStAL, Univ. Inria, Univ. Lille, CNRS, Centrale Inria, UMR 9189 - CRIStAL Lille, Centrale Lille, Inria Lille, UMR 9189 - CRIStAL France France France [email protected] [email protected] [email protected] Vincent Aranega Stéphane Ducasse Univ. Lille, CNRS, Centrale Lille, Inria, Univ. Lille, CNRS, Centrale Inria, UMR 9189 - CRIStAL Lille, UMR 9189 - CRIStAL France France [email protected] [email protected] Abstract Studies and work on debugging acknowledge that main- Debugging is one of the most important and time consuming stream debuggers are not well adapted to several debugging activities in software maintenance, yet mainstream debuggers scenarios [3, 27, 31]. This has led to the appearance of new de- are not well-adapted to several debugging scenarios. This bugging techniques proposing to augment traditional interac- has led to the research of new techniques covering specific tive debuggers with, e.g., stateful breakpoints [4], control-flow families of complex bugs. Notably, recent research proposes aware breakpoints [5], object-centric breakpoints [10, 34], the to empower developers with scripting DSLs, plugin-based and automatic insertion of breakpoints based on dynamic execu- moldable debuggers. However, these solutions are tailored to tions [45], or declarative statements from the developer [21]. specific use-cases, or too costly for one-time-use scenarios. A line of research has also started to study scripting APIs to In this paper we argue that exposing a debugging scripting empower developers to implement debugging scripts adapted interface in mainstream debuggers helps in solving many chal- to their needs.
    [Show full text]