"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Archive for the ‘Génie logiciel’ Category

See http://fr.wikipedia.org/wiki/G%C3%A9nie_logiciel

[Grenoble] Soirée Spéciale avec Bruce Eckel : Scala as a first programming language » le mercredi 12 octobre 2011

Posted by patrick sur octobre 7, 2011

Source:: http://www.jugevents.org/jugevents/event/41752

Est-il besoin de présenter Bruce Eckel ?
Sans doute avez vous déjà vus son nom sur les bestsellers: Thinking in Java ou Thinking in C++.

Nous profitons de sa présence à la conférence internationale ICALEPCS à l’ESRF pour l’inviter au Java User Group.

Bruce Eckel : Scala as a first programming language

Bruce Eckel : Scala as a first programming language

Autres liens

Comptes rendus:


Posted in 2011, Années, Architecture logicielle, C_sharp, design pattern, DotNet, Grenoble, java, Langages | Tagué: , , | Leave a Comment »

Sphinx developpment : Implemented improved glossary markup which allows multiple terms per definition.

Posted by patrick sur janvier 7, 2011

Implemented improved glossary markup which allows multiple terms per definition

+   In contrast to regular definition lists, *multiple* terms per entry are
+   allowed, and inline markup is allowed in terms.  You can link to all of the
+   terms.  For example::
+      .. glossary::
+         term 1
+         term 2
+            Definition of both terms.
+   (When the glossary is sorted, the first term determines the sort order.)
.. versionadded:: 0.6
You can now give the glossary directive a « :sorted:«  flag that will
automatically sort the entries alphabetically.

+   .. versionchanged:: 1.1
+      Now supports multiple terms and inline markup in terms.


--- a/tests/root/markup.txt
+++ b/tests/root/markup.txt
 .. glossary::
+   :sorted:
       Particle with integer spin.
-   fermion
+   *fermion*
       Particle with half-integer spin.
+   tauon
+   myon
+   electron
+      Examples for fermions.
+   über
+      Gewisse
+   änhlich
+      Dinge


This development is very interesting. Use of the visitor pattern.

. rst:directive:: .. glossary::
   This directive must contain a reST definition list with terms and
   definitions.  The definitions will then be referencable with the :rst:role:`term`
   role.  Example::
   This directive must contain a reST definition-list-like markup with terms and
   definitions.  The definitions will then be referencable with the
   :rst:role:`term` role.  Example::
      .. glossary::
@@ -169,10 +169,25 @@ Glossary
            The directory which, including its subdirectories, contains all
            source files for one Sphinx project.
   In contrast to regular definition lists, *multiple* terms per entry are
   allowed, and inline markup is allowed in terms.  You can link to all of the
   terms.  For example::
      .. glossary::
         term 1
         term 2
            Definition of both terms.
   (When the glossary is sorted, the first term determines the sort order.)
   .. versionadded:: 0.6
      You can now give the glossary directive a ``:sorted:`` flag that will
      automatically sort the entries alphabetically.
   .. versionchanged:: 1.1
      Now supports multiple terms and inline markup in terms.

Posted in 2011, Documentation, Doc_sphinx, python, reStructuredText, Sphinx | Leave a Comment »

Doxylink is a Sphinx extension to link to external Doxygen API documentation

Posted by patrick sur septembre 19, 2010


Doxylink is a Sphinx extension to link to external Doxygen API documentation.

It works much like the extlinks extension but it does some more processing to link C++ symbols against their Doxygen HTML documentation.

When generating your Doxygen documentation, you need to instruct it to create a ‘tag’ file. This is an XML file which contains the mapping between symbols and HTML files

Doxylink is a Sphinx extension to link to external Doxygen API documentation.

Posted in 2010, Années, C++, Documentation, Doc_sphinx, Génie logiciel, Langages, reStructuredText, Sphinx | Tagué: , , , | Leave a Comment »

Quelques liens sur des modules python intéressants: plac, tox, shinken, six

