About Lectures Research Software Blog
Musical Site

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.

Thursday, June 25 2015

Clon 1.0b24 is released -- IMPORTANT


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, September 26 2012

Clon 1.0b23 is out

A new version of Clon, the Command-Line Options Nuker is out.

Amongst other things, the following improvements have been made:

  • Support for ABCL has been updated, now that it provides a full MOP.
  • 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.
  • The DUMP macro has been extend to accept a &rest argument that will be passed on to the underlying, implementation-specific, dumping facility.
  • A contrib directory has been added, for storing unapplied patches, suggestions etc.

Grab it at the usual place.

Tuesday, May 22 2012

Clon 1.0b22 is out

A new version of Clon, the Command-Line Options Nuker is out.

The most important change in this release is the support for LispWorks, which brings the number of supported implementations to 8. One left to go, and I may eventually switch to RC status. Thanks to Martin Simmons for providing a fully functionnal version of LW 6.1. As for CLISP and Allegro, there is an optional dependency on CFFI for LispWorks.

Two backward incompatible changes that may affect you:

  • Variables renamings: *current-context* has been renamed *context*, and *default-synopsis* has been renamed *synopsis*. This should remain transparent unless you're using Clon in a somewhat advanced way.
  • clon:exit has been upgraded to SBCL's new quitting protocol. If you use this function (or if you want to compile the demo programs), please upgrade to SBCL 1.0.57.

Finally, support for terminal autodetection and stream handling in general has been improved for all implementations.

Grab it at the usual place.

Monday, March 12 2012

Clon 1.0b21 is out

One year between b19 and b20. 4 days between b20 and b21...

This new version of Clon introduces support for a new compiler, Allegro Common Lisp, in both standard and modern form. Support for dumping is only rudimentary for ACL (although it's only a marginal feature of the library). The dump macro uses Allegro's dumplisp mechanism to dump a lisp image which is not directly executable (full application delivery is complicated and only available in the Enterprise edition). Apart from that, the rest should work fine. As in the case of CLISP, Allegro may benefit from the presence of CFFI in order to provide terminal autodetection. This is an optional dependency only.

Grab it at the usual place.

Thursday, March 8 2012

Clon 1.0b20 is out

I'm happy to announce a new release of Clon, the Command-Line Options Nuker for standalone Common Lisp executables. In addition to a lot of uninteresting code and infrastructure changes, this new release comes with several important improvements and new features.

At the end-user level

  • there is a new error handler available via the --clon-error-handler option, called "interactive". This error handler provides the same restarts as the one called "none" (which actually triggers the Lisp debugger), but in a less frightening way for end-users not knowing about Lisp at all. In particular, the error and restart messages are more readable and you don't see a Lisp stack anywhere. See the end-user manual and the user manual for more information.
  • there is a new option called --clon-lisp-information which, as its name suggests, provides information about the underlying Lisp (implementation type and version). This will in fact be more useful for developers than for end-users, but it's still and end-user level feature. See the end-user manual for not much more information.

At the user-level

  • Clon now provides a command-line polling API through the functions cmdline-options-p and cmdline-p. See the user manual for more information.
  • Support for using Clon interactively, that is, without dumping executables has been improved. This is mostly useful for debugging purposes. See the user manual for more information.
  • Clon now provides a compile-time / run-time unified configuration facility thanks to a variable named cl-user::com.dvlsoft.clon.configuration that is handled before the ASDF system is loaded. Thanks to this, Clon is now able to communicate its own indentation information to (X)Emacs directly (thanks to a process that I've previously described here), and also handles portability problems in a smoother way (see below).
  • One of the available configuration options is called :restricted mode. In this mode, Clon never attempts to communicate with ttys via ioctl calls, at the expense of terminal autodetection (size and highlighting). This is implemented by making a termio ASDF module conditionally loaded in the system definition. There are cases where Clon will switch to restricted mode automatically (e.g. when using CLISP compiled without FFI support). However, some other situations are more problematic, for instance when using SBCL under MinGW, in which case the SB-GROVEL module is available but doesn't work. In such situations, it is necessary to configure Clon explicitely for restricted mode before loading the system. See the user manual for more information.

That's it. Grab it at the usual place. Yesterday, I realized that it's been slightly more than a year since the b19 release. Gee, time flies like the wind...

Wednesday, February 9 2011

Clon 1.0b19 is out

Clon version 1.0b19 has just been released. This version comes with a couple of fixes related to error handling and a switch from the GPL to the BSD license. Grab it here.

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")
	                (: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...

Monday, January 24 2011

Clon 1.0b17 is out

I'm happy to announce the release of Clon version 1.0b17. This version notably introduces support for ABCL and expands the documentation in the portability section. Grab it here.

Tuesday, November 30 2010

Clon v1.0b16 now supports CLISP


I'm happy to annouce the release of Clon version 1.0 beta 16.
Most notable news for this release is the support for CLISP, which comes at the expense on one dependency (over cffi).

Grab it here.

Thursday, November 18 2010

Clon v1.0b15 now supports ECL


I'm happy to annouce the release of Clon version 1.0 beta 15.
Most notable news for this release is the support for ECL.

Grab it here

Thursday, November 11 2010

Clon v1.0b12 now supports CCL


I'm happy to annouce the release of Clon version 1.0 beta 12.
Most notable news for this release is the support for CCL.

Grab it here.

Tuesday, November 9 2010

Clon 1.0b11 now supports CMU-CL


I'm happy to annouce the release of Clon version 1.0 beta 11.
Most notable news for this release is the support for CMU-CL.

Grab it here.

Tuesday, August 31 2010

Clon: the Command-Line Options Nuker library for Common Lisp

I'm happy to announce the first public release of Clon, the Command-Line Options Nuker library for Common Lisp.

Clon currently requires SBCL to work. If you want to help porting it to other implementations, 'grep PORTME **/*' in the sources.

Get it here.

Clon is a library for managing command-line options in standalone Common Lisp applications. It provides a unified option syntax with both short and long names, automatic completion of partial names and automatic retrieval/conversion of option arguments from the command-line, associated environment variables, fallback or default values. Clon comes with a set of extensible option types (switches, paths, strings etc.). Clon also provides automatic generation and formatting of help strings, with support for highlighting on tty's through ISO/IEC 6429 SGR. This formatting is customizable through "themes".

Monday, March 30 2009

ILC 2009 lightning talks

As almost every participant I believe, my opinion is that the lightning talks were a great idea in the first place, and also a great success.

At the very last minute, I changed my mind about the contents. I got a bit bored with too much Lisp technical stuff and decided I would talk about Lisp, Jazz and Aïkido for a change (see the corresponding Sci-Blog entry). Some people did like the idea and I got several very interesting conversations after that. It's always cool to meet other lispers that are musicians as well, and even martial arts practitioners !

I'll keep the Clon stuff for the European Lisp Workshop instead, and I think I will give a tutorial on it there.

Tuesday, March 17 2009

ILC 2009 (if everything goes well)

So I'm almost ready to fly to Cambridge, MA, for the International Lisp Conference, where I'm going to present my second paper on the behavior and performance of Lisp... well, that is, if my plane actually takes off. There's a general strike in France on thursday.

Why am I not surprised ?

This year, the conference will have lightening talks as well, so I figured I could take the opportunity to introduce my fellow lispers to Clon, the Command-Line Option Nuker. It's a library for managing command-line options in standalone lisp applications. It's not released yet (I still have some work to do in it) but it's close, so advertising it already is a nice way to sort of putting pressure onto myself...

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