About Lectures Research Software Blog
Musical Site
MySpace
Facebook

Moods Blog

Dojo Shin Kaï

RSS Feed
Thank you!

XHTML 1.0 conformant
CSS 2.0 conformant
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff.

Tuesday, February 28 2017

Declt 2.1 "Jonathan Archer" is out

I'm happy to announce the release of Declt 2.1 "Jonathan Archer".

New in this release:

  • Handle recent change in SBCL's SB-INT:INFO API.
  • Handle list of contacts (strings) in ASDF systems author and maintainer slots.
  • Some backward-incompatible changes in the keyword arguments to the DECLT function.
  • More hyperlinks between systems and source files.
  • More robust system's packages collection (no more code walking).
  • More robust handling of unavailable ASDF components.
  • More robust naming of cross-references.

Find it at the usual place...

Wednesday, November 4 2015

Declt 2.0.1 "Benjamin Sisko" is out

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).

Find it at the usual place...

Monday, October 12 2015

ASDF-FLV 2.0

I've just released version 2.0 of ASDF-FLV, my ASDF extension for supporting file-local variables (ala *PACKAGE*). The code hasn't changed, but as for my other libraries, the system and package names are now prefixed with net.didierverna. ASDF-FLV is also available on GitHub now.

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 ;-).

Monday, July 13 2015

Declt 2.0 is out -- IMPORTANT

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 Clon 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 net.didierverna instead of com.dvlsoft. Do I need to apologize for this again? :-)

Find it at the usual place...

Monday, June 29 2015

Declt 1.1 is released

Hello,

as promised last week, I've just released a new version of Declt, my reference manual generator for ASDF systems. This new version (1.1) is now able to document Clon again (the documentation of which has been updated on the website).

New in this release:

  • Declt now properly handles and documents complex system and component dependencies, such as :feature :require and :version statements,
  • Declt also documents a system's :if-feature if any.

But the most important addition is the ability to document several ASDF systems in the same reference manual. More precisely, Declt now documents not only the main system but also all its subsystems. A subsystem is defined as a system on which the main one depends on in any way, and which is also part of the same distribution (under the same directory tree). Declt also understands multiple system definitions from the same .asd file.

Enjoy!

Thursday, June 25 2015

Clon 1.0b24 is released -- IMPORTANT

Hello,

I'm happy to announce the release of the next beta version of Clon, the Common Lisp / Command Line Options Nuker library. This release doesn't contain much change in terms of functionality, but it contains a lot of change in terms of infrastructure, plus very important and backward-incompatible modifications. So if you're a Clon user, please read on.

