[Grenoble] Soirée Spéciale avec Bruce Eckel : Scala as a first programming language" le mercredi 12 octobre 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++.

• 
  http://www.artima.com/weblogs/viewpost.jsp?thread=328540
  (‘Scala: The Static Language that Feels Dynamic. The highest complement you can deliver in the Python world is to say that something is "Pythonic" — that it feels and fits into the Python way of thinking. I never imagined that a static language could feel this way, but Scala does — and possibly even better‘)
• Sa page Wikipedia (
  http://en.wikipedia.org/wiki/Bruce_Eckel)
  
• Ses ouvrages sur Amazon (Java, C++, Flex, Python, C#, Design Patterns …)
• Sa société MindView, Inc
• son blog :
  http://www.artima.com/weblogs/index.jsp?blogger=beckel
  
• 
  http://www.artima.com/weblogs/viewpost.jsp?thread=335549
  (Web App with jQuery, CoffeeScript, Ajax, Web.py & Heroku)
• 
  http://www.artima.com/weblogs/viewpost.jsp?thread=334450
  (Speaking in Grenoble, France and Stockholm)

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

Autres liens

• 
  http://en.wikipedia.org/wiki/Scala_%28programming_language%29
  ("Scala (pronounced /ˈskɑːlə/ skah-lə) is a multi-paradigm programming language designed to integrate features of object-oriented programming and functional programming.^[2] The name Scala is a portmanteau of "scalable" and "language", signifying that it is designed to grow with the demands of its users…Scala has the same compilation model as Java and C# (separate compilation, dynamic class loading), so Scala code can call Java libraries (or .NET libraries in the .NET implementation).")

Comptes rendus:

• 
  http://www.alpesjug.fr/?p=1003 
  
• Bruce Eckel va sortir un livre "Atomic Scala" en 2012. Ce livre est co-écrit avec Diane Marsh.
• 
  http://www.reinventing-business.com/2011/10/mind-expanding-trip-through-europe.html
  (‘…it goes a long way to answering my question of why Scandinavians seem to be so productive and innovative in the world of computers. The list is long, especially when it comes to language designers: Niclaus Wirth (Pascal), Bjarne Stroustrup (C++) and Martin Odersky (Scala) are probably the most well-known names. Maybe it starts with the weather and long dark winters that make indoor and intellectual activities a natural path, but the Scandinavians have taken this and turned lifelong learning into a foundation of their culture (in the programming world, at least).’)
• 
  https://docs.google.com/present/view?id=dcpmkg5z_266ds4wt6cc&pli=1
  (‘Reinventing Business’)

• Sources
• - Bruce Eckel à Grenoble le mercredi 12 octobre 2011 (
  http://www.alpesjug.fr/?p=1003
  )
  - programmingsummercamp

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

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:
 
    boson
       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.

• https://bitbucket.org/birkenfeld/sphinx/changeset/32c4f57a02c9
  • 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)

. rst:directive:: .. glossary::
155	155
156		This directive must contain a reST definition list with terms and
157		definitions. The definitions will then be referencable with the :rst:role:`term`
158		role. Example::
	156	This directive must contain a reST definition-list-like markup with terms and
	157	definitions. The definitions will then be referencable with the
	158	:rst:role:`term` role. Example::
159	159
160	160	.. glossary::
161	161
…	…	@@ -169,10 +169,25 @@ Glossary
169	169	The directory which, including its subdirectories, contains all
170	170	source files for one Sphinx project.
171	171
	172	In contrast to regular definition lists, *multiple* terms per entry are
	173	allowed, and inline markup is allowed in terms. You can link to all of the
	174	terms. For example::
	175
	176	.. glossary::
	177
	178	term 1
	179	term 2
	180	Definition of both terms.
	181
	182	(When the glossary is sorted, the first term determines the sort order.)
	183
172	184	.. versionadded:: 0.6
173	185	You can now give the glossary directive a ``:sorted:`` flag that will
174	186	automatically sort the entries alphabetically.
175	187
	188	.. versionchanged:: 1.1
	189	Now supports multiple terms and inline markup in terms.

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

http://packages.python.org/sphinxcontrib-doxylink/

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.

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

• 
  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.gnulinuxmag.com/index.php/2010/07/09/gnulinux-magazine-hs-n%C2%B049-aoutseptembre-2010-chez-votre-marchand-de-journaux
    
  • 
    http://shinken.git.sourceforge.net/git/gitweb.cgi?p=shinken/shinken;a=tree
    
  • 
    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…’)
  • 
    http://2010.rmll.info/IMG/pdf/RMLL2010-AdminSys-SupervisionGrandsEnvironnements.pdf
    

