Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 187
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 188
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 189
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 194
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 195
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 196
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 197
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 241
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 264
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 269
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 275
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 285
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 286
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 296
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 297
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 298
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 308
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 309
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 310
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 311
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 321
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 322
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 323
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 324
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 325
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 497
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 527
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 540
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 587
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 626
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 670
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 673
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 682
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 688
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 693
Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 699
Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410
Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 272
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 110
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 130
Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 295 Didier Verna's Scientific Blog - Tag - Common LispDidier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff.2024-01-31T17:45:28+00:00Didier Vernaurn:md5:a22c53786aff986a2da4c770c233a8f9DotclearQuickref 4.0 beta 1 "The Aftermath" is releasedurn:md5:8f02a28bc783b6ec739e129a4aee9838Thursday, May 26 2022Thursday, May 26 2022Didier VernaLispCommon LispdocumentationQuicklispQuickrefreference manualsreleaseTexinfotypesetting <p>Dear all,</p>
<p>as <a href="https://www.didierverna.net/blog/index.php?post/2022/05/10/Declt-4.0-beta-1-William-Riker-is-released">previously announced</a>, I have released the first Quickref version compatible with Declt 4.0 (which is now at beta 2) and which is going to keep track of the development over there. Because Declt 4 is currently considered in beta state, so is Quickref 4 for the time being.</p>
<p>There are a number of important changes in this new major version of the library. Not much interesting from the outside is an infrastructure overhaul which improves the parallel support. The index generation code has also been rewritten to benefit from the recent changes in Declt. Slightly more interesting from the outside is an improvement of the self-documenting aspects of the public interface when used interactively, along with more usage correctness checks. Also, the build environment has been upgraded to Debian Bullseye.</p>
<p>But the most critical change, of course, is the name for the 4.x series. In compliance with the general theme (Iron Maiden songs), and because Quickref 4 is meant to closely follow the brave new Declt version, I thought "Brave New World" would be nice. On the other hand, as Declt wanders through its uncharted 4.0 beta territory, Quickref 4 is likely to suffer the consequences, so perhaps "The Aftermath" is more appropriate...</p>
<p>Anyway, the Docker images are up to date, and so is the <a href="https://quickref.common-lisp.net/" hreflang="en" title="Quickref Website">Quickref website</a>, currently documenting 2110 Common Lisp libraries.</p>
<p>Enjoy!</p>https://www.didierverna.net/blog/index.php?post/2022/05/26/Quickref-4.0-beta-1-The-Aftermath-is-released#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/171Declt 4.0 beta 1 "William Riker" is releasedurn:md5:1c96271acd67ac54443f9a8e9622871aTuesday, May 10 2022Tuesday, May 10 2022Didier VernaLispCommon LispDecltdocumentationreference manualsTexinfo <p>Today, after two years and a half of (irregular) development, and 465 commits, I have released the first beta version of <a href="https://github.com/didierverna/declt" title="Declt Repository">Declt</a> 4.0, my reference manual generator for Common Lisp libraries.</p>
<p>I seldom release official beta versions of software, let alone make announcements about them, but this one deserves an exception. Since version 3, Declt has been undergoing a massive, SOC-oriented, overhaul. The intent is to reimplement it into a clean 3-stages pipeline. Stage one, the "assessment" stage is in charge of gathering information. Stage two, the "assembly" stage, creates a documentation template specifying how the information is to be organized. Finally, Stage three, the "typesetting" stage, renders the template in a specific output format. Of course, the purpose is to eventually be able to support different kinds of templates and output formats.</p>
<p>Declt 4.0b1 marks the achievement of Stage one, which is now complete. It also contains a lot of new (and long awaited) features and improvements. The user manual has been updated to provide an overview of the new architecture, along with some details about Stage one of the pipeline. From now on, I'm also going to release new versions of <a href="https://gitlab.common-lisp.net/quickref/quickref" title="Quickref Repository">Quickref</a> to closely follow the evolution of Declt.</p>
<p>Apart from the aforementioned architecture overhaul, which really boils down to internals shaking and shouldn't affect the end-user much, a lot of new features and improvements are also provided in this release. They are listed below.</p>
<h3>Backward Incompatible Changes</h3>
<p>For the benefit of Separation of Concerns, but also for other reasons, a number of keyword arguments to the <code>declt</code> function have been renamed. <code>:hyperlinks</code> becomes <code>:locations</code>, <code>:version</code> becomes <code>:library-version</code>, <code>:texi-directory</code> becomes <code>:output-directory</code>, and <code>:texi-name</code> becomes <code>:file-name</code>.</p>
<h3>New Features</h3>
<h4>Default / Standard Values</h4>
<p>Declt now has the ability to advertise or hide properties that get default / standard values (e.g. standard method combination, <code>:instance</code> slot allocation, <em>etc.</em>).</p>
<h4>Support for Aliases</h4>
<p>Declt now recognizes and advertises "aliases", that is, funcoids which have their <code>fdefinition</code>, macro, or compiler macro function set manually to another, original, definition.</p>
<h4>Support for New Programmatic Entities</h4>
<p>Typed structures and <code>setf</code> compiler macros are now properly detected and documented with all the specific information.</p>
<h4>Proper Support for Uninterened Symbols</h4>
<p>Such symbols may be encountered on several occasions such as slot names (<code>trivialib</code>, for example, defines structures with uninterned slot names in order to prevent access to them). Definitions named with uninterned symbols are considered private, and denoted by the <em>empty set</em> package (∅).</p>
<h4>SBCL 2.1.2 Required</h4>
<p>The following enhancements depend on it:</p>
<ul>
<li>short form <code>setf</code> expanders now get correct source information,</li>
<li>method combinations lambda-lists are now documented.</li>
</ul>
<h4>Domestic <em>vs.</em> Foreign Definitions</h4>
<p>The concept of domestic (as opposed to foreign) definition has been extended to include those created in one of the sources files of the library being documented, even if the symbol naming the definition is from a foreign package. If the source file is unknown, then the symbol's package must be domestic. The general intent is to consider language extensions as domestic, hence, always documented. For example, a new method on a standard generic function (say, <code>initialize-instance</code>) will now always appear in the documentation.</p>
<p>This refinement is accompanied by a new option allowing to include foreign definitions in the generated documentation. Of course, only foreign definitions somehow related to the library being documented will appear in the documentation. Also, those definitions will in general be partial: only the parts relevant to the library being documented will appear. Continuing with the <code>initialize-instance</code> example, new methods normally appear as toplevel, standalone definitions in the documentation (and their parent generic function is simply mentioned). If foreign definitions are included however, there will be a toplevel entry for the generic function, and all methods defined in the library will be documented there (truly foreign methods won't appear at all).</p>
<h4>Introspection Heuristic</h4>
<p>Until now, there was a single heuristic for finding domestic definitions, which was to start from domestic packages and scan as many connections between symbols as possible. That heuristic is reasonably fast, but may occasionally miss some domestic definitions. Declt now has the ability to scan all symbols in the Lisp image instead of only the ones from domestic packages. This new option ensures that all domestic definitions are found, at the expense of a much greater computation time.</p>
<h4>Supported Licenses</h4>
<p>The Microsoft Public License has been added.</p>
<h4>Info Installation Category</h4>
<p>In other words, the value of Texinfo's <code>@direntry</code> command is now customizable (instead to being hardwired to "Common Lisp").</p>
<h3>Improvements</h3>
<h4>Documentation Thinning</h4>
<p>Packages reference lists do not point to methods directly anymore (as they can be reached via the generic function's reference). Also, only slots for which the parent classoid is named from another package are now referenced.</p>
<p>Files reference lists do not point to slots anymore (as they can be reached via the parent classoid's reference). Also, only methods for which the parent generic function is defined in another file are now referenced.</p>
<p>The readability of long references has been improved. In particular, they don't advertise the type of the referenced definitions anymore, when there is no ambiguity.</p>
<p>Slot documentation now advertises the slot name's package only when different from that of the parent classoid.</p>
<p>Non standalone method documentation now advertises the source file only when different from that of the parent generic function.</p>
<p>The rendering of EQL specializers has been inmproved.</p>
<p>The documentation of <code>setf</code> / writer methods doesn't render the "new value" argument / specializer anymore.</p>
<h4>Merging</h4>
<p>Generic definitions containing only reader / writer methods are upgraded to specific reader / writer categories, and definition merging is now only attempted on those.</p>
<h4>Lambda Lists</h4>
<p>Uninformative parts of lambda lists are now filtered out. This includes <code>&whole</code>, <code>&environment</code>, <code>&aux</code> variables, along with options / keyword variables and default values.</p>
<p>Method specializers in lambda lists now link back to their respective class definitions.</p>
<h4>Method Combinations</h4>
<p>The method combination discovery scheme has been upgraded to benefit from SBCL 1.4.8's enhancements (themselves following my <a href="https://www.lrde.epita.fr/~didier/research/publications/papers.php#verna.18.els" title="Paper Link">ELS 2018 paper</a>). The old code didn't break, but prevented unused method combinations from being detected.</p>
<h3>Bug Fixes and Workarounds</h3>
<h4>ASDF</h4>
<p>Better handling of missing / unloaded components or dependencies (this can happen for instance with feature-dependent conditional inclusion).</p>
<p>Cope with the lack of specification of the license information in ASDF systems by coercing to a string.</p>
<p>Fix several cases of system files documentation duplication. Declt automatically documents .asd files as special cases of Lisp files. However, some systems have the bad (IMHO) habit of mentioning them explicitly as components (e.g. static files). When this happens, Declt silently discards that definition and keeps its own (at the expense of having a slightly incorrect system documentation).</p>
<h4>Anchoring</h4>
<p>After <strong>years</strong> of vain attempts at providing human-readable yet unique anchor names (which was only really useful for Info, BTW), I finally got rid of my last bit of idealism. Anchor names now use numerical definition UIDs, and since Texinfo allows me to expand references with some more information than just the anchor, it's good enough. Besides, it fixes the last remaining rare cases exhibiting the fact that it's just impossible to have anchors that are both human-readable and unique.</p>
<h4><code>Setf</code> Expanders</h4>
<p>Fix the computation of short form <code>setf</code> epxander lambda lists (which didn't correctly handle the presence of optional or rest arguments before.</p>
<p>Handle the potential unavailability of a <code>setf</code> expander's update function or short form operator. Document it if applicable. Also signal a warning when the expander is domestic.</p>https://www.didierverna.net/blog/index.php?post/2022/05/10/Declt-4.0-beta-1-William-Riker-is-released#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/170TFM 1.1 "Carolingan Miniscules" is releasedurn:md5:2ee99c7ec0d8304e8cdf28039bd45ee1Monday, March 16 2020Monday, March 16 2020Didier VernaLispCommon LispfontreleaseTeXTFMtypesetting <p>I'm happy to announce the release of TFM version 1.1 "Carolingan Miniscules". TFM is a TeX Font Metrics parser library for Common Lisp.</p>
<p>This release provides support for font scaling and freezing. Scaling is done, as in TeX, by overriding the font's design size, all other dimensions remaining relative to it. Freezing, on the other hand, converts all relative dimensions into absolute ones, potentially saving a lot of run-time arithmetic computation.</p>
<p>Get it at the usual <a href="https://www.lrde.epita.fr/~didier/software/lisp/typesetting.php#tfm" hreflang="en" title="TFM">place</a>.</p>https://www.didierverna.net/blog/index.php?post/2020/03/16/TFM-1.1-Carolingan-Miniscules-is-released#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/165Quickref 3.0 "The Alchemist" is releasedurn:md5:b03de99bb1f33499218b1ec82abc4367Thursday, November 21 2019Thursday, November 21 2019Didier VernaLispCommon LispdocumentationQuickrefreference manualsrelease <p>Following up with the latest <a href="https://www.didierverna.net/blog/index.php?post/2019/11/19/Declt-3.0-Montgomery-Scott-is-released">release of Declt</a>, I'm also happy to announce the release of <a href="https://www.lrde.epita.fr/~didier/software/lisp/typesetting.php#quickref" hreflang="en" title="Quickref homepage">Quickref 3.0</a> "The Alchemist", our reference manuals aggregator for Quicklisp libraries. The official <a href="http://quickref.common-lisp.net" hreflang="en" title="Quickref official website">website</a> has been updated yesterday with both the latest Quicklisp version, and the new Declt, resulting in the documentation of 1792 Common Lisp libraries.</p>https://www.didierverna.net/blog/index.php?post/2019/11/21/Quickref-3.0-The-Alchemist-is-released#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/162Declt 3.0 "Montgomery Scott" is releasedurn:md5:089d24770a162c421feec49d6bdc041dTuesday, November 19 2019Tuesday, November 19 2019Didier VernaLispCommon LispDecltdocumentationreference manualsreleaseTexinfo <p>I'm pleased to announce the release of Declt 3.0 "Montgomery Scott", my Texinfo reference manual generator for Common Lisp libraries.</p>
<p>This is a new major release of the library, although the changes may not be so visible from the outside. The main concern in this release has been to increase the robustness of the output, from three different angles.</p>
<ol>
<li>Many places from where Declt attempts to extract meaningful information are underspecified (ASDF system slots notably).</li>
<li>The pretty-printing of Lisp items can be difficult, given the liberalism and extensibility of the language.</li>
<li>Finally, several restrictions in the syntax of Texinfo itself (anchor names notably) get in the way.</li>
</ol>
<p>These issues were described in a <a href="https://www.lrde.epita.fr/~didier/research/publications/papers.php#verna.19.tug" hreflang="en" title="TUG 2019 Paper">paper</a> presented at the TeX Users Group conference, this summer in Palo Alto. This release goes a long way toward fixing them.</p>
<p>The new generated reference manuals look mostly the same as before, but some important things have changed under the hood, notably the names of hyperlinks and cross-references (backward-incompatible, hence the increase in the major version number). The output is now also much more robust with respect to the final output format: the generation of HTML, DVI, Postscript, PDF, and even plain Info should work fine and has been tested on all Quicklisp libraries (in fact, Quickref will also be upgraded in the near future to provide all those formats at once).</p>
<p>Those improvements do come at a cost. Unicode is now required (even for Info readers). To be honest, many Lisp libraries already had that implicit requirement. Also, this release depends on improvements and bug fixes only available in Texinfo 6.7, now a requirement as well. I have to thank Gavin Smith, from the Texinfo team, for his collaboration.</p>
<p>Apart from that, this release also has a number of bug fixes.</p>
<ul>
<li>Some method specializers were not handled properly.</li>
<li>The manuals were missing documentation for some non-Lisp source files.</li>
<li>There were some glitches in the pretty-printing of unreadable objects.</li>
</ul>
<p>Get it at the <a href="https://www.lrde.epita.fr/~didier/software/lisp/typesetting.php#declt" hreflang="en" title="Declt home page">usual place</a>, and enjoy!</p>https://www.didierverna.net/blog/index.php?post/2019/11/19/Declt-3.0-Montgomery-Scott-is-released#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/161Quickref 2.0 "Be Quick or Be Dead" is releasedurn:md5:d222f8ae490f9a3e218807c72a48f4e9Monday, April 8 2019Monday, April 8 2019Didier VernaLispCommon LispDecltdocumentationLispQuicklispQuickrefreference manuals <p>Surfing on the energizing wave of ELS 2019, the <a href="https://european-lisp-symposium.org/2019/index.html" hreflang="en" title="12th European Lisp Symposium">12 European Lisp Symposium</a>, I'm happy to announce the release of Quickref 2.0, codename "Be Quick or Be Dead".</p>
<p>The major improvement in this release, justifying an increment of the major version number (and the very appropriate codename), is the introduction of parallel algorithms for building the documentation. I presented this work last week in Genova so I won't go into the gory details here, but for the brave and impatient, let me just say that using the parallel implementation is just a matter of calling the <code>BUILD</code> function with <code>:parallel t :declt-threads x :makeinfo-threads y</code> (adjust x and y as you see fit, depending on your architecture).</p>
<p>The second featured improvement is the introduction of an author index, in addition to the original one. The author index is still a bit shaky, mostly due to technical problems (calling <code>asdf:find-system</code> almost two thousand times simply doesn't work) and also to the very creative use that some library authors have of the ASDF <code>author</code> and <code>maintainer</code> slots in the system descriptions. It does, however, a quite decent job for the majority of the authors and their libraries'reference manuals.</p>
<p>Finally, the repository now has a fully functional continuous integration infrastructure, which means that there shouldn't be anymore lags between new Quicklisp (or Quickref) releases and new versions of the <a href="http://quickref.common-lisp.net" hreflang="en" title="documentation website">documentation website</a>.</p>
<p>Thanks to Antoine Hacquard, Antoine Martin, and Erik Huelsmann for their contribution to this release! A lot of new features are already in the pipe. Currently documenting 1720 libraries, and counting...</p>https://www.didierverna.net/blog/index.php?post/2019/04/08/Quickref-2.0-Be-Quick-or-Be-Dead-is-released#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/159Announcing Quickref: a global documentation project for Common Lispurn:md5:f1aa517f7c1930e0f40691fb0c3c7909Wednesday, December 13 2017Wednesday, December 13 2017Didier VernaLispCommon LispDecltdocumentationreference manuals <p>Today, we deployed the first version of <a href="http://quickref.common-lisp.net" hreflang="en">Quickref</a>, a new global documentation project for Common Lisp.</p>
<p>The purpose of Quickref is to provide a centralized collection of reference manuals for the whole <a href="https://www.didierverna.net/blog/index.php?post/2017/12/13/quicklisp.org" hreflang="en">Quicklisp</a> world. This means around 1500 libraries, for a total of around 3000 ASDF systems. The reference manuals are generated by <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt" hreflang="en">Declt</a>, which is probably the most complete documentation system for Common Lisp currently available, and delivered in HTML (PDF versions could easily be made available as well).</p>
<p>A lot of things can still be improved, but I'm pretty satisfied with the result so far. 3000 ASDF systems is a hell of a test suite for Declt, and I'm happy to report that it passes on practically all of them. Only a couple of issues remain, not even due to Declt itself, and less than a dozen or so libraries still pose problems (mostly technical difficulties due to foreign dependencies).</p>
<p>Quickref was made by Antoine Martin, as part of an internship with me. Many thanks to him! We still have some cleanup and packaging to do, but we expect to open-source the infrastructure soon. I also want to thank Mark Evenson, Erik Huelsmann and the <a href="http://cl-foundation.org/" hreflang="en">Common Lisp Foundation</a> for hosting the project on common-lisp.net (it was only natural)!</p>
<p>Finally, let me restate this again (and again): reference manuals are not user manuals. They are... reference manuals. Although automatically generated, there are some things you can do, as a library author, to improve the output (this is an area of Declt which I intend to work on in the future). Please refer to the Declt user manual (notably section 3.2 <a href="https://www.lrde.epita.fr/~didier/software/lisp/declt/user/" hreflang="en">Coding Style</a>) for more information.</p>https://www.didierverna.net/blog/index.php?post/2017/12/13/Announcing-Quickref%3A-a-global-documentation-project-for-Common-Lisp#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/154Standard IO syntax and the Robustness Principleurn:md5:1121e4f37da4394f2ad923def9408855Friday, October 27 2017Friday, October 27 2017Didier VernaLispCommon Lispcommon-lisp-statdeclt <p>Here is a flagrant illustration of the <a href="https://en.wikipedia.org/wiki/Robustness_principle" hreflang="en">robustness principle</a>, or rather, of a failure to honor it.</p>
<p>I was investigating a bug in <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt" hreflang="en">Declt</a> where some floating point numbers were printed with exponent markers (<em>e.g.</em> <code>0.5f0</code> instead of just <code>0.5</code>) in the Texinfo file, which broke the parsing of the file by Perl.</p>
<p>Eventually, I found out a double infringement of the robustness principle. First of all, Declt failed to comply with part 1 of the robustness principle: <em>be lenient with the others</em>. The Texinfo file generation routine should have been wrapped into a call to <code>WITH-STANDARD-IO-SYNTAX</code> and it wasn't. Always do that to be on the safe side. Lesson learnt.</p>
<p>This failure on my part, however, had the interesting consequence of exhibiting what I consider a serious infringement of part 2 of the robustness principle: <em>be strict with yourself</em>. It would have remained unnocited otherwise. The culprit here is not Declt. This time, it's the <a href="https://github.com/blindglobe/common-lisp-stat" hreflang="en">common-lisp-stat</a> library. Problem: the simple fact of loading this library globally changes the value of <code>*READ-DEFAULT-FLOAT-FORMAT*</code> from <code>SINGLE-FLOAT</code> (the default) to <code>DOUBLE-FLOAT</code>. This is bad, and it can break your code in all sorts of nasty ways.</p>
<h3>Explanation</h3>
<p><code>*READ-DEFAULT-FLOAT-FORMAT*</code> tells the reader how to read floats when no exponent marker is provided. By default, <code>0.5</code> will be read as a <code>SINGLE-FLOAT</code>. But this variable also influences the printer (out of a concern for printing readably I guess): when printing a float of a different format than the current default, then the appropriate exponent marker is also printed. So here is precisely what happened. Declt had been compiled with some floats (<em>e.g.</em> <code>0.5</code>) read as <code>SINGLE-FLOAT</code>s. Later on, those floats were supposed to be printed aesthetically as such. But right after loading common-lisp-stat, the default format changed to <code>DOUBLE-FLOAT</code> and all of a sudden <code>0.5</code> started to be printed as <code>0.5f0</code>.</p>
<h3>Consequences</h3>
<p>This is bad enough already, but consider that messing with the standard IO syntax globally like this can break your code in all other sorts of even nastier ways. Imagine for instance that common-lisp-stat had been loaded <strong>before</strong> Declt, and Declt needed to be recompiled. All of a sudden, Declt would be using double floats and the bug would be gone. That is, until the next start of the REPL, after which all floats would be printed like <code>0.5d0</code>!</p>
<p>So granted, my code wasn't robust enough. But please, don't mess with standard IO syntax globally!</p>https://www.didierverna.net/blog/index.php?post/2017/10/27/Standard-IO-syntax-and-the-Robustness-Principle#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/153Declt 2.3 "Robert April" is outurn:md5:c62c272c8682fecab7cc014fb36bfbe1Monday, October 16 2017Monday, October 16 2017Didier VernaLispCommon LispDecltdocumentationreference manualsreleasesoftwareTexinfo <p>I'm happy to announce the release of Declt 2.3. Declt is my reference manual generator for Common Lisp libraries.</p>
<p>The improvements and bug fixes in the last two releases are the result of running Declt against the whole Quicklisp world (around 3000 ASDF systems for 1500 libraries).
See this <a href="https://www.didierverna.net/blog/index.php?post/2017/12/13/Announcing-Quickref%3A-a-global-documentation-project-for-Common-Lisp">post</a> for more information.</p>
<p>New in this release:</p>
<ul>
<li>Advertise file extensions in references.</li>
<li>Advertise the type of foreign definitions.</li>
<li>More robust display and indexing of, and with, lambda-lists.</li>
<li>Use UTF8 special characters to denote invisble ones.</li>
<li>More robust support for Texinfo brace escaping.</li>
<li>Handle modules sharing the same location.</li>
<li>Ensure output is done with standard IO syntax.</li>
<li>Fix potential duplication of some (non-lisp) files and document all static files.</li>
<li>Fix potential duplication of packages documentation.</li>
</ul>
<p>From the 2.2 "Christopher Pike" release (not previously advertised):</p>
<ul>
<li>Require a UTF-8 environment.</li>
<li>Understand ASDF's notion of inferred system, and also be more protective against ASDF extensions.</li>
<li>Support for improper lambda lists (e.g. destructuring ones).</li>
<li>Improve contact defaulting code.</li>
<li>Update support for SBCL's setf expanders introspection.</li>
<li>Accept ASDF system designators.</li>
<li>Various bug fixes in the areas of method combinations, accessor definition merging and setf expanders.</li>
</ul>
<p>Find it at the usual <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">place</a>...</p>https://www.didierverna.net/blog/index.php?post/2017/10/16/Declt-2.2-Christopher-Pike-is-out#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/152Declt 2.1 "Jonathan Archer" is outurn:md5:14f228dcdb2b1b0feaf268d6dcdb523aTuesday, February 28 2017Tuesday, February 28 2017Didier VernaLispASDFCommon LispDecltdocumentationreference manualsrelease <p>I'm happy to announce the release of Declt 2.1 "Jonathan Archer".</p>
<p>New in this release:</p>
<ul>
<li>Handle recent change in SBCL's <code>SB-INT:INFO</code> API.</li>
<li>Handle list of contacts (strings) in ASDF systems author and maintainer slots.</li>
<li>Some backward-incompatible changes in the keyword arguments to the <code>DECLT</code> function.</li>
<li>More hyperlinks between systems and source files.</li>
<li>More robust system's packages collection (no more code walking).</li>
<li>More robust handling of unavailable ASDF components.</li>
<li>More robust naming of cross-references.</li>
</ul>
<p>Find it at the usual <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">place</a>...</p>https://www.didierverna.net/blog/index.php?post/2017/02/28/Declt-2.1-Jonathan-Archer-is-out#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/150Declt 2.0.1 "Benjamin Sisko" is outurn:md5:0c5f5b9f5ab65da29b5d73d88e331b6aWednesday, November 4 2015Wednesday, November 4 2015Didier VernaLispASDFCommon LispDecltdocumentationreference manualsrelease <p>Declt 2.0.1 "Benjamin Sisko" is out. This is a bugfix release with one internal change (a special variable was not following the earmuffs convention) and one actual bugfix (the same Texinfo anchor was generated for symbols with the same name but in different packages).</p>
<p>Find it at the usual <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">place</a>...</p>https://www.didierverna.net/blog/index.php?post/2015/11/04/Declt-2.0.1-Benjamin-Sisko-is-out#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/144ASDF-FLV 2.0urn:md5:86c9e018615bed99c9798f4c92c57eaaMonday, October 12 2015Monday, October 12 2015Didier VernaLispASDFASDF-FLVCommon Lisprelease <p>I've just released version 2.0 of <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#asdf-flv">ASDF-FLV</a>, my ASDF extension for supporting file-local variables (ala <code>*PACKAGE*</code>). The code hasn't changed, but as for my other libraries, the system and package names are now prefixed with <code>net.didierverna</code>. ASDF-FLV is also available on <a href="https://github.com/didierverna/asdf-flv" hreflang="en">GitHub</a> now.</p>
<p>The reason I'm doing this now is that at least two of my other libraries are going to use it in a mandatory way, either directly or indirectly (and in turn, that's because no implementation has bothered to implement CDR #9 yet ;-).</p>https://www.didierverna.net/blog/index.php?post/2015/10/12/ASDF-FLV-2.0#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/141The Return of Segfaultsurn:md5:e0812f09dafade8f30cb198e46a3b5d5Wednesday, August 5 2015Wednesday, August 5 2015Didier VernaLispCommon LispconferenceECOOPOptional TypesSTOPWeak Typing <p>I was watching the discussion between Gilad Bracha and Matthias Felleisen on gradual typing this afternoon (it's available on <a href="https://youtu.be/JBmIQIZPaHY" hreflang="en">YouTube</a>). This was the last event at the STOP workshop, part of ECOOP 2015 in Prague. I couldn't attend it because I was somewhere else (Curry On) at the time. The discussion is interesting, but if you go all the way, in the last 10 minutes or so, you will notice that Matthias seems to be completely obsessed with what he calls the "Return of the SegFaults".</p>
<p>Basically, the point is the following. Mathias dislikes the optional types in Common Lisp because it's opening the door to unsafety. Initially, any dynamic language has a sound type system (all type errors are caught; at run-time, yes, but they are caught). As soon as you introduce an optional type system ala Lisp, the compiler implementors are "pushed" to use the provided type information for optimization, hence weakening the type system and breaking soundness. It's the "return of segfauts".</p>
<p>Of course, I agree with that, at least on the principle. Yes, Common Lisp's weak, optional type system is an antiquated thing. However, it seems to me that Matthias is forgetting two important things on the practical level:</p>
<ol>
<li>by default in many implementations that I know, if not all of them, introducing type declarations doesn't actually break the soundness of the type system but leads to even more type checking. For example, <code>(defun plus (a b) (+ a b))</code> works on every possible numerical value, but add <code>(declare (type fixnum a b))</code> in there and it will suddenly stop working on anything else but integers. It's only if you require the compiler to optimize for <code>speed</code> at the expense of <code>safety</code> that you effectively weaken your type system.</li>
<li>In practice, the risk of re-introducing segfaults in your application may be mitigated by the interactive aspect of the development (TDD made easier, simultaneous write / compile / run / test / debug phases etc.).</li>
</ol>
<p>So my impression is that Matthias is largely exaggerating the problem, but I'm not really qualified to tell. That's why I would like to know from you guys, working with Lisp in the industry, writing large applications, lots of type annotations, and <code>(declaim (optimize (speed 3) (safety 0) (debug 0))</code> (EDIT: that's exaggerated of course, I really mean breaking safety for performance reasons): how much of a problem the "return of the segfaults" really is in practice ?</p>
<p>As a side note, this reminds me of the dynamic vs. lexical scoping debate. Many people were and still are strongly opinionated against dynamic scoping by default. Of course, I too, at least in principle. But how dangerous dynamic scoping really is in practice (EDIT: I'm not talking about expressiveness, e.g. closures, here. Only unsafety.)? What I can tell you is that in the 15 years I was actively maintaining the XEmacs codebase, I may have run into name clashes due to dynamic scoping... twice.</p>https://www.didierverna.net/blog/index.php?post/2015/08/05/The-Return-of-Segfaults#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/138Declt 2.0 is out -- IMPORTANTurn:md5:2f726f4c179437afc9ce519a7a68a6d8Monday, July 13 2015Monday, July 13 2015Didier VernaLispASDFCommon LispDecltdocumentationreference manualsrelease <p>Declt 2.0 "Kathryn Janeway" is out. This release doesn't contain any change in functionality, yet deserves a major version upgrade since it contains 3 important changes: an infrastructure revamp (along the lines of what <a href="https://www.lrde.epita.fr/~didier/software/lisp/clon.php">Clon</a> endured not so long ago), a license switch from the GNU GPL to a BSD one, and finally a system / package name change. The prefix is now <code>net.didierverna</code> instead of <code>com.dvlsoft</code>. Do I need to apologize for this again? :-)</p>
<p>Find it at the usual <a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">place</a>...</p>https://www.didierverna.net/blog/index.php?post/2015/07/13/Declt-2.0-is-out-IMPORTANT#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/137Insider Threat Detection at Haystaxurn:md5:b119977f0519c1e8a07db8eb45443f5bWednesday, January 14 2015Wednesday, January 14 2015Didier VernaLispAllegroCommon LispconferenceFranz Inc.Threat Detection <p>Reported to me by Craig Norvell: <a href="http://www.haystax.com" hreflang="en">Haystax</a> appears to have some interesting Lisp projects in the works. Combining Lisp, Prolog, RDF (AllegroGraph), and a BBN for insider threat detection solutions.</p>
<p>From their website:</p>
<blockquote><p>Haystax's predictive models are continuously updated based on the prevailing threat environment making it highly suitable for both detection and continuous evaluation of threats. These unique models go beyond traditional web and business intelligence to enable organizations to achieve contextual real-time situational awareness by fusing all operationally relevant information - private, public, video and live feeds - into consolidated views to show patterns and identify threats that are usually buried in too much noise or not placed in proper context.</p></blockquote>
<p>Here is a <a href="http://stids.c4i.gmu.edu/papers/STIDSPapers/STIDS2014_T11_SchragEtAl.pdf" hreflang="en">Technical paper</a>, and the <a href="http://stids.c4i.gmu.edu" hreflang="en">STIDS Conference website</a>. If you are interested, it looks like you can also attend a <a href="http://www.haystax.com/haystax-franz-inc-partner-deliver-insider-threat-detection-solutions/" hreflang="en">webcast</a> on January 21st.</p>https://www.didierverna.net/blog/index.php?post/2015/01/14/Insider-Threat-Detection-at-Haystax#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/132Declt 1.0 is outurn:md5:e8e2dc0f858d8f31ec13e9f596020d5fSaturday, August 24 2013Saturday, August 24 2013Didier VernaLispCommon LispDecltreference manualsreleaseTexinfo <p>After 15 betas, I'm happy enough with the current state of <a href="http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt" hreflang="en">Declt</a> to finally make a 1.0 release.</p>
<p>A lot of things have changed since the previous version, sometimes in a backward-incompatible way. Many more items are documented (including, as you have recently <a href="https://www.didierverna.net/blog/index.php?post/2013/08/16/Lisp-Corner-Cases%3A-Method-Combinations">seen</a>, method combinations). In addition to the reference manual, generated by Declt itself, there is now a real user manual.</p>
<p>Declt is still SBCL-only, requires ASDF 3 and Texinfo 4 but generates code that is compatible with Texinfo 5. Also, beware, I've deleted the old repository and moved the project to <a href="https://github.com/didierverna/declt" hreflang="en">GitHub</a>. Below is a more precise description of what Declt currently does.</p>
<p>Declt (pronounce "dec'let") is a reference manual generator for
Common Lisp libraries. It works by loading an ASDF system and introspecting
its contents. The generated documentation contains the description for
the system itself and its components (modules and files), the packages
defined in that system and the definitions found in those packages.</p>
<p>Exported and internal definitions are listed separately. This allows the
reader to have a quick view on the library's public API. Within each
section, definitions are sorted lexicographically.</p>
<p>In addition to ASDF system components and packages, Declt documents
the following definitions: constants, special variables, symbol macros,
macros, setf expanders, compiler macros, functions (including
setf ones), generic functions and methods (including setf ones),
method combinations, conditions, structures, classes and types.</p>
<p>The generated documentation includes every possible bit of information
that introspecting can provide: documentation strings, lambda lists
(including qualifiers and specializers where appropriate), slots
(including type, allocation and initialization arguments), definition
source file etc.</p>
<p>Every documented item provides a full set of cross-references to related
items: ASDF component dependencies, parents and children, classes direct
methods, super and subclasses, slot readers and writers, setf
expanders access and update functions etc.</p>
<p>Finally, Declt produces exhaustive and multiple-entry indexes for
every documented item.</p>
<p>Reference manuals are generated in Texinfo format (compatible, but not
requiring Texinfo 5). From there it is possible to produce readable /
printable output in info, HTML, PDF, DVI and PostScript with tools such
as makeinfo, texi2dvi or texi2pdf.</p>
<p>The Declt reference manual is the primary example of documentation generated by Declt itself.</p>https://www.didierverna.net/blog/index.php?post/2013/08/24/Declt-1.0-is-out#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/123Lisp Corner Cases: Method Combinationsurn:md5:db81def30591c38265fa88f2d26e1fb3Friday, August 16 2013Friday, August 16 2013Didier VernaLispCLOSCommon LispCommon Lisp StandardDecltmethod combinationMOP <p>In the process of writing <a href="http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">Declt</a>, I had to deepen my knowledge of some Lisp corner cases, notably in the area of introspection. As you know, Lisp has in fact more than 2 namespaces. Sometimes, introspecting a potential symbol definition in one namespace is trivial. COMPILER-MACRO-FUNCTION is one example. The "functional" namespace is heterogeneous but you can still make your way out of macros, regular or generic functions very easily. In the same vein, distinguishing constants, special variables and symbol macros in the "variables" namespace is more complicated because there is no standard way to access that information, but with the help of some vendor-specific machinery (e.g. SB-INT:INFO), it's still doable.</p>
<p>At some point, I tackled the case of method combinations, and to my greatest surprise, found out that introspecting a method combination by name is not simple. In fact, it's not even doable. The reason is that method combinations don't have a namespace proper. Let me explain why.</p>
<p>You define a new method combination of some NAME with DEFINE-METHOD-COMBINATION, and you use it with the :METHOD-COMBINATION option to DEFGENERIC. But how do you introspect a NAME for a potential method combination definition? Well, you can't do exactly that. First, there is no standard way to do so. Next, let's look at what the MOP provides. One would expect something along the lines of FIND-CLASS...</p>
<p>There is indeed something called FIND-METHOD-COMBINATION, but either I'm missing something, or it is really, and I mean <em>really</em> badly designed. The arguments to this function are: a generic function meta-object, a method combination name and some method combination options. So if this function is supposed to be the equivalent of FIND-CLASS for method combinations, what in the hell are the 1st and 3rd arguments for? In fact, it's not supposed to do what its name suggests. According to the AMOP, p.191, the purpose of this function is to "determine the method combination object used by a generic function". In practice however (at least in SBCL), it's not doing that either (see below), and anyway, determining the method combination object used by a generic function is better achieved by using the GENERIC-FUNCTION-METHOD-COMBINATION accessor.</p>
<p>So this protocol doesn't seem to make any sense. In order to understand what to make of all this, I looked at how SBCL handles method combinations (I don't know what other vendors do) and here is what I found. When you call DEFINE-METHOD-COMBINATION for some NAME, SBCL creates a new method for FIND-METHOD-COMBINATION, eql-specialized on that NAME. This method is encapsulated in a closure containing the method combination's definition, <em>ignores</em> its first argument (the generic function meta-object; that's why I said that it's not really doing what the AMOP says it does), recreates and returns a <em>new</em> method combination object on the fly every time it is called.</p>
<p>This has several consequences. First, the notion of "method combination named NAME" doesn't really make sense. Method combinations don't have a proper namespace. Every time you create a new generic function, the method combination essentially becomes local to that function. Redefining a method combination has no effect on existing generic functions using a method combination of the same NAME. To put it differently, you can end up with several generic functions using different yet equally named method combinations.</p>
<p>In Declt, I'm now assuming that programmers behave and only define method combinations once. Which brings us to the second consequence. With that assumption in mind, the "proper" way to introspect a NAME for a method combination definition (at least in SBCL) is to first look for the existence of a FIND-METHOD-COMBINATION method eql-specialized on that NAME, and then call it to retrieve the actual definition.</p>
<p>I haven't thought about it a lot yet, but it would be interesting to investigate the idea of cleaning this up a bit. I mean, establishing a real global namespace for method combinations, creating an alternate FIND-METHOD-COMBINATION protocol more along the lines of FIND-CLASS. And then, it could also be interesting to investigate on the potential applications of allowing method combination redefinition to affect live generic functions, just like class redefinition affects live instances...</p>https://www.didierverna.net/blog/index.php?post/2013/08/16/Lisp-Corner-Cases%3A-Method-Combinations#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/122Nice little trick du joururn:md5:955f71a03ef41dfd0b54836c3f8bf836Wednesday, June 26 2013Wednesday, June 26 2013Didier VernaLispCommon LispStreamsTrick <p>This morning, I came up with a nice little trick which made my day. Perhaps this is already well known or even idiomatic, but in case it is not, it goes like this.</p>
<p>Sometimes, I have to read a whole Lisp file containing more than just one toplevel form and get the contents as an unprocessed list of expressions. This happens for instance when loading a DSL program that needs post-treatment.</p>
<p>Usually, I end up doing something like this:</p>
<pre class="lisp lisp" style="font-family:inherit"><span style="color: #66cc66;">(</span>with-open-file <span style="color: #66cc66;">(</span>stream filename<span style="color: #66cc66;">)</span>
<span style="color: #66cc66;">(</span>loop <span style="color: #66cc66;">:</span><span style="color: #555;">for</span> expr <span style="color: #66cc66;">=</span> <span style="color: #66cc66;">(</span>read stream <span style="color: #b1b100;">nil</span> <span style="color: #66cc66;">:</span><span style="color: #555;">eof</span><span style="color: #66cc66;">)</span>
<span style="color: #66cc66;">:</span><span style="color: #b1b100;">if</span> <span style="color: #66cc66;">(</span><span style="color: #b1b100;">eq</span> expr <span style="color: #66cc66;">:</span><span style="color: #555;">eof</span><span style="color: #66cc66;">)</span>
<span style="color: #66cc66;">:</span><span style="color: #b1b100;">return</span> exprs
<span style="color: #66cc66;">:</span><span style="color: #555;">else</span>
<span style="color: #66cc66;">:</span><span style="color: #555;">collect</span> expr <span style="color: #66cc66;">:</span><span style="color: #555;">into</span> exprs<span style="color: #66cc66;">)</span><span style="color: #66cc66;">)</span><span style="color: #66cc66;">)</span></pre>
<p>But for some reason, this has always felt clunky to me. I mean, instead of ogling the family jewels of this poor shy file, I should be able to read it as a whole (hint: read-delimited-list) and preserve its intimacy.</p>
<p>And then I realized that the only thing that prevents me from using read-delimited-list is the lack of an ending parenthesis. But as always, Common Lisp immediately comes to the rescue, this time with its rich streams API. The idea is that you can create a string stream that just contains the closing parenthesis, and concatenate this stream at the end of the file one. I can now do something like this instead:</p>
<pre class="lisp lisp" style="font-family:inherit"><span style="color: #66cc66;">(</span>with-open-file <span style="color: #66cc66;">(</span>stream filename<span style="color: #66cc66;">)</span>
<span style="color: #66cc66;">(</span>read-delimited-<span style="color: #b1b100;">list</span> #\<span style="color: #66cc66;">)</span> <span style="color: #66cc66;">(</span>make-concatenated-stream stream <span style="color: #66cc66;">(</span>make-string-input-stream <span style="color: #ff0000;">")"</span><span style="color: #66cc66;">)</span><span style="color: #66cc66;">)</span><span style="color: #66cc66;">)</span><span style="color: #66cc66;">)</span></pre>
<p>Not only it is shorter, it also looks much more elegant to me.</p>https://www.didierverna.net/blog/index.php?post/2013/06/26/Nice-little-trick-du-jour#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/120Declt 1.0b15 "Kyoto" is outurn:md5:6cff3803caf4b135de4419ca9fafaa1cTuesday, October 23 2012Tuesday, October 23 2012Didier VernaLispCommon LispDecltdocumentationreleasesoftware <p>This is Declt 1.0b15, the "Kyoto" release...
Declt is a reference manual generator for Common Lisp libraries.</p>
<p>This version underwent a major internals overhaul, required by some of the new features described below:</p>
<ul>
<li>Packages sections now advertise all definitions instead of just the symbols naming them. They also advertise their use-list and used-by-list, with cross-references.</li>
<li>Conditions, structures and classes now advertise their sub- and super-classes, direct methods, initargs and slots, with cross-references.</li>
<li>Slots documentation include docstring, type, initargs, initforms, readers and writers with cross-references.</li>
<li>Declt now documents symbol macros and compiler macros.</li>
<li>The <code>*LINK-FILES*</code> special is gone (<code>M-x all-hail-purely-functional-style</code>).</li>
<li>All ASDF components now advertise their descriptions and long descriptions, if any.</li>
<li>Docstrings are displayed in a more reader-friendly fashion.</li>
<li>Documentation entries for methods are nested within the corresponding generic function entry.</li>
</ul>
<p>Grab it at the usual <a href="http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">place</a>.</p>https://www.didierverna.net/blog/index.php?post/2012/10/23/Declt-1.0b15-Kyoto-is-out#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/109Clon 1.0b23 is outurn:md5:0a03fbc0e1d29a2d9b9daf92cc382165Wednesday, September 26 2012Wednesday, September 26 2012Didier VernaLispClonCommon Lispreleasesoftware <p>A new version of Clon, the Command-Line Options Nuker is out.</p>
<p>Amongst other things, the following improvements have been made:</p>
<ul>
<li>Support for ABCL has been updated, now that it provides a full MOP.</li>
<li>A workaround for SBCL's CC environment variable problem has been implemented. If the variable is not set (required for sb-grovel), Clon now switches to restricted mode instead of aborting.</li>
<li>The <code>DUMP</code> macro has been extend to accept a <code>&rest</code> argument that will be passed on to the underlying, implementation-specific, dumping facility.</li>
<li>A <code>contrib</code> directory has been added, for storing unapplied patches, suggestions etc.</li>
</ul>
<p>Grab it at the usual <a href="http://www.lrde.epita.fr/~didier/software/lisp/clon.php">place</a>.</p>https://www.didierverna.net/blog/index.php?post/2012/09/26/Clon-1.0b23-is-out#comment-formhttps://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/107