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.
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.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
Chers collègues,
La prochaine session du séminaire Performance et Généricité du LRDE
(Laboratoire de Recherche et Développement de l'EPITA) aura lieu le
Mercredi 15 février 2012 (14h-16h).
Au programme:
* 14h: Des performances dans les nuages avec la virtualisation des langages
-- Yann Régis-Gianas
http://www.pps.jussieu.fr/~yrg/
«The effective exploitation of his powers of abstraction must be
regarded as one of the most vital activities of a competent programmer.»
disait Dijsktra.
En effet, pour aborder la complexité d'un problème, l'explicitation des
concepts utiles à sa formalisation et à sa résolution est bien souvent
une étape clé. Lorsque que l'on étend ce processus à une classe de
problèmes qui partagent les mêmes concepts, il est naturel de se doter
d'un langage le plus approprié possible pour manipuler ces abstractions
spécifiques à un domaine (en anglais, «Domain Specific Language»).
Comment implémenter ces DSLs? Une première approche classique reflète
les constructions du DSL sous la forme d'un jeu de fonctions de
bibliothèque. L'avantage de cette approche est d'utiliser directement
son langage généraliste préféré, et sa chaîne de compilation optimisée,
de façon à générer du code machine à moindre frais. Par contre, dans ce
cadre, l'écriture de passe d'optimisations spécifiques au DSL --- à
moins d'utiliser des techniques pointues de méta-programmation --- est a
priori impossible.
Une seconde approche, opposée, consiste à écrire un compilateur pour le
DSL à partir de zéro. Toute liberté est alors donnée à l'implémenteur
d'intégrer à son compilateur des passes d'optimisation spécifiques… mais
au prix d'une réimplémentation de passes de compilation déjà présentes,
et certainement plus abouties, dans le compilateur de son langage
généraliste favori.
Dans cet exposé, je présenterai les travaux de Martin Odersky et son
équipe sur la virtualisation de DSLs à l'intérieur du langage de
programmation Scala. La virtualisation de langage utilise intensivement
le polymorphisme et la composition mixin de Scala ainsi que des
techniques de génération de code à l'exécution pour embarquer des
langages spécifiques dans Scala dont la compilation peut réutiliser des
modules du compilateur mais aussi étendre ces derniers par des
optimisations spécifiques au domaine.
-- Yann Régis-Gianas est un ancien élève de l'EPITA, promo CSI 2003. À sa
sortie de l'école, il a poursuivi un troisième cycle en passant un DEA à
l'Université Paris Diderot et une thèse à l'INRIA Rocquencourt. Il est
aujourd'hui maître de conférence à Paris Diderot et travaille sur le
design des langages de programmation et de preuve.
Pour plus de renseignements, consultez http://seminaire.lrde.epita.fr/.
L'entrée du séminaire est libre. Merci de bien vouloir diffuser cette
information le plus largement possible.
--
Akim Demaille
Akim.Demaille(a)lrde.epita.fr
We are happy to announce the publication of the following new technical
report, available for download and online reading:
JSPP: Morphing C++ into JavaScript
Christopher Chedeau, Didier Verna
EPITA Research and Development Laboratory, Technical Report #201201-TR
Abstract:
In a time where the differences between static and dynamic languages are
starting to fade away, this report brings one more element to the
"convergence" picture by showing that thanks to the novelties from the
recent C++0x standard, it is relatively easy to implement a JavaScript
layer on top of C++. By that, we not only mean to implement the language
features, but also to preserve as much of its original notation as
possible. In doing so, we provide the programmer with a means to freely
incorporate highly dynamic JavaScript-like code into a regular C++
program.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
L'IRILL organise une journée de conférences et de discussions sur
l'enseignement de technologies des logiciels libres dans l'enseignement
supérieur. Le LRDE participera à cet événement qui aura lieu le jeudi 2
février 2012 dans les locaux de l'IRILL à l'antenne parisienne de
l'INRIA, 23, avenue d'Italie, 75013 Paris.
Pour en savoir plus :
http://www.irill.org/events/lsoc-logiciels-libres-et-enseignement-superieur
--
Daniela Becker
Responsable administrative du LRDE
Hello,
I'm happy to announce the release of Patcher 4.0. This is a major
release introducing many new changes and enhancements.
Patcher is a tool designed to automate and ease the maintenance of
archive-based projects. It provides assistance in building, reporting
and committing patches, as well as in handling the corresponding
ChangeLog entries, for example by creating skeletons. Patcher is the
official tool for XEmacs development.
New in this release:
** NEW FEATURES
- Support floating projects and temporary relocation
allowing to use the same project descriptor for various directories.
- Support for automatic detection of submodules
via the :submodule-detection-function project option and the
patcher-detect-submodules function. Currently supported RCS submodules are
Mercurial and Git via the functions 'patcher-[hg|git]-detect-submodules.
- Support ephemeral ChangeLogs
thanks to a new :change-logs-status project option. Ephemeral ChangeLogs are
not stored in ChangeLog files, but exist only temporarily for mail or log
message insertion (See ChangeLogs Status in the documentation).
- ChangeLog minor mode
providing easy navigation through the mail/ChangeLog buffers cycle via C-c C-p
n, C-c C-p p, C-c C-p N, C-c C-p P and C-c C-p m (See ChangeLogs Navigation in
the documentation).
- Support for switching to mail buffer and inserting ChangeLogs at once
via C-c C-p l from ChangeLog buffers.
- patcher-mail-insert-change-logs gets a prefix argument
allowing to temporarily change the ChangeLogs appearance. It also supports
inserting ChangeLogs even when the project is set not to.
- Additional binding for patcher-logmsg-commit: C-c C-p c
- Commit command buffer is now editable
Commit is done via C-c C-p c or C-c C-c (patcher-cmtcmd-commit).
- Fontification of commit command and log message buffers
with comment syntax and initial informative help. See new Patcher faces.
- Support for commit or log message canceling
via C-c C-z.
- Support for project abortion
via C-c C-p k or C-c C-k in all relevant buffers, including ChangeLogs.
- Support Subject: header modification in mail adaptation routines
via a new project option :subject-rewrite-format.
- Support project-wide dynamic subject modification
via C-c C-p S in both mail and log message buffers.
- Implement :kill-source-files-after-sending project option
- Support for source file saving
- Support for CVS diff's broken exit code policy
via a new project option: :ignore-diff-status.
* FIXES AND IMPROVEMENTS
- Improved support for temporary subprojects
making them behave like permanent ones (with a specific subdirectory and set
of files).
- Much better error handling
including exit code checking for external processes.
- Improved support for overlapping Patcher instances
through buffer and file referencing for both ChangeLog and source files.
- Documentation rewrite and sections organization cleanup
- More checks for project consistency
including missing or spurious ChangeLog entries, source diffs, undiffable and
uncommittable projects etc.
- Improved project rediffing
including support for partially generated ChangeLog skeletons, and interactive
prompting for skeleton un/re-generation.
* BACKWARD INCOMPATIBLE CHANGES
- Mercurial themes renamed from 'mercurial to 'hg
in order to remain consistent with the other RCS theme names.
- ChangeLogs insertion in mail buffers rebound to C-c C-p l
- Compressed ChangeLogs insertion in logmsg buffers rebound to C-c C-p L
- Removed directory-sep-char hacks
until the need for it raises again. Probably better implemented via project
options anyway.
- Diff commands can no longer be changed from patcher-mail-[adapt]
but instead, the prefix argument allows for temporary subproject
specification.
- patcher-*-subproject entry points removed
since they are no longer needed (see above).
- Removed :kill-source-file-after-diffing option
- :kill-source-files-after-sending renamed to :kill-sources-after-sending
- patcher-mail-check-change-logs-insertion is now a project option
named :check-change-logs-insertion.
- patcher-mail-check-commit-action is now a project option
named :check-commit.
- :change-logs-diff-command option now understands nil instead of 'diff
- The 'packed ChangeLogs appearance has been renamed to 'pack
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
Hello, and happy new year to all !
I'm pleased to announce that I will hold a 90 minutes session at the
next ACCU conference in Oxford, April 2012.
The session's topic is given below:
Impact of Extensibility on Domain Specific Language Design and Implementation
Domain-specific languages (DSLs) are usually very different from the
general purpose language (GPL) in which the embedding application is
written. The need for designing a DSL as a completely new language often
comes from the lack of extensibility of the chosen GPL. By imposing a
rigid syntax, a set of predefined operators and data structures, the
traditional GPL approach leaves no choice but to implement a DSL as a
different language, with its own lexical and syntactic parser, semantic
analyzer and possibly its own brand new interpreter or even compiler.
Some GPLs, however, are extensible or customizable enough to let one
implement a DSL merely as either a subset or an extension of the
original language. While the end-user does not see a difference with the
traditional approach, the gain for the developer is substantial. Since
the DSL is now just another entry point for the same original GPL, there
is essentially only one application written in only one language to
maintain. Moreover, no specific language infrastructure (parser,
interpreter, compiler etc.) is required for the DSL anymore, since it is
simply expressed in terms of the original GPL.
The purpose of this presentation is to illustrate the most important
factors that make a language truly extensible, and to show how
extensibility impacts the process of DSL design and implementation.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22