Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 187

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 188

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 189

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 194

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 195

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 196

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 197

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 241

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 264

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 269

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 275

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 285

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 286

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 296

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 297

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 298

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 308

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 309

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 310

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 311

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 321

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 322

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 323

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 324

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 325

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 497

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 527

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 540

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 587

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 626

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 670

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 673

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 682

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 688

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 693

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/ on line 699

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/ on line 410

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/ on line 410

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 633

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 272

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 110

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 130

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/ in /home/didierve/ on line 295
Didier Verna's Scientific Blog Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff. 2024-01-31T17:45:28+00:00 Didier Verna urn:md5:a22c53786aff986a2da4c770c233a8f9 Dotclear Quickref 4.0 beta 1 "The Aftermath" is released urn:md5:8f02a28bc783b6ec739e129a4aee9838 Thursday, May 26 2022 Thursday, May 26 2022 Didier Verna Lisp Common LispdocumentationQuicklispQuickrefreference manualsreleaseTexinfotypesetting <p>Dear all,</p> <p>as <a href="">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="" hreflang="en" title="Quickref Website">Quickref website</a>, currently documenting 2110 Common Lisp libraries.</p> <p>Enjoy!</p> Declt 4.0 beta 1 "William Riker" is released urn:md5:1c96271acd67ac54443f9a8e9622871a Tuesday, May 10 2022 Tuesday, May 10 2022 Didier Verna Lisp Common 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="" 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="" 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>&amp;whole</code>, <code>&amp;environment</code>, <code>&amp;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="" 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> Clon 1.0b25 is out urn:md5:d0eabd92747d0bb008c68a3314de082b Wednesday, March 24 2021 Wednesday, March 24 2021 Didier Verna Lisp Cloncommand-line optionsrelease <p>Today, I'm releasing the next beta version of Clon, my command-line options management library.</p> <p>The previous official release occurred 6 years ago. Since then, a number of changes had been quietly sleeping in the trunk but never made their way into Quicklisp. More recently, I have also applied a number of changes that are worth mentioning here.</p> <p>First of all, a large part of the infrastructure as been updated, following the evolution of the 8 supported compilers, and that of ASDF and CFFI as well. This should normally be transparent to the user though, provided that one uses reasonably recent compiler / ASDF version ("reasonably" intentionally left undefined). Other than that...</p> <ul> <li>The constraints on <code>termio</code> support auto-detection had become slightly too restrictive, so they have been relaxed.</li> <li>The <code>exit</code> function has been deprecated in favor of <code>uiop:quit</code>.</li> <li>The support for running in scripts rather than in dumped executables has been improved, notably by offering the possibility to provide an alternate program name when <code>argv<a href="">0</a></code> is not satisfactory.</li> <li>Clon is now compatible with executables dumped via ASDF's <code>program-op</code> operation, or dumped natively. The demonstration programs in the distribution have been updated to illustrate both dumping methods (ASDF, and Clon's <code>dump</code> function).</li> <li>The documentation on application delivery has been largely rewritten, and has become a full chapter rather than a thin appendix.</li> </ul> <p>There are also a few bug fixes in this release.</p> <ul> <li>Several custom readtable problems have been fixed for CCL, CLISP, and ECL (thanks to Thomas Fitzsimmons). Note that Clon depends on <code>named-readtables</code> now.</li> <li>Clon now compiles its <code>termio</code> support correclty with a C++ based ECL (thanks to Pritam Baral).</li> <li>One problem in the conversion protocol for path options has been corrected (thanks to Olivier Certner).</li> </ul> <p>All entrey points are on Clon's web <a href="" hreflang="en" title="Clon">page</a>.</p> <p>Enjoy!</p> ELS 2020 happening online, and for free urn:md5:604889ed0cf9cd7a55a68c5d3f7d7101 Tuesday, April 14 2020 Tuesday, April 14 2020 Didier Verna Lisp conferenceELSLisp <p>Hi all,</p> <p>this is the latest (and probably last) update on the status of ELS 2020 with regard to the current pandemic. Jumping to the conclusion: ELS 2020 will take place on April 27-28, as initially planned, but as an online event.</p> <p>In order to minimize the technical risks, the talks are being recorded, and will be broadcast according to the schedule advertised on the website (still subject to last minute modifications). We still want the event to be interactive, so the broadcasts will be accompanied with a live chat for discussion. Specific instructions for joining the event will be advertised on the website in a timely fashion.</p> <p>I am writing this the day after French president Macron announced one more month of confinement here, and that the European borders would remain closed "until further notice". I am now convinced that this is the best solution for us, under these circumstances. Simply cancelling the event was of course completely out of the question. Organizing a fully interactive online event was considered too risky. Finally, postponing the physical event would have meant doubling the workload of the organizers, planning for an uncertain date, most probably after summer, which would also have put us too close to ELS 2021 (which will happen around the end of March, in co-location with &lt;Programming&gt; again).</p> <p>Of course, it is frustrating for everyone to miss the opportunity to meet face to face as we do each and every year, but again, under the circumstances, I truly think this is the best we can do, and I want to thank all the people for whom this new setting implies an additional workload.</p> <p>Since the very early days of ELS, we made a point in keeping the event as cheap as possible. Because the financial cost for this year was considerably reduced, we decided to make the event free and open to anyone, if it's any consolation. We also hope that this can be an incentive to bring a larger audience to the symposium, and perhaps spread the Lisp virus a bit more!</p> <p>Looking forward to watching the talks and reading you on the live chat! Stay safe.</p> <p><a href="" hreflang="en" title="ELS 2020">ELS 2020</a></p> ELS 2020 COVID update urn:md5:617f25a124fffa250322751b15bca660 Sunday, March 29 2020 Sunday, March 29 2020 Didier Verna Lisp conferenceELSLisp <p>Dear all,</p> <p>as promised two weeks ago, here is an update on the current situation of ELS 2020. Thank you all for your patience.</p> <ol> <li>Given the evolution of the world-wide situation with regard to the COVID pandemic, it will come as no surprise that we have to cancel the Zurich event.</li> <li>I have consequently closed the registrations, and I will proceed with full refunding this afternoon. Note owever that it will take some time for the money to get back to your accounts.</li> <li>In the meantime, the reviewing process has continued as usual, and I'm happy to announce that thanks to the authors, the PC, and under the supervision of Ioanna, we now have a preliminary programme online! At least, this will already give you a taste of what we have this year.</li> <li>A fallback solution is still under consideration, so stay tuned for updates. What I can tell you right now is this: a fully online event is very unlikely. More likely would be a semi-interactive online event, with the broadcasting of pre-recorded talks and a real-time channel for interaction. We have not completely ruled out the possibility of just postponing the physical event, but that solution is not very probable. Finally, if we go for an online event, I will make sure that it will be free and open for anyone to "attend".</li> </ol> <p>So, this is what I can tell you right now. Finally, I also want to extend my warmest thanks to all the persons who showed their support (notably financial, which is critical), by staying optimistic and registering anyway, hoping for the best. This means a lot.</p> <p>Stay safe!</p> TFM 1.1 "Carolingan Miniscules" is released urn:md5:2ee99c7ec0d8304e8cdf28039bd45ee1 Monday, March 16 2020 Monday, March 16 2020 Didier Verna Lisp Common 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="" hreflang="en" title="TFM">place</a>.</p> How Deep Learning may change the face of customer support urn:md5:6ce8dd165d527f37495e580074642252 Wednesday, March 11 2020 Wednesday, March 11 2020 Didier Verna Miscellaneous Customer SupportDeep Learning <p>Today, I was browsing the support forum of a software product I own a license for, and I suddenly realized something which is probably not obvious at all, especially if you're not yourself a computer scientist. For some time now, I've been noticing something I found rather odd in various threads on this forum. In many situations, one of the product developers (I guess), a very active, kind, and responsive person ends up replying "well, <em>the product</em> can't be perfect". This is a response I felt very uncomfortable with, right from the start. Why? Well, I don't think anyone expects any product (especially software) to be perfect. People on the forum just report bugs, and expect some form of acknowledgement that the bug is there, is reproducible, and that a workaround or a fix is on its way, or will be soon. But why does this developer feel the need for confessing that the product is "not perfect", and why so often? It almosts sounds like an embarassed apology.</p> <p>The product in question is in fact a real-time audio signal analysis application. In order to remain not too specific, let's just say that you feed it with some music, and it spits out the notes as it recognizes them. With my CS background, I'm used to signal processing application using Fourier transforms and whatnot to perform deterministic computation on the processed signal. But recently, I found out that this product uses Deep Learning technologies, and then I suddenly understood what's going on.</p> <p>Imagine you get a complaint that your "legacy" signal processing software is unable to recognize a C2 in a bunch of simultaneous notes. You could probably figure out (and reply) that there's a bug in your Fourier transform implementation, or that you got the amplitude computation wrong, and the note is below the activation threshold, or you have a low-cut filter that was not configured properly, or whatever.</p> <p>But now imagine that your software is a (correct) gigantic neural net. What can you say? Not only there isn't a specific algorithm to debug. On top of that, you're also completely incapable of deciphering what's really going on <strong>in</strong> the net. So you need to re-train your system, probably. But what can you say to your customer? There is no specific bug to acknowledge, let alone a specific workaround or imminent "bugfix". Besides, who knows what previously fine situation could degrade after the new training? So yes, I suppose, you're a bit stuck on how and what exactly you can reply to your customer. Apart maybe from what computer scientists know very well about that kind of technology: it can <strong>never</strong> be perfect.</p> <p>Now that I've come to realize this, it seems to me that as Deep technologies continue to spread to a variety of applications, the face of customer support may change drastically, in the sense that while users continue to experience very specific problems, it will no longer be possible to provide them with very specific answers.</p> Onward! Essays 2020 Call for Papers urn:md5:3bc9cf9a8b41a032bdf8c87c1df194a1 Tuesday, March 3 2020 Tuesday, March 3 2020 Didier Verna Miscellaneous computer scienceconferenceProgrammingProgramming Languages <pre> Onward! Essays 2020 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software Renaissance Chicago Downtown Hotel Chicago, USA November 18--20 2020 Part of SPLASH 2020 Systems, Programming Languages and Applications: Software for Humanity Onward! is a premier multidisciplinary conference focused on everything to do with programming and software: including processes, methods, languages, communities, applications and education. Compared to other conferences, Onward! is more radical, more visionary, and more open to ideas that are well-argued but not yet proven. It is not looking for research-as-usual papers. To allow room for bigger, bolder and/or less mature ideas, it accepts less exact methods of validation, such as compelling arguments, exploratory implementations, and substantial examples. Onward! Essays is looking for clear and compelling pieces of writing about topics important to the software community (there is also a parallel Papers track with a seperate announcement). An essay can be an exploration of the topic and its impact, or a story about the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps the one the author took to reach an understanding of the topic. The subject area—software, programming, and programming languages—should be interpreted broadly and can include the relationship of software to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. Format and Selection: Onward! essays must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN's Republication Policy. Submitters should also be aware of ACM's Policy and Procedures on Plagiarism. Onward! essays should use the ACM SIGPLAN Conference acmart format. Please refer to the conference's website above for full details. The Onward! Essays track follows a two-phase review process. Essays are peer-reviewed in a single-blind manner. Accepted essays will appear in the Onward! Proceedings in the ACM Digital Library, and must be presented at the conference. Submissions will be judged on the potential impact of the ideas and the quality of the presentation. Important dates: All deadlines are midnight, anywhere on Earth. Essay submission: 23 April First-round notification: 11 June Second-round submission: 15 July Final notification: 30 July Conference: 18--20 November Programme Committee: Didier Verna, EPITA Research lab, France (Program Chair) Anya Helene Bagge, University of Bergen, Norway Alexandre Bergel, University of Chile Jean Bresson, Ableton, Germany Maxime Chevalier-Boisvert, Université de Montréal, Québec Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Hidehiko Masuhara, Tokyo Institute of Technology, Japan Kent Pitman, PTC, USA Donya Quick, Stevens Institute of Technology, USA Gordana Rakić, University of Novi Sad, Serbia </pre> Quickref 3.0 "The Alchemist" is released urn:md5:b03de99bb1f33499218b1ec82abc4367 Thursday, November 21 2019 Thursday, November 21 2019 Didier Verna Lisp Common LispdocumentationQuickrefreference manualsrelease <p>Following up with the latest <a href="">release of Declt</a>, I'm also happy to announce the release of <a href="" hreflang="en" title="Quickref homepage">Quickref 3.0</a> "The Alchemist", our reference manuals aggregator for Quicklisp libraries. The official <a href="" 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> Declt 3.0 "Montgomery Scott" is released urn:md5:089d24770a162c421feec49d6bdc041d Tuesday, November 19 2019 Tuesday, November 19 2019 Didier Verna Lisp Common 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="" 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="" hreflang="en" title="Declt home page">usual place</a>, and enjoy!</p> TFM 1.0 "Artificial Uncial" is released urn:md5:44cf6fd807583e986e500351ac9a86fc Wednesday, October 9 2019 Wednesday, October 9 2019 Didier Verna Lisp fontreleaseTeXTFMtypesetting <p>I'm happy to announce the first stable version of TFM, a TeX Font Metrics parser for Common Lisp. TFM is the standard font description format used by TeX. The TFM library parses and decodes TFM files into an abstract data structure, providing easy access to the corresponding font information. Get it <a href="" hreflang="en">here</a>.</p> Quickref 2.0 "Be Quick or Be Dead" is released urn:md5:d222f8ae490f9a3e218807c72a48f4e9 Monday, April 8 2019 Monday, April 8 2019 Didier Verna Lisp Common LispDecltdocumentationLispQuicklispQuickrefreference manuals <p>Surfing on the energizing wave of ELS 2019, the <a href="" 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="" 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> Final call for papers: ELS 2019, 12th European Lisp Sympoiusm urn:md5:5f5ebc80a3961fc5fd04cfe1a02512a5 Friday, February 1 2019 Friday, February 1 2019 Didier Verna Lisp ACMconferenceELSLispSyposium <pre> ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In cooperation with: ACM SIGPLAN In co-location with &lt;Programming&gt; 2019 Sponsored by EPITA and Franz Inc. Recent news: - Submission deadline extended to Friday February 8. - Keynote abstracts now available. - &lt;Programming&gt; registration now open: - Student refund program after the conference. The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 12th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: Note: to help us with the review process please indicate the type of submission by entering either &quot;paper&quot;, &quot;demo&quot;, or &quot;tutorial&quot; in the Keywords field. Important dates: - 08 Feb 2019 Submission deadline (*** extended! ***) - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: Marco Antoniotti, Universita Milano Bicocca, Italy Marc Battyani, FractalConcept, France Pascal Costanza, IMEC, ExaScience Life Lab, Leuven, Belgium Leonie Dreschler-Fischer, University of Hamburg, Germany R. Matthew Emerson, thoughtstuff LLC, USA Marco Heisig, FAU, Erlangen-Nuremberg, Germany Charlotte Herzeel, IMEC, ExaScience Life Lab, Leuven, Belgium Pierre R. Mai, PMSF IT Consulting, Germany Breanndán Ó Nualláin, University of Amsterdam, Netherlands François-René Rideau, Google, USA Alberto Riva, Unversity of Florida, USA Alessio Stalla, ManyDesigns Srl, Italy Patrick Krusenotto, Deutsche Welle, Germany Philipp Marek, Austria Sacha Chua, Living an Awesome Life, Canada Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 </pre> FiXme 4.5 is out urn:md5:4cd0cbd7249dfa97ac0505dba2ee84c6 Thursday, January 3 2019 Thursday, January 3 2019 Didier Verna LaTeX FiXmeLaTeXreleaseTeX <p>I'm pleased to announce the release of FiXme 4.5 (my collaborative annotation tool for LaTeX).</p> <p>New in this release:</p> <pre> ** Public interface for extending FiXme with new key/value options. ** Revamp the AUCTeX support with help from Arash Esbati and Ikumi Keita. ** Fix PDF signature layouts not working anymore reported by Soeren Wolfers. ** Fix spurious space at the end of environments contents reported by Frank Mittelbach. </pre> <p>Get it at the <a href="">usual</a> place.</p> Quickref open-sourced urn:md5:304a614a4980be94308da4b4dd7073f4 Tuesday, August 7 2018 Tuesday, August 7 2018 Didier Verna Lisp Decltdockerdocumentationquicklispquickrefreference manuals <p>8 months after the <a href="">original announcement</a>, we finally open-sourced Quickref. The complete source code is available <a href="" hreflang="en">here</a>.</p> <p>I gave a lightning talk at <a href="" hreflang="en">ELS 2018</a>, in which I claimed I would release the code in "something like two weeks". That was 4 months ago :-). I apologize for the delay, especially to Zach who expressed interest in how we did the Docker thing at the time. I wanted to clean up the code before the first public release (I'm a maniac like that), which I did, but it took some time.</p> <p>Compared to what I announced at ELS, Quickref also has a couple of new features, most importantly the ability to generate documentation for only what's already installed, rather than for the whole Quicklisp world. This can be very convenient if you just want some local documentation for the things you use daily. Finally, there is also a very rudimentary support for multithreading, which currently doesn't bring much. But the code has been prepared for going further in that direction; this will be the topic of another internship which will start next September.</p> <p>Browse no less than 1588 reference manuals right now at <a href="" hreflang="en"></a>, and recreate your own local version with this Docker 2-liner:</p> <pre> docker run --name quickref quickref/quickref docker cp quickref:/home/quickref/quickref . </pre> Lisp, Jazz, Aikido, 10 years later urn:md5:1a9a3eb08ba2e6eda9dbed77320161c9 Wednesday, May 2 2018 Wednesday, May 2 2018 Didier Verna Lisp AestheticsAikidoArtJazzLispProgramming <p>10 years ago, I published a <a href="">short blog</a> entitled "Lisp, Jazz, Aikido", barely scratching the surface of what I found to be commonalities between the 3 disciplines. At the time, I had the intuition that those ideas were the tip of a potentially big iceberg, and I ended the blog with the following sentence: "I'd like to write a proper essay about these things when I find the time... someday."</p> <p>Well, 10 years later, I did. The essay, which is 50 pages long, has been published in the <a href="" hreflang="en">Art, Science, and Engineering of Programming Journal</a>, and actually received the Reviewers'Choice Award 2018. I'm not the bragging type, far from it, but I had to mention this because this essay is so personal, and I invested so much in its preparation (more than 300 hours) that I am as deeply touched by the award as I would have been hurt, had it been negatively received...</p> <p>The live presentation has unfortunately not been recorded, but I took the time to make a screencast afterwards, which is now <a href="" hreflang="en">available on YouTube</a>. Just like the essay, this presentation is not in the typical setting that you'd expect at a scientific conference...</p> <p>If you've got an artistic fiber, if you're sensitive to the aesthetic dimension in what you do, you may enjoy this work...</p> Announcing Quickref: a global documentation project for Common Lisp urn:md5:f1aa517f7c1930e0f40691fb0c3c7909 Wednesday, December 13 2017 Wednesday, December 13 2017 Didier Verna Lisp Common LispDecltdocumentationreference manuals <p>Today, we deployed the first version of <a href="" 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="" 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="" 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="" hreflang="en">Common Lisp Foundation</a> for hosting the project on (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="" hreflang="en">Coding Style</a>) for more information.</p> Standard IO syntax and the Robustness Principle urn:md5:1121e4f37da4394f2ad923def9408855 Friday, October 27 2017 Friday, October 27 2017 Didier Verna Lisp Common Lispcommon-lisp-statdeclt <p>Here is a flagrant illustration of the <a href="" hreflang="en">robustness principle</a>, or rather, of a failure to honor it.</p> <p>I was investigating a bug in <a href="" 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="" 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> Declt 2.3 "Robert April" is out urn:md5:c62c272c8682fecab7cc014fb36bfbe1 Monday, October 16 2017 Monday, October 16 2017 Didier Verna Lisp Common 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="">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="">place</a>...</p> FiXme 4.4 is out urn:md5:c63418fb8ec3cddcb8f34732762b40d5 Sunday, March 5 2017 Sunday, March 5 2017 Didier Verna LaTeX FiXmeLaTeXreleaseTeX <p>I'm pleased to announce the release of FiXme 4.4 (my collaborative annotation tool for LaTeX).</p> <p>New in this release:</p> <pre> ** Handle existing yet empty lox files properly meaning, don't actually typeset an empty list of corrections. ** Don't update the lox file in final mode avoiding potential typesetting artifacts, reported by Lars Madsen. ** Various internals and documentation improvements. </pre> <p>Get it at the <a href="">usual</a> place.</p>