- cmucl-imp - mailman3.common-lisp.net

31 May '10

Dear CMUCL developers, I have finally released ASDF 2, officially starting with release 2.000. http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release and for inclusion in all Common Lisp implementations. I thank all those who helped develop and test this release, including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll, and many more. We welcome bug reports on our launchpad site: https://launchpad.net/asdf I'm using ASDF 2 at ITA. Recent versions are already included in ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portable naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows. * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a Lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). Or just keep the default directory hierarchies being searched empty. * Windows support may have been insufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, ECL, CMUCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Your denial of the importance of objectivity amounts to announcing your intention to lie to us. No-one should believe anything you say. - John McCarthy

1 0

2010-06 snapshot tagged
by Raymond Toy 30 May '10

30 May '10

The June snapshot has been tagged. Binaries will be uploaded soon. Besides a few random bug fixes, this snapshot includes asdf2 and mk-defsystem. You can use (require :asdf) or (require :defsystem) to load them. Ray

1 0

Including ASDF 2 in the next CMUCL release
by Faré 04 May '10

04 May '10

Dear CMUCL developers, could you test for inclusion with your implementation the current release candidate of ASDF 2 (version 1.715 as of this writing)? http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release. Could you please send us fixes for any glaring bugs, and otherwise include ASDF 2 in any alpha-testing release channel for users of your implementation? I think it's mostly ready, and I'd like to have it widely tested before the actual release, which I hope will happen this month of May 2010, hopefully without any code change (except maybe for some tweaks to enhance support for some Lisp implementations on some operating systems), and with slightly enhanced documentation (notably based on your feedback). I'm using ASDF 2 at ITA. Recent versions are already included in ECL and ABCL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portably handle naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows (though we still lack implementation-dependent configuration support except on LispWorks). [NOTE: I couldn't parse this item. I juggled the sentence structure, but I still don't get it. What kind of configuration support is needed for Windows? What aspects of configuration that we have on other OSes is missing from Windows?] * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). * On Windows, when not using cygwin, only LispWorks has proper defaults for configuration pathnames. Other implementations make do. Patches welcome. * Windows support has not been sufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Always strive to be the best yourself you can be. For you can't possibly be anyone else, anyway.

1 0

May snapshot tagged
by Raymond Toy 03 May '10

03 May '10

The May snapshots have been tagged. Binaries will be uploaded soon. To build this month's snapshot, use boot-2010-04-1 as your bootstrap file. Ray

1 0

COMPILE regression in Apr 2010 snapshot (?)
by Madhu 27 Apr '10

27 Apr '10

