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.

Tuesday, January 21 2014

Richard P. "dick" Gabriel to be the first keynote speaker at ELS 2014

Hello everyone,

it's an immense pleasure to welcome Richard P. "dick" Gabriel as the first keynote speaker of the 7th European Lisp Symposium. You can read about his talk on this page. This will hopefully make people wake up early on the fist day :-)

EDIT and we now have 2 more guest speakers: Pascal Costanza and Gábor Melis! Can't wait!

Tuesday, January 7 2014

ELS 2014 Programme Committee

The preliminary Programme Committee for the next European Lisp Symposium has just been selected! We have a nice team coming in hot... See http://www.european-lisp-symposium.org/content-organization-full.html.

Wednesday, December 18 2013

ILC 2014 Call for Papers

2014 is going to be a busy year for Lisp. The 7th European Lisp Symposium (Paris, May) will be followed by the International Lisp Conference (August, Montréal). ILC 2014's Call for Papers is just out! And this year, we have a special focus for you...

	       ILC 2014 - International Lisp Conference
			  "Lisp on the Move"

     August 14-17 2014, Université de Montréal, Montréal, Canada

	      Sponsored by the Association of Lisp Users



Lisp is one of the greatest ideas from computer science and a major
influence for almost all programming languages and for all
sufficiently complex software applications.

The International Lisp Conference is a forum for the discussion of
Lisp and, in particular, the design, implementation and application of
any of the Lisp dialects.  We encourage everyone interested in Lisp to

We invite high quality submissions in all areas involving Lisp
dialects and any other languages in the Lisp family, including, but
not limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript,
Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc.

This year's focus will be directed towards integrated solutions,
including mobile computing. We especially invite submissions in the
following areas:

  * Pervasive computing
  * Interoperability
  * Portability
  * Implementation challenges/tradeoffs for embedded/mobile platforms
  * Language support for mobile toolkits and frameworks
  * Language support for distribution
  * Language support for reliability, availability, and serviceability
  * Mobile IDEs
  * Mobile applications

Contributions are also welcome in other areas, including but not
limited to:

  * Language design and implementation
  * Language integration, inter-operation and deployment
  * Applications (especially commercial)
  * Reflection, meta-object protocols, meta-programming
  * Domain-specific languages
  * Programming paradigms and environments
  * Efficient parallel and concurrent computation
  * Language support for managing both manual and automatic GC
  * Theorem proving
  * Scientific computing
  * Data mining
  * Semantic web

Technical Programme:

Original submissions in all areas related to the conference themes are
invited for the following categories:

  Papers: Technical papers of up to 10 pages that describe original

  Demonstrations: Abstracts of up to 2 pages for demonstrations of
  tools, libraries and applications.

  Workshops: Abstracts of up to 2 pages for groups of people who intend
  to work on a focused topic for half a day.

  Tutorials: Abstracts of up to 2 pages for in-depth presentations about
  topics of special interest for 1 to 2 hours.

  Panel discussions: Abstracts of up to 2 pages for discussions about
  current themes. Panel discussion proposals must mention panel member
  who are willing to partake in a discussion.

The conference will also provide slots for lightning talks, to be
registered on-site every day.

For inquiries about any other kind of participation (commercial
exhibits, advertising, prizes, book signing etc.), please see the
contacts below.

Important Dates:

 - May    18, 2014: Submission deadline
 - June   09, 2014: Notification of acceptance
 - June   29, 2014: Final Papers due
 - August 14, 2014: Conference

All submissions should be formatted following the ACM SIGS guidelines
and include ACM classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates and

Submissions should be uploaded to Easy Chair, at the following
address: https://www.easychair.org/conferences/?conf=ilc14

Organizing Committee:

General Chair:   Marc Feeley (Université de Montréal, Montréal, Canada)
Programme Chair: Didier Verna (EPITA Research lab, Paris, France)
Local chair:     Marc Feeley (Université de Montréal, Montréal, Canada)

Programme Committee:
to be announced


  * General Questions: ilc14-organizing-committee at alu.org
  * Programme Committee: ilc14 at easychair.org

For more information, see http://www.international-lisp-conference.org

Saturday, November 30 2013

7th European Lisp Symposium, May 5-6 2014, IRCAM, Paris, France

