DOCSLIB.ORG

WCL: Delivering Efficient Common Lisp Applications Under Unix 1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
WCL: Delivering Efficient Common Lisp Applications Under Unix 1 WCL: Delivering Efficient Common Lisp Applications under Unix Wade Hennessey Center for Design Research Stanford University wade@ sunrise. stanf ord. edu Abstract: Common Lisp implementations for Unix from foreign data. However, because Lisp programs can- have traditionally provided a rich development environ- not be provided to other programmers in a form com- ment at the expense of an inefficient delivery environ- patible with the native system linker, Lisp must remain ment. The goal of WCL is to allow hundreds of Lisp “in control” by linking foreign code into the Lisp image. applications to be realistically available at once, while Unfortunately, foreign debugging information is usually allowing several of them to run concurrently. WCL ac- lost in the process, thus making debugging of mixed complishes this by providing Common Lisp as a Unix language programa difficult. shared library that can be linked with Lisp and C code Standalone applications are produced by dynami- to produce efficient applications. For example, the cally loading application code into a running Lisp and executable for a Lisp version of the canonical “Hello then saving a memory image to disk. Autoloading can World!” program requires only 40k bytes under SunOS be used to delay the loading of code until runtime, thus 4.1 for SPARC. WCL also supports a full development reducing image size, but it can substantially increase the environment, including dynamic file loading and debug- startup time of an application. Treeshakers and selec- ging. A modified version of GDB [1], the GNU Debug- tive loading of subparts of the Lisp system are also used ger, is used to debug WCL programs, providing support to reduce the size of saved memory images, but the in- for mixed language debugging. The techniques used in herently intertwined nature of Common Lisp makes this WCL should also be applicable to other high-level lan- difficult to use effectively. Furthermore, the read-only guages that allow runtime mappings from names to ob- portions of a memory image can be shared only with jects. other people running exactly the same image. Thus, every application that is even partially written in Lisp must duplicate both on disk and in memory a signifi- 1 Introduction cant portion of the Lisp runtime library, no matter how small the executable size becomes. 1.1 Lisp Machine Approach Many Common Lisp implementations for Unix are 1.2 Unix and WCL approach modeled after the “Lisp Machine” view of comput- Window oriented Unix programs encountered problems ing. A Lisp development environment is often a multi- similar to Common Lisp when dealing with large li- megabyte executable that contains a compiler, evalua- braries such as X. Every application that wanted to ac- tor, dynamic linker, debugger, runtime library, threads cess the window system was statically linked to include package, editor, window system interface, etc., all run- large portions of the X library, giving each application ning in a single address space. Support for passing data its own copy of the library code. For example, when to foreign languages is typically quite good, although the executable for the X Calculator program xcalc is great effort is usually taken to distinguish Lisp data linked this way, it occupies 773k bytes of disk space un- Permission to copy without fee all or part of this material is der Ultrix 4.1 on a MIPS based DECStation. Dozens of granted provided that the copies are not made or distributed for other X clients have similar disk requirements, leading direct commercial advantage, the ACM copyright notice and the to a poor utilization of disk space and memory. title of the publication and its date appear, and notice is given Shared library support was added to many versions that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee of Unix to overcome this problem. Executable only and/or spacific permission. contain the code that is unique to a specific application, 1992 ACM LISP & F. P.-6 I92ICA @ 1992 ACM 0.89791 -483 -X1921000610260 . ..$I .50 260 while common library code is shared both on disk and heap. A Common Lisp conservative GC is actually a in memory with other applications. For example, under bit simpler than a conservative GC for Scheme because SunOS 4.1 on SPARC, xcalc only requireds 82k bytes Common Lisp does not support heap allocated upward of disk space because it shares the X library code with continuations. A static heap that is not subject to other applications. garbage collection is also provided for permanent ob- WCL takes advantage of shared libraries to produce jects that should never be copied. correspondingly efficient Lisp applications. WCL emits standard “.0” files that can be linked into a sharable 2.2 Runtime Model library using ld, the standard Unix linker. Applications can then be linked with shared libraries using ld again. Every Lisp function is translated into a corresponding Thus, Lisp libraries can be shard with other programs C function, using name mangling to convert Lisp names just as easily as a library written in C or Fortran. into legal C names. Depending upon the compiler’s Most Lisp systems also provide their own unique optimization settings, Lisp functions may be called di- debugger that executes in the same address space as rectly, just as they would normally be called in C, or the Lisp system. This differs from the Unix model of they may be called indirectly through the function cell debugging in which the debugger executes in a supe- of the symbol that names the function. The first argu- rior process that runs and controls the program being ment to every Lisp function is an argument count, fol- debugged in a separate, inferior process. In order to lowed by the required arguments. The varargs/stdarg make WCL programs work well with other languages, support in C is used to support optional, keyword and the GNU debugger GDB has been modified to under- rest arguments. Both heap allocated and stack allo- stand Lisp. GDB was chosen because it is an excel- cated rest argument lists are supported, as well as stack lent debugger with full source code availability. The re- allocated rest argument vectors. sult is that Lisp and C programs can be linked together Multiple values are supported by overloading the and debugged using the native tools used by other Unix purpose of the argument count. If a caller wants to programs. Similarly, native profiling and code analysis receive multiple values, a pointer to a stack allocated tools can also be applied to Lisp programs. structure is passed as the argument count. The ac- tual argument count is stored inside of this structure, along with sufficient space for receiving the values. The 2 WCL Compiler and Runtime structure pointer is distinguishable from an actual argu- Model ment count because argument counts are small integers, while stack pointers appear as large integers greater WCL translates Common Lisp into either K+R or ANSI than call-arguments-limit. C. As Lisp code is translated to C, information about If a callee wants to return multiple values, the first symbol usage, structure definitions, and package oper- value is returned as the function’s normal return value, ations is also recorded. This information is currently while the remaining values are stored into the values stored as a comment at the start of the emitted C file, structure along with a return value count. This sys- although it should eventually be stored in a special sec- tem imposes no overhead on the normal single value tion of the object file. The information is later used by expected, single value returned, function call. The only the linking portions of the WCL development system. complication involves passing a multiple value holder on to other functions when making tail calls. For example, if A calls B expecting multiple values, and B does a tail 2.1 Memory Model call to C, B must pass along the multiple value holder The runtime model for WCL is fairly conventional. All from A to C. However, it must determine at runtime dynamically allocated storage comes from a single heap. if A passed a multiple value holder. This check adds Every object in the heap has a single word header, one a few instructions to tail calls. However, this approach byte of which is used as a type field. The least significant has the advantage of using standard C while still being bit of every Lisp pointer is used as a tag bit. A tag of ef%cient. O indicates that the pointer is really a 31 bit immediate Catch, throw, dynamic return-from, dynamic go, integer, while a tag of 1 signifies that the type field in unwimd-prot ect, and special variable binding are all the object header indicates the object’s type. A single supported by set jmp and long jmp, and a stack allo- table of all possible character objects is maintained to cated “dynamic chain”. For example, a call to throw avoid allocating characters in the heap. first searches the dynamic chain for a corresponding A conservative GC based on the work done in cat ch tag. If found, then the chain is unwound, undoing Scheme->C [2] is used to garbage collect the dynamic special bindings and using longjmp to hop up the stack 261 and execute cleanup code in any unwind-protects. any copying of data, allowing destructive operations to Once the stack is unwound, long j mp transfers control work on returned data as expected. This same tech- to the catch point. nique can also be used to pass and receive arrays of any Set jmp and long j mp present a few problems for rank and element type.
Load more