Helu, here is an unpolished test case to show the problem: -=-=- (defmacro frob-keyvals-string (string) (with-input-from-string (stream string) `(progn ,@(loop for key = (let ((x (read stream nil stream))) (if (eq x stream) (loop-finish) x)) for val = (read stream) for comment = (read stream) collect (list 'defvar key (list 'quote val) (string comment)))))) (frob-keyvals-string " foo fooval foocomment bar barval barcomment car carval carcomment") -=-=- When compiled with COMPILE-FILE in the 2010-04 snapshot, the above snippet appears to recompile the macro definition as many times as there are DEFVARs in the macro expansion. -- Madhu

3 6

Re: [cmucl-imp] PCL::*OPTIMIZE-GF-CALLS-P* bug when GF name is shadowed lexically
by Raymond Toy 25 Apr '10

25 Apr '10

On 2/18/10 8:49 PM, Madhu wrote: > CMUCL does not correctly handle FLETs in DEFMETHOD bodies which use the > same name as that of the generic function. > An example might be: > > ; (setq pcl::*optimize-gf-calls-p* t) > (defmethod foo (bar var) (format t "GENERICFOO ~S, ~S.%" bar var)) > > (defclass fnarr ()()) > > (defmethod foo ((bar fnarr) var) > (flet ((foo (&optional arg) > (foo var (class-of arg)))) ; gf FOO call > (foo bar))) ; local function FOO call > > ;; (incorrect) Error when evaluating > (foo (make-instance 'fnarr) t) > > > Perhaps the immediate symptom can be treated in WALK-METHOD-LAMBDA as > follows? -- Madhu > I'm not familiar with PCL at all, but that looks reasonable. I'll check it in shortly. Ray

2 4

ELW 2010 deadline extension -- April 25th
by Didier Verna 21 Apr '10

21 Apr '10

+------------------------------------------------------------+ | CALL FOR PAPERS | | 7th European Lisp Workshop | | June 22 2010, Maribor, Slovenia, co-located with ECOOP | +------------------------------------------------------------+ Important Dates =============== Submission deadline: April 25, 2010 ** EXTENDED ** Notification of acceptance: May 05, 2010 ECOOP early registration deadline: May 10, 2010 7th European Lisp Workshop: June 22, 2010 Please note that registration must be done with ECOOP itself. For more information visit http://www.european-lisp-workshop.org Contact: Didier Verna, didier(a)lrde.epita.fr Invited Speaker =============== Manuel Serrano (INRIA, France) http://www-sop.inria.fr/members/Manuel.Serrano/ Overview ======== "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp, one of the eldest computer languages still in use today, is gaining momentum again. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch, making it the ideal candidate for writing Domain Specific Languages. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and remains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. This workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit contributions that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components: there will be formal talks, and interactive turorial/demo/coding sessions. Papers ====== Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. Suggested topics include (but are not limited to): - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Protocol meta-programming and libraries - New language features and abstractions - Software evolution - Development aids - Persistent systems - Dynamic optimization - Implementation techniques - Hardware Support - Efficiency, distribution and parallel programming - Educational approaches and perspectives - Experience reports and case studies Interactive Tutorial/Demo/Coding Sessions ========================================= Additionally, we invite less formal talks in the form of interactive tutorial/demo/coding sessions. The purpose of these sessions is both to demonstrate and receive feedback on any interesting Lisp system, either stable or under development. Being less formal than technical paper presentations, these sessions are expected to be highly interactive. Submission Guidelines ===================== Potential contributors are encouraged to submit: - a long paper (around 10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes, - a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future, - a proposal for an interactive tutorial/demo/coding session (1-2 pages) describing the involved library or application, and the subject of the session. Papers (both long and short) should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms (see below). Authors will later be required to sign an ACM copyright form, as the workshop proceedings will be published in the ACM Digital Library. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=elw2010 Organizers ========== Didier Verna, EPITA Research and Development Laboratory, Paris Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel Robert Strandh, LaBRI, University of Bordeaux 1, France Christophe Rhodes, Goldsmiths College, University of London -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

ELS2010 call for participation
by Christophe Rhodes 13 Apr '10

13 Apr '10

Apologies to recipients of multiple copies of this: 3rd European Lisp Symposium =========================== May 6-7, 2010, Fundacao Calouste Gulbenkian Lisbon, Portugal Call for Participation ~~~~~~~~~~~~~~~~~~~~~~~ Registration for the 3rd European Lisp Symposium (ELS 2010) is now open at [http://www.european-lisp-symposium.org/] Scope and Programme Highlights ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. As well as presentations of the accepted technical papers and tutorials, the programme features the following highlights: - Kent Pitman of HyperMeta Inc. will offer reflections on Lisp Past, Present and Future; - Pascal Costanza will lead a tutorial session on Parallel Programming in Common Lisp; - Matthias Felleisen of PLT will talk about languages for creating programming languages; - there will be opportunities for attendees to give lightning talks and demos of late-breaking work. Social events ~~~~~~~~~~~~~~ - Symposium banquet (included with registration) - Excursion to Sintra (optional), for six centuries the favourite Summer residence of the Kings of Portugal, who were attracted by cool climates and the beauty of the town's setting. Programme Chair ~~~~~~~~~~~~~~~~ Christophe Rhodes, Goldsmiths, University of London, UK Local Chair ~~~~~~~~~~~~ Antonio Leitao, Technical University of Lisbon, Portugal Programme Committee ~~~~~~~~~~~~~~~~~~~~ + Marco Antoniotti, Universita Milano Bicocca, Italy + Giuseppe Attardi, Universita di Pisa, Italy + Pascal Costanza, Vrije Universiteit Brussel, Belgium + Irene Anne Durand, Universite Bordeaux I, France + Marc Feeley, Universite de Montreal, Canada + Ron Garret, Amalgamated Widgets Unlimited, USA + Gregor Kiczales, University of British Columbia, Canada + Antonio Leitao, Technical University of Lisbon, Portugal + Nick Levine, Ravenbrook Ltd, UK + Scott McKay, ITA Software, Inc., USA + Peter Norvig, Google Inc., USA + Kent Pitman, PTC, USA + Christian Queinnec, Universite Pierre et Marie Curie, France + Robert Strandh, Universite Bordeaux I, France + Didier Verna, EPITA Research and Development Laboratory, France + Barry Wilkes, Citi, UK + Taiichi Yuasa, Kyoto University, Japan Registration ~~~~~~~~~~~~~ Registration is open at [http://www.european-lisp-symposium.org/] and costs EUR120 (EUR60 for students) until 22nd April, and EUR200 (EUR120 for students) afterwards. Registration includes a copy of the proceedings, coffee breaks, and the symposium banquet. Accommodation is not included.

1 0

April snapshot tagged
by Raymond Toy 01 Apr '10

01 Apr '10

The April snapshot has been tagged. Binaries will be uploaded soon. This snapshot includes support for internationalization. To bootstrap this, use boot-2010-02-1.lisp. You may also want to use the -P option for build.sh so that the pot and po files are updated. If you want to update the piglatin translation, you'll need to load tools/piglatin.lisp and run (do-translations). Also, a cricital bug in SSE2 has been fixed. GC hooks that used the floating-point would corrupt the SSE2 registers and cause computations to return, essentially, random results. This didn't affect x87. Ray

1 0

I18n branch merged to trunk
by Raymond Toy 19 Mar '10

19 Mar '10

The i18n branch (intl-branch) has been merged to the trunk. To build this, you need to use boot-2010-02-1.lisp as the bootstrap file with build.sh. You may also want to use the -P option for build.sh to generate/update the po files with any new strings. There's an updated Pig latin (machine) translation that includes translations for all strings in CMUCL. Currently, hemlock, clx, and clm are not translated. It might be nice to support clx, but since that is from an external source, I'd rather not touch it. I've test this briefly on Mac OS X and Linux, and only with the unicode builds. Everything seems to be working. Ray

1 0