ELS 2014 is finally settled. I have the pleasure to welcome Kent Pitman as the Programme Chair, and Gérard Assayag as a co Local Chair ! The symposium is going to be held at IRCAM, a French institute for research on music and acoustics, so I hope there's going to be a lot of Lisp & music talks!

		 ELS'14 - 7th European Lisp Symposium
			 IRCAM, Paris, France

			    May 5-6, 2014


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 7th 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

Please note that IRCAM, the conference venue, is a French institute
for research on music and acoustics. Submissions relating Lisp to
music or other acoustical matters will hence be particularly welcome,
although given no heightened favor during the review process.

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

  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 classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates and

Important dates:

 - TODAY:       Mark your calendar. Start planning now!
 - 09 Mar 2014: Submission deadline
 - 31 Mar 2014: Notification of acceptance
 - 21 Apr 2014: Final Papers due
 - 05 May 2014: Symposium. Join us there!

Program Committee:

    Kent Pitman, Hypermeta Inc., U.S.A.

  Local Organizers:
    Didier Verna, EPITA Research Lab, France
    Gérard Assayag, IRCAM, France

    To be announced later

Search Keywords:

#els2014, ELS 2014, ELS '14, European Lisp Symposium 2014,
European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium,
European Lisp Conference 2014, European Lisp Conference '14


Tuesday, November 12 2013

JBBE: Fake Academic Journal, the Next Generation

If you work in the academy, you are surely already getting a lot of spam from fake conferences asking for papers, PC participation etc. You also know that several years ago, a new form of harassment appeared: fake academic journals. There seems to be more and more of those everyday.

Sometimes, they're a bit hard to spot, especially if their focus seems to be in accordance with your activities. A hint is that you've never heard of them before, though. And sometimes, they're not hard to spot... at all. Meet the stupidest fake academic journal ever: the Journal of Bioinformatics and Biological Engineering.

Here's what I recieved yesterday:

We recently noticed your outstanding paper “Lisp: Report on the 5th workshop ELW at ECOOP 2008” and it well suits the focus and scope of Journal of Bioinformatics and Biological Engineering(JBBE). Considering that we share the same interests in Bioinformatics and Biological Engineering, we are now sending this message to you and sincerely invite you to share your new research or updated results in JBBE.

So, here are a couple of remarks:

  1. It's cool that you have noticed this paper "recently", although it's almost 6 years old now.
  2. The paper in question is actually not a paper. It's a conference proceedings for which I was programme chair, so basically, I wrote only the cover in it.
  3. Finally, there is nothing related to Biology in there. It's about a dynamic programming language.

Well done, guys. You almost got me! Ah, one more thing: I do have some interest in Computer Science and Biology, and I even wrote two papers in this area. Apparently, you failed to spot them, though...

Here's the end of the message:

Please kindly forward this email to your colleagues and students. We shall be greatly appreciated to hear from you at any time.

No, I won't forward this email to my colleagues. And no, you shan't be "greatly appreciated" to hear from me at any time!

Monday, September 23 2013

Keynote at ACCU 2014

I am thrilled to announce that I will be a keynote speaker at the next ACCU conference. The abstract of my keynote is given below. Looking forward to see you there!

Biological Realms in Computer Science

In biology, evolution is usually seen as a tinkering process, different from what an engineer does when he plans the development of his systems. Recently, studies have shown that even in biology, there is a part of good engineering. As computer scientists, we have much more difficulty to admit that there is also a great deal of tinkering in what we do, and that our software systems behave more and more like biological realms every day.

This keynote will take you to a journey through the bonds between biology and computer science. Starting with an epistemological and historical view, we will see how these bonds developed over the years, but we will also ask ourselves whether these bonds were intentionally created, or whether they already existed, before we even found them. We will also meet the Engineer and the Tinkerer, and see that they are not necessarily different persons. Finally, through such notions as Determinism, Predictability and Control, we will envision and explain a possible future for our software systems seen as living organisms; a future that's in fact already here, but that we are reluctant to accept.

Tuesday, September 3 2013

Menu bar icons for Emacs

A huge peeve of mine on OS X is the mixture of the (application) menu bar, starting on the left, and the status bar, starting on the right: when you have a lot of status indicators like me, even a reasonably sized application menu bar will irreparably hide a lot of status, which is really annoying.

One day, I had this idea that application menu bar (wide) titles could be replaced with (narrow) icons, hence leaving more space to the status bar. Of course, it shouldn't be up to the menu, or even to the application itself to choose which icon to use. It should be up to the user. A user will want a single icon set to work with all applications (e.g. you choose a nice File icon, and you want all applications to use it instead of the word "File").

