DOCSLIB.ORG

Delphi Event Tagging

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Delphi Event Tagging DELPHI Collaboration @ DELPHI 89-92 DAS 101 , Ne DELPHI EVENT TAGGING M. Dam (Oslo), A. De Angelis (Udine), P. Eerola (Helsinki), R. Fruhwirth (Vienna), P. Gavillet (CERN), P.O. Hulth (Stockholm), M. Innocente (Udine), B. King (Liverpool), J.P. Laugier (Saclay), J. Maillard (CDF), M. Pimenta (Lisboa), P. Privitera (Bologna), M. Tarantino (Udine), J. Varela (Lisboa), C. Werner (Lisboa), M. Zito (Genova), R. Zukanovich (CDF) DELPHI EVENT TAGGING M. Dam (Oslo), A. De Angelis (Udine), P. Eerola (Helsinki), R. Fruhwirth (Vienna), P. Gavillet (CERN), P.O. Hulth (Stockholm), M. Innocente (Udine), B. King (Liverpool), J.P. Laugier (Saclay), J. Maillard (CDF), M. Pimenta (Lisboa), P. Privitera (Bologna), M. Tarantino (Udine), J. Varela (Lisboa), C. Werner (Lisboa), M. Zito (Genova), R. Zukanovich (CDF) Abstract The DELPHI event tagging is an application designed to check the raw data output, to perform a fast on-line pattern recognition of the events, and to provide for them a classifi- cation. This application will be implemented on the on-line 3081/E emulator system. In this note, the general structure of the application, the detector algorithms and the implementation are described. A summary is provided for the performance tests. Contents 1 Introduction 2 3081/E Emulators Description of the General Steering 3.1 The Initialization Step (T4INIT) ........0.........0.0..0..0.00.4. 3.2 The Processing Step (T4LOOP) ..............0.000 000000 0G 3.3 The Termination Step (T4END) ........... 00.00.0000 0 beeen Detector algorithms 4.1.1 The T4TPC Algorithm .............0. 0.000000. ween 4.1.2 Some performancetests .........0..0.000000 eee eee eee 4.2 Outer Detector ©... 2... tk eas 4.2.1 Introduction .........0.00.0. ee ees 4.2.2 Information provided by the Outer Detector. ................ 4.2.3 Brief description of the method used .................00004 4.2.4 Summary ......... 0.0. ee es 43 HPC... 2. ens 4.3.1 General structure of the program ................000800. 4.3.2 Test of performance .........0..00000 ce eee ee eee eg 44 EMP... 2... ee eg 4.4.1 Input/Output... ..... 0.00.00 000. ee ee ng 4.4.2 User access to thresholds and parameters ...............-.. 4.4.3 Performance .........0.0.00 cc eee ee ey 4.5 Hadron Calorimeter .........0.0..0.0000. cee eee ee ee ee 4.5.1 Input/Output........ 0.000000 000. ee eeee eee 4.5.2 User access to thresholds and parameters .................. 4.5.3 Performance ....... 0... 00 cee ee es 46 SAT 2... ek ee ee 4.6.1 Adjustable thresholds and variables .................0000. 4.7 Forward Chambers (A and B)..... Pe ee Global performance and timing tests FADO implementation Graphic interface 7.1 Graphic representation of elements ................0000 eee. 1 Introduction The event tagging software for DELPHI is essentially made of: e A set of detector modules able to perform:a fast pattern recognition starting from the raw data (and eventually taking advantage of the data preprocessing form the Ist, 2nd and 3rd level trigger). These modules provide a simplified “reconstruction” of the event and a flag telling if the individual detector is able to classify the event as a “real event” by himself. e A general steering driving the sequence of the calls to the detector modules (and eventually calling only a subgroup of modules). The steering is thought in such a way to optimize the calls to the modules in order to classify an event spending the minimum CPU time. In the final version of the tagging such a logic will be controlled in a FADO ([FAD.1], [FAD.2]) environment. At the end of the tagging processing, an event can be classified as cosmic, beam gas, other background, or Z, eventually specifying the Z decay channel for which it is a candidate. The tagging software will run on a battery of three 3081/E emulators working in parallel, sited in the DAS central partition [EMU.1]. The DELPHI tagging software is coupled to a graphic interface for the visual scanning of the events. 2 3081/E Emulators The 3081/E emulator is a processor which emulates an IBM system 370 computer. It is designed to execute any High Energy Physics application program, giving results that are bit for bit identical with those obtained on an IBM system 370 mainframe. It is a reduced instruction set machine, running its own unique microcode which is produced from IBM machine code by a TRANSLATOR program. The 3081/E emulator has the following hardware features: 1. Modular architecture consisting of: e Five execution units (Control and register board, Floating point add/subtract card, Integer card, Multiply card, Divide card) e One Interface card e Memory cards 2. Separated program and data memory which ensures that a program cannot overwrite its own instructions 3. Memory configurable in 0.5 Mbytes units up to 7 Mbytes 4, Full support for FORTRAN 77 including double precision 64 bit floating point arithmetic and character type instructions, but excluding I/O instructions. 5. Pseudo-dual port interfacing to external busses (Fastbus in Delphi) 6. High speed external data transfer capability. The 3081/E has 64 bit internal data paths and a 120 ns clock. ?. A performance that is equivalent to an unit IBM 370/168. Advantage is taken of several hardware design feature to pipeline program instruction at the translate step. Referring to expected rates (Input rate of 5 Hz, Output rate of 2 Hz) with 3 to 4 Emulators the processing time in each 3081/E must be less than 500 ms by event [EMU.1]. Comparing to the Delphi analysis off-line program DELANA using as much as 16 megabytes of memory necessary to load complete database for each detector, the tagging program must use 4 megabytes of memory at maximum depending on the hardware configuration of the Delphi 3081/E emulators. Thus only partial database for each detector with a few geometrical and calibration constants can be loaded. Our program needs, for the moment, 0.5 Mbyte of Program Memory and 3.0 Mbytes of Data memory. 3 Description of the General Steering The DELPHI 4'*-level Tagging process is divided into three main steps: the initialization step T4INIT, the processing step T4LOOP, and the termination step T4END. 3.1 The Initialization Step (T4INIT) This first step takes care of the following: 1. Initialization of ZEBRA, used as memory management system (Call MZEBRA) Creation of a special division to receive Raw—Data (Call MZDIV) Creation of a Link area for: (Call MZLINT) e Raw Data e Detector algorithms (TPC, HCAL, HPC, EMF , OD, SAT, FCAB., ...) . Initialization of TANAGRA if requested. [*XTANAGRA] (Call TSTLIM) . Initialization of HBOOK4 if requested. [xHIST] (Call HLIMIT) . Initialization of the Input/Output files depending on the computer: [xVAX ,xIBM ,xEMUL] (Call FZFILE) a) Block size definition. (FZDEF sequence) b) I/O Mode choice. (Native (= default) or Exchange) c) Fortran Read/Write mode or QIO Package choice. Initialization of TANAGRA files if requested. [*XTANAGRA] (Call TOPTN) 6. Detector Algorithms choice by defining a vector IT4ORD: (Call T4ORDI) a) One can choose the Detector Algorithms to be activated in the process (= n means yes, = -1 means no; n is the detector number for T4ORDI); b) One can change the order of calling the detectors in the process. Ex: IT4ORD(i) = n...... Detector Algorithm number n called in the i-th position , where l<n<l10. n= 1 means TPC , n = 2 means OD ,n = 3 means HPC ,n = 4 means HAC, n = 5 means SAT , n = 6 means EM , n = 7 means FCAB, n = 8,9 and 10 are free for later use. ?. Initialization of different energy and angle cuts needed to associate detectors in the aim of tagging particles. 8. Initialization of the Tagging Statistics. 9. Initialization of the general purpose Commons. 3.2 The Processing Step (T4LOOP) This is the core of the Tagging processing: the Loop on events. Here we: 1. Read the Event in the Raw Data division (Call T4READ) 2. Loop on the chosen algorithms (order defined in T4ORDI): CALL T4TPC (if TPC ) .... Time Projection Chamber algorithm | CALL T4EMF (if EMF ) .... Forward Electromagnetic Calorimeter algorithm CALL T4HCAL (if HC ) .... Hadron Calorimeter algorithm CALL T4HPC (if HPC ) .... Barrel Electromagnetic Calorimeter algorithm CALL T40D (if OD ).... Outer Detector algorithm CALL T4SAT (if SAT ) .... Small Angle Tagger algorithm CALL T4FCAB (if FCAB) .... Forward Chambers A and B algorithm Each algorithm outputs a Flag: IFu (u = TPC, EMF, ves) One has: IF'u = -1 — means no data (or bad data) for the corresponding detector for this event; Iu = 0 — means no physical relevant clusters(or tracks) seen by the corresponding detector for this event; IFu = 1-— means physical relevant clusters(tracks) seen by the corresponding detector for this event. Each detector fills in a Common T4vRES (v = T,E,C,H,S,O and F for each detector respectively TPC,EMF,HCAL,HPC,SAT,OD and FCAB) giving: e the number of clusters (tracks) for the event; e for each cluster(track) some relevant information as E(p), 6, ¢. (see appendix on output format) 3. ‘Try to take a decision for the final tagging of (Call T4PHYS) by trying to combine the calorimetric information and the TPC tracks for each event (this subroutine is not yet fully coded as it shall depend highly on the tagging philosophy to be clearly defined in the future). A FADO implementation is foreseen to perform this tagging decision in a more general way. 4. Get the tagging information given by each detector. (Call T4BITS) 5. Write tagged events on stream 1, all events on stream 2. (Call FZOUT) 3.3 The Termination Step (T4END) Here we 1.
Load more

