DOCSLIB.ORG

LAMBDA-GTK: a Portable Graphics Layer for Common Music

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
LAMBDA-GTK: a Portable Graphics Layer for Common Music λGTK: A PORTABLE GRAPHICS LAYER FOR COMMON MUSIC Heinrich Taube Composition/Theory School of Music University of Illinois Urbana, IL USA ABSTRACT presented an undue hardship or problem. But with the publication of Notes from the Metalevel [5] (the λGTK (LAMBDA GTK) is a new, portable graphics author’s book on algorithmic composition) in 2004, layer for implementing graphical user interface (GUI) new users who have no background in sound synthesis tools in Common Music [1] (CM), an algorithmic or programming have begun to experiment with music composition environment that runs in Common algorithmic composition and Common Music. The Lisp [2] and Scheme [3]. λGTK provides a complete author decided to use this recent circumstance as the interface to the popular GTK2 [4] graphics libraries and impetus to implement a graphic layer. Since CM is currently supports the development of graphical displays both portable and free, two central requirements of the in three different public domain Lisp implementations new graphics code are that (1) the graphics libraries on two different operating systems. Two full-featured must also be free and (2) the graphical tools that are GUI tools for Common Music -- a music data developed must be usable in more than one public visualization tool called Plotter and an executive “front domain Lisp implementation and on more than one end” window called CMIO -- are briefly described as operating system. After considering a number of examples of λGTK functionality. A key feature of different strategies and options the author decided to λGTK is that it is generated programmatically from base CM’s graphics on Version 2 of the Gimp Tool Kit information parsed from GTK header declarations rather (GTK2). GTK is a popular, public domain graphics than coded directly by hand. One benefit of this package that runs on multiple platforms, including implementation method is that larger (or less inclusive) Linux, OS X and Windows. Its powerful windowing interfaces can be generated on demand so Lisp features, free distribution, and stable release cycles make applications only need to load bindings for entry points it a good choice to implement source portable graphical in the GTK libraries that they actually use. Porting interfaces for Common Music. After first attempting to λGTK to new Lisp implementations is also much less use and adopt a few existing Lisp/GTK interfaces it work than if the layer had been coded by hand, and became apparent that there was no existing software that resolving errors and other porting issues is now a global offered a complete Lisp binding for the complete GTK2 operation (regenerating the layer) rather than a local one API or that would run on multiple operating systems (finding each affected entry and editing it by hand in a and Lisp implementations. Mario Momar’s LGTK [6] text editor). To port λGTK to a new Lisp the developer package was the best candidate system, but, because it simply provides “back end” functions to the generating is written by hand, it implements only a tiny fraction of program that translates the system’s intermediate Lisp the thousands of possible GTK entry points. After representation of GTK’s data structures into the considering the size of GTK and the fact that multiple appropriate foreign function interface (FFI) code for the bindings would be required for a portable layer, the new target host. The λGTK layer itself does not depend author decided that generating Common Music’s on anything in Common Music and is available as a graphics layer was the appropriate way to solve both separate, free software package released under the Lisp problems. Lesser General Public License (LLGPL). 2. λGTK DESIGN 1. BACKGROUND AND MOTAVATION Common Music is an object-oriented music λGTK is a cross-platform Lisp interface to the complete composition environment. It generates sound by GTK+2 family of shared libraries. Its design reflects transforming a high-level Lisp representation of musical solutions to two separate but equally problematic Lisp structure (algorithms, musical event descriptions and implementation issues: variability between different other compositional representations) into a variety of Lisp environments and the large number of GTK entry protocols for controlling sound synthesis and music points that a working Lisp interface might want to use. score generation. CM has bindings for both Common Most Lisp vendors provide a foreign function interface Lisp and Scheme dialects of Lisp and runs in a variety (FFI) protocol that specifies how Lisp programs can of Lisp implementations and operating systems. Its interface to non-Lisp (typically C) executables stored in highly portable nature, coupled with the fact that neither shared libraries. A number of Lisp implementations also Common Lisp nor Scheme requires a graphics standard, provide the ability for foreign code to call Lisp has made Common Music an essentially text-based functions encapsulated as foreign function callbacks. system until now. For a certain class of user – someone Any Lisp implementation that provides these two trained in musical synthesis languages or having prior features -- FFI linking to shared libraries and foreign programming experience – the lack of GUI tools has not function callback support -- is a candidate for using GTK2 as a windowing API. Happily, most Lisp implementations now fulfil these two essential pointers to ints, floats and doubles are also handled requirements in one way or another. Unfortunately, automatically: foreign values are allocated and because the Lisp language specification does not cover initialized on the Lisp side, the pointers are then foreign function interface design, the manner in which passed to GTK, dereferenced upon return and vendors implement these features varies widely with returned to the Lisp caller as multiple values. each Lisp implementation. In order to deal with this variability between Lisp FFI designs as well as with the • Lisp names for GTK's enums, structs and functions. sheer size of GTK’s programming interface (which Lisp names are formed by substituting "-" for "_" contains literally thousands of function, struct and enum and converting C library prefixes like glib_ and into exported Lisp package prefixes like definitions) λGTK contains no hand-coded software gtk_ beyond a handful of functions (ten) that implement glib: and gtk: (Figure 1). vendor specific “glue code” for creating and registering • Lisp accessor functions for reading and setting slot callbacks and allocating foreign structures. The rest of values in GTK structs. Struct slots that contain the interface -- currently consisting of 3,500 Lisp included structures are also supported, e.g. definitions for CM’s current graphics tools -- is gtk:widget.allocation.width. The first programmatically generated from two information argument to a Lisp foreign structure accessor is a database files. The first file (gtk.ffi) contains a Lisp pointer to the struct. If the referenced slot is an representation of all GTK library header declarations. array then a second required argument provides the The second file (gtk.api) is an API inclusion file that index. The final argument to a struct accessor is allows fine-grain control over which enums, structs, optional; if specified, it replaces the current value in struct slot accessors and API functions will receive Lisp the slot. For example: bindings in the generated interface. Both database files (gdk:rectangle.x rect) ; get x value (gtk.ffi and gtk.api) were derived from C header files (gdk:rectangle.x rect 100) ; set x value using FFIGEN [7], a program originally developed by Lars Thomas Hansen and now maintained by Gary Given the simple and consistent name translations, Byers as part of his OpenMCL [8] Lisp anyone who is familiar with GTK programming and implementation. FFIGEN uses output from the C Lisp function call syntax will find that graphics work compiler’s pre-processor to translate GTK header with λGTK is straightforward and requires no declarations into equivalent expressions formatted as documentation beyond the GTK API reference itself Lisp lists. These Lisp list expressions can then be read, (Figure 1). manipulated and analyzed by Lisp programs. In order to generate a GTK interface, λGTK reads the parsed header (gtk:define-signal-handler bye :void (w d) (format t "bye!~%") information contained in the gtk.ffi database and then (gtk:main-quit)) translates that information into the foreign function binding code for each supported Lisp implementation. (defun hello-world () The λGTK translation generator is organized into two (let ((w (gtk:window-new 0)) layers: a common file (lambda-gtk-common.lisp) and a (b (gtk:button-new-with-label "Hello World!"))) “back end” implementation file for each target FFI (gtk:container-add w b) (lambda-gtk-openmcl.lisp, lambda-gtk-cmucl.lisp, and (gtk:container-set-border-width w 10) so on). The translation program uses only a very modest (g:signal-connect w "destroy" set of features from its host Lisp environment and is (g:callback bye) (g:nullptr)) easily portable to any Common Lisp and reasonably (gtk:widget-show-all w) featured Scheme. λGTK currently generates GTK (gtk:main))) bindings for three different Common Lisp compilers on two different operating systems: Figure 1. The canonical “Hello World!” in λGTK. • OpenMCL 0.14.2-p on PPC/Darwin • SBCL [9] 0.8.16 on x86/Linux 4. COMMON MUSIC and λGTK • CMUCL [10] 19a on x86/Linux Two additional ports, to CLISP [11] on Windows XP λGTK provides Common Music with a portable and Guile Scheme [12] on x86/Linux, are in progress. graphics layer that behaves identically across different Lisp implementations and operating systems. Because 3. λGTK FEATURES λGTK is so new, the current release of Common Music contains only two GUI programs: a data visualization tool called Plotter, and a front end window, called The generated interface provides the following features CMIO, that facilitates algorithmic generation of musical to Common Music: material to and from the supported sound synthesis • Source portable GUI programming across the applications.
Load more