So one day, I implemented a SIMBL plugin and preference pane for doing exactly that. Don't look for it, it's never been released. It lets the user create associations between menu titles and icons and hijacks OS X applications to modify the appearance of their menu bar. Alas, it doesn't work very well. Native Cocoa applications not doing anything fancy with their menus are ok, but most other applications are not.

Emacs menu bar icons Today, let me introduce some support for this feature in Emacs. Attached to this article is a patch against the current trunk plus a small image file. For this to work, you will need to put the image file (barsplit.png) in the etc/images/ directory of Emacs'source tree, apply the patch and recompile (--with-ns of course). Then, find yourself a nice set of icons and go customize the options menu-bar-use-icons, menu-bar-icons-directory and menu-bar-icons in the "menu" custom group. The docstrings should be self-explanatory. As you can see on the screenshot, what you get is a much narrower, visual menu bar. The first menu (the so-called "application menu") always uses the official application's icon. The other ones are your choice. Finally, the menu bar ends with a visual separator allowing to better distinguish its end from the start of the status bar.

The current implementation is very naive (sorry, I meant highly dynamic): titles / icons associations are recomputed every time the menu bar is redrawn. But this has in fact some advantages:

  1. the code is quite simple,
  2. customizations made by the user are visible immediately, without the need for a complex event listener / notification / whatever machinery (this machinery may already exist in the Emacs codebase though).

In fact, I've been using this patch for quite a while now and I didn't notice any performance impact on my 3 years-old Mac Book Pro. One last thing you need to know: the behavior of this feature may be unreliable (even if implemented correctly, which I think I did) because messing with the menu bar like this is uncharted territory, totally unsupported by Apple. Enjoy anyway :-)

Now, if somebody comes up with a nice and comprehensive set of menu bar icons for Emacs (and other OS X apps), I'd be delighted...

Saturday, August 24 2013

Declt 1.0 is out

After 15 betas, I'm happy enough with the current state of Declt to finally make a 1.0 release.

A lot of things have changed since the previous version, sometimes in a backward-incompatible way. Many more items are documented (including, as you have recently seen, method combinations). In addition to the reference manual, generated by Declt itself, there is now a real user manual.

Declt is still SBCL-only, requires ASDF 3 and Texinfo 4 but generates code that is compatible with Texinfo 5. Also, beware, I've deleted the old repository and moved the project to GitHub. Below is a more precise description of what Declt currently does.

Declt (pronounce "dec'let") is a reference manual generator for Common Lisp libraries. It works by loading an ASDF system and introspecting its contents. The generated documentation contains the description for the system itself and its components (modules and files), the packages defined in that system and the definitions found in those packages.

Exported and internal definitions are listed separately. This allows the reader to have a quick view on the library's public API. Within each section, definitions are sorted lexicographically.

In addition to ASDF system components and packages, Declt documents the following definitions: constants, special variables, symbol macros, macros, setf expanders, compiler macros, functions (including setf ones), generic functions and methods (including setf ones), method combinations, conditions, structures, classes and types.

The generated documentation includes every possible bit of information that introspecting can provide: documentation strings, lambda lists (including qualifiers and specializers where appropriate), slots (including type, allocation and initialization arguments), definition source file etc.

Every documented item provides a full set of cross-references to related items: ASDF component dependencies, parents and children, classes direct methods, super and subclasses, slot readers and writers, setf expanders access and update functions etc.

Finally, Declt produces exhaustive and multiple-entry indexes for every documented item.

Reference manuals are generated in Texinfo format (compatible, but not requiring Texinfo 5). From there it is possible to produce readable / printable output in info, HTML, PDF, DVI and PostScript with tools such as makeinfo, texi2dvi or texi2pdf.

The Declt reference manual is the primary example of documentation generated by Declt itself.

Friday, August 16 2013

Lisp Corner Cases: Method Combinations

In the process of writing Declt, I had to deepen my knowledge of some Lisp corner cases, notably in the area of introspection. As you know, Lisp has in fact more than 2 namespaces. Sometimes, introspecting a potential symbol definition in one namespace is trivial. COMPILER-MACRO-FUNCTION is one example. The "functional" namespace is heterogeneous but you can still make your way out of macros, regular or generic functions very easily. In the same vein, distinguishing constants, special variables and symbol macros in the "variables" namespace is more complicated because there is no standard way to access that information, but with the help of some vendor-specific machinery (e.g. SB-INT:INFO), it's still doable.

