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 - page 5
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.

Monday, November 28 2011

CL-RCFiles 2.0

Just a quick note to mention the release of CL-RCFiles 2.0. This version adds pre-loading initialization files. From the README file:

This very small Common Lisp library provides a way to add initialization files to ASDF systems. Every time ASDF loads <system>, one or several corresponding <system>.lisp files are loaded automatically afterwards. This lets you conditionally plug in additional behavior on a per-system basis without cluttering up any global Common Lisp init file.

By default, these initialization files are expected to be found in: - ~/share/common-lisp/rc/pre/ for pre-loading initialization, - ~/share/common-lisp/rc/post/ for post-loading initialization.

For backward-compatibility, files found directly in the rc/ directory are considered to be post-loading initialization files.

You can modify the rc-files location by changing the values of the global variables *directory*, *pre-directory*, and *post-directory*.

Get it here.

Tuesday, October 25 2011

ILC 2012

The ALU has announced the next International Lisp Conference. ILC 2012 will take place at the end of October or Early November. I can't wait to meet the international Lisp crowd again, and what's more, in Kyoto, my favorite city in the world! I think I will take the opportunity to buy a new Hakama there. Maybe a Noren or two as well...

In the meantime, stay tuned for the next European Lisp Symposium, to occur in Zadar (Croatia) sometime around end April / early May 2012 !

John McCarthy died last night

John McCarthy John McCarthy, the creator of the most elegant and powerful language ever, has died. I won't repeat what others in the Lisp community are and will be saying all over the place in the next few days. There is only one thing I would like to say right now: I remember him, and I am very happy (for him) that he was still here with us to celebrate the 50th anniversary of his wonderful baby...

 

Wednesday, July 20 2011

One more indentation hack

Here's yet another indentation hack that I came up with recently.

All the work done by Nikodemus on the Slime indentation contrib is pretty cool, especially the notion of indentation style (though I wish the styles were Custom variables, but that is another story). I tend to use indentation styles for global, maybe collaborative preferences, but on several occasions however, I find that this approach has a couple of drawbacks.

  • One of them is that the indentation information is far away from the corresponding symbol, in a separate file. If you change a function's prototype for instance, you may also need to load the file(s) in which the corresponding style(s) is (are) defined and edit them.
  • The other problem is that if you want to let other people edit your source code and honor your indentation style, you also need to provide them with the style definition, and they need to load it separately.

For those reasons, I tend to think that the indentation style approach is not very well suited for project-specific indentation settings. What I would like is to provide indentation information close to the function definition, and also to have that information automatically available when anyone loads the project into Slime. Here's a way to do it.

The key to success here is the function swank:eval-in-emacs which, as its name suggests, sends some Emacs Lisp code to your (X)Emacs session for evaluation. This function effectively allows you to trigger some Emacs Lisp computation from a Common Lisp file. Remember that indentation information is stored in the common-lisp-indent-function property of a symbol. The function clindent below does this:

(defun clindent (symbol indent)
  "Set SYMBOL's indentation to INDENT in (X)Emacs.
This function sets SYMBOL's common-lisp-indent-function property.
If INDENT is a symbol, use its indentation definition.
Otherwise, INDENT is considered as an indentation definition."
  (when (and (member :swank *features*)
	     (let ((configuration
		     (find-symbol "MY.PACKAGE.CONFIGURATION" :cl-user)))
	       (when (and configuration (boundp configuration))
		 (getf (symbol-value configuration) :swank-eval-in-emacs))))
    (funcall (intern "EVAL-IN-EMACS" :swank)
	     `(put ',symbol 'common-lisp-indent-function
		   ,(if (symbolp indent)
			`(get ',indent 'common-lisp-indent-function)
		      `',indent))
	     t)))

As explained in the docstring, this function will ask (X)Emacs to put SYMBOL's common-lisp-indent-function property to a definition, either provided directly, or retrieved from another symbol. For example, if your package defines an econd macro, you may want to call it like this:

(clindent 'econd 'cond)

This function ensures that Swank is actually available before using it (first condition in the and clause). I will explain the other weird bits later on.

The next question is when exactly do we want to call this function? The answer is: pretty much on all occasions. Your code might be loaded from source and interpreted, or it might be compiled. But then, it might be compiled within or outside a Slime environment. In any case, you want your indentation information to be sent to (X)Emacs everytime it's possible. So obviously, we're gonna wrap this function in an eval-when form thanks to a macro. This is also a good opportunity to save some quoting.

(defmacro defindent (symbol indent)
  "Set SYMBOL's indentation to INDENT in (X)Emacs.
SYMBOL and INDENT need not be quoted.
See CLINDENT for more information."
  `(eval-when (:compile-toplevel :execute :load-toplevel)
     (clindent ',symbol ',indent)))

And now, right on top of your econd definition, you can just say this:

(defindent econd cond)

Now here's one final step. If your package uses its own readtable, it's even more convenient to define a reader-macro for indentation information. I choose #i:

(defun i-reader (stream subchar arg)
  "Read an argument list for the DEFINDENT macro."
  (declare (ignore subchar arg))
  (cons 'defindent (read stream)))
 
(set-dispatch-macro-character #\# #\i #'i-reader *readtable*)

And now, the code in my package will look like this:

#i(econd cond)
(defmacro econd #|...|#)

Pretty cool, eh?

All right. We still have two weirdos to explain in the clindent function.

First, you noticed that the function's computation is conditionalized on the existence of a cl-user::my.package.configuration variable, which actually stores a property list of various compiling or loading options for this package. The option we're interested in is :swank-eval-in-emacs, which must be set to non-nil. Here's why. The execution of Emacs Lisp code from Swank is (rightfully) considered as a security risk so it is disabled by default. If you want to authorize that, you need to set the (Emacs) variable slime-enable-evaluate-in-emacs to t. Otherwise, calling swank:evaluate-in-emacs is like calling 911. So we have a chicken-and-egg problem here: if we want to avoid an error in clindent, we would need to check the value of this variable, but in order to do that, we would need to evaluate something in (X)Emacs ;-)

The solution I choose is hence to disable the functionality by default, and document the fact that if people want to use my indentation information, they need to set both the Slime variable and my package-specific option to non-nil before loading the package (possibly setting them back to nil afterwards). They also need to trust that I'm not going to inject anything suspicious into their (X)Emacs session at the same time...

The last bit we need to explain is the final t argument passed to swank:eval-in-emacs. The corresponding parameter is called nowait in the function's prototype. It has something to do with asynchronous computation, and in fact, I don't really know what's going on under the hood, but what I do know is that if you set it to t, Swank doesn't care about the return value of your form anymore, which is fine because we're only doing a side effect. On the other hand, if you omit that parameter, Swank will try to interpret the return value in some way, and you will most probably get a serialization error. Indeed, the return value is the indentation definition itself, so for example, (&rest (&whole 2 &rest 1)) doesn't make (Common Lisp) sense.

That's it. Happy indenting!

Tuesday, July 19 2011

LaTeX Coding Standards

EDIT: the paper is now freely available for non TUG members.

I'm happy to announce that my contribution to TUG 2011, the next TeX Users Group International conference, has been accepted. Please find the title and abstract below.



Towards LaTeX Coding Standards

Because LaTeX (and ultimately TeX) is only a macro-expansion system, the language does not impose any kind of good software engineering practice, program structure or coding style whatsoever. As a consequence, writing beautiful code (for some definition of "beautiful") requires a lot of self-discipline from the programmer.

Maybe because in the LaTeX world, collaboration is not so widespread (most packages are single-authored), the idea of some LaTeX Coding Standards is not so pressing as with other programming languages. Some people may, and probably have developed their own programming habits, but when it comes to the LaTeX world as a whole, the situation is close to anarchy.

Over the years, the permanent flow of personal development experiences contributed to shape my own taste in terms of coding style. The issues involved are numerous and their spectrum is very large: they range from simple code layout (formatting, indentation, naming schemes etc.), mid-level concerns such as modularity and encapsulation, to very high-level concerns like package interaction/conflict management and even some rules for proper social behavior.

In this talk, I will report on all these experiences and describe what I think are good (or at least better) programming practices. I believe that such practices do help in terms of code readability, maintainability and extensibility, all key factors in software evolution. They help me, perhaps they will help you too.

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, June 21 2011

read-time string concatenation

Sometimes, I miss the string concatenation capability of C. I mean, the way that you can split a long string into smaller ones and have them automatically concatenated together. The format function has a tilde (~) directive that does something along these lines, but there are two problems:

  • first, I'm not necessarily facing the problem in format calls,
  • next, my favorite text editor cannot properly indent the string contents when I press the TAB key.

Here's an example:

(defclass sample ()
  ((slot :documentation
	 "A very long slot documentation, that doesn't even fit in 80 columns, which is a shame...")))

If that were C code, I could write this:

(defclass sample ()
  ((slot :documentation
	 "A very long slot documentation, "
	 "that doesn't even fit in 80 columns, "
	 "which is a shame...")))

But (thank God) this is not C code. We can come very close to that however. Here's a small reader function that will automatically concatenate strings prefixed with a tilde (~) character (in honor of format's directive):

(defun tilde-reader (stream char)
  "Read a series of ~\"string\" to be concatenated together."
  (declare (ignore char))
  (flet ((read-string (&aux (string (read stream t nil t)))
	   (check-type string string "a string")
	   string))
    (apply #'concatenate 'string
	   (read-string)
	   (loop :while (char= (peek-char t stream nil nil t) #\~)
		 :do (read-char stream t nil t)
		 :collect (read-string)))))

Let's add it to the current readtable:

(set-macro-character #\~ #'tilde-reader)

And now I can write this:

(defclass sample ()
  ((slot :documentation
	 ~"A very long slot documentation, "
	 ~"that doesn't even fit in 80 columns, "
	 ~"which is a shame...")))

Everyday of my life I thank Common Lisp for being so flexible. The next step would be to make cl-indent.el aware that tilde-strings really are the same object, and hence should be vertically aligned in all contexts. I'm not there yet. Jeeze, this indentation hacking will never end... :-)

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.

Monday, May 30 2011

European Lisp Symposium in-between

It's been two months since ELS 2011 is over and I didn't have the time to give my impressions as the programme chair until now. I still don't have much time, so it's going to be quick, but before that, here are two announcements in this transition phase:

  • the proceedings are now available as a single PDF file.
  • eventhough a couple of options are already under consideration, we are still looking for volunteers to be next year's local chair. If this is of interest to you and you have the ability to locate ELS 2012 at your place, please contact us.

About ELS 2011 now. I'd say that it was a great success, perhaps the most successful of the 4 occurrences. We got two full days of interesting talks on various topics and of different forms. We gathered more than 60 persons from all around Europe and also a quite a few from the US (ITA contributed greatly to that :-). The final panel was very nice (something quite rare these days). The local organization went also pretty smoothly.

In retrospect, and as the person in charge of the contents, I have several hypothesis on what makes such an event successful, especially in those days where academic events suffer from a decreasing level of attendance.

  1. Having a "special focus" helps. Having an important one (like Parallelism and Efficiency) helps even more.
  2. Having a regularly occurring event also helps a lot, especially for academicians. This is not new, but it really is important to know that ELS will always happen roughly at the same period every year. Academicians (at least) need to plan their work that long in advance.
  3. I also like more and more the formula of a "mixed" conference where you invite formal (technical) papers, demonstrations, position papers etc. Some people know how to write technical papers, some people don't, are not so good at it, or just don't have the time for it, but it doesn't mean they have nothing interesting to say. ELS 2011 had about 50% formal presentations and 50% demonstrations. I decided to create the different sessions not by grouping talks based on format, but based on topic, and I think this went pretty well. The sessions didn't look completely heterogeneous to me.
  4. Having invited speakers helps. This is of course not new at all, but here, I would just like to answer something I've read recently about ELS 2011; a blogger (I don't remember who) saying that he didn't understand why 2 out of the 3 guests were not speaking about Lisp at all. My opinion on this is simple: as a community (in general; not speaking of Lisp in particular), we have a tendency to be separated from the rest of the CS crowd and loose track of what's going on next door. We don't talk to each other enough. Hell, it's already so difficult to stay up-to-date with your own crowd sometimes! So when I attend a very focused conference, like a language-specific one, I'm always happy to be served a couple of talks that can broaden my view of things, even if they have no direct connection with my own activities. In our specific case, I was very happy with Craig Zilles'presentation and I can see how this could be of interest to us in the long term.

So, that's it for now. Stay tuned for next year's location, and in the meantime, remember that some other Lisp events are already planned: ECLM in Amsterdam, and ILC in Kyoto... simply my favorite place in the world!

[CfP] ACM Symposium on Applied Computing: Separation of Concerns

Programming for Separation of Concerns (PSC) at ACM Symposium on Applied Computing (SAC) March 25-29, 2012 Riva del Garda (Trento) Italy

Description and Objectives

Complex systems are intrinsically expensive to develop because several concerns must be addressed simultaneously. Once the development phase is over, these systems are often hard to reuse and evolve because their concerns are intertwined and making apparently small changes force programmers to modify many parts. Moreover, legacy systems are difficult to evolve due to additional problems, including: lack of a well defined architecture, use of several programming languages and paradigms, etc.

Separation of concerns (SoC) techniques such as computational reflection, aspect-oriented programming and subject-oriented programming have been successfully employed to produce systems whose concerns are well separated, thereby facilitating reuse and evolution of system components or systems as a whole. However, a criticism of techniques such as computational reflection is that they may bring about degraded performance compared with conventional software engineering techniques. Besides, it is difficult to precisely evaluate the degree of flexibility for reuse and evolution of systems provided by the adoption of these SoC techniques. Other serious issues come to mind, such as: is the use of these techniques double-edged? Can these systems suffer a ripple effect, whereby a small change in some part has unexpected and potentially dangerous effects on the whole?

The Programming for Separation of Concerns (PSC) track at the 2012 Symposium on Applied Computing (SAC) aims to bring together researchers to share experiences in using SoC techniques, and explore the practical problems of existing tools, environments, etc. The track will address questions like: Can performance degradation be limited? Are unexpected changes dealt with by reflective or aspect-oriented systems? Is there any experience of long term evolution that shows a higher degree of flexibility of systems developed with such techniques? How such techniques cope with architectural erosion? Are these techniques helpful to deal with evolution of legacy systems?

Topics

Authors are invited to submit original papers. Submissions are encouraged, but not limited, to the following topics:

  • Software architectures
  • Configuration management systems
  • Software reuse and evolution
  • Performance issues for metalevel and aspect oriented systems
  • Software engineering tools
  • Consistency, integrity and security
  • Generative approaches
  • Experiences in using reflection, composition filters, aspect- and subject- orientation
  • Evolution of legacy systems
  • Reflective and aspect oriented middleware for distributed systems
  • Modelling of SoC techniques to allow predictable outcomes from their use
  • Formal methods for metalevel systems

Paper Submission

Original papers from the above mentioned or other related areas will be considered. Only full papers about original and unpublished research are sought. Parallel submission to other conferences or tracks is not acceptable.

Papers can be submitted in electronic format via the SAC website (www.softconf.com/c/sac2012/) within 31 August 2011. Please make sure that the authors name and affiliation do not appear on the submitted paper.

Peer groups with expertise in the track focus area will blindly review submissions to the track. At least one author of the accepted paper should register and participate in the PSC track. Accepted papers will be published in the annual conference ACM proceedings.

The camera-ready version of the accepted paper should be prepared using the ACM format (guidelines will be given on the SAC website). The maximum number of pages allowed for the final papers is six (6), with the option, at additional cost, to add two (2) more pages.

A set of papers submitted to the PSC track and not accepted as full papers will be selected as poster papers and published in the ACM proceedings as 2-page papers, with the option, at additional cost, to add one (1) more page.

Important Dates

Paper Due August 31, 2011 Author Notification Oct. 12, 2011 Camera Ready Nov. 2, 2011

Please check the web site for updates: www.dmi.unict.it/~tramonta/sac/

Friday, May 6 2011

Common Lisp indentation in XEmacs

UPDATE: since the original publication of this blog entry, Nikodemus Siivola and I have done some more work on various other aspects of Common Lisp indentation, and I must say that the result is pretty satisfactory. Nikodemus has merged all the changes into Slime, and I have done so for XEmacs. If you're an XEmacs user, you don't need to use the slime-indentation contrib to get these improvements. Simply upgrade the "prog-modes" package and load cl-indent.el.

I have just modified XEmacs to improve the indentation of Common Lisp code. This change involves two things: the support for multiple method qualifiers in a call to defmethod and, much more importantly, a cleaner and more flexible scheme for indenting lambda lists. The patch has also been submitted to the GNU Emacs developers. Below is a more detailed description of what you get with these changes.

Method qualifiers

Until now, only one method qualifier was understood. Below are some examples demonstrating that the one method qualifier and the argument list are indented by 4 characters, and the method's body only by 2:

(defmethod foo :around ()        (defmethod foo :around
  do-this)                           ()
                                   do-this)
(defmethod foo
    :around ()                   (defmethod foo
  do-this)                           :around
                                     ()
                                   do-this)

Now let's add a second method qualifier:

(defmethod foo comb :around ()        (defmethod foo	    
	   do-this)			  comb :around () 
					  do-this)

Woops. Neither is correct. But now, you get this instead:

(defmethod foo comb :around ()        (defmethod foo	    
  do-this)				  comb :around () 
					do-this)

Three more examples to show how confused we were:

(defmethod foo comb :around     (defmethod foo comb     (defmethod foo 
  ()				    :around		    comb       
  do-this)			  ()			    :around    
				  do-this)		  ()	       
							  do-this)

And how better we just got:

(defmethod foo comb :around     (defmethod foo comb     (defmethod foo
    ()				    :around		    comb      
  do-this)			    ()			    :around   
				  do-this)		    ()	      
							  do-this)

Indeed, you can see that everything between the method's name and its body is now correctly indented by 4.

Lambda Lists

The next round of changes deals with the formatting of lambda-lists. As such, this will apply everywhere a lambda-list is expected, such as defun, defgeneric, defmethod etc. First of all, here are two examples showing that we were not very clever before:

(defun foo (mand1 mand2
	    &optional opt1
	    opt2
	    &rest args
	    &key key1 key2
	    (key3 val3) &aux aux1
	    aux2)
  do-this)

(defun foo (mand1 mand2 &optional opt1
	    opt2
	    &rest args
	    &key key1 key2
	    (key3 val3) &aux aux1
	    aux2)
  do-this)

Basically, everything was blindly aligned at the beginning of the lambda-list. Here is what you get now:

(defun foo (mand1 mand2
	    &optional opt1
	      opt2
	    &rest args
	    &key key1 key2
	      (key3 val3) &aux aux1
			    aux2)
  do-this)

(defun foo (mand1 mand2 &optional opt1
			  opt2
	    &rest args
	    &key key1 key2
	      (key3 val3) &aux aux1
			    aux2)
  do-this)

The difference is that keyword parameters are indented with respect to their corresponding keyword. The amount of indentation is provided by a new customizable user option named lisp-lambda-list-keyword-parameter-indentation (oh boy, what a mouthful). If you prefer, you can also have the parameters vertically aligned with each other. Set the new customizable user option named lisp-lambda-list-keyword-parameter-alignment to t and you will get this instead:

(defun foo (mand1 mand2
	    &optional opt1
		      opt2
	    &rest args
	    &key key1 key2
		 (key3 val3) &aux aux1
				  aux2)
  do-this)

(defun foo (mand1 mand2 &optional opt1
				  opt2
	    &rest args
	    &key key1 key2
		 (key3 val3) &aux aux1
				  aux2)
  do-this)

Finally, just as you could align keyword parameters together, you can also align the keywords together. Set the new customizable user option named lisp-lambda-list-keyword-alignment to t, and you will get this (only the second example differs):

(defun foo (mand1 mand2 &optional opt1
				  opt2
			&rest args
			&key key1 key2
			     (key3 val3) &aux aux1
					      aux2)
  do-this)

These are in fact my preferred settings, although both alignment options default to nil. Here is a final example demonstrating how you could format a long lambda-list with plenty of arguments:

(defun foo (mand1 mand2
	    &optional
	      opt1 opt2 opt3
	    &key
	      key1 key2 key3
	    &aux
	      aux1 aux2 aux3)
  do-this)

These indentation problems have been a huge peeve of mine for quite a long time. I hope you will find the changes useful!

Saturday, April 30 2011

Receive and Pay... NOT!

ReceiveAndPay doesn't allow you to create your own password. They probably don't trust people to come up with a good one. Fair enough. So they generate a new password for you on an HTTPS page, and then sends it loud and clear to you by email! Good work gentlemen. ;-)

But wait, it gets better. I have sent them an email about this. Here is what I just got back:

Answer to your question: Sir, we have taken good note of your message. The passwords are generated automatically by our system.

Right, thank you very much :-)

So either there is a dumbass at the other end of the line, or (more probably because it is Saturday), that was an automated response. In that case, they should really be putting their time and energy into thinking about their security policy instead of trying to get clever about the contents of their (former ;-) customers messages...

Wednesday, April 27 2011

XEmacs 21.5.30 "garlic" is released

At long last, there is a new release of XEmacs 21.5. A lot of stuff has happened in this release, but the most important thing is that this is the last GPLv2 version of XEmacs. Future versions (including the current trunk) will be licensed GPLv3 or later. In fact, the first GPLv3 release, 21.5.31, is expected to follow this one by a couple of days. Thanks mostly to Aidan Kehoe, I'm also quite happy that XEmacs Lisp is more Common Lisp'y than ever.

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

Friday, April 1 2011

[CfP] DLS 2011: the 7th Dynamic Languages Symposium

Dynamic Languages Symposium 2011

Co-located with SPLASH 2011 In association with ACM SIGPLAN

Portland, Oregon, USA, October 24, 2011

http://www.dynamic-languages-symposium.org/dls-11/

Call for papers

The 7th Dynamic Languages Symposium (DLS) at SPLASH 2011 is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, Lua, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development.

DLS 2011 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library.

Areas of interest include but are not limited to:

  • Innovative language features and implementation techniques
  • Development and platform support, tools
  • Interesting applications
  • Domain-oriented programming
  • Very late binding, dynamic composition, and runtime adaptation
  • Reflection and meta-programming
  • Software evolution
  • Language symbiosis and multi-paradigm languages
  • Dynamic optimization
  • Hardware support
  • Experience reports and case studies
  • Educational approaches and perspectives
  • Object-oriented, aspect-oriented, and context-oriented programming

Submissions and proceedings

We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality.

Accepted papers will be published in the ACM Digital Library.

Papers are to be submitted electronically in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html.

Important dates

Submission of papers: June 17, 2011 (hard deadline) Author notification: July 19, 2011 Final versions due: August 19, 2011 DLS 2011: October 24, 2011 SPLASH 2011: October 22-27, 2011

Program chair

Theo D'Hondt, Software Languages Lab, Vrije Universiteit Brussel, Belgium

Program committee

  • Andrew Black, Portland State University, USA
  • William R. Cook, University of Texas at Austin, USA
  • Marc Feeley, University of Montreal, Canada
  • Roberto Ierusalimschy, PUC-Rio, Brazil
  • Michele Lanza, University of Lugano, Switzerland
  • Hidehiko Masuhara, University of Tokyo, Japan
  • Mira Mezini, University of Darmstadt, Germany
  • Mark Miller, Google, USA
  • Manuel Serrano, INRIA Nice, France
  • Laurence Tratt, Middlesex University, UK
  • David Ungar, IBM, USA
  • Didier Verna, EPITA Research and Development Laboratory, France

Monday, March 21 2011

ELS 2011 last minute addition

Hello all,

I'm pleased to inform you that we have a last minute addition to the 4th European Lisp Symposium's programme: a presentation by Alec Berryman from ITA software about parallelizing an SBCL codebase for performance. I think this will make a perfect introduction to the subsequent panel entitled "Lisp: the next challenges"...

Hope to see you there, still time to register!

Wednesday, March 2 2011

ELS 2011 programme now available!

The final programme for the 4th European Lisp Symposium is now online! 2 full days of keynotes, technical papers, demonstrations, lightning talks and panels with a special focus on performance, efficiency, parallelism, concurrency, distribution...

Early bird registration is still available until March 12th so hurry!

Hope to see you there.

Wednesday, February 23 2011

Declt 1.0b9 is out

The next edition of Declt, the Documentation Extractor from Common Lisp to Texinfo, is out. In this release:

  • Bugfix: rendering the documentation for methods with EQL specializers didn't work.
  • Feature: licensing and copyrighting the reference manual is now optional. Licenses currently supported are BSD and GPL.
  • Declt now generates its own reference manual by default.
  • Some package infrastructure changes that should remain transparent.

Grab it here

Happy documenting!

Tuesday, February 15 2011

Register now to ELS 2011 !

The 4th European Lisp Symposium is now open for registration! See the website for details.

The early registration deadline is March 12. There is also a reduced fee for students and accompanying persons.

The complete program will be available shortly.

Hope to see you there!

Friday, February 11 2011

Clarification proposal for CLHS 22.3

There are some fuzzy corner cases in the way the Common Lisp standard describes the syntax and semantics of FORMAT directives. I have prepared a first draft of a clarification proposal for the relevant parts of the standard, which is attached in PDF format. I'm giving myself some time for comments and feedback before actually submitting this to the Common Document Repository.

Update: this document (in version 1.1) has been submitted and accepted today as a new item in the Common Document Repository. It can now be officially referred to as "CDR 7".

- page 5 of 9 -

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