Python packaging : Hitchhiker guide, toydist, envbuilder

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

• 
  http://guide.python-distribute.org/index.html
  (‘Welcome to The Hitchhiker’s Guide to Packaging.. under development…’)

• 
  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://github.com/cournape/toydist
    
  • 
    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://cournape.github.com/toydist/features.html
      
• 
  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.’)
  • 
    http://jasonbaker.github.com/envbuilder/0.3/
    (documentation)

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

• 
  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://software.opensuse.org/search
    
  • 
    http://ldn.linuxfoundation.org/search/node/obs
    
  • 
    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.’)
  • 
    http://2008.rmll.info/Service-de-construction-de.html
    (‘Le service de construction de paquetages d’openSUSE est une plate-forme permettant aux développeurs de créer des paquetages pour différentes distributions : opensuse, fedora, debian, etc.Vincent Untz est contributeur du projet GNOME, et travaille chez Novell, l’éditeur de la distribution openSUSE. Il nous présentera cet outil utilisé pour openSUSE, mais utilisable également par d’autres projets.’)

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

http://archive.netbsd.se/?ml=&a=2009-01&t=6220842

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.

thanks,

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

• 
  http://www.kroah.com/log/
  

linux kernel

• 
  http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary
  

linux drivers

• 
  http://lwn.net/Kernel/LDD3/
  

usb vendor id (VID), product ID

• 
  https://usb-ids.gowdy.us/read/UD/
  

python usb module

• 
  http://github.com/gregkh/usbview/
  (‘USBView is a small GTK application to show what the device tree of the USB bus looks like. It shows a graphical representation of the  devices that are currently plugged in, showing the topology of the USB bus. It also displays information on each individual device on the bus’)
• 
  http://github.com/gregkh/usbutils/blob/v0.87/lsusb.py
  
• 
  http://pypi.python.org/pypi/pyusb/0.4.2
  (‘PyUSB provides easy USB access to python. The module contains classes and methods to support the most USB operations.’)
• 
  http://usbip.sourceforge.net/
  (‘USB/IP Project aims to develop a general USB device sharing system over IP network. To share USB devices between computers with their full functionality, USB/IP encapsulates "USB I/O messages" into TCP/IP payloads and transmits them between computers’)
• 
  http://code.google.com/p/pyusbip/
  

libusb library

• 
  http://git.libusb.org/?p=libusb.git;a=summary
  
• 
  http://pypi.python.org/pypi/pylibusb/0.2
  

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

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

pycon 2010 Atlanta

State of python packaging

• 
  http://tarekziade.wordpress.com/2010/02/20/pycon-slides-answers-to-gm-questions/
  
  • 
    http://ziade.org/slides/pycon-2010-state-of-packaging.pdf
    
  • 
    http://tarekziade.wordpress.com/2010/02/10/pep-345-and-386-accepted-summary-of-changes/
    
    • 
      http://www.python.org/dev/peps/pep-0314/
      
    • 
      http://www.python.org/dev/peps/pep-0345/
      
    • 
      http://www.python.org/dev/peps/pep-0376/
      
    • 
      http://www.python.org/dev/peps/pep-0386/
      

• (‘:Deployment, development, packaging, and a little bit of the cloud’ by Ian Bicking)

• (‘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.’)

• (‘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 )

• (‘[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.’)

• (‘New *and* Improved: Coming changes to unittest, the standard library test framework’ by Michael Foord)

  • http://docs.python.org/dev/library/unittest.html
• (‘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’)
• (‘Understanding the Python GIL by David Beazley‘)

  • 
    http://www.dabeaz.com/python/Understanding
    GIL.pdf

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

-
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://bitbucket.org/esmljaos/flexirest/overview/
  (The medium-featured, flexible reStructuredText utility)

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

• 
  http://sourceforge.net/apps/trac/gsdview/browser/trunk/doc/themes/sourceforge
  
  
• 
  http://sourceforge.net/apps/trac/gsdview/browser/trunk/doc/themes/sourceforge/README.txt
  ‘)

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

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

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:

-
http://docs.scipy.org/numpy/Front%20Page/

 

Extensions sphinx

• 
  http://pypi.python.org/pypi/sphinxcontrib-sdedit/0.3
  (‘Sphinx extension for drawing sequence diagrams This package contains the Sphinx extension for sdedit.’)