At some point, I tackled the case of method combinations, and to my greatest surprise, found out that introspecting a method combination by name is not simple. In fact, it's not even doable. The reason is that method combinations don't have a namespace proper. Let me explain why.

You define a new method combination of some NAME with DEFINE-METHOD-COMBINATION, and you use it with the :METHOD-COMBINATION option to DEFGENERIC. But how do you introspect a NAME for a potential method combination definition? Well, you can't do exactly that. First, there is no standard way to do so. Next, let's look at what the MOP provides. One would expect something along the lines of FIND-CLASS...

There is indeed something called FIND-METHOD-COMBINATION, but either I'm missing something, or it is really, and I mean really badly designed. The arguments to this function are: a generic function meta-object, a method combination name and some method combination options. So if this function is supposed to be the equivalent of FIND-CLASS for method combinations, what in the hell are the 1st and 3rd arguments for? In fact, it's not supposed to do what its name suggests. According to the AMOP, p.191, the purpose of this function is to "determine the method combination object used by a generic function". In practice however (at least in SBCL), it's not doing that either (see below), and anyway, determining the method combination object used by a generic function is better achieved by using the GENERIC-FUNCTION-METHOD-COMBINATION accessor.

So this protocol doesn't seem to make any sense. In order to understand what to make of all this, I looked at how SBCL handles method combinations (I don't know what other vendors do) and here is what I found. When you call DEFINE-METHOD-COMBINATION for some NAME, SBCL creates a new method for FIND-METHOD-COMBINATION, eql-specialized on that NAME. This method is encapsulated in a closure containing the method combination's definition, ignores its first argument (the generic function meta-object; that's why I said that it's not really doing what the AMOP says it does), recreates and returns a new method combination object on the fly every time it is called.

This has several consequences. First, the notion of "method combination named NAME" doesn't really make sense. Method combinations don't have a proper namespace. Every time you create a new generic function, the method combination essentially becomes local to that function. Redefining a method combination has no effect on existing generic functions using a method combination of the same NAME. To put it differently, you can end up with several generic functions using different yet equally named method combinations.

In Declt, I'm now assuming that programmers behave and only define method combinations once. Which brings us to the second consequence. With that assumption in mind, the "proper" way to introspect a NAME for a method combination definition (at least in SBCL) is to first look for the existence of a FIND-METHOD-COMBINATION method eql-specialized on that NAME, and then call it to retrieve the actual definition.

I haven't thought about it a lot yet, but it would be interesting to investigate the idea of cleaning this up a bit. I mean, establishing a real global namespace for method combinations, creating an alternate FIND-METHOD-COMBINATION protocol more along the lines of FIND-CLASS. And then, it could also be interesting to investigate on the potential applications of allowing method combination redefinition to affect live generic functions, just like class redefinition affects live instances...

Tuesday, July 16 2013

ELS 2013 Proceedings

I have just compiled the proceedings for ELS 2013, the 6th European Lisp Symposium. I have also asked Manuel and Nick to add them to their respective pages, the official ELS 2013 page and the audio recordings page.

Thanks to both of them for their support !

Wednesday, June 26 2013

Nice little trick du jour

This morning, I came up with a nice little trick which made my day. Perhaps this is already well known or even idiomatic, but in case it is not, it goes like this.

Sometimes, I have to read a whole Lisp file containing more than just one toplevel form and get the contents as an unprocessed list of expressions. This happens for instance when loading a DSL program that needs post-treatment.

Usually, I end up doing something like this:

(with-open-file (stream filename)
  (loop :for expr = (read stream nil :eof)
	  :if (eq expr :eof)
	    :return exprs
	    :collect expr :into exprs)))

But for some reason, this has always felt clunky to me. I mean, instead of ogling the family jewels of this poor shy file, I should be able to read it as a whole (hint: read-delimited-list) and preserve its intimacy.

And then I realized that the only thing that prevents me from using read-delimited-list is the lack of an ending parenthesis. But as always, Common Lisp immediately comes to the rescue, this time with its rich streams API. The idea is that you can create a string stream that just contains the closing parenthesis, and concatenate this stream at the end of the file one. I can now do something like this instead:

