show 314 results

Blog entries

  • Debian Lenny release date - almost there ?

    2009/02/09 by Arthur Lutz
    http://www.debian.org/logos/openlogo-nd-50.png

    Being big fans of debian, we are impatiently awaiting the new stable release of the distribution : lenny. Finding it pretty difficult to find information about when they were expecting to release it, I asked a colleague if he knew. He's a debian developer so I though he might have the info. And he did : according to the debian.devel mailing list we should be having the release for the 14th of February 2009. In other words : in 5 days!

    http://thread.gmane.org/gmane.linux.debian.devel.announce/1318

    There's a few geeky emails on the release date if you have time to read the threads.

    http://www.sinologic.net/wp-content/uploads/2008/08/lenny_debian.jpg

  • LUTIN77: Logilab Unit Test IN fortran 77

    2009/01/28 by Andre Espaze

    We've just released a new project on logilab.org : lutin77. It's a test framework for Fortran77.

    The goal of this framework is to make unit tests in fortran 77 by having few dependencies: a POSIX environment with C and fortran 77 compilers. Of course, you can use it for making integration or acceptance tests too. The 0.1 version has just been released here: http://www.logilab.org/project/lutin77

    If you are new to the unit tests way of building software, I must admit it lacks examples. For an introduction to the techniques involved, you can have a look at Growing Object-Oriented Software, Guided by Tests even if mocked subroutines will be for later. But remember that if you do not like to write tests, you are probably not writing unit tests.


  • Résumé de la rencontre francophone autour des forges du 21 janvier 2009

    2009/01/27

    Définition d'une forge

    Je vous propose tout d'abord une définition assez complète d'une forge logicielle.

    « Une forge ou plate-forme d'hébergement de projets logiciels est un ensemble réunissant les technologies du travail coopératif et du génie logiciel pour permettre le développement coordonné de logiciels en équipe. Les services de base d'une telle plate-forme sont axés sur le partage de fichiers (code source, données et exécutables) et l'animation du groupe. Ils permettent la rédaction et la programmation collaborative, et facilitent la communication dans le groupe grâce à des outils associés aux projets tels que des gestionnaires de listes de messagerie, des logiciels de suivi des tâches et de gestion des rapports d'anomalies. L'utilisation d'une plate-forme de ce type améliore la qualité des réalisations en accélérant les processus d'échange entre développeurs et les cycles de version des logiciels, tout en facilitant l'implication des utilisateurs dans la détection des erreurs ou la mise en lumière des fonctionnalités pertinentes des logiciels.»

    Tirée de http://overcrowded.anoptique.org/ForgesEtatArt (licence Art Libre, créateur initial Benoît Sibaud, diffusable sous LAL, CC By, CC By-SA et GFDL).

    Voir:

    Problèmes recensés

    image by http://flickr.com/photos/fastjack/ under creative commons

    Je liste ici quelques problèmes qui m'ont semblé émerger pendant les discussions de la journée.

    • forks nombreux du projet GForge avec peu de collaboration entre les projets
    • périmètre technique souvent imposé dans le débat; ce qui gêne la définition fonctionnelle d'une forge
    • forte hiérarchie des responsabilités avec un rôle 'développeur' limité au profit de celui du 'chef de projet'
    • très orienté web avec une stratégie d'intégration de produits tiers; d'où une situation délicate pour l'homogénéité des solutions à cause des limitations du protocole HTTP
    • la méthodologie de conception des logiciels n'est pas évoquée dans le choix d'une solution (et pas d'approche Agile en général).

    Présentations

    ALM, cycle de vie des logiciels et poste client

    Voir:

    http://gforge.org/themes/gforgegroup/images/logo.jpg
    Projet NovaForge

    Forge très aboutie où une approche MDA a été mise en oeuvre pour la génération de cas de tests à partir des cas d'utilisation décrits en UML.

    Intégration continue

    Plusieurs outils ont été nommés. J'ai placé la liste sur la page du wiki dédiée.

    Interopérabilité sémantique

    Projet xfmigration

    Ce projet vise à migrer le contenu d'une forge (BerliOS) vers GForge sans passer par le backend SGBD. L'idée est alors d'utiliser différentes ontologies pour 'mapper' les concepts des 2 forges.

    Cross-Forge Migration Tool is a concept for facilitating the migration process of project metadata between forge platforms. It uses SWRL rules for mapping and OWL-S standard for exporting mapping results.

    Voir:

    Projet HELIOS

    L'exposé présentait un cas d'utilisation du web sémantique pour la recherche et le tri de rapport d'anomalies sur des forges séparées. L'exemple utilisé a été de pouvoir rapatrier; puis sélectionner des tickets relatifs au projet Konqueror à travers le bugzilla de Debian et celui du projet lui-même. Il est ainsi possible de détecter certains doublons ou incohérences de versions.

    http://www.cubicweb.org/index-cubicweb.png
    Projet CubicWeb forge

    J'ai pu présenter le framework CubicWeb et son architecture de composants. La présentation n'étant pas prévue initialement mais j'ai pû faire une démonstration à partir de la forge publique de Logilab.

    À partir d'un schéma enrichi des composants installés, il est possible de faire des requêtes RQL (similaire à SPARQL) sur des entités et des sources distantes (Base de données, LDAP, subversion, ...). Logilab travaille aujourd'hui à l'ajout d'ontologies dans la manipulation de ce schéma.

    Remerciements

    Je remercie les organisateurs de cette rencontre édition 2009 ainsi que l'ensemble des intervenants propices à l'échange de points de vue.


  • Apycot big version change

    2009/01/26 by Arthur Lutz

    The version convention that we use is pretty straight forward and standard : it's composed of 3 numbers separated by dots. What are the rules to incrementing each on of these numbers ?

    • The last number is a incremented when bugs are corrected
    • The middle number is incremented when stories (functionalities) are implemented to the software
    • The first number is incremented when we have a major change of technology

    Well... if you've been paying attention, apycot just turned 1.0.0, the major change of technology is that it is now integrated to CubicWeb (instead of just generating html files). So for a project in your forge, you describe the apycot configuration for it, and the tests for quality assurance are launched on a regular basis. We're still in the process of stabilizing it (latest right now it 1.0.5), but it already runs on the CubicWeb projects, see the screenshot below :

    http://www.logilab.org/image/7682?vid=download

    You should also know that now apycot has two components : the apycotbot which runs the tests and an cubicweb-apycot which displays the results in cubicweb (download cubicweb-apycot-1.0.5.tar.gz and apycotbot-1.0.5.tar.gz).


  • We're now publishing for Ubuntu aswell

    2009/01/26 by Arthur Lutz
    http://www.ubuntu.com/themes/ubuntu07/images/ubuntulogo.png

    We've always been big fans of debian here at Logilab. So publishing debian packages for our open source software has always been a priority.

    We're now a bit involved with Ubuntu, work with it on some client projects, have a few Ubuntu machines lying around, and we like it too. So we've decided to publish our packages for Ubuntu as well as for debian.

    In the 0.12.1 version of logilab-devtools we introduced publishing of Ubuntu packages with lgp (Logilab Packaging) - see ticket. Since then, you can add the following Ubuntu source to your Ubuntu system

    deb http://ftp.logilab.org/dists hardy/
    

    For now, only hardy is up and running, give us a shout if you want something else!


  • Rencontre francophone autour des forges

    2009/01/19
    http://farm1.static.flickr.com/25/61448490_5f9a023307_m.jpg

    Logilab sera présent le Mercredi 21 janvier à la rencontre francophone autour des forges. Les présentations et les discussions porteront sur :

    • échange de données entre forges, interopérabilité
    • définition d’un modèle d’intégration ouvert
    • recherche multi-forges
    • gestion des permissions et partage d’identités
    • interaction entre la forge et le poste client

    Logilab espère ainsi bénéficier de l'expérience de chacun et des pistes d'évolutions pour, à terme, les intégrer dans son projet de forge basé sur CubicWeb.

    Toutes les informations de l'événement sont disponibles ici.

    photo par StormyDog sous licence Creative Commons.


  • Release of CubicWeb 3.0

    2009/01/05 by Nicolas Chauvat
    http://www.cubicweb.org/index-cubicweb.png

    As some readers of this blog may be aware of, Logilab has been developing its own framework since 2001. It evolved over the years trying to reach the main goal (managing and publishing data with style) and to incorporate the goods ideas seen in other Python frameworks Logilab developers had used. Now, companies other than Logilab have started providing services for this framework and it is stable enough for the core team to be confident in recommending it to third parties willing to build on it without suffering from the tasmanian devil syndrom.

    CubicWeb version 3.0 was released on the last day of 2008. That's 7 years of research and development and (at least) three rewrites that were needed to get this in shape. Enjoy it at http://www.cubicweb.org/ !


  • hgview 0.10.0

    2008/12/30 by Graziella Toutoungis

    I have the pleasure of announcing that the version hgview 0.10.0 was posted on this site and is available for downloading. In this version we added some new functionalities like :

    • The possibility to order all revisions by date or author or description.....
    • Support for localtime.
    • Improve the message header when hg mv is used and fix the author base color
    • Integration of bboissin's fixes
    http://www.selenic.com/hg-logo/logo-droplets-50.png

    Finally : We have taken into account older versions. As pointed out by some users, mercurial version 1.1.x wasn't working very well with hgview, so we created patches which have to be applied according to the version of mercurial you are using.


  • Pyreverse : UML Diagrams for Python

    2008/12/23 by Emile Anclin

    Pyreverse analyses Python code and extracts UML class diagrams and package depenndencies. Since september 2008 it has been integrated with Pylint (0.15).

    Introduction

    Pyreverse builds a diagram representation of the source code with:
    • class attributes, if possible with their type
    • class methods
    • inheritance links between classes
    • association links between classes
    • representation of Exceptions and Interfaces

    Generation of UML diagrams with Pyreverse

    The command pyreverse generates the diagrams in all formats that graphviz/dot knows, or in VCG :

    The following command shows what dot knows:

    $ dot -Txxx
    Format: "xxx" not recognized. Use one of: canon cmap cmapx cmapx_np dia dot
    eps fig gd gd2 gif hpgl imap imap_np ismap jpe jpeg jpg mif mp pcl pdf pic
    plain plain-ext png ps ps2 svg svgz tk vml vmlz vrml vtx wbmp xdot xlib
    

    pyreverse creates by default two diagrams:

    $ pyreverse -o png -p Pyreverse pylint/pyreverse/
    [...]
    creating diagram packages_Pyreverse.png
    creating diagram classes_Pyreverse.png
    
    • -o : sets the output format
    • -p name : yields the output files packages_name.png and classes_name.png

    Options

    One can modify the output with following options:

    -a N, -A    depth of research for ancestors
    -s N, -S    depth of research for associated classes
    -A, -S      all ancestors, resp. all associated
    -m[yn]      add or remove the module name
    -f MOD      filter the attributes : PUB_ONLY/SPECIAL/OTHER/ALL
    -k          show only the classes (no attributes and methods)
    -b          show 'builtin' objects
    

    Examples:

    General Vue on a Module

    pyreverse -ASmy -k -o png pyreverse/main.py -p Main
    
    [image : classes_Main.png, class diagram with all dependencies]

    full size image

    With these options you can have a quick vue of the dependencies without being lost in endless lists of methods and attributes.

    Detailed Vue on a Module

    pyreverse -c PyreverseCommand -a1 -s1 -f ALL -o png  pyreverse/main.py
    
    [image : PyreverseCommand.png, pyreverse.diagram.ClassDiagram class diagram with one dependency level]

    module in full size image

    Show all methods and attributes of the class (-f ALL). By default, the class diagram option -c uses the options -A, -S, -my, but here we desactivate them to get a reasonably small image.

    Configuration File

    You can put some options into the file ".pyreverserc" in your home directory.

    Exemple:

    --filter-mode=PUB_ONLY --ignore doc --ignore test
    
    This will exclude documentation and test files in the doc and test directories. Also, we will see only "public" methods.

  • Fusionner dans le bon sens avec mercurial

    2008/11/27 by Nicolas Chauvat
    http://www.selenic.com/hg-logo/logo-droplets-50.png

    Contrairement à ce que l'on pourrait penser a priori, il y a un bon et un mauvais sens pour fusionner deux têtes dans en entrepôt mercurial.

    Prenons un exemple et admettons que l'on parte d'une révision 123. Alfred, Barnabé et Coruscant font des changements qui produisent l'arbre suivant:

    123 -> 124 -> 125 ---> 126 -> 129 --> 130
                       \-> 127 -> 128 /
    

    Si dans le même temps, Zoé part de la révision 123 et produit l'arbre:

    123 -> 131
    

    quand Zoé va vouloir faire son hg push sur l'entrepôt partagé, elle va avoir le message "ça crée des têtes, est-ce que vous êtes sûr de vouloir faire ce push". Zoé va se dire qu'il vaut mieux commencer par un 'pull' et un 'merge', mais c'est là qu'il faut se méfier.

    En effet, si Zoé est sur la révision 131 et qu'elle fusionne avec 130, le changeset sera énorme car il contiendra tous les changements qui permettent de passer de 123 à 130. En revanche, si Zoé passe sur la 130 et fusionne avec la 131, elle n'aura que les changements qu'elle vient d'apporter. Dans le premier cas, le 'merge' sera difficile à comprendre, alors qu'il sera bien plus simple dans le second.

    Au final, comment faire la fusion dans le "bon" sens ?

    1/ hg push -> ah tient, ça crée des têtes, donc je ne le fais pas

    2/ hg pull -u ou hg pull suivi de hg merge -> y'a eu un merge

    3/ hg status -> beaucoup de fichiers modifiés... oulàlà, c'est bizarre je vais regarder

    4/ hgview -> ah oui, sur l'autre tête y'a beaucoup plus de changements, donc je vais plutôt faire le 'merge' dans l'autre sens

    5/ hg up -C ab123_autre_tete -> je me retrouve sur l'autre tête

    6/ hg merge cd456_ma_tete -> un joli 'merge'

    7/ hg status -> seulement quelques fichiers modifés, voilà qui est mieux

    8/ hg ci -m merge -> youpi, je valide cette fusion

    9/ hg push -> tagada, je partage avec mes voisins

    Moralité: faites des hg status et des hgview aussi souvent que nécessaire pour préparer vos commits et parvenir à un historique facile à comprendre.

    Remarque: on peut aussi remplacer les étapes 5, 6 et 7 par hg diff -r ab123_autre_tete -r cd456_ma_tete pour afficher le diff de ma_tete par rapport à autre_tete, car l'opération de fusion doit être symétrique et donner le même résultat qu'on la lance depuis l'une ou l'autre tête, même si l'affichage par défaut de hg status et hg diff dépend de la tête qui constitue le premier parent (l'étape 5 ayant justement pour effet de changer ce premier parent).


show 314 results