First of all, a huge revamp of the library's infrastructure (package hierarchy, ASDF and Make implementations) occurred. A large portion of this work is actually not mine, but Fare's (big thanks to him, 'cause the level of ASDF expertise required just means that I couldn't have done that by myself). The purpose here was twofold: first, remove all logic from the ASDF files (so that other system managers could be used; not sure that's actually useful right now) and second, split the library in two: the core, basic functionality and the non-standard platform-dependent bells and whistles (read: termio support). The result is that Clon now comes with 4 different ASDF systems! A setup system allows you to configure some stuff prior to loading the library, a core system allows you to load only the basic functionality and the regular one loads everything, autodetecting platform-dependent features as before. The fourth system is auxiliary and not to be used by hand. All of this is properly documented. For a code maniac like me, this new infrastructure is much more satisfactory, and I've learned a lot about ASDF less known features.

Next, I've moved the repository to Github. Please update your links! It seems that I've lost all my former tags in the process, but oh well...Only the Git repo has moved. The main Clon web page still contains the full history of tarballs, the preformatted documentation, and will continue to do so in the future.

Finally (I've kept this to myself until the last possible minute because I'm scared like hell to tell): I've changed the systems and packages names... The com.dvlsoft prefix has been replaced with net.didierverna. All other libraries of mine will eventually endure the same surgery. It's for the best, I apologize for it and I swear I will never ever do that again, EVER (fingers crossed behind my back).

So what's next? Before considering an official 1.0 release, there are two things that I want to do. First, cleanup some remaining Fixmes and some shaky error handling. Second, provide an even simpler way of using Clon than what the Quick Start chapter in the doc demonstrates. The idea is to just implement a main function with keyword arguments, and those argument magically become command-line options.

A side-effect of this work is that Declt now chokes on Clon, because some ASDF features that it doesn't understand are in use. So Declt has a couple of new challenges ahead, and you should expect a new release in the weeks to come.

Wednesday, June 29 2011

Declt 1.0b12 is out

I've just released the next version of Declt, my reference manual generator for ASDF systems.

This release includes some fixes for the Info format target but most notably, support for documenting (generic) writer functions and methods. When it makes sense, the documentations for func and (setf func) are grouped together. Getting closer to an official 1.0 stable version...

Grab it here, and enjoy!

Tuesday, May 31 2011

Declt 1.0b11 is out

I've just released a new version of Declt, my Texinfo reference manual generator for ASDF systems. This release contains only one bugfix: when trying to create links to source files, Declt now checks whether the files actually exist or not.

Tracking this bug down had the side-effect of exhibiting a misfeature of SBCL's introspection facility: the COPY-<struct> functions (automatically generated by defstruct calls) have their definition source set to target-defstruct.lisp which is an SBCL source file. It would make more sense to set it to the file containing the defstruct call instead, as is already the case for constructors, predicates and accessor functions. Patch sent to the SBCL developers.

Tuesday, April 26 2011

ASDF-FLV and a new CDR proposal

UPDATE: the CDR proposal corresponding to this blog is now finalized. It can be referred to as CDR #9.

In my ELS 2011 lightning talk, I announced the development of a new Common Lisp library called XFormat, which provides extensible format strings. A first release of this library is imminent. In this talk, I also mentionned the need for what I called "file-local variables". A file-local variable is a user-defined special variable that would behave as *PACKAGE* and *READTABLE* with respect to *LOAD* and *COMPILE-FILE*.

I have just created and released a very small library called ASDF-FLV which provides file-local variables through ASDF. In an ideal world, this library would become obsolete because file-local variables are so simple to implement that they should rather be done as an extension to the Common Lisp Standard, and provided by every Lisp vendor. That is the purpose of a new CDR proposal that I also just published on the discussion mailing list. This proposal is attached below for reference (update: it is now the final version).

Tuesday, January 25 2011

Optional ASDF system dependencies (Clon v1.0b18)

Clon v1.0b18 is now out. Compared to the previous version, the only small bit of change is the fact that the CLISP implementation now depends only optionally on cffi, whereas that dependency was mandatory before. Doing this is actually quite simple but raised the question of optional ASDF system dependencies, a topic on which there's quite a bit to be said.

A bit of context first. Clon has a terminal autodetection feature which allows it to automatically highlight its output on a tty (see --clon-highlight=auto) and also compute the output line width in case the COLUNMS environment variable is not set. This feature requires an ioctl call which is beyond Lisp. Since one of my goals is to have as few dependencies as possible (zero being the ideal number), I looked at compiler-specific solutions to this problem. The result is that SBCL, CMU-CL, CCL and ECL provide solutions almost out-of-the-box: SBCL has a grovel contributed module, CMU-CL and CCL already have system bindings and ECL has its own ffi interface. The ABCL port doesn't support terminal autodetection yet, but that's another (Java) story. The only black sheep in the picture is CLISP which, as far as I can tell, neither has a native binding for ioctl, nore any built-in grovel facility, hence the need for cffi.

Previously, my system definition file was like that:

#+clisp (asdf:operate 'asdf:load-op :cffi-grovel)
 
(asdf:defsystem :com.dvlsoft.clon
  #| ... |#
  :depends-on (#+clisp :cffi)
  :components ((:file "package")
	                #+clisp
	                (:module "clisp"
		           :depends-on ("package")
		           :components ((cffi-grovel:grovel-file "constants")))
	                (module "src"
                          :depends-on ("package" #+clisp "clisp")
                          :components #| ... |#)))

And then later, I had a file with the concerned utility function:

(defun stream-line-width (stream)
  #+clisp (#| CLISP implementation |#)
  #| etc. |#)

After that, I started looking at ways to make the dependency on cffi optional. After all, it makes sense to avoid that dependency at the cost of not being able to autodetect terminals.

One thing I fell on almost by accident is ASDF's :weakly-depends-on keyword. Here is an interesting thread about it. It was an accident because that feature is not documented :-( People, however, have very mitigated feelings about it, as shown in this other thread (syntax and semantics both appear somewhat shaky and underspecified). Besides, the aparent behavior is that if A weakly depends on B and B is not present, then A is operated anyway. So I could probably have my "src" module weakly depend on the "clisp" one, but that doesn't change the fact the "clisp" module should not be included at all if cffi is not there.

In the same thread, somebody proposes another kind of dependency called :contigent-on which looks closer to what I would need for the "clisp" module: a module the contingency of which is not present will not be processed. This new kind of dependency doesn't seem to be implemented yet, however.

So, all of this seems a bit frightening. Too borderline for my taste. Fortunately, my solution is much simpler, although probably not universal.

This first thing to do is only attempt to load cffi-grovel:

(eval-when (:load-toplevel :execute)
  #+clisp (handler-case (asdf:operate 'asdf:load-op :cffi-grovel)
	    (asdf:missing-component ()
	      (format *error-output* "~
*********************************************************************
* WARNING: ASDF component CFFI-GROVEL not found.
* Clon will be loaded without support for terminal autodetection.
* See section A.1 of the user manual for more information.
*********************************************************************"))))

After that, if loading it were successful, we end up with cffi as a feature, so we can just conditionalize on that:

(asdf:defsystem :com.dvlsoft.clon
  #| ... |#
  :depends-on (#+(and clisp cffi) :cffi)
  :components ((:file "package")
	                #+(and clisp cffi)
	                (:module "clisp"
		           :depends-on ("package")
		           :serial t
		           :components ((cffi-grovel:grovel-file "constants")))
	                (module "src"
                          :depends-on ("package" #+(and clisp cffi) "clisp")
                          :components #| ... |#)))

One last problem remains however: what to do in the source code, for the feature-dependent parts. Conditionalizing an ASDF system may indeed lead to trouble: for instance, what would happen if the function stream-line-width was compiled with cffi around, and later used in a context where it is not? To be on the safe side, what you really need is to dynamically check for the feature. One possible solution is this:

  1. move all feature-dependent code to the "clisp" module and make that a protocol,
  2. everytime you need to access the feature, dynamically check whether the protocol functions are fbound.

In my specific case, what I did was to implement a CLISP-specific version of stream-line-width, called clisp/stream-line-width and put it in a new file in the "clisp" module, now defined as follows:

#+(and clisp cffi)
	       (:module "clisp"
		 :depends-on ("package")
		 :serial t
		 :components ((cffi-grovel:grovel-file "constants")
			                (:file "util")))

Then, the original function is rewritten like this:

(defun stream-line-width (stream)
  #+clisp (when (fboundp 'clisp/stream-line-width) (clisp/stream-line-width stream))
  #| etc. |#)

So now I think I'm on the safe side, and Clon has zero mandatory dependency again...

French Flag English Flag
Copyright (C) 2008 -- 2013 Didier Verna didier@lrde.epita.fr