(with-open-file (stream filename)
  (read-delimited-list #\) (make-concatenated-stream stream (make-string-input-stream ")"))))

Not only it is shorter, it also looks much more elegant to me.

Friday, June 14 2013

ELS 2013 Material

ELS 2013, the 6th European Lisp Symposium, took place in Madrid on June 3th and 4th.

During the symposium, Nick Levine recorded audio versions of the presentations and collected them here. Nick has also agreed to collect other material from the presenters (slides notably) and put it at the same location. The page is growing up as we speak.

It was good to see you all in Madrid. Thanks to all the presenters and thanks Nick for doing this!

Tuesday, May 28 2013

el-rcfiles is released (first public version)

I've been using this for years, but never bothered to make it public until now.

el-rcfiles is a very small and simple library which provides Unix-like RC files for Emacs Lisp libraries. It's compatible with GNU Emacs and XEmacs, available in ELPA form, as a tarball and from GitHub. More details (including download) available here, but here is also the library's commentary section, for quick reference.

;;; Commentary:

;; The purpose of el-rcfiles is to provide the equivalent of traditional
;; Unix rc files (i.e. configuration files) for Emacs Lisp
;; libraries. The advantages of using configuration files are the
;; following:
;;   - your initialization file is less bloated,
;;   - since configuration files are lazily loaded, your Emacs session
;;     is (or begins) lighter. That is unless you already use lots of
;;     EVAL-AFTER-LOAD forms...

;; Usage:

;; 1. Load the library, go to the rcfiles Custom group and tweak (or not).
;; 2. Put a call to (rcfiles-register-rc-files) in your initialization
;;    file. This function can also be called interactively anytime you
;;    add, remove or modify a configuration file.
;; 3. Put your configuration code for a library `foo' in a file called
;;    `<rcfiles-directory>/foo<rcfiles-pseudo-extension>.el'.

Tuesday, May 14 2013

Emacs session bootstrap tweaks

This article essentially describes the top of my Emacs init file. That part of the code is devoted to modify the session bootstrap process, that is, some things that are normally done very early. It mostly deals with the package infrastructure but also contains a couple of other tricks that some people may consider useful. It goes like this…

The first line is self-explanatory (and please, be warned that I will discard any comment about it. You know why).

(require 'cl)

Platform-specific tweaks

A self-contained Emacs.app on MacOS X has its own site-lisp directory, but I want to make sure that the standard Unix one is here as well, and takes precedence.

(when (featurep 'ns)
  (add-to-list 'load-path "/usr/local/share/emacs/site-lisp"))

When not starting Emacs from the command-line (e.g. MacOS X app clicks or Quicksilver, Unitiy launcher on Ubuntu etc.), I don't necessarily get my environment-based exec-path so I need to restore it. Note that this trick works because the standard value is (I think) computed when Emacs is built, and I happen to build it myself, in my own environment.

(let ((standard-exec-path (cadar (get 'exec-path 'standard-value))))
  (mapc (lambda (path) (setq exec-path (remove path exec-path)))
  (setq exec-path (append standard-exec-path exec-path)))

ELPA infrastructure

Initialize ELPA now so that the rest of the initialization process may rely on packages without having to go through after-init-hook.

(require 'package)

I want system-wide directories to be named emacs-packages instead of site-lisp/elpa.

(setq package-directory-list
      (let (result)
        (dolist (path load-path)
          (and (stringp path)
                 (equal (file-name-nondirectory path) "site-lisp")
                 (push (expand-file-name "emacs-packages"
                                                       (directory-file-name path)))
	(nreverse result)))

I want my local directory to follow the same convention.

(setq package-user-dir "~/.emacs.d/emacs-packages")

Now, it's okay to initialize ELPA.


Now that the packages have been initialized, I actually want ELPA to install in /usr/local/share/emacs/emacs-packages by default, and keep my local directory for manual installations. One simple way to achieve that is to set my local directory to /usr/local/share/emacs/emacs-packages and to remove that from the system-wide directory list. One small drawback of this is that my local path is gone, so any new package installed there won't be seen until the next restart. This is not much of a problem though.

(setq package-user-dir "/usr/local/share/emacs/emacs-packages"
        package-directory-list (remove "/usr/local/share/emacs/emacs-packages"

Site and local (non ELPA) packages infrastructure

The purpose of this other infrastructure is to support packages that would be installed manually, outside ELPA, and in a way similar to XEmacs packages. A packages directory has lisp/, etc/ and info/ subdirectories. Every package installs its stuff directly in etc/ and info/, but adds its own subdirectory to lisp/ and puts its code (including a potential autoloads file) in there.

This additional infrastructure comes in handy in several situations. For instance, having Slime (auto)loaded in your session now becomes as simple as this:

ln -s /path/to/slime /usr/local/share/emacs/local-packages/lisp/

(defun dvl-initialize-packages (directory)
  "Initialize non-ELPA packages DIRECTORY.
This means:
  - adding the whole lisp/ subtree to LOAD-PATH,
  - loading the autoload files found there.
  (let ((default-directory (expand-file-name "lisp" directory)))
    ;; 1. Update LOAD-PATH
    (setq load-path
	   (let ((load-path (copy-sequence load-path)))
	     (append (copy-sequence (normal-top-level-add-to-load-path '(".")))
    ;; 2. Load autoload files
    (loop for directory in load-path
	    while (string-prefix-p default-directory directory)
	    do (mapc #'load (directory-files directory t "-autoloads\\.el$"))))
  ;; 3. Update the default Info directory list
  (add-to-list 'Info-default-directory-list
   (expand-file-name "info" directory)))
(require 'info)

Be sure to do this by increasing priority order.

(mapc #'dvl-initialize-packages

And now we can re-initialize Info with the proper defaults.

(setq Info-directory-list nil)

Custom settings

Now that we have bootstrapped the complete packages infrastructure, we can set the Custom file to something that makes sense and load it now.

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

RC Files

Finally, install the rc files loader and we're done bootstrapping.


That completes my session bootstrap process.

So long, TweetDeck

In a recent blog full of marketting crap, Twitter announced that they are dropping all versions of TweetDeck except for the web-based app, and that they are also dropping support for Facebook integration. Well, that's too bad because these were the only two things that made me use it.

The annoucement starts like this:

To continue to offer a great product that addresses your unique needs ...

Yeah, right. Great product? Not so much. For starters, it would have been really great if it had gotten support for Google Plus at some point. Something that many of us were desperately hoping for.

As for my "unique needs", thank you very much but you don't know squat about them obviously, and besides, they're not even "unique". Again, for many of us, what were the 2 crucial features of TweetDeck, compared to the other alternatives?

  1. Social net aggregation (including Twitter and Facebook) plus sorting and filtering facilities; something that many other tools (such as HootSuite) do,
  2. Social net merging, something that to the best of my knowledge, no other tool does.

This second feature was absolutely crucial to me. The ability to have the "Home" column displaying all social feeds all at once, all in one place. The "Interactions" column displaying a merge of all my interactions on both Facebook and Twitter all at once, all in one place. Boy, did I wish Google Plus was there as well. And now this is all gone.

So I guess I'm back to the stone age now. One freaking web page for every social net. Or I could finally switch to HootSuite, with its so ugly and so much bloated interface. Correct me if I'm wrong, but I don't think HootSuite does social merging (is there a tool left that does it now?). But at least, it has some partial support for Google Plus (only pages; let's hope that this will change soon).

The annoucement starts like this:

From the whole TweetDeck team, we’re excited about what the future holds. We hope you are too.

Well, you know, not so much, really.

So long, TweetDeck, and thanks for your help until today.

Hint: the next social net killer app will need to do social merging, sorting and filtering, with at least Twitter, Facebook and Google Plus. Now, to your keyboards, you geeks.

Tuesday, April 23 2013

Lisp, GSoC and CDRs

Here's a bright idea: why not take the GSoC opportunity to have someone implement all current CDRs in every major Common Lisp implementation? Not that I'm volunteering for anything. I'm justing throwing the though out in the open...

Monday, April 22 2013

ELS 2013 registration now open


just a quick note to let you know that we have finally opened the registration process for ELS 2013. See the bottom the page for more information. It is possible to register via PayPal or via direct bank transfer.

Looking forward to see you all !

Sunday, March 24 2013

COP'13 - 5th international workshop on context-oriented programming

			   Call for Papers

     Fifth International Workshop on Context-Oriented Programming
      Worokshop in conjunction with ECOOP, ECMFA, and ECSA 2013
		 Montpellier, France, July 2nd, 2013



Context information plays an increasingly important role in our
information-centric world. Software systems must adapt to changing
contexts over time, and must change even while they are
running. Unfortunately, mainstream programming languages and
development environments do not support this kind of dynamic change
very well, leading developers to implement complex designs to
anticipate various dimensions of variability. Starting from this
observation, Context-Oriented Programming (COP) has emerged as a
solution to directly support variability depending on a wide range of
dynamic attributes, making it possible to dispatch run-time behaviour
on any property of the execution context.

The goal of the 5th International Workshop on Context-Oriented
Programming (COP’13) is to further establish context orientation as a
common thread to language design, application development, and system
support. Several researchers are working on Context-Oriented
Programming and related ideas, and implementations ranging from
prototypes to mature platform extensions used in commercial
deployments have illustrated how multi-dimensional dispatch can indeed
be supported effectively to achieve expressive run-time behavioural

Topics of interest include but are not limited to:

- Interesting application domains and scenarios
- Programming language abstractions for context-oriented programming
  (e.g. dynamic scoping, roles, traits, prototype-based extensions)
- Theoretical foundations for context-oriented programming (e.g.,
  semantics, type systems)
- Configuration languages (e.g. feature description interpreters,
  transformational approaches)
- Interaction between non-functional programming concerns and
  context-oriented programming (e.g. security, persistence,
  concurrency, distribution)
- Modularization approaches for context-oriented programming
  (e.g. aspects, modules, layers, plugins)
- Guidelines to include context-oriented programming in programs
  (e.g. best practices, patterns)
- Runtime support for context-oriented programming (e.g. reflection,
  dynamic binding)
- Tool support

Important dates

 * Paper submission:   April 19, 2013
 * Notification:       May 8, 2013
 * Final papers due:   May 22, 2013 (to be confirmed)
 * Early registration: May 31, 2013

Submission guidelines

COP invites submissions of high-quality papers reporting original
research, or describing innovative contributions to, or experience
with context-oriented programming, its implementation, and
application. Papers that depart significantly from established ideas
and practices are particularly welcome.  Submissions must not have
been published previously and must not be under review for any another
refereed event or publication. The program committee will evaluate
each contributed paper based on its relevance, significance, clarity,
and originality.  

It is planned to publish accepted papers in the ACM Digital Library,
unless the authors choose not to. In case of publication in the ACM
Digital Library, authors must transfer copyright to ACM upon
acceptance (for government work, to the extent transferable), but
retain various rights (see ACM Copyright Policy. Authors are
encouraged to publish auxiliary material with their paper (source
code, test data, etc.); they retain copyright of auxiliary material.

Papers should be submitted electronically via EasyChair (URL TBA) in
PDF format.  Submissions must be written in English (the official
language of the workshop) and must not exceed 6 pages. They should use
the ACM SIGPLAN 10 point format, templates for which are available at

Program Committee

  Tomoyuki Aotani, Japan Advanced Institute of Science and Technology, Japan
  Pascal Costanza, Intel, USA
  Carl Friedrich Bolz, Heinrich-Heine-Universität Düsseldorf, Germany
  Sebastián González, UCLouvain, Belgium
  Atsushi Igarashi (Chair), Kyoto University, Japan
  David Lorenz, Open University of Israel, Israel
  Didier Verna, EPITA Research and Development Laboratory (LRDE), France

Organising committee

  Malte Appeltauer, SAP Innovation Center, Germany
  Sebastián González, UCLouvain, Belgium
  Robert Hirschfeld, Hasso-Plattner-Institut, Germany
  Atsushi Igarashi, Kyoto University, Japan (primary contact)
  Hidehiko Masuhara, University of Tokyo, Japan

More information

See the workshop website at 

Tuesday, February 26 2013

Dyla'13, 7th Workshop on Dynamic Languages and Applications

Dyla'13, 7th Workshop on Dynamic Languages and Applications
Colocated with ECOOP, ECMFA and ECSA
1–5 July, Montpellier, France


!! Important dates

- Submission deadline:  April 19th
- Notification: mid-May
- Workshop: July 1st
- Ecoop early registration: mid-May

!! Abstract

The advent of Java and C# has been a major breakthrough in the adoption of
some important object-oriented language characteristics. This breakthrough
turned academic features like interfaces, garbage collection, and
meta-programming into technologies generally accepted by
industry. Nevertheless, the massive adoption of these languages now also gives
rise to a growing awareness of their limitations. A number of reactions from
industry testify this: invokedynamic bytecode instruction has been included in
latest Java virtual machine release; the dynamic language runtime (DLR) is
gaining popularity; C# adopted dynamic as a valid static type. Gartner
prognoses further growth (http://blogs.gartner.com/mark_driver/2008/12/10) of
dynamic languages.

Researchers and practitioners struggle with static type systems, overly
complex abstract grammars, simplistic concurrency mechanisms, limited
reflection capabilities, and the absence of higher-order language constructs
such as delegation, closures and continuations. Dynamic languages such as
Ruby, Python, JavaScript and Lua are a step forward in addressing these
problems while getting more and more popular. Making these languages
mainstream requires practitioners to look back and pick mechanisms up in
existing dynamic languages such as Lisp, Scheme, Smalltalk and
Self. Practitioners also need to further explore discover new dynamic
approaches in the context of new challenging fields such as pervasive

The goal of this workshop is to act as a forum where practitioners can discuss
new advances in the design, implementation and application of dynamically
typed languages that, sometimes radically, diverge from the statically typed
class-based mainstream. Another objective is to discuss new as well as older
"forgotten" languages and features in this context. Topics of interest
include, but are not limited to:

- programming language extensions
- programming environment extensions
- executing environments
- static and dynamic analyses
- optional type-checking
- meta-object protocols
- reserve engineering
- domain-specific languages/tooling
- testing environments
- live programming

!! Targeted audience

The expected audience of this workshop is practitioners and researchers
sharing the same interest in dynamically typed languages. Lua, Python, Ruby,
Scheme and Smalltalk are gaining a significant popularity both in industry and
academia. Nevertheless, each community has the tendency to only look at what
it produces. Broadening the scope of each community is the goal of the
workshop. To achieve this goal we will form a PC with leading persons from all
languages mentioned above, fostering participation from all targeted

!! Workshop Format and Submission Information

The workshop will have a demo-oriented style. The idea is to allow
participants to demonstrate new and interesting features and discuss what they
feel is relevant for the dynamic-language community. To participate to the
workshop, you can either

- submit (before __April 19th 2013__) an article (ACM Tighter Alternate style
http://www.acm.org/sigs/publications/proceedings-templates) describing your
presentation and/or tool. Articles whose length ranges from 2 to 15 pages will
be carefully reviewed by a program committee including but not limited to the
organizers. Each accepted paper will be presented for 20 to 30 minutes and be
published to the ACM Digital Library (at the option of each author) and the
workshop's web site. The submission website is

- or give a 10-minute lightning demo of your work. A dedicated session will be
allocated for this, provided there is ample time available.

A session on pair programming is also planned. People will then get a chance
to share their technologies by interacting with other participants.

!! Program committee

- Carl Friedrich Bolz, Heinrich-Heine-Universität Düsseldorf, Germany
- Camillo Bruni, Inria Lille-Nord Europe, France
- Adrian Kuhn, University of British Columbia, Canada
- Lukas Renggli, Google, Switzerland (http://www.lukas-renggli.ch/)
- Juan Pablo Sandoval Alcocer, University of Chile
- Bastian Steinert, Hasso-Plattner-Institute, Germany
- Veronica Uquillas Gomez, Vrije Universiteit Brussel, Belgium
- Simon Urli, University of Nice-Sophia Antipolis, France
- Didier Verna, EPITA Research and Development Laboratory, France
- the 4 workshop organizers

!! Workshop Organizers

- Alexandre Bergel (http://bergel.eu)
- Damien Cassou (http://damiencassou.seasidehosting.st)
- Jorge Ressia (http://www.jorgeressia.com)
- Serge Stinckwich (http://www.doesnotunderstand.org)

!! News feed

Follow us on twitter: http://twitter.com/dyla2013
For further information: http://rmod.lille.inria.fr/web/pier/Events/Dyla13

Monday, January 28 2013

FiXme 4.2 is out

I'm pleased to announce that, after more than two years, I've managed to put up a very small release of FiXme (my collaborative annotations tool for LaTeX2e) in which I didn't even author the two included changes...

Keep the faith. FiXme is still alive !

New in this veresion (4.2):

** Improve Danish translation
thanks to Lars Madsen.
** Fix buglet in redefinition of \@wrindex
reported by Norman Gray.

Get it at the usual place.

- page 1 of 7

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