Recommended publications
  • The Copyright Law of the United States (Title 17, U.S
    NOTICE WARNING CONCERNING COPYRIGHT RESTRICTIONS: The copyright law of the United States (title 17, U.S. Code) governs the making of photocopies or other reproductions of copyrighted material. Any copying of this document without permission of its author may be prohibited by law. CMU Common Lisp User's Manual Mach/IBM RT PC Edition David B. McDonald, Editor April 1989 CMU-CS-89-132 . School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 This is a revised version of Technical Report CMU-CS-87-156. Companion to Common Lisp: The Language Abstract CMU Common Lisp is an implementation of Common Lisp that currently runs on the IBM RT PC under Mach, a Berkeley Unix 4.3 binary compatible operating system. This document describes the implementation dependent choices made in developing this implementation of Common Lisp. Also, several extensions have been added, including the proposed error system, a stack crawling debugger, a stepper, an interface to Mach system calls, a foreign function call interface, the ability to write assembler language routines, and other features that provide a good environment for developing Lisp code. This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976 under contract F33615-87-C-1499 and monitored by the Avionics Laboratory, Air Force Wright Aeronautical Laboratories, Aeronautical Systems Division (AFSC), Wright-Patterson AFB, OHIO 45433-6543. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S.
    [Show full text]
  • Allegro CL User Guide
    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
    [Show full text]
  • The Embeddable Common Lisp
    ACM Lisp Pointers 8(1), 1995, 30-41 The Embeddable Common Lisp Giuseppe Attardi Dipartimento di Informatica, Universit`adi Pisa Corso Italia 40, I-56125 Pisa, Italy net: [email protected] Abstract The Embeddable Common Lisp is an implementation of Common Lisp designed for being embeddable within C based applications. ECL uses standard C calling conventions for Lisp compiled functions, which allows C programs to easily call Lisp functions and viceversa. No foreign function interface is required: data can be exchanged between C and Lisp with no need for conversion. ECL is based on a Common Runtime Support (CRS) which provides basic facilities for memory management, dynamic loading and dumping of binary images, support for multiple threads of execution. The CRS is built into a library that can be linked with the code of the application. ECL is modular: main modules are the program development tools (top level, debugger, trace, stepper), the compiler, and CLOS. A native implementation of CLOS is available in ECL: one can configure ECL with or without CLOS. A runtime version of ECL can be built with just the modules which are required by the application. 1 Introduction As applications become more elaborate, the facilities required to build them grow in number and sophistica- tion. Each facility is accessed through a specific package, quite complex itself, like in the cases of: modeling, simulation, graphics, hypertext facilities, data base management, numerical analysis, deductive capabilities, concurrent programming, heuristic search, symbolic manipulation, language analysis, special device control. Reusability is quite a significant issue: once a package has been developed, tested and debugged, it is un- desirable having to rewrite it in a different language just because the application is based in such other language.
    [Show full text]
  • GNU/Linux AI & Alife HOWTO
    GNU/Linux AI & Alife HOWTO GNU/Linux AI & Alife HOWTO Table of Contents GNU/Linux AI & Alife HOWTO......................................................................................................................1 by John Eikenberry..................................................................................................................................1 1. Introduction..........................................................................................................................................1 2. Traditional Artificial Intelligence........................................................................................................1 3. Connectionism.....................................................................................................................................1 4. Evolutionary Computing......................................................................................................................1 5. Alife & Complex Systems...................................................................................................................1 6. Agents & Robotics...............................................................................................................................1 7. Programming languages.......................................................................................................................2 8. Missing & Dead...................................................................................................................................2 1. Introduction.........................................................................................................................................2
    [Show full text]
  • Programming Environments John Foderaro In
    Programming Environments John Foderaro In this issue we feature a description of Delph! Common Lisp, an enhanced version of Kyoto Common Lisp. Company: Delphi S.p.A. Via della Vetraia, 11 1-55049 Viareggio, Italy tel: + 39 (584) 395225 fax: + 39 (584) 395366 tlx: 501542 DELPlll I Product name: Delphi Common Lisp Version of product described: All versions. This version available when: This year. Contact Delphi for more information. Hardware available on: Sun 3, Sun 4, Sun 386i, general 386-based machines running Unix system V. Available on a wide variety of hardware and operating systems in the near future. Delphi Common Lisp is a full implementation of Common Lisp than runs on a range of general-purpose computers. DCL provides several major facilities on top of the Common Lisp standard to provide a more complete and powerful programming language including - Common Lisp Object System, in complete accordance with the ANSI X3J 13 subcommittee proposal. - CLX, the emerging standard binding between Common l,isp and the X Window system "client" functionality. It's implemented entirely in Lisp (doesn't go through XLib) and provides direct access from Lisp to all X Window client functions. - "Multithread" facility to create and control concurrent threads of program execution. Useful for U.I. design and other applications where interrupts can come from a variety of sources as well as parallel processing research. - ttigh productivity facilities like ZetaLisp LOOP macro, Symbolics-style DEFSYSTEM, autoioad facility, EMACS editor interface Influence: The Common Lisp component of DCL is based on Kyoto Common Lisp, meaning that it's extremely portable and, now, performs quite well.
    [Show full text]
  • CLX — Common LISP X Interface
    CLX Common LISP X Interface 1988, 1989 Texas Instruments Incorporated Permission is granted to any individual or institution to use, copy, modify and distribute this document, provided that this complete copyright and permission notice is maintained, intact, in all copies and supporting documentation. Texas Instruments Incorporated makes no representations about the suitability of this document or the software described herein for any purpose. It is provided ”as is” without express or implied warranty. CLX Programmer’s Reference i ACKNOWLEDGMENTS Primary Interface Author: Robert W. Scheifler MIT Laboratory for Computer Science 545 Technology Square, Room 418 Cambridge, MA 02139 [email protected] Primary Implementation Author: LaMott Oren Texas Instruments PO Box 655474, MS 238 Dallas, TX 75265 [email protected] Design Contributors: Dan Cerys, BBN Scott Fahlman, CMU Kerry Kimbrough, Texas Instruments Chris Lindblad, MIT Rob MacLachlan, CMU Mike McMahon, Symbolics David Moon, Symbolics LaMott Oren, Texas Instruments Daniel Weinreb, Symbolics John Wroclawski, MIT Richard Zippel, Symbolics Documentation Contributors: Keith Cessna, Texas Instruments Kerry Kimbrough, Texas Instruments Mike Myjak LaMott Oren, Texas Instruments Dan Stenger, Texas Instruments The X Window System is a trademark of MIT. UNIX is a trademark of AT&T Bell Laboratories. ULTRIX, ULTRIX–32, ULTRIX–32m, ULTRIX–32w, and VAX/VMS are trademarks of Digital Equipment Corporation. ii CLX Programmer’s Reference CONTENTS Section Title 1 INTRODUCTION TO CLX 2 DISPLAYS 3 SCREENS 4 WINDOWS AND PIXMAPS 5 GRAPHICS CONTEXTS 6 GRAPHIC OPERATIONS 7 IMAGES 8 FONTS AND CHARACTERS 9 COLORS 10 CURSORS 11 ATOMS, PROPERTIES, AND SELECTIONS 12 EVENTS AND INPUT 13 RESOURCES 14 CONTROL FUNCTIONS 15 EXTENSIONS 16 ERRORS A PROTOCOL VS.
    [Show full text]
  • CAPI User Guide Version 6.1 Copyright and Trademarks CAPI User Guide (Macintosh Version) Version 6.1 August 2011 Copyright © 2011 by Lispworks Ltd
    LispWorks® for Macintosh CAPI User Guide Version 6.1 Copyright and Trademarks CAPI User Guide (Macintosh version) Version 6.1 August 2011 Copyright © 2011 by LispWorks Ltd. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of LispWorks Ltd. The information in this publication is provided for information only, is subject to change without notice, and should not be construed as a commitment by LispWorks Ltd. LispWorks Ltd assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. The software described in this book is furnished under license and may only be used or copied in accordance with the terms of that license. LispWorks and KnowledgeWorks are registered trademarks of LispWorks Ltd. Adobe and PostScript are registered trademarks of Adobe Systems Incorporated. Other brand or product names are the registered trade- marks or trademarks of their respective holders. The code for walker.lisp and compute-combination-points is excerpted with permission from PCL, Copyright © 1985, 1986, 1987, 1988 Xerox Corporation. The XP Pretty Printer bears the following copyright notice, which applies to the parts of LispWorks derived therefrom: Copyright © 1989 by the Massachusetts Institute of Technology, Cambridge, Massachusetts. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, pro- vided that this copyright and permission notice appear in all copies and supporting documentation, and that the name of M.I.T.
    [Show full text]
  • Release Notes and Installation Guide
    LispWorks® Release Notes and Installation Guide Version 4 .4.5 Copyright and Trademarks LispWorks Release Notes and Installation Guide Version 4.4.5 March 2005 Copyright © 2005 by LispWorks Ltd. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of LispWorks Ltd. The information in this publication is provided for information only, is subject to change without notice, and should not be construed as a commitment by LispWorks Ltd. LispWorks Ltd assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. The software described in this book is furnished under license and may only be used or copied in accordance with the terms of that license. LispWorks and KnowledgeWorks are registered trademarks of LispWorks Ltd. Adobe and PostScript are registered trademarks of Adobe Systems Incorporated. Other brand or product names are the registered trade- marks or trademarks of their respective holders. The code for walker.lisp and compute-combination-points is excerpted with permission from PCL, Copyright © 1985, 1986, 1987, 1988 Xerox Corporation. CLX and CLUE bear the following copyright notice, which applies to the parts of LispWorks derived therefrom: Texas Instruments Incorporated, P.O. Box 149149, MS 2151, Austin, Texas 78714-9149 Copyright © 1987, 1988, 1989, 1990, 1991 Texas Instruments Incorporated. Permission is granted to any individual or institution to use, modify and distribute this software, provided that this complete copyright and permission notice is maintained, intact, in all copies and documentation.
    [Show full text]
  • Gsharp, Un Éditeur De Partitions De Musique Interactif Et Personnalisable
    Gsharp, un éditeur de partitions de musique interactif et personnalisable Christophe Rhodes* — Robert Strandh** * Department of Computing Goldsmiths, University of London London SE14 6NW United Kingdom [email protected] ** LaBRI, Université Bordeaux 1 351, Cours de la libération 33405 Talence Cedex France [email protected] RÉSUMÉ. Dans cet article, nous présentons Gsharp, un projet dont le but est la création d’un éditeur de partitions de musique traditionnelles. Le logiciel Gsharp est écrit en Common Lisp et utilise CLIM (Common Lisp Interface Manager) comme bibliothèque pour l’interaction avec l’utilisateur. De nombreux algorithmes et structures de données ont été inventés afin d’assurer un performance acceptable pour de simples interactions comme l’insertion ou la suppression d’une note ou d’un accord. ABSTRACT. In this article, we present Gsharp, a project with the purpose of creating an editor for traditional music scores. Gsharp is written in Common Lisp, and uses the CLIM (Common Lisp Interface Manager) library for interactions with the user. Several new algorithms and data structures were invented in order to ensure acceptable performance for simple interactions such as inserting or deleting a note or a chord. MOTS-CLÉS : édition de partitions, Common Lisp, CLIM, personnalisation, logiciels interactif KEYWORDS: score editing, Common Lisp, CLIM, customization, interactive software 2e soumission à Document Numérique, le 23 janvier 2009 2 2e soumission à Document Numérique 1. Introduction Gsharp est un projet dont le but est la création d’un éditeur de partitions de mu- sique. Il s’agit d’un logiciel interactif dans le sens qu’après chaque action de la part de l’utilisateur, le résultat final de la mise en page est visible.
    [Show full text]
  • Some Lisp Tools for Musicology Research Aids for an Electronic Corpus of Lute Music
    Some Lisp tools for musicology Research aids for an Electronic Corpus of Lute Music David Lewis,∗ Christophe Rhodes† Centre for Cognition, Computation and Culture Goldsmiths College, University of London New Cross, London, SE14 6NW 28th June 2006 Abstract We present the tools that have been developed in the course of implementing a resource to assist in musicological investigation of lute music. We discuss the use we have made of current Lisp-based technologies in our applications, and the modifications and customizations we have needed to make. Our tools both have the current ability to service musicological queries, and have an evident path for further development to enhance their utility. 1 Introduction There is a long history of association between musicology and computer technology. The term ‘Music Information Retrieval’ dates back at least as far as 1966 [1], and the earliest computer-based music encoding and analysis initiative, centred around the works of Josquin des Prez, was started by Lewis Lockwood and Arthur Mendel in Princeton at 1963 [2]. It is perhaps surprising, therefore, that the impact of computing on the discipline has been negligible. One reason for this is the complexity of some of the tasks required: music analysis is frequently very difficult or even impossible to specify algorith- mically and artistic, interpretative or creative processes pose special challenges. This is not, however, the case for all musicological tasks, and probably the greatest impediment to routine, productive use of computers for musicology lies in a severe lack of encoded data. Lisp’s history predates even the use of computers in musicology; the vibrancy of the user community has ebbed and flowed over the last 45 years, but it is relatively clear that Lisp is emerging from the downturn of the AI Winter: over the last five years, many developments (including implementation maintenance, library development, and the continuation of Moore’s law) have made it easier for users to run powerful software on their desktop computers.
    [Show full text]
  • GNU/Linux AI & Alife HOWTO
    GNU/Linux AI & Alife HOWTO GNU/Linux AI & Alife HOWTO Table of Contents GNU/Linux AI & Alife HOWTO......................................................................................................................1 by John Eikenberry..................................................................................................................................1 1. Introduction..........................................................................................................................................1 2. Symbolic Systems (GOFAI)................................................................................................................1 3. Connectionism.....................................................................................................................................1 4. Evolutionary Computing......................................................................................................................1 5. Alife & Complex Systems...................................................................................................................1 6. Agents & Robotics...............................................................................................................................1 7. Statistical & Machine Learning...........................................................................................................2 8. Programming languages.......................................................................................................................2 9. Missing & Dead...................................................................................................................................2
    [Show full text]
  • A Free Implementation of CLIM
    A Free Implementation of CLIM Robert Strandh∗ Timothy Moorey August 17, 2002 Abstract McCLIM is a free implementation of the Common Lisp Interface Man- gager, or CLIM, specification. In this paper we review the distinguishing features of CLIM, describe the McCLIM implementation, recount some of the history of the McCLIM effort, give a status report, and contemplate future directions. McCLIM is a portable implementation of the Common Lisp Interface Man- gager, or CLIM, specification[9] released under the Lesser GNU Public License (LGPL). CLIM was originally conceived as a library for bringing advanced fea- tures of the Symbolics Genera system[3], such as presentations, context sensitive input, sophisticated command processing, and interactive help, to Common Lisp implementations running on stock hardware. The CLIM 2.0 specification added \look-and-feel" support so that CLIM applications could adopt the appearance and behavior of native applications without source code changes. Several Lisp vendors formed a consortium in the late 80s to share code in a common CLIM implementation, but for a variety of reasons the visibility of CLIM has been limited in the Common Lisp community. The McCLIM project has created an implementation of CLIM that, in the summer of 2002, is almost feature complete. Initially created by merging several developers' individual efforts, McCLIM is being used by several programs including a music editor, a web browser, and an IRC client (see Figure 1). Some non-graphic parts of CLIM have been adopted into the IMHO web server[2]. In this paper we review the distinguishing features of CLIM, describe the McCLIM implementation, recount some of the history of the McCLIM effort, give a stlatus report, and contemplate future directions for McCLIM.
    [Show full text]