Posted by patrick sur juillet 13, 2010

  • http://pypi.python.org/pypi/plac/ (‘…There is no want of command line arguments parsers in the Python world. The standard library alone contains three different modules: getopt (from the stone age), optparse (from Python 2.3) and argparse (from Python 2.7). All of them are quite powerful and especially argparse is an industrial strength solution; unfortunately, all of them feature a non-zero learning curve and a certain verbosity. They do not scale down well, at least in my opinion. It should not be necessary to stress the importance of scaling down; nevertheless, a lot of people are obsessed with features and concerned with the possibility of scaling up, forgetting the equally important issue of scaling down. This is an old meme in the computing world: programs should address the common cases simply and simple things should be kept simple, while at the same keeping difficult things possible. plac adhere as much as possible to this philosophy and it is designed to handle well the simple cases, while retaining the ability to handle complex cases by relying on the underlying power of argparse. Technically plac is just a simple wrapper over argparse which hides most of its complexity by using a declarative interface: the argument parser is inferred rather than written down by imperatively. Still, plac is surprisingly scalable upwards, even without using the underlying argparse. I have been using Python for 8 years and in my experience it is extremely unlikely that you will ever need to go beyond the features provided by the declarative interface of plac: they should be more than enough for 99.9% of the use cases. plac is targetting especially unsophisticated users, programmers, sys-admins, scientists and in general people writing throw-away scripts for themselves, choosing the command line interface because it is the quick and simple. Such users are not interested in features, they are interested in a small learning curve: they just want to be able to write a simple command line tool from a simple specification, not to build a command-line parser by hand. Unfortunately, the modules in the standard library forces them to go the hard way. They are designed to implement power user tools and they have a non-trivial learning curve. On the contrary, plac is designed to be simple to use and extremely concise, as the examples below will show…’)
    • http://micheles.googlecode.com/hg/plac/doc/plac.html#plac-vs-the-rest-of-the-world (‘…Originally plac boasted about being « the easiest command-line arguments parser in the world ». Since then, people started pointing out to me various projects which are based on the same idea (extracting the parser from the main function signature) and are arguably even easier than plac: opterator by Dusty Phillips CLIArgs. Luckily for me none of such projects had the idea of using function annotations and argparse; as a   consequence, they are no match for the capabilities of plac. Of course, there are tons of other libraries to parse the command line. For instance Clap by Matthew Frazier which appeared on PyPI just the day before plac; Clap is fine but it is certainly not easier than placplac can also be used as a replacement of the cmd module in the standard library and as such it shares many features with the module cmd2 by Catherine Devlin. However, this is completely coincidental, since I became aware of the cmd2 module only after writing plac. by Pavel Panchekha ..’)
  • http://codespeak.net/tox/ (‘tox aims to automate state-of-the-art packaging, testing and deployment of Python software right from your console or CI server, invoking your tools of choice‘)
  • http://packages.python.org/six/ (‘Six provides simple utilities for wrapping over differences between Python 2 and Python 3.‘)
  • http://www.shinken-monitoring.org/faq/ (‘Shinken is a new monitoring tool in AGLv3 written in Python compatible with Nagios. The main goal of Shinken is to allow users to have a fully flexible architecture for their monitoring system that can easily scale to large environments. Shinken is backward compatible with the Nagios configuration standard and plugins. It works on any operative system and architecture that supports Python, which includes Windows and Mac OS X/Darwin‘)

Posted in 2 to 3, 2010, Administration, Administration système, Années, Génie logiciel, python, tests, tests | Tagué: , , , , , , , | Leave a Comment »

Python packaging : Hitchhiker guide, toydist, envbuilder

Posted by patrick sur avril 22, 2010

Toujours beaucoup de mouvement en ce qui concerne la distribution de modules python.

  • http://cournape.wordpress.com/2010/04/22/first-public-release-of-toydist/ (‘The goals of toydist are simplicity and extensibility. There should be only one way to package simple packages (ideally, relying only on the toysetup.info file), while being flexible enough to handle complex softwares. The ultimate goal of toydist is to replace the hideous distutils extensions to build NumPy and SciPy. ‘)
  • http://pypi.python.org/pypi/envbuilder/0.3.0 (‘ A package for automatic generation of virtualenvs Envbuilder is a system for automatically building virtualenvs in Python. To do this, it uses a .env config file to define parcels, which are individual pieces of software to be checked out and installed into the virtualenv. It is mainly tested under Linux, but it should work under any platform that supports unix-y commands (including cygwin). In fact, you might even be able to make one config file work on both Windows and *nix if you’re careful.’)

Posted in 2010, Développement logiciel, distribute, Distribution de logiciel, Doc_sphinx, Génie logiciel, package_management, packaging, toydist | Leave a Comment »

Le service de construction de paquetages d’openSUSE : openSUSE build service (OBS)

Posted by patrick sur avril 7, 2010

  • http://en.wikipedia.org/wiki/OpenSUSE_Build_Service (« …The openSUSE Build Service is an open and complete distribution development platform designed to encourage developers to compile packages for multiple Linux distributions including openSUSE, Red Hat, Mandriva, Ubuntu, Fedora and Debian. It typically simplifies the packaging process, so developers can more easily package a single program for many distributions, and many openSUSE releases, making more packages available to users regardless of what distribution version they use. The build service software is published under the GPL. In an acknowledgement of its usefulness to the wider Linux community, the Linux Foundation has announced that the project will be added to the Linux Developer Network (LDN) »)
  • http://fr.opensuse.org/Build_Service ( » … OpenSUSE Build Service (OBS) est une plateforme complète de développement de distribution fournissant l’infrastructure nécessaire pour le développement des futures distributions basées sur openSUSE. Il comporte également les services qui permettent la compilation et la création de paquets pour les autres distributions Linux, comme Fedora, Debian, Ubuntu, et bien d’autres. Les utilisateurs d’openSUSE peuvent facilement passer en revue les différents paquets via l’interface web http://software.opensuse.org/ et télécharger les derniers paquets. Les interfaces ouvertes permettent aux services externes (par ex: SourceForge) et aux pages web d’interagir avec le Build Service et d’utiliser ses ressources…..)

Posted in 2010, command line interface, Développement logiciel, Distribution de logiciel, logiciel libre, openSUSE build service, packaging, python | Tagué: , , , , , , | Leave a Comment »

Quelques liens sur le développement de pilotes USB sous GNU/Linux: Greg Kroah-Hartman, Daniel Drake, fprint, libusb, pylibusb, lsusb.py, LDD3

Posted by patrick sur mars 22, 2010


FYI, this is a patch that will be sent out in the next round to Linus
for inclusion in 2.6.25.

If anyone has any objections about it, please let me know.


greg k-h


From: Greg Kroah-Hartman
Subject: USB: mark USB drivers as being GPL only

Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL.  This patch moves the USB apis to enforce that decision.

There are no known closed source USB drivers in the wild, so this patch
should cause no problems.

Signed-off-by: Greg Kroah-Hartman

Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the GPL.
This patch moves the USB apis to enforce that decision.

The USB subsystem has changed a lot over time, and it has been possible
to create userspace USB drivers using usbfs/libusb/gadgetfs that operate
as fast as the USB bus allows.  Because of this, the USB subsystem will
not be allowing closed source kernel drivers to register with it, after
this grace period is over.  If anyone needs any help in converting their
closed source drivers over to use the userspace filesystems, please
contact the linux-usb-<email removed> mailing list, and the developers
there will be glad to help you out. Greg Kroah-Hartman

linux kernel

linux drivers

usb vendor id (VID), product ID

python usb module

libusb library

fprint library depends on libusb

  • http://www.reactivated.net/ (‘My fprint efforts lead to me adopting the libusb project. I am working on libusb-1.0 which will offer new features allowing for more powerful applications’)
  • http://www.reactivated.net/fprint/wiki/Main_Page (« The fprint project aims to plug a gap in the Linux desktop: support for consumer fingerprint reader devices »)
  • http://www.reactivated.net/fprint/wiki/Libfprint

    • Written in C
    • Licensed as LGPL-2.1
    • Depends on libusb for USB communication and glib
    • Primarily developed for linux, but should be fairly portable
    • Offers a single API to application developers to access the entire range of supported devices
    • Supports imaging – downloading live fingerprint scans from the device
    • Includes image processing/matching code
    • Supports enrollment/verification – enrolling a print from a known user, and then later comparing a live scan to the enrolled print


Posted in 2010, Années, Drivers, Git, libusb, USB | Tagué: , , , , , , , | Leave a Comment »

Python: quelques liens sur pycon 2010 : state of packaging, PEP345, PEP 386, unittest, cmd2, GIL, distributing, etc..

Posted by patrick sur février 28, 2010

pycon 2010 Atlanta

pycon 2010 Atlanta

State of python packaging

  • http://blip.tv/file/3259547 (‘:Deployment, development, packaging, and a little bit of the cloud’ by Ian Bicking)
  • http://blip.tv/file/2061678 (‘Eggs and Buildout Deployment in Python, Puzzled about Python eggs and packages? Wondering how to repeatably pull together collections of packages into standalone development, testing and deployment environments, all while managing inter-dependencies? In this participatory tutorial, we’ll start with distutils, walk through using eggs in the cheeseshop and creating your own eggs, touch a bit on using virtualenv to set up a development environment, and then dig into using zc.buildout to rigorously control assembly specifications, with build recipes, versioning and dependency management. We’ll close by showing how to create your own recipes. Attendees are strongly encouraged to bring a laptop or partner with someone who does.’)
  • http://blip.tv/file/2080263 (‘How I Distribute Python applications on Windows – py2exe & InnoSetup’ by Brian Dorsey There are many deployment options for Python code. I’ll share what has worked well for me on Windows, packaging command line tools and services using py2exe and InnoSetup. I’ll demonstrate a simple build script which creates windows binaries and an InnoSetup installer in one step. In addition, I’ll go over common errors which come up when using py2exe and hints on troubleshooting them. This is a short talk, so there will be a follow-up Open Space session to share experience and help each other solve distribution problems )
  • http://blip.tv/file/2072580 (‘[VIDEO HAS ISSUES: no audio first 1.5m] If you’ve ever created a nifty application that makes people’s lives easier you know the truly hard part is convincing others to use it. One way to increase the number of people installing your software is to convince Linux distributions to package your software so that their end users can install by using the system tools they’re used to. One way of convincing them is by making your application easy to package.’)
  • http://blip.tv/file/3263882 (‘New *and* Improved: Coming changes to unittest, the standard library test framework’ by Michael Foord)
  • http://blip.tv/file/3261338 (‘Easy command-line applications with cmd and cmd2’ by Catherine Devlin)
    • http://catherine.devlin.googlepages.com/cmd2.html (‘cmd2 is a tool for writing command-line interactive applications. It is based on the Python Standard Library’s cmd module, and can be used anyplace cmd is used simply by importing cmd2 instead’)
  • http://blip.tv/file/3254256 (‘Understanding the Python GIL by David Beazley‘)

Posted in 2010, Génie logiciel, python, tests | Tagué: , , , , , | Leave a Comment »

Python documentation: news sphinx/numpydoc + flexirest + sphinx sourceforge theme/{gsdview,bestgui}

Posted by patrick sur novembre 16, 2009

http://pypi.python.org/pypi/numpydoc/0.3.1 (Sphinx extension to support docstrings in Numpy format)

http://pypi.python.org/pypi/flexirest/ (‘ The medium-featured, flexible reStructuredText utility. Flexirest is a project that was born out of the authors long-running interest for reStructuredText, and the idea of writing everyday documents like letters, invoices and other simple documents in this way. Flexirest tries to strike a middle ground between docutils own command line tool chain (rst2html et al), that I find a little to minimalistic and Sphinx, that I find very nice but a little heavy to use for a quickie document like a random letter or some such. In short, the goal of flexirest is to enable you to use the reST format for everyday documents instead of a word processor or similar with minimal fuzz. Hence you get to stay in the comfy environment of your text editor and tool chain. And you can check in your docs in text format into your version control system of choice. And, if used correctly, you get to reuse a couple of stylings that you only need to create once. There are some modestly advanced tricks you can do too, primarily writing your own docutils roles, but I wouldn’t consider those the major points of flexirest. For more information on how to operate flexirest, see the quick manual.’)

http://groups.google.fr/group/sphinx-dev/browse_thread/thread/8e97570a6321dd8d?hl=fr (‘sphinx theme that could be useful to authors of sourceforge hosted projects. The look is more or less the same of the default theme but there are some facilities that could be useful.
A more detailed description of the theme can be found at:

And, finally, two projects of using it:

  • http://gsdview.sourceforge.net/ (‘GSDView (Geo-Spatial Data Viewer) is a lightweight viewer for geo-spatial data and products. It is written in python and Qt4 and it is mainly intended to be a graphical front-end for the GDAL library and tools. GSDView is modular and has a simple plug-in architecture.’)
  • http://bestgui.sourceforge.net/ (‘BESTGUI is a Graphical User Interface (GUI) for BEST written in Python and GTK+. The Basic Envisat SAR Toolbox (BEST) is a collection of executable software tools that has been designed to facilitate the use of ESA (the European Space Agency) SAR data. It operates according to user-generated parameters files. For more detail you should refer to the BEST Home Page.’)

Posted in 2009, Documentation, Génie logiciel, python, reStructuredText | Tagué: , | Leave a Comment »

Des nouvelles de python : Guido Van Rossum et la documentation avec sphinx/rest , numpy, scipy, ipython

Posted by patrick sur novembre 9, 2009

Documentation rest/sphinx


Guido Van Rossum

http://neopythonic.blogspot.com/2009/11/python-in-scientific-world.html (‘...After the meeting, Fernando showed me a little about how NumPy is maintained. They have elaborate docstrings that are marked up with a (very light) variant of Sphynx, and they let the user community edit the docstrings through a structured wiki-like setup. Such changes are then presented to the developers for review, and can be incorporated into the code base with minimal effort.

An important aspect of this approach is that the users who edit the docstrings are often scientists who understand the computation being carried out in its scientific context, and who share their knowledge about the code and its background and limitations with other scientists who might be using the same code. This process, together with the facilities in IPython for quickly calling up the docstring for any object, really improves the value of the docstrings for the community. Maybe we could use something like this for the Python standard library; it might be a way that would allow non-programmers to help contribute to the Python project (one of the ideas also mentioned in the diversity discussions).’)
http://fdoperez.blogspot.com/2009/11/guido-van-rossum-at-uc-berkeleys.html (‘…I wanted both to thank him for creating and shepherding such a high-quality language for us scientists, and to establish a good line of communication with him (and indirectly the core python development group) so that he can understand better what are some of the use patterns, concerns and questions we may have regarding the language.I have the impression that in this we were successful, especially as we had time after the open presentations for a more detailed discussion of how we use and develop our tools. Most of us in scientific computing end up spending an enormous amount of time with open interpreter sessions, typically IPython ones (I started the project in the first place because I wanted a very good interactive environment, beyond Python’s default one), and in this work mode the key source of understanding for code are good docstrings. This is an area where I’ve always been unhappy about the standard library, whose docstrings are typically not very good (and often they are non-existent). We showed Guido the fabulous Numpy/Scipy docstring editor by Pauli Virtanen and Emmanuelle Gouillart, as well as the fact that Numpy has an actual docstring standard that is easy to read yet fairly complete. I hope that this may lead in the future to an increase in the quality of the Python docstrings, and perhaps even to the adoption of a more detailed docstring standard as part of PEP 8, which I think would be very beneficial to the community at large…’)A voir:



Extensions sphinx


Posted in 2009, Documentation, Doc_sphinx, Génie logiciel, python, reStructuredText, Sphinx | Tagué: , , , | Leave a Comment »