Recommended publications
  • MELT a Translated Domain Specific Language Embedded in the GCC
    MELT a Translated Domain Specific Language Embedded in the GCC Compiler Basile STARYNKEVITCH CEA, LIST Software Safety Laboratory, boˆıte courrier 94, 91191 GIF/YVETTE CEDEX, France [email protected] [email protected] The GCC free compiler is a very large software, compiling source in several languages for many targets on various systems. It can be extended by plugins, which may take advantage of its power to provide extra specific functionality (warnings, optimizations, source refactoring or navigation) by processing various GCC internal representations (Gimple, Tree, ...). Writing plugins in C is a complex and time-consuming task, but customizing GCC by using an existing scripting language inside is impractical. We describe MELT, a specific Lisp-like DSL which fits well into existing GCC technology and offers high-level features (functional, object or reflexive programming, pattern matching). MELT is translated to C fitted for GCC internals and provides various features to facilitate this. This work shows that even huge, legacy, software can be a posteriori extended by specifically tailored and translated high-level DSLs. 1 Introduction GCC1 is an industrial-strength free compiler for many source languages (C, C++, Ada, Objective C, Fortran, Go, ...), targetting about 30 different machine architectures, and supported on many operating systems. Its source code size is huge (4.296MLOC2 for GCC 4.6.0), heterogenous, and still increasing by 6% annually 3. It has no single main architect and hundreds of (mostly full-time) contributors, who follow strict social rules 4. 1.1 The powerful GCC legacy The several GCC [8] front-ends (parsing C, C++, Go .
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Latexsample-Thesis
    INTEGRAL ESTIMATION IN QUANTUM PHYSICS by Jane Doe A dissertation submitted to the faculty of The University of Utah in partial fulfillment of the requirements for the degree of Doctor of Philosophy Department of Mathematics The University of Utah May 2016 Copyright c Jane Doe 2016 All Rights Reserved The University of Utah Graduate School STATEMENT OF DISSERTATION APPROVAL The dissertation of Jane Doe has been approved by the following supervisory committee members: Cornelius L´anczos , Chair(s) 17 Feb 2016 Date Approved Hans Bethe , Member 17 Feb 2016 Date Approved Niels Bohr , Member 17 Feb 2016 Date Approved Max Born , Member 17 Feb 2016 Date Approved Paul A. M. Dirac , Member 17 Feb 2016 Date Approved by Petrus Marcus Aurelius Featherstone-Hough , Chair/Dean of the Department/College/School of Mathematics and by Alice B. Toklas , Dean of The Graduate School. ABSTRACT Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah.
    [Show full text]
  • Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb
    pipenightdreams osgcal-doc mumudvb mpg123-alsa tbb-examples libgammu4-dbg gcc-4.1-doc snort-rules-default davical cutmp3 libevolution5.0-cil aspell-am python-gobject-doc openoffice.org-l10n-mn libc6-xen xserver-xorg trophy-data t38modem pioneers-console libnb-platform10-java libgtkglext1-ruby libboost-wave1.39-dev drgenius bfbtester libchromexvmcpro1 isdnutils-xtools ubuntuone-client openoffice.org2-math openoffice.org-l10n-lt lsb-cxx-ia32 kdeartwork-emoticons-kde4 wmpuzzle trafshow python-plplot lx-gdb link-monitor-applet libscm-dev liblog-agent-logger-perl libccrtp-doc libclass-throwable-perl kde-i18n-csb jack-jconv hamradio-menus coinor-libvol-doc msx-emulator bitbake nabi language-pack-gnome-zh libpaperg popularity-contest xracer-tools xfont-nexus opendrim-lmp-baseserver libvorbisfile-ruby liblinebreak-doc libgfcui-2.0-0c2a-dbg libblacs-mpi-dev dict-freedict-spa-eng blender-ogrexml aspell-da x11-apps openoffice.org-l10n-lv openoffice.org-l10n-nl pnmtopng libodbcinstq1 libhsqldb-java-doc libmono-addins-gui0.2-cil sg3-utils linux-backports-modules-alsa-2.6.31-19-generic yorick-yeti-gsl python-pymssql plasma-widget-cpuload mcpp gpsim-lcd cl-csv libhtml-clean-perl asterisk-dbg apt-dater-dbg libgnome-mag1-dev language-pack-gnome-yo python-crypto svn-autoreleasedeb sugar-terminal-activity mii-diag maria-doc libplexus-component-api-java-doc libhugs-hgl-bundled libchipcard-libgwenhywfar47-plugins libghc6-random-dev freefem3d ezmlm cakephp-scripts aspell-ar ara-byte not+sparc openoffice.org-l10n-nn linux-backports-modules-karmic-generic-pae
    [Show full text]
  • Lisping Copyleft: a Close Reading of the Lisp LGPL 15
    Lisping Copyleft: A Close Reading of the Lisp LGPL 15 Lisping Copyleft: A Close Reading of the Lisp LGPL Eli Greenbaum a (a) Attorney, Yigal Arnon & Co. Jerusalem DOI: 10.5033/ifosslr.v5i1.75 Abstract: The idioms of both the General Public License (the “GPL”) and the Lesser General Public License (the “LGPL”) seem to be grounded in the C programming language. This article analyses the Lisp Lesser General Public License (colloquially and here referred to as the “LLGPL”), a specific attempt to apply the LGPL to a language with a programming paradigm and method of building and distributing programs that traditionally differs substantially from the approach of C. In addition, this article attempts to understand whether the LLGPL actually succeeds in its stated goal of translating the LGPL to the Lisp context or whether the LLGPL changes the requirements and philosophical moorings of the LGPL. Keywords: Law; information technology; Free and Open Source Software; copyleft, copyright; derivation; compilation; Lisp; LGPL; Introduction The idioms of both the General Public License (the “GPL”) and the Lesser General Public License 1 (the “LGPL”) seem to be grounded in the C programming language. The licenses refer to “compiling”, “linking” and “header files”, features of the C programming languages which may not be present in other languages that are not traditionally compiled. Similarly, the licenses do not expressly include provisions relating to features of object-oriented programming languages.2 Do the GNU licenses work as intended when applied in these other contexts? 3 This article analyses the Lisp 1 The LLGPL license is drafted as a preamble to version 2.1 of the LGPL.
    [Show full text]
  • Platform Freedom for a Graphical Lisp Application Through Armed Bear Common Lisp
    CARMA: Platform Freedom for a Graphical Lisp Application through Armed Bear Common Lisp John D. Hastings Alexandre V. Latchininsky Dept. of Computer Science Dept. of Renewable Resources University of Nebraska-Kearney University of Wyoming Kearney, NE, USA Laramie, WY, USA [email protected] [email protected] Abstract 1. Introduction CARMA is an advisory system that uses artificially- CARMA is an advisory system for grasshopper infesta- intelligent techniques including case-based reasoning tions that has been successfully used since 1996 (Hast- to provide advice about the most environmentally and ings, Branting, & Lockwood 2002). CARMA, short economically effective responses to grasshopper infes- for CAse-based Rangeland Management Advisor, em- tations. CARMA’s core AI reasoner was initially writ- ploys a variety of artificially-intelligent (AI) techniques ten in Common Lisp and integrated with an Allegro to provide advice about the most environmentally and Common Lisp for Windows graphical user interface economically effective responses to grasshopper infes- (GUI). CARMA went public in 1996 and has been tations. In the process, CARMA demonstrates an ap- used successfully since. Recently, CARMA’s architec- proach to providing advice concerning the behavior of ture was reworked in order to avoid periodic develop- a complex biological system by exploiting multiple, in- ment and deployment fees, and to produce a platform- dividually incomplete, knowledge sources (Hastings, independent system by following a philosophy called Branting, & Lockwood 1996) including utilization of a platform freedom which emphasizes freedom from technique known as approximate-model-based adapta- both platform dependence and software costs. The im- tion which integrates case-based reasoning with model- plementation also demonstrates an approach to creating based reasoning for the purposes of prediction within a Lisp application with an appealing GUI which is web complex physical systems.
    [Show full text]
  • Integral Estimation in Quantum Physics
    INTEGRAL ESTIMATION IN QUANTUM PHYSICS by Jane Doe A dissertation submitted to the faculty of The University of Utah in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Mathematical Physics Department of Mathematics The University of Utah May 2016 Copyright c Jane Doe 2016 All Rights Reserved The University of Utah Graduate School STATEMENT OF DISSERTATION APPROVAL The dissertation of Jane Doe has been approved by the following supervisory committee members: Cornelius L´anczos , Chair(s) 17 Feb 2016 Date Approved Hans Bethe , Member 17 Feb 2016 Date Approved Niels Bohr , Member 17 Feb 2016 Date Approved Max Born , Member 17 Feb 2016 Date Approved Paul A. M. Dirac , Member 17 Feb 2016 Date Approved by Petrus Marcus Aurelius Featherstone-Hough , Chair/Dean of the Department/College/School of Mathematics and by Alice B. Toklas , Dean of The Graduate School. ABSTRACT Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah.
    [Show full text]
  • Weak References Data Structures and Implementation
    Weak References Data Structures and Implementation Bruno Haible ILOG GmbH 24 April 2005 What is a Weak Pointer? ● Garbage collection preserves all objects that are reachable from the root set. ● A weak pointer holds its object without causing it to be reachable. What is a Weak Hashtable? ● A weak hash-table holds its key-value pairs without causing them to be reachable. ● Four kinds: – :key – :value – :key-and-value – :key-or-value A Strong Feature ● Adding extra info to sealed objects. ● Memoizing prior results. ● Uniquification. ● Hash consing. ● Avoiding attach/detach protocols. ● Global garbage collection. Caveats ● Extra time spent in GC (for W weak pointers: – O(W²) in some implementations, – O(W) in other implementations) Weak Datastructures ● Weak pointer ● Weak “and” relation ● Weak “or” relation ● Weak association (= weak mapping) ● Weak “and” mapping ● Weak “or” mapping ● Weak association list ● Weak hash-table Primitive Weak Datastructures ● Weak pointers ● Weak :key mappings ● Weak hash-tables The others can be emulated. Levels of Support 1.Support for weak pointers. 2.Support for weak :key mappings or weak hash-tables, with “key not in value” restriction. 3.Support for weak :key mappings or weak hash-tables, without restriction. 4.Scalable support for weak :key mappings or weak hash-tables. Implementations of Level 1 ● Common Lisp: GNU clisp 2.33.80, OpenMCL 0.14.1, Allegro CL 6.2, LispWorks 4.3, Corman Lisp 1.1, CMUCL 19a, SBCL 0.8.20 ● Scheme: GNU guile 1.7.1, MIT Scheme 7.7.1, BBN Scheme, MzScheme 205, Scheme48 ● Other
    [Show full text]
  • Gnustep HOWTO Installing the Gnustep Developement System
    GNUstep HOWTO Installing the GNUstep developement system This document explains how to build the different components of the GNUstep core libraries. Last Update: 6 May 2021 Copyright c 1996 - 2007 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation. i Table of Contents 1 Introduction ::::::::::::::::::::::::::::::::::::: 1 2 Summary::::::::::::::::::::::::::::::::::::::::: 2 3 Compiling and Installing the packages::::::::: 5 3.1 Installing the Core Libraries :::::::::::::::::::::::::::::::::::: 5 3.1.1 Alternate Library Setup ::::::::::::::::::::::::::::::::::: 6 3.1.2 Building the Package :::::::::::::::::::::::::::::::::::::: 6 4 Additional Installation :::::::::::::::::::::::::: 7 4.1 Environment Setup ::::::::::::::::::::::::::::::::::::::::::::: 7 4.2 GNUstep Home :::::::::::::::::::::::::::::::::::::::::::::::: 7 4.3 Time Zone ::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 4.4 GNUstep deamons:::::::::::::::::::::::::::::::::::::::::::::: 8 5 Test Tools and Applications :::::::::::::::::::: 9 6 Machine Specific Instructions ::::::::::::::::: 10 7 Getting Libraries via git ::::::::::::::::::::::: 11 1 1 Introduction This document explains how to build the GNUstep core libraries. The core libraries, along with associated tools and other files provide everything nec- essary for a working GNUstep system. In order to easily compile and debug GNUstep projects,
    [Show full text]
  • CLISP - Conversational LISP
    Session 25 Hardware and Software for Artificial Intelligence CLISP - Conversational LISP Warren Teitelman Xerox Palo Alto Research center Palo Alto, California 94304 Abstract CLISP is an attempt to make LISP programs The syntax for a conditional expression is easier to read and write by extending the correspondingly simple:* syntax of LISP to include infix operators, IF-THEN statements, FOR-DO-WHILE statements, Figure 2 and similar ALGOL-like constructs, without Syntax of a conditional Expression changing the structure or representation of the language. CLISP is implemented through <conditional expression> ::x LISP's error handling machinery, rather than (COND <clause> ... <clause>) by modifying the interpreter: when an <clause> :;= (<form> <form>) expression is encountered whose evaluation causes an error, the expression is scanned Note that there are no IF's, THEN's, for possible CLISP constructs, which are BEGIN's, END'S, or semi-colons. LISP avoids then converted to the equivalent LISP the problem of parsing the conditional expressions. Thus, users can freely expression, i.e., delimiting the individual intermix LISP and CLISP without having to clauses, and delimiting the predicates and distinguish which is which. Emphasis in the consequents within the clauses, by requiring design and development of CLISP has been on that each clause be a separate element in the system aspects of such a facility, with the conditional expression, namely a the goal in mind of producing a useful tool, sublist, of which the predicate is always not just another language. To this end, the first element, and the consequent the CLISP includes interactive error correction second element- As an example, let us and many 'Do-what-I-Mean* features.
    [Show full text]
  • Einführung in LISP
    Einführung in LISP Simon Lutz, Frank Preiswerk “Real Programmers don't write in LISP. Only idiots' programs contain more parenthesis than actual code.” “Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.” 04/19/06 Seminar 10 Programmiersprachen - Lisp/Scheme - Simon Lutz, Frank Preiswerk 1 Zeitlicher Überblick 1958: Lisp wurde von John McCarthy am MIT speziell für nicht-numerische Probleme designed und von Steve Russell auf einer IBM 704 Maschine implementiert. Der Name bedeutet “List Processing Language”. 1968: Erster Lisp Compiler geschrieben in Lisp von Tim Hart und Mike Levin. 1968-70: Implementation von SHRDLU mittels Lisp, berühmtes AI-System. 1970er Jahre: Performanz von bestehenden Lisp-Systemen wird zum Thema, es entstehen optimierte Lisp-Maschinen. Heute wieder verschwunden. 1980er – 1990er Jahre: Bemühungen für eine Vereinheitlichung der vielen bestehenden Lisp-Dialekte: Common Lisp entsteht. 1994: ANSI veröffentlicht Common Lisp Standard. Dies zu einem Zeitpunkt, als der Weltmarkt für Lisp viel kleiner war als in den früheren Zeiten. 04/19/06 Seminar 10 Programmiersprachen - Lisp/Scheme - Simon Lutz, Frank Preiswerk 2 Lisp heute Nach einem Rückgang in den 90er Jahren ist das Interesse seit 2000 wieder gestiegen, massgeblich im Rahmen von Open Source Implementationen von Common Lisp. 2004: Peter Seibel’s “Practical Common Lisp” ist für kurze Zeit an zweiter Stelle von Amazon’s populärsten Programmierbüchern. April 2006: Tiobe Software rankt Lisp auf Platz 14 der populärsten Programmiersprachen. Neue “Lisper” beschreiben die Sprache gerne als “eye-opening experience” und behaupten, in Lisp deutlich produktiver zu sein als in anderen Sprachen.
    [Show full text]
  • Evaluation of Music Notation Packages for an Academic Context
    EVALUATION OF MUSIC NOTATION PACKAGES FOR AN ACADEMIC CONTEXT Pauline Donachy Dept of Music University of Glasgow [email protected] Carola Boehm Dept of Music University of Glasgow [email protected] Stephen Brandon Dept of Music University of Glasgow [email protected] December 2000 EVALUATION OF MUSIC NOTATION PACKAGES FOR AN ACADEMIC CONTEXT PREFACE This notation evaluation project, based in the Music Department of the University of Glasgow, has been funded by JISC (Joint Information Systems Committee), JTAP (JISC Technology Applications Programme) and UCISA (Universities and Colleges Information Systems Association). The result of this project is a software evaluation of music notation packages that will be of benefit to the Higher Education community and to all users of music software packages, and will aid in the decision making process when matching the correct package with the correct user. Six main packages are evaluated in-depth, and various others are identified and presented for consideration. The project began in November 1999 and has been running on a part-time basis for 10 months, led by Pauline Donachy under the joint co-ordination of Carola Boehm and Stephen Brandon. We hope this evaluation will be of help for other institutions and hope to be able to update this from time to time. In this aspect we would be thankful if any corrections or information regarding notation packages, which readers might have though relevant to be added or changed in this report, could be sent to the authors. Pauline Donachy Carola Boehm Dec 2000 EVALUATION OF MUSIC NOTATION PACKAGES FOR AN ACADEMIC CONTEXT ACKNOWLEDGEMENTS In fulfillment of this project, the project team (Pauline Donachy, Carola Boehm, Stephen Brandon) would like to thank the following people, without whom completion of this project would have been impossible: William Clocksin (Calliope), Don Byrd and David Gottlieb (Nightingale), Dr Keith A.
    [Show full text]