Recommended publications
  • Some Global Optimizations for a Prolog Compiler
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector J. LOGIC PROGRAMMING 1985:1:43-66 43 SOME GLOBAL OPTIMIZATIONS FOR A PROLOG COMPILER C. S. MELLISH 1. INTRODUCTION This paper puts forward the suggestion that many PROLOG programs are not radically different in kind from programs written in conventional languages. For these programs, it should be possible for a PROLOG compiler to produce code of similar efficiency to that of other compilers. Moreover, there is no reason why reasonable efficiency should not be obtained without special-purpose hardware. Therefore, at the same time as pursuing the goal of special hardware for running PROLOG programs, we should be looking at how to maximize the use of conven- tional machines and to capitalize on developments in conventional hardware. It seems unlikely that conventional machines can be efficiently used by PROLOG programs without the use of sophisticated compilers. A number of possible optimiza- tions that can be made on the basis of a static, global analysis of programs are presented, together with techniques for obtaining such analyses. These have been embodied in working programs. Timing figures for experimental extensions to the POPLOG PROLOG compiler are presented to make it plausible that such optimiza- tions can indeed make a difference to program efficiency. 2. WHAT ARE REAL PROLOG PROGRAMS LIKE? It is unfortunate that very little time has been spent on studying what kinds of programs PROLOG programmers actually write. Such a study would seem to be an important prerequisite for trying to design a PROLOG optimising compiler.
    [Show full text]
  • Incremental Compilation in Compose*
    Incremental Compilation in Compose? A thesis submitted for the degree of Master of Science at the University of Twente Dennis Spenkelink Enschede, October 28, 2006 Research Group Graduation Committee Twente Research and Education prof. dr. ir. M. Aksit on Software Engineering dr. ir. L.M.J. Bergmans Faculty of Electrical Engineering, M.Sc. G. Gulesir Mathematics and Computer Science University of Twente Abstract Compose? is a project that provides aspect-oriented programming for object-oriented lan- guages by using the composition filters model. In particular, Compose?.NET is an implemen- tation of Compose? that provides aspect-oriented programming to Microsoft Visual Studio languages. The compilation process of Compose?.NET contains multiple compilation modules. Each of them has their own responsibilities and duties such as parsing, analysis tasks and weaving. However, all of them suffer from the same problem. They do not support any kind of incre- mentality. This means that they perform all of their operations in each compilation without taking advantage of the results and efforts of previous compilations. This unavoidably results in compilations containing many redundant repeats of operations, which slow down compila- tion. To minimize these redundant operations and hence, speed up the compilation, Compose? needs an incremental compilation process. Therefore, we have developed a new compilation module called INCRE. This compilation module provides incremental performance as a service to all other compilation modules of Compose?. This thesis describes in detail the design and implementation of this new compila- tion module and evaluates its performance by charts of tests. i Acknowledgements My graduation time was a long but exciting process and I would not have missed it for the world.
    [Show full text]
  • Separate Compilation As a Separate Concern
    Separate Compilation as a Separate Concern A Framework for Language-Independent Selective Recompilation Nathan Bruning Separate Compilation as a Separate Concern THESIS submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in COMPUTER SCIENCE by Nathan Bruning born in Dordrecht, the Netherlands Software Engineering Research Group Department of Software Technology Faculty EEMCS, Delft University of Technology Delft, the Netherlands www.ewi.tudelft.nl c 2013 Nathan Bruning. All rights reserved. Separate Compilation as a Separate Concern Author: Nathan Bruning Student id: 1274465 Email: [email protected] Abstract Aspect-oriented programming allows developers to modularize cross-cutting con- cerns in software source code. Concerns are implemented as aspects, which can be re-used across projects. During compilation or at run-time, the cross-cutting aspects are “woven” into the base program code. After weaving, the aspect code is scattered across and tangled with base code and code from other aspects. Many aspects may affect the code generated by a single source module. It is difficult to predict which dependencies exist between base code modules and aspect modules. This language-specific information is, however, crucial for the development of a compiler that supports selective recompilation or incremental compilation. We propose a reusable, language-independent framework that aspect-oriented lan- guage developers can use to automatically detect and track dependencies, transpar- ently enabling selective recompilation. Our implementation is based on Stratego/XT, a framework for developing transformation systems. By using simple and concise rewrite rules, it is very suitable for developing domain-specific languages. Thesis Committee: Chair: Prof.
    [Show full text]
  • Incremental Flow Analysis 1 Introduction 2 Abstract Interpretation
    Incremental Flow Analysis Andreas Krall and Thomas Berger Institut fur Computersprachen Technische Universitat Wien Argentinierstrae A Wien fanditbgmipscomplangtuwienacat Abstract Abstract interpretation is a technique for ow analysis widely used in the area of logic programming Until now it has b een used only for the global compilation of Prolog programs But the programming language Prolog enables the programmer to change the program during run time using the builtin predicates assert and retract To supp ort the generation of ecient co de for programs using these dynamic database predicates we extended abstract interpretation to b e executed incrementally The aim of incremental abstract interpretation is to gather program information with minimal reinterpretation at a program change In this pap er we describ e the implementation of incremental abstract interpretation and the integration in our VAM based Prolog P compiler Preliminary results show that incremental global compilation can achieve the same optimization quality as global compilation with little additional cost Intro duction Since several years we do research in the area of implementation of logic programming lan guages To supp ort fast interpretation and compilation of Prolog programs we develop ed the VAM Vienna Abstract Machine with two instruction p ointers Kra KN and P the VAM Vienna Abstract Machine with one instruction p ointer KB Although P the VAM manages more information ab out a program than the WAM Warren Abstract Machine War it is necessary to add ow analysis
    [Show full text]
  • Successful Lisp - Contents
    Successful Lisp - Contents Table of Contents ● About the Author ● About the Book ● Dedication ● Credits ● Copyright ● Acknowledgments ● Foreword ● Introduction 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 Appendix A ● Chapter 1 - Why Bother? Or: Objections Answered Chapter objective: Describe the most common objections to Lisp, and answer each with advice on state-of-the-art implementations and previews of what this book will explain. ❍ I looked at Lisp before, and didn't understand it. ❍ I can't see the program for the parentheses. ❍ Lisp is very slow compared to my favorite language. ❍ No one else writes programs in Lisp. ❍ Lisp doesn't let me use graphical interfaces. ❍ I can't call other people's code from Lisp. ❍ Lisp's garbage collector causes unpredictable pauses when my program runs. ❍ Lisp is a huge language. ❍ Lisp is only for artificial intelligence research. ❍ Lisp doesn't have any good programming tools. ❍ Lisp uses too much memory. ❍ Lisp uses too much disk space. ❍ I can't find a good Lisp compiler. ● Chapter 2 - Is this Book for Me? Chapter objective: Describe how this book will benefit the reader, with specific examples and references to chapter contents. ❍ The Professional Programmer http://psg.com/~dlamkins/sl/contents.html (1 of 13)11/3/2006 5:46:04 PM Successful Lisp - Contents ❍ The Student ❍ The Hobbyist ❍ The Former Lisp Acquaintance ❍ The Curious ● Chapter 3 - Essential Lisp in Twelve Lessons Chapter objective: Explain Lisp in its simplest form, without worrying about the special cases that can confuse beginners.
    [Show full text]
  • The PLT Course at Columbia
    Alfred V. Aho [email protected] The PLT Course at Columbia Guest Lecture PLT September 10, 2014 Outline • Course objectives • Language issues • Compiler issues • Team issues Course Objectives • Developing an appreciation for the critical role of software in today’s world • Discovering the principles underlying the design of modern programming languages • Mastering the fundamentals of compilers • Experiencing an in-depth capstone project combining language design and translator implementation Plus Learning Three Vital Skills for Life Project management Teamwork Communication both oral and written The Importance of Software in Today’s World How much software does the world use today? Guesstimate: around one trillion lines of source code What is the sunk cost of the legacy software base? $100 per line of finished, tested source code How many bugs are there in the legacy base? 10 to 10,000 defects per million lines of source code Alfred V. Aho Software and the Future of Programming Languages Science, v. 303, n. 5662, 27 February 2004, pp. 1331-1333 Why Take Programming Languages and Compilers? To discover the marriage of theory and practice To develop computational thinking skills To exercise creativity To reinforce robust software development practices To sharpen your project management, teamwork and communication (both oral and written) skills Why Take PLT? To discover the beautiful marriage of theory and practice in compiler design “Theory and practice are not mutually exclusive; they are intimately connected. They live together and support each other.” [D. E. Knuth, 1989] Theory in practice: regular expression pattern matching in Perl, Python, Ruby vs. AWK Running time to check whether a?nan matches an regular expression and text size n Russ Cox, Regular expression matching can be simple and fast (but is slow in Java, Perl, PHP, Python, Ruby, ...) [http://swtch.com/~rsc/regexp/regexp1.html, 2007] Computational Thinking – Jeannette Wing Computational thinking is a fundamental skill for everyone, not just for computer scientists.
    [Show full text]
  • An Extension to the Eclipse IDE for Cryptographic Software Development
    Universidade do Minho Conselho de Cursos de Engenharia Mestrado em Inform´atica Master Thesis 2007/2008 An Extension to the Eclipse IDE for Cryptographic Software Development Miguel Angelo^ Pinto Marques Supervisores: Manuel Bernardo Barbosa - Dept. de Inform´aticada Universidade do Minho Acknowledgments First of all I would like to thank my supervisor Manuel Bernardo Barbosa for all oppor- tunities, guidance and comprehension that he has provided to me. I would also like to thank my friends, Andr´e,Pedro and Ronnie for the support given to me during this difficult year. To Ana the kindest person in the world, who is always there for me. And finally, to my mother to whom I dedicate this thesis. Thank you all, Miguel \Prediction is very difficult, especially about the future." Niels Bohr ii Abstract Modern software is becoming more and more, and the need for security and trust is de- terminant issue. Despite the need for sophisticated cryptographic techniques, the current development tools do not provide support for this specific domain. The CACE project aims to develop a toolbox that will provide support on the specific domain of cryptography. Several partners will focus their expertise in specific domains of cryptography providing tools or new languages for each domain. Thus, the use of a tool integration platform has become an obvious path to follow, the Eclipse Platform is defined as such. Eclipse has proven to be successfully used as an Integrated Development Environment. The adoption of this platform is becoming widely used due to the popular IDE for Java Development (Java Development Tools).
    [Show full text]
  • Constructing Hybrid Incremental Compilers for Cross-Module Extensibility with an Internal Build System
    Delft University of Technology Constructing Hybrid Incremental Compilers for Cross-Module Extensibility with an Internal Build System Smits, J.; Konat, G.D.P.; Visser, Eelco DOI 10.22152/programming-journal.org/2020/4/16 Publication date 2020 Document Version Final published version Published in Art, Science, and Engineering of Programming Citation (APA) Smits, J., Konat, G. D. P., & Visser, E. (2020). Constructing Hybrid Incremental Compilers for Cross-Module Extensibility with an Internal Build System. Art, Science, and Engineering of Programming, 4(3), [16]. https://doi.org/10.22152/programming-journal.org/2020/4/16 Important note To cite this publication, please use the final published version (if applicable). Please check the document version above. Copyright Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim. This work is downloaded from Delft University of Technology. For technical reasons the number of authors shown on this cover page is limited to a maximum of 10. Constructing Hybrid Incremental Compilers for Cross-Module Extensibility with an Internal Build System Jeff Smitsa, Gabriël Konata, and Eelco Vissera a Delft University of Technology, The Netherlands Abstract Context Compilation time is an important factor in the adaptability of a software project. Fast recompilation enables cheap experimentation with changes to a project, as those changes can be tested quickly.
    [Show full text]
  • Incremental Compilation
    VisualAge® C++ Professional for AIX® Incremental Compilation Ve r s i o n 5.0 Note! Before using this information and the product it supports, be sure to read the general information under “Notices” on page v. Edition Notice This edition applies to Version 5.0 of IBM® VisualAge C++ and to all subsequent releases and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the level of the product. © Copyright International Business Machines Corporation 1998, 2000. All rights reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices ...............v Build in a Team Environment ........17 Programming Interface Information ......vii Projects and Subprojects ..........17 Trademarks and Service Marks ........vii Project Files ..............19 Industry Standards ...........viii How Project Files Are Processed ......19 Example: Project File ...........20 About This Book...........ix Related Configuration Files ........20 Project File Syntax ............21 Chapter 1. Incremental Compilation Chapter 3. Using the Incremental Concepts ..............1 Compiler ..............27 Incremental C++ Builds...........1 Build ................27 Incremental Configuration Files ........2 Build from the Command Line ........28 Basic Configuration Files .........3 Build Executable Programs .........29 More Complex Configuration Files ......3 Group Source Files in a Configuration .....29 Configuration File Directives .........4 Compile and Bind Resources ........30 Configuration File Syntax ..........6 Macros in C++ Source Files .........30 Example: Configuration File .........7 Search Paths for Included Source Files (AIX) . 32 How Configuration Files are Processed .....8 Cleaning Up After Builds..........33 Sources ................9 When to Use Makefiles ..........35 Primary vs Secondary Sources .......11 Macro vs Non-macro Sources .......11 Targets ................12 Chapter 4.
    [Show full text]
  • Using an IDE
    Using an IDE Tools are a big part of being a productive developer on OpenJFX and we aim to provide excellent support for all three major IDEs: NetBeans, IntelliJ IDEA, and Eclipse. Regardless of which development environment you prefer, you should find it easy to get up and running with OpenJFX. We hope you will return the favor by submitting patches and bug reports! This section assumes that you have already succeeded in Building OpenJFX. A gradle build must complete before IDE support will fully work (otherwise your IDE will just be a glorified text editor with lots of red squiggles!). Specific instructions for using each IDE is provided below, followed by a discussion on Developer Workflow, Using Mercurial, and Communication with other members of the team. Further information on how we work can be found under Co de Style Rules. IDE Pre-Requirements Get a build of the latest JDK Get an IDE that supports the latest JDK JDK-8 Only: Delete jfxrt.jar (or move it to a different directory) Using NetBeans (JDK-8) Invoke NetBeans Add the JDK8 Platform Import the NetBeans Projects Rebuild Run Sample Code Run Sample Code with gradle built shared libraries Using IntelliJ IDEA Open the IntelliJ Project Make Run Sample Code Run Sample Code with Gradle Built Shared Libraries Using Eclipse Import the Eclipse Projects Configure Eclipse to use the latest JDK JUnit tests Running a dependent project Run Sample Code (NOTE: old) Using Gradle Run Sample Code with Gradle Built Shared Libraries (Note: old) IDE Pre-Requirements Despite the fact that most of the major IDE's support gradle directly, we have decided to provide pre-generated IDE configuration files in order to make using an IDE smooth and painless.
    [Show full text]
  • Advanced Programming Language Design (Raphael A. Finkel)
    See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/220692467 Advanced programming language design. Book · January 1996 Source: DBLP CITATIONS READS 41 3,040 1 author: Raphael Finkel University of Kentucky 122 PUBLICATIONS 6,757 CITATIONS SEE PROFILE All content following this page was uploaded by Raphael Finkel on 16 December 2013. The user has requested enhancement of the downloaded file. ADVANCED PROGRAMMING LANGUAGE DESIGN Raphael A. Finkel ❖ UNIVERSITY OF KENTUCKY ▲ ▼▼ Addison-Wesley Publishing Company Menlo Park, California · Reading, Massachusetts New York · Don Mills, Ontario · Harlow, U.K. · Amsterdam Bonn · Paris · Milan · Madrid · Sydney · Singapore · Tokyo Seoul · Taipei · Mexico City · San Juan, Puerto Rico hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh On-line edition copyright 1996 by Addison-Wesley Publishing Company. Permission is granted to print or photo- copy this document for a fee of $0.02 per page, per copy, payable to Addison-Wesley Publishing Company. All other rights reserved. Acquisitions Editor: J. Carter Shanklin Proofreader: Holly McLean-Aldis Editorial Assistant: Christine Kulke Text Designer: Peter Vacek, Eigentype Senior Production Editor: Teri Holden Film Preparation: Lazer Touch, Inc. Copy Editor: Nick Murray Cover Designer: Yvo Riezebos Manufacturing Coordinator: Janet Weaver Printer: The Maple-Vail Book Manufacturing Group Composition and Film Coordinator: Vivian McDougal Copyright 1996 by Addison-Wesley Publishing Company 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 any other media embodiments now known, or hereafter to become known, without the prior written permission of the publisher.
    [Show full text]
  • IBM Visualage C++ for AIX Offers a Traditional Makefile-Based Compiler
    Software Announcement March 28, 2000 IBM VisualAge C++ for AIX Offers a Traditional Makefile-based Compiler Overview AIX) for the editing function within the integrated development At a Glance The VisualAge C++ Professional environment (IDE) for AIX , Version 5.0 software is a VisualAge C++ Professional for • Support for multiple code stores highly productive, and powerful AIX, Version 5.0 is a powerful within the incremental compiler development environment for application development allowing a large project to be building C and C++ applications. environment that includes: implemented in separate and VisualAge C++ Professional offers smaller units • the flexibility of a set of C++ Incredible flexibility with the choice of a traditional, compilers supported by a suite of • Easier transition from the makefile-based C++ compiler tools designed to offer a rich incremental compiler to the or the highly productive IBM environment for object-oriented traditional compiler with the incremental C++ compiler application development. ordered name lookup option, which allows the compiler to try • Support for the latest ANSI 98 VisualAge C++ Professional for AIX to resolve all names to the same C++ standards in both now includes a traditional, declarations that a traditional compilers, including a complete makefile-based C++ compiler. This compiler would ANSI Standard Template makefile-based compiler supports Library the latest 1998 ANSI/ISO C++ • More flexible source control with standard and includes a complete the ability to check files into or • Support for 32-bit and 64-bit implementation of the ANSI Standard out of virtually any source control optimization in both compilers Template Library (STL).
    [Show full text]