Archive for the ‘Génie logiciel’ Category
Posted by patrick sur octobre 7, 2011
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
Posted in 2011, Années, Architecture logicielle, C_sharp, design pattern, DotNet, Grenoble, java, Langages | Tagué: Bruce Heckell, Grenoble, JugAlpes | Leave a Comment »
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.
Particle with integer spin.
Particle with half-integer spin.
+ Examples for fermions.
This development is very interesting. Use of the visitor pattern.
- CHANGES (3 lines added, 0 lines removed)
- doc/markup/para.rst (18 lines added, 3 lines removed)
- sphinx/addnodes.py (3 lines added, 0 lines removed)
- sphinx/domains/std.py (86 lines added, 22 lines removed)
- sphinx/roles.py (0 lines added, 1 lines removed)
- sphinx/writers/html.py (4 lines added, 0 lines removed)
- sphinx/writers/latex.py (5 lines added, 1 lines removed)
- sphinx/writers/manpage.py (4 lines added, 0 lines removed)
- sphinx/writers/texinfo.py (3 lines added, 0 lines removed)
- sphinx/writers/text.py (4 lines added, 0 lines removed)
- tests/root/markup.txt (13 lines added, 1 lines removed)
Posted in 2011, Documentation, Doc_sphinx, python, reStructuredText, Sphinx | Leave a Comment »
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é: C++, c++ documentation, doxygen, sphinx extension | Leave a Comment »
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 plac. plac 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‘)
- http://en.wikipedia.org/wiki/Shinken_%28software%29 (‘Shinken is an open source computer systemnetwork monitoring software application compatible with Nagios. It watches hosts and services, alerting users when things go wrong and again when they get better. The major improvement of Shinken over Nagios is the availability to have a load balanced and high available architecture very easily. The administrator only has to manage one configuration, the system automatically « cuts » it into parts and dispatch it to workers nodes. It take its name from this functionality, a Shinken is a sharp Japanese sword and ‘)
- http://fr.wikipedia.org/wiki/Shinken_%28informatique%29 (‘…Ce qui diffère Shinken de son aîné Nagios n’est pas tant le langage de programmation utilisé que son architecture qui repose sur le principe Unix : à une tâche, un outil. C’est pour cette raison que Shinken n’est pas monolithique comme Nagios, mais utilise cinq processus différents qui travaillent ensembles et permettent d’obtenir une flexibilité bien supérieure au Nagios originel. C’est cette architecture qui permet d’obtenir la mise en place facile d’une supervision distribuée : un processus s’occupe de lire la configuration de l’utilisateur et la découpe intelligemment (en respectant les relations entre les éléments) afin de distribuer les morceaux vers des processus chargés d’absorber la charge de supervision. De cette manière, en cas de nouvelle charge, l’utilisateur peut rajouter des processus sans avoir à modifier sa configuration en profondeur. C’est un lissage de charge automatique. C’est de ce choix architectural que vient le nom de logiciel. Shinken, un nom de katana très tranchant, représente l’objectif du projet, à savoir de découper la configuration pour la renvoyer sur des daemons.’)
- http://www.gabes.fr/jean/2010/07/12/retour-des-rmll/ (‘…J’espère qu’elle fera réagir l’auteur de Nagios dans le bon sens, il est encore temps de se mettre à travailler ensemble. En tout cas, le projet avance, il semble plaire à beaucoup de monde. J’ai ainsi pu rencontrer l’équipe de Fusion Inventory lors des RMLL et il semble que nos projets soient amené à coopérer fortement dans l’avenir…’)
Posted in 2 to 3, 2010, Administration, Administration système, Années, Génie logiciel, python, tests, tests | Tagué: command line argument parser, Gerhard Laußer, Jean Gabès, Michele Simionato, nagios, plac, shinken, six | Leave a Comment »
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://cournape.github.com/toydist/ (‘Welcome to toydist main (sphinx) documentation. Toydist is a no-nonsense packaging tool solution for python softwares. Packaging simple python code consists in writing a simple declarative text file. Toydist aims at being simpler, more pythonic and more extensible than existing python packaging tools.’)
- 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 »
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…..)
- voir aussi: GNU/Linux magazine N°126, avril 2010 « OpenSUSE Build Service: créez vos paquets binaires pour (presque) toutes les distributions. ..OBS supporte les distibutions suivantes: OpenSUSE (bien sûr) et SELES, Fedora et RHEL, Mandriva, Debian et xUbuntu, pour les architectures i586 et x86_64. » Auteur: Alexandre Courbot.)
- https://build.opensuse.org/ (« …The openSUSE Build Service is the only service that allows developers to package software for all major Linux distributions. The service provides software developers with a convenient and easy to use tool to create and release open source software for openSUSE and other Linux distributions on different hardware architectures and for a broad user audience…« )
- http://www.novell.com/communities/node/9226/using-opensuse-build-service-create-and-distribute-kernel-module-packages (« Using the OpenSUSE Build Service to Create and Distribute Kernel Module Packages »)
- http://en.opensuse.org/Build_Service/CLI#osc.2C_the_Python_command_line_client (‘osc is written in Python, and in addition to the commandline interface it also provides a Python module, for use by other Python programs. osc is a subversion-like client. It serves as client for the source code repository part of the build service, and it is used to edit metadata or query about build results. Introductory usage examples are shown below. Note the Build_Service_Tutorial, which gives a more systematic introduction.osc is extensible. You can modify the behavior or write your own commands.’)
- http://sourceforge.net/projects/monoosc/ (‘MonoOSC is a project composed of two parts. A CSharp, C#, library used to access the openSUSE Build Service, OBS. The second part is a nice GUI which uses this library. MonoOSC requires the Mono 2.1 version of the distribution.’)
Posted in 2010, command line interface, Développement logiciel, Distribution de logiciel, logiciel libre, openSUSE build service, packaging, python | Tagué: avril 2010, create kernel modules, GNU/Linux magazine N°126, http://software.opensuse.org/search, monoosc, openSUSE build service, osc | Leave a Comment »
Posted by patrick sur février 28, 2010
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é: Brian Dorsey, Catherine Devlin, innosetup, Michael Foord, py2exe, Tarek Ziadé | Leave a Comment »
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é: sourceforge, sphinx theme | Leave a Comment »
Posted by patrick sur novembre 9, 2009
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).’)
(‘…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:
Posted in 2009, Documentation, Doc_sphinx, Génie logiciel, python, reStructuredText, Sphinx | Tagué: Guido Van Rossum, ipython, sequence diagram, UML | Leave a Comment »