show 316 results

Blog entries

  • Mercurial 2.3 sprint, Day 1-2-3

    2012/05/15 by Pierre-Yves David

    I'm now back from Copenhagen were I attended the mercurial 2.3 sprint with twenty other people. A huge amount of work was done in a very friendly atmosphere.

    Regarding mercurial's core:

    • Bookmark behaviour was improved to get closer to named branch's behaviour.
    • Several performance improvements regarding branches and heads caches. The heads cache refactoring improves rebase performance on huge repository (thanks to Facebook and Atlassian).
    • The concept I'm working on, Obsolete markers, was a highly discussed subject and is expected to get partly into the core in the near future. Thanks to my employer Logilab for paying me to work on this topic.
    • General code cleanup and lock validation.
    http://www.logilab.org/file/92956?vid=download

    Regarding the bundled extension :

    • Some fixes where made to progress which is now closer to getting into mercurial's core.
    • Histedit and keyring extensions are scheduled to be shipped with mercurial.
    • Some old and unmaintained extensions (children, hgtk) are now deprecated.
    • The LargeFile extension got some new features (thanks to the folks from Unity3D)
    • Rebase will use the --detach flag by default in the next release.
    http://www.logilab.org/file/92958?vid=download

    Regarding the project itself:

    http://www.logilab.org/file/92955?vid=download

    Regarding other extensions:

    http://www.logilab.org/file/92959?vid=download

    And I'm probably forgetting some stuff. Special thanks to Unity3D for hosting the sprint and providing power, network and food during these 3 days.


  • Mercurial 2.3 day 0

    2012/05/10 by Pierre-Yves David

    I'm now at Copenhagen to attend the mercurial "2.3" sprint.

    About twenty people are attending, including staff from Atlassian, Facebook, Google and Mozilla.

    I expect code and discussion about various topic among:

    • the development process of mercurial itself,
    • performance improvement on huge repository,
    • integration of Obsolete Markers into mercurial core,
    • improvement on various aspect (merge diff, moving some extension in core, ...)

    I'm of course very interested in the Obsolete Markers topic. I've been working on an experimental implementation for several months. An handful of people are using them at Logilab for two months and feedback are very promising.


  • Mêlée numérique 2012: État de l'art Big Data

    2012/05/03 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mêlée numérique à Toulouse.

    Après une mini-conf d'une heure sur l'état de l'art de l'Open Data, j'ai suivi l'après midi "état de l'art Big Data" au même format.

    Big Data vu par SGI

    Ma première surprise a été d'apprendre où était caché SGI (vous vous rappelez peut-être les postes Indigo qu'on trouvait pour faire du graphisme et de l'animation...) depuis tout ce temps : et bien non, ils ne sont pas morts mais montent des calculateurs pour des grands comptes. Le premier intervenant était donc M. Carsalade, responsable infrastructure chez SGI, qui a pris quelques exemples d'applications et d'infrastructures "Big Data" (petabytes de données) menées par SGI.

    Parmi les applications citées : calculateurs chez NOAA (sorte de Météo France aux US) ou Total (analyse des sols), Cosmos Project (15 tera de ram...), génomiques

    SGI déploie par ex. :

    • 500 000 serveurs SGI chez Amazon pour S3/eC2, site web, AWS...
    • 300 000 serveurs SGI chez Microsoft pour Live Search (Bing, Exchange, MSN, etc.)

    La technologie est souvent basée sur HADOOP, qui permet la recherche en parallèle sur un cloud, basée sur le principe map / reduce initiée par Google.

    On note l'évolution des technologies dans le temps et par volume croissant:

    • OLTP (données structurées),
    • data warehouse (données essentiellement structurées),
    • Big Data (données essentiellement non structurées)

    Il conclut que Big Data, c'est :

    • la capacité de stockage de données, et celle de l'agrandir au fur et à mesure du besoin,
    • travailler sur ces données (HADOOP), les analyser et les visualiser,
    • mais aussi archiver ces données, problématique souvent ignorée au premier abord mais pourtant nécessaire.

    Big Data vu par une PME spécialisée

    La présentation suivante de M.Royer (Datasio) est un peu plus technique.

    Pour commencer, une liste des sources de données problématiques potentielles (i.e. la production ne s'arrête pas) :

    • production par des réseaux d'observation autonome (capteurs météo, GPS, RFID, balises Argos...),
    • données dépendantes d'une communauté d'utilisateurs et d'individus instrumentés,
    • données produites plus vite qu'on ne les traite,
    • "on verra le traitement plus tard".

    Synthèse de ces problèmes : les "3 V" du Big Data: Volume / Variété / Vélocité.

    Les techniques autour de Big Data promettent de :

    • faciliter la collecte et l'aggrégation (mesurer les opérations, acquérir tous les flux possibles, stocker les mesures brutes)
    • valoriser le capital de données (découvrir après coup des opportunités inexploitées, outils de fouille adaptés aux gros volumes, extraire et distiller l'information)

    Il revient sur HADOOP en quelques mots :

    • solution Open Source, issu de la fondation Apache,
    • à l'initiative de Yahoo via un essaimage Hortonworks
    • c'est un projet en maturation, avec une communauté active, mais des branches de code variées,
    • constitué d'un système de fichier distribué avec redondance (parallélisation des données) et possibilité map / reduce (parallélisation des tâches à effectuer sur les données)

    Si Big Data est un nouveau terme pour une problématique qui n'est pas nouvelle, une différence liée à la technique map / reduce les traitements sont effectués sur les serveurs qui hébergent les données au lieu de pousser les données vers un calculateur. Attention au fait cependant que pour fonctionner, les algorithmes doivent fonctionner de manière indépendante sur un sous-ensemble indéterminé de données (donc finalement indépendamment sur chaque "donnée"). Enfin, on se concentre sur l'efficience de la création et de la lecture des données, à l'inverse des bases de données traditionnelles qui se concentrent également sur la mise à jour et la suppression.

    Je ne sais pas s'il y avait une conclusion, la présentation a été abrégée faute de temps.

    Big Data vu par Météo France

    La dernière présentation était celle de M.Beuraud de Météo France dont la problématique, pas simple mais à laquelle nous sommes tous sensibles, est la prévision numérique du temps.

    Il note tout d'abord que la qualité des prévisions a augmenté : la qualité d'une prévison à 48h aujourd'hui vaut prévision à 24h il y a 15 ans en lien avec l'augmentation des performances du centre de calcul HPC de Météo France à Toulouse (évolution matérielle tous les 3 ans) :

    • 2 GFlops en 1991 (date de l'ouverture du centre), basé sur des machines Cray 2,
    • 100 TFlops en 2009, basé sur des machines NEC SX9

    Le volume de données étudiées est maintenant beaucoup plus important, principalement du fait de la constellation de satellites qui s'est développée et qui produit un volume beaucoup plus important que les mesures conventionnelles (au sol). On a vu un "déluge de données" satellitaires depuis 2010. D'un point de vue stockage, le site est passé de 20Go en 1991 à plusieurs pétaoctets aujourd'hui.

    De par les différentes contraintes extérieures (données à fournir aux clients), une prévision à 24h doit être faite en 25 minutes. De plus, la puissance de calcul nécessaire augmente sans cesse notamment à cause des facteurs suivants (en plus du volume de données à analyser qui augmente) :

    • maille de plus en plus petite,
    • couplage de modèles de plus en plus nombreux,
    • prévision ensembliste : on lance X fois le même modèle avec des entrées différentes pour voir la stabilité de la prédiction.

    A noter qu'ici, on n'est pas dans des technos de type HADOOP.

    Il conclut que le volume de données à traiter va continuer à grandir, et que la gestion des données est l'enjeu majeur de la décennie qui s'ouvre.

    Conclusion

    J'ai été surpris de voir l'angle d'approche pour la présentation d'une thématique Big Data, qui était pour moi (novice je l'avoue) plus liée aux technologies Web. J'ai finalement trouvé que c'était intéressant de remettre ça avec cette perspective, et ainsi de replacer ce que recouvrent finalement les mots Big Data. Encore un grand mot qui veut tout et rien dire quoi :p


  • Mélée numérique 2012: État de l'art Open Data

    2012/04/27 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mélée numérique à Toulouse.

    J'y ai assisté à une mini-conf d'une heure sur l'état de l'art de l'Open Data. Comme d'habitude, je conseillerais plutôt, lors des salons de ce type, d'aller voir les conférences sur des thèmes qui vous sont inconnus, sous peine de ne pas apprendre grand chose. C'est resté pas trop mal, et voici ce que j'ai retiré de cette présentation conjointe de Bluenove, et Inno3.

    Data, c'est quoi exactement ?

    Dans le cadre de l'Open Data la donnée est le matériaux brute. C'est une valeur, une observation. Ce n'est pas une information, qui recoupe et interprète plusieurs données.

    Le recoupement de données permet de créer des informations de valeurs. Cependant certaines données n'ont pas vocation à être ouvertes (ex. données stratégiques, personnelles, défense).

    Qui sont les acteurs de l'Open Data ?

    On distingue :

    Qui a ouvert ses données ?

    En France : Étalab, 16 ministères, 5 administrations publiques, 2 régions, 5 départements, 11 métropoles, 7 municipalités, 3 grandes entreprises (réseau férré, sncf, la poste), 4 initiatives culturels, PS...

    Dans le monde: 28 pays, environ 120 localités de toutes tailles. On voit se former des initiatives continentales,

    Pour quels résultats ?

    • Un nouveau type d'information (NR issu d'une collaboration journaliste/développeur/graphiste), plus ou moins couvert sous le terme "Data viz" (eg OWNI)
    • Des applications diverses, parfois issues de concours (eg application téléphone Tourisme 71)

    Quels sont les freins et incitations ?

    Il y a une incitation/obligation venant de l'Europe (2003) et de l'état (2006) pour les acteurs publics, les acteurs privés délégataires d'un service public ou monopolistiques. On peut ajouter les modèles économiques basés sur la société de l'information (eg http://www.openstreetmap.org/ qui crée des données ouvertes collaborativement depuis 2006)

    Les freins viennent :

    • des données non diffusables,
    • d'une cohabitation parfois difficile avec Loi informatique et liberté / CNIL (le recoupement de plusieur sources peut finir par redonner des données "personnelles").

    De plus cette incitation à la transparence crée nouveaux rapport entre secteur public et privé (je ne m'en plaindrai pas personnellement :p ).

    Quels droits / quelles licences sur les données ?

    Rappel : la propriété intellectuelle recrée une notion similaire à la propriété matérielle mais sur des oeuvres. Les données ne sont pas soumise à la propriété intellectuelle. Les données originelles, ainsi qu'une base de données à forte valeur ajoutée, ou encore les signes distinctifs (marque, nom de domaine, logo, etc) sont considérés ou considérables comme des oeuvres.

    Il faut donc une gestion stratégique des différents droits de propriété intellectuelle. Que faut-il partager ou retenir ? Quel est l'encadrement souhaité ? Copyleft (eg GPL) ou non ? Compatibilité entre jeux de données ?

    Aujourd'hui on a comme licenses pour les données :

    • les licences basées sur le droit d'auteur (CC)
    • les licences basées sur la loi de 1978 (droit public en france, uniquement pour collectivité, pas de propriété intellectuelle) (LIP et APIE)
    • les licences spécialisées (ODBL, PDDL, ODC-By créées par Open knowledge foundation)
    • les licences dédiées (Licence Ouverte)

    En France (dans l'administration publique ?) l'ODBL et la Licence Ouverte sont principalement utilisées.

    En Europe et à l'étranger, on trouve plutôt l'ODBL, CC-0 et autres licences dédiées.

    Et l'Open Data dans l'entreprise ?

    Bluenove a mené une enquête auprès de grands groupes. Quelques résultats (l'intégralité est publiée dans un petit livre blanc dont j'ai un exemplaire) :

    • les bénéfices attendus de l'ouverture et de la réutilisation sont avant tout d'améliorer la satisfaction des clients, et en dernier lieu de se différencier de ses concurrents
    • les obstacles ressentis : le besoin de contrôler la réutilisation de ses données, la peur de donner l'accés à ses données aux concurents ou encore la frilosité à la réutilisation de données des autres (problème potentiel de fraicheur et/ou qualité des données)

    43 % des entreprises sondées disent qu'une réfléxion autour de l'Open Data est en cours évolution.

    Conclusion

    Aujourd'hui, les licences sont matures et ne posent plus vraiment problème. On peut espérer avoir rapidement plus de données et d'acteurs dans l'Open Data. Cependant dans le public comme dans le privé une difficulté est d'encadrer la production : motiver la production de données, accueillir les résultats et gérer la diffusion (qui a dit CubicWeb ? En toute objectivité :p ).

    NR: On notera l'absence de discussion autour des formats de publication de données notamment. Pour conclure, j'aurais plutôt appelé ça état les lieux que état de l'art, même si ça reste un effort de synthèse appréciable.


  • Debian bug squashing party in Paris

    2012/02/16 by Julien Cristau

    Logilab will be present at the upcoming Debian BSP in Paris this week-end. This event will focus on fixing as many "release critical" bugs as possible, to help with the preparation of the upcoming Debian 7.0 "wheezy" release. It will also provide an opportunity to introduce newcomers to the processes of Debian development and bug fixing, as well as provide an opportunity for contributors in various areas of the project to interact "in real life".

    http://www.logilab.org/file/88881?vid=download

    The current stable release, Debian 6.0 "squeeze", came out in February 2011. The development of "wheezy" is scheduled to freeze in June 2012, for an eventual release later this year.

    Among the things we hope to work on during this BSP, the latest HDF5 release (1.8.8) includes API and packaging changes that require some changes in dependent packages. With the number of scientific packages relying on HDF5, this is a pretty big change, as tracked in this Debian bug.


  • Introduction To Mercurial Phases (Part III)

    2012/02/03 by Pierre-Yves David

    This is the final part of a series of posts about the new phases feature we implemented for mercurial 2.1. The first part talks about how phases will help mercurial users, the second part explains how to control them. This one explains what people should take care of when upgrading.

    Important upgrade note and backward compatibility

    Phases do not require any conversion of your repos. Phase information is not stored in changesets. Everybody using a new client will take advantage of phases on any repository they touch.

    However there is some points you need to be aware of regarding interaction between the old world without phases and the new world with phases:

    Talking over the wire to a phaseless server using a phased client

    As ever, the Mercurial wire protocol (used to communicate through http and ssh) is fully backward compatible [1]. But as old Mercurial versions are not aware of phases, old servers will always be treated as publishing.

    Direct file system access to a phaseless repository using a phased client

    A new client has no way to determine which parts of the history should be immutable and which parts should not. In order to fail safely, a new repo will mark everything as public when no data is available. For example, in the scenario described in part I, if an old version of mercurial were used to clone and commit, a new version of mercurial will see them as public and refuse to rebase them.

    Note

    Some extensions (like mq) may provide smarter logic to set some changesets to the draft or even secret phases.

    The phased client will write phase data to the old repo on its first write operation.

    Direct file system access to a phased repository using a phaseless client

    Everything works fine except that the old client is unable to see or manipulate phases:

    • Changesets added to the repo inherit the phase of their parents, whatever the parents' phase. This could result in new commits being seen as public or pulled content seen as draft or even secret when a newer client uses the repo again!
    • Changesets pushed to a publishing server won't be set public.
    • Secret changesets are exchanged.
    • Old clients are willing to rewrite immutable changesets (as they don't know that they shouldn't).

    So, if you actively rewrite your history or use secret changesets, you should ensure that only new clients touch those repositories where the phase matters.

    Fixing phases error

    Several situations can result in bad phases in a repository:

    • When upgrading from phaseless to phased Mercurial, the default phases picked may be too restrictive.
    • When you let an old client touch your repository.
    • When you push to a publishing server that should not actually be publishing.

    The easiest way to restore a consistant state is to use the phase command. In most cases, changesets marked as public but absent from your real public server should be moved to draft:

    hg phase --force --draft 'public() and outgoing()'
    

    If you have multiple public servers, you can pull from the others to retrieve their phase data too.

    Conclusion

    Mercurial's phases are a simple concept that adds always on and transparent safety for most users while not preventing advanced ones from doing whatever they want.

    Behind this safety-enabling and useful feature, phases introduce in Mercurial code the concept of sharing mutable parts of history. The introduction of this feature paves the way for advanced history rewriting solutions while allowing safe and easy sharing of mutable parts of history. I'll post about those future features shortly.


    [1]You can expect the 0.9.0 version of Mercurial to interoperate cleanly with one released 5 years later.

    [Images by Crystian Cruz (cc-nd) and C.J. Peters (cc-by-sa)]


  • Introduction To Mercurial Phases (Part II)

    2012/02/02 by Pierre-Yves David

    This is the second part of a series of posts about the new phases feature we implemented for mercurial 2.1. The first part talks about how phases will help mercurial users, this second part explains how to control them.

    Controlling automatic phase movement

    Sometimes it may be desirable to push and pull changesets in the draft phase to share unfinished work. Below are some cases:

    • pushing to continuous integration,
    • pushing changesets for review,
    • user has multiple machines,
    • branch clone.

    You can disable publishing behavior in a repository configuration file [1]:

    [phases]
       publish=False
       

    When a repository is set to non-publishing, people push changesets without altering their phase. draft changesets are pushed as draft and public changesets are pushed as public:

    celeste@Chessy ~/palace $ hg showconfig phases
       phases.publish=False
       
    babar@Chessy ~/palace $ hg log --graph
       @  [draft] add a carpet (2afbcfd2af83)
       |
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       babar@Chessy ~/palace $ hg outgoing ~celeste/palace/
       [public] Add wall color (0d1feb1bca54)
       [public] Add a table in the kichen (139ead8a540f)
       [draft] add a carpet (3c1b19d5d3f5)
       babar@Chessy ~/palace $ hg push ~celeste/palace/
       pushing to ~celeste/palace/
       searching for changes
       adding changesets
       adding manifests
       adding file changes
       added 3 changesets with 3 changes to 2 files
       babar@Chessy ~/palace $ hg log --graph
       @  [draft] add a carpet (2afbcfd2af83)
       |
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       
    celeste@Chessy ~/palace $ hg log --graph
       o  [draft] add a carpet (2afbcfd2af83)
       |
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       

    And pulling gives the phase as in the remote repository:

    celeste@Chessy ~/palace $ hg up 139ead8a540f
       celeste@Chessy ~/palace $ echo The wall will be decorated with portraits >> bedroom
       celeste@Chessy ~/palace $ hg ci -m 'Decorate the wall.'
       created new head
       celeste@Chessy ~/palace $ hg log --graph
       @  [draft] Decorate the wall. (3389164e92a1)
       |
       | o  [draft] add a carpet (3c1b19d5d3f5)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       ---
       babar@Chessy ~/palace $ hg pull ~celeste/palace/
       pulling from ~celeste/palace/
       searching for changes
       adding changesets
       adding manifests
       adding file changes
       added 1 changesets with 1 changes to 1 files (+1 heads)
       babar@Chessy ~/palace $ hg log --graph
       @  [draft] Decorate the wall. (3389164e92a1)
       |
       | o  [draft] add a carpet (3c1b19d5d3f5)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       

    Phase information is exchanged during pull and push operations. When a changeset exists on both sides but within different phases, its phase is unified to the lowest [2] phase. For instance, if a changeset is draft locally but public remotely, it is set public:

    celeste@Chessy ~/palace $ hg push -r 3389164e92a1
       pushing to http://hg.celesteville.com/palace
       searching for changes
       adding changesets
       adding manifests
       adding file changes
       added 1 changesets with 1 changes to 1 files
       celeste@Chessy ~/palace $ hg log --graph
       @  [public] Decorate the wall. (3389164e92a1)
       |
       | o  [draft] add a carpet (3c1b19d5d3f5)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       ---
       babar@Chessy ~/palace $ hg pull ~celeste/palace/
       pulling from ~celeste/palace/
       searching for changes
       no changes found
       babar@Chessy ~/palace $ hg log --graph
       @  [public] Decorate the wall. (3389164e92a1)
       |
       | o  [draft] add a carpet (3c1b19d5d3f5)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       o  [public] Add wall color (0d1feb1bca54)
       |
       
       

    Note

    pull is read-only operation and does not alter phases in remote repositories.

    You can also control the phase in which a new changeset is committed. If you don't want new changesets to be pushed without explicit consent, update your configuration with:

    [phases]
       new-commit=secret
       

    You will need to use manual phase movement before you can push them. See the next section for details:

    Note

    With what have been done so far for 2.1, the "most practical way to make a new commit secret" is to use:

       hg commit --config phases.new-commit=secret
       
    [1]You can use this setting in your user hgrc too.
    [2]Phases as ordered as follow: public < draft < secret

    Manual phase movement

    Most phase movements should be automatic and transparent. However it is still possible to move phase manually using the hg phase command:

    babar@Chessy ~/palace $ hg log --graph
       @    [draft] merge with Celeste works (f728ef4eba9f)
       |\
       o |  [draft] add a carpet (3c1b19d5d3f5)
       | |
       | o  [public] Decorate the wall. (3389164e92a1)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       
       babar@Chessy ~/palace $ hg phase --public 3c1b19d5d3f5
       babar@Chessy ~/palace $ hg log --graph
       @    [draft] merge with Celeste works (f728ef4eba9f)
       |\
       o |  [public] add a carpet (3c1b19d5d3f5)
       | |
       | o  [public] Decorate the wall. (3389164e92a1)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       
       

    Changesets only move to lower [#] phases during normal operation. By default, the phase command enforces this rule:

    babar@Chessy ~/palace $ hg phase --draft 3c1b19d5d3f5
       no phases changed
       babar@Chessy ~/palace $ hg log --graph
       @    [draft] merge with Celeste works (f728ef4eba9f)
       |\
       o |  [public] add a carpet (3c1b19d5d3f5)
       | |
       | o  [public] Decorate the wall. (3389164e92a1)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       
       

    If you are confident in what your are doing you can still use the --force switch to override this behavior:

    Warning

    Phases are designed to avoid forcing people to use hg phase --force. If you need to use --force on a regular basis, you are probably doing something wrong. Read the previous section again to see how to configure your environment for automatic phase movement suitable to your needs.

    babar@Chessy ~/palace $ hg phase --verbose --force --draft 3c1b19d5d3f5
       phase change for 1 changesets
       babar@Chessy ~/palace $ hg log --graph
       @    [draft] merge with Celeste works (f728ef4eba9f)
       |\
       o |  [draft] add a carpet (3c1b19d5d3f5)
       | |
       | o  [public] Decorate the wall. (3389164e92a1)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       
       

    Note that a phase defines a consistent set of revisions in your history graph. This means that to have a public (immutable) changeset all its ancestors need to be immutable too. Once you have a secret (not exchanged) changeset, all its descendant will be secret too.

    This means that changing the phase of a changeset may result in phase movement for other changesets:

    babar@Chessy ~/palace $ hg phase -v --public f728ef4eba9f # merge with Celeste works
       phase change for 2 changesets
       babar@Chessy ~/palace $ hg log --graph
       @    [public] merge with Celeste works (f728ef4eba9f)
       |\
       o |  [public] add a carpet (3c1b19d5d3f5)
       | |
       | o  [public] Decorate the wall. (3389164e92a1)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       
       babar@Chessy ~/palace $ hg phase -vf --draft 3c1b19d5d3f5 # add a carpet
       phase change for 2 changesets
       babar@Chessy ~/palace $ hg log --graph
       @    [draft] merge with Celeste works (f728ef4eba9f)
       |\
       o |  [draft] add a carpet (3c1b19d5d3f5)
       | |
       | o  [public] Decorate the wall. (3389164e92a1)
       |/
       o  [public] Add a table in the kichen (139ead8a540f)
       |
       
       

    The next and final post will explain how older mercurial versions interact with newer versions that support phases.

    [Images by Jimmy Smith (cc-by-nd) and Cory Doctorow (cc-by-sa)]


  • Introduction To Mercurial Phases (Part I)

    2012/02/02 by Pierre-Yves David
    credit: redshirtjosh, http://www.flickr.com/photos/43273828@N06/4111258568/

    On the behalf of Logilab I put a lot of efforts to include a new core feature named phases in Mercurial 2.1. Phases are a system for tracking which changesets have been or should be shared. This helps to prevent common mistakes when modifying history (for instance, with the mq or rebase extensions). It will transparently benefit to all users. This concept is the first step towards simple, safe and powerful rewritting mecanisms for history in mercurial.

    This serie of three blog entries will explain:

    1. how phases will help mercurial users,
    2. how one can control them,
    3. how older mercurial versions interact with newer versions that support phases.

    Preventing erroneous history rewriting

    credit: anita.priks, http://www.flickr.com/photos/46785534@N06/6358218623/

    History rewriting is a common practice in DVCS. However when done the wrong way the most common error results in duplicated history. The phase concept aims to make rewriting history safer. For this purpose Mercurial 2.1 introduces a distinction between the "past" part of your history (that is expected to stay there forever) and the "present" part of the history (that you are currently evolving). The old and immutable part is called public and the mutable part of your history is called draft.

    Let's see how this happens using a simple scenario.


    A new Mercurial user clones a repository:

    babar@Chessy ~ $ hg clone http://hg.celesteville.com/palace
    requesting all changes
    adding changesets
    adding manifests
    adding file changes
    added 2 changesets with 2 changes to 2 files
    updating to branch default
    2 files updated, 0 files merged, 0 files removed, 0 files unresolved
    babar@Chessy ~/palace $ cd palace
    babar@Chessy ~/palace $ hg log --graph
    @  changeset:   1:2afbcfd2af83
    |  tag:         tip
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:41:56 2012 +0100
    |  summary:     We need a kitchen too.
    |
    o  changeset:   0:898889b143fb
       user:        Celeste the Queen <Celeste@celesteville.com>
       date:        Wed Jan 25 16:39:07 2012 +0100
       summary:     First description of the throne room
    

    The repository already contains some changesets. Our user makes some improvements and commits them:

    babar@Chessy ~/palace $ echo The wall shall be Blue >> throne-room
    babar@Chessy ~/palace $ hg ci -m 'Add wall color'
    babar@Chessy ~/palace $ echo In the middle stands a three meters round table >> kitchen
    babar@Chessy ~/palace $ hg ci -m 'Add a table in the kichen'
    

    But when he tries to push new changesets, he discovers that someone else already pushed one:

    babar@Chessy ~/palace $ hg push
    pushing to http://hg.celesteville.com/palace
    searching for changes
    abort: push creates new remote head bcd4d53319ec!
    (you should pull and merge or use push -f to force)
    babar@Chessy ~/palace $ hg pull
    pulling from http://hg.celesteville.com/palace
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 1 changesets with 1 changes to 1 files (+1 heads)
    (run 'hg heads' to see heads, 'hg merge' to merge)
    babar@Chessy ~/palace $ hg log --graph
    o  changeset:   4:0a5b3d7e4e5f
    |  tag:         tip
    |  parent:      1:2afbcfd2af83
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:58:23 2012 +0100
    |  summary:     Some bedroom description.
    |
    | @  changeset:   3:bcd4d53319ec
    | |  user:        Babar the King <babar@celesteville.com>
    | |  date:        Wed Jan 25 16:52:02 2012 +0100
    | |  summary:     Add a table in the kichen
    | |
    | o  changeset:   2:f9f14815935d
    |/   user:        Babar the King <babar@celesteville.com>
    |    date:        Wed Jan 25 16:51:51 2012 +0100
    |    summary:     Add wall color
    |
    o  changeset:   1:2afbcfd2af83
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:41:56 2012 +0100
    |  summary:     We need a kitchen too.
    |
    o  changeset:   0:898889b143fb
       user:        Celeste the Queen <Celeste@celesteville.com>
       date:        Wed Jan 25 16:39:07 2012 +0100
       summary:     First description of the throne room
    

    Note

    From here on this scenario becomes very unlikely. Mercurial is simple enough for a new user not to be that confused by such a trivial situation. But we keep the example simple to focus on phases.

    Recently, our new user read some hype blog about "rebase" and the benefit of linear history. So, he decides to rewrite his history instead of merging.

    Despite reading the wonderful rebase help, our new user makes the wrong decision when it comes to using it. He decides to rebase the remote changeset 0a5b3d7e4e5f:"Some bedroom description." on top of his local changeset.

    With previous versions of mercurial, this mistake was allowed and would result in a duplication of the changeset 0a5b3d7e4e5f:"Some bedroom description."

    babar@Chessy ~/palace $ hg rebase -s 4 -d 3
    babar@Chessy ~/palace $ hg push
    pushing to http://hg.celesteville.com/palace
    searching for changes
    abort: push creates new remote head bcd4d53319ec!
    (you should pull and merge or use push -f to force)
    babar@Chessy ~/palace $ hg pull
    pulling from http://hg.celesteville.com/palace
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 1 changesets with 1 changes to 1 files (+1 heads)
    (run 'hg heads' to see heads, 'hg merge' to merge)
    babar@Chessy ~/palace $ hg log --graph
    @  changeset:   5:55d9bae1e1cb
    |  tag:         tip
    |  parent:      3:bcd4d53319ec
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:58:23 2012 +0100
    |  summary:     Some bedroom description.
    |
    | o  changeset:   4:0a5b3d7e4e5f
    | |  parent:      1:2afbcfd2af83
    | |  user:        Celeste the Queen <Celeste@celesteville.com>
    | |  date:        Wed Jan 25 16:58:23 2012 +0100
    | |  summary:     Some bedroom description.
    | |
    o |  changeset:   3:bcd4d53319ec
    | |  user:        Babar the King <babar@celesteville.com>
    | |  date:        Wed Jan 25 16:52:02 2012 +0100
    | |  summary:     Add a table in the kichen
    | |
    o |  changeset:   2:f9f14815935d
    |/   user:        Babar the King <babar@celesteville.com>
    |    date:        Wed Jan 25 16:51:51 2012 +0100
    |    summary:     Add wall color
    |
    o  changeset:   1:2afbcfd2af83
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:41:56 2012 +0100
    |  summary:     We need a kitchen too.
    |
    o  changeset:   0:898889b143fb
       user:        Celeste the Queen <Celeste@celesteville.com>
       date:        Wed Jan 25 16:39:07 2012 +0100
       summary:     First description of the throne room
    

    In more complicated setups it's a fairly common mistake, Even in big and successful projects and with other DVCSs.

    In the new Mercurial version the user won't be able to make this mistake anymore. Trying to rebase the wrong way will result in:

    babar@Chessy ~/palace $ hg rebase -s 4 -d 3
    abort: can't rebase immutable changeset 0a5b3d7e4e5f
    (see hg help phases for details)
    

    The correct rebase still works as expected:

    babar@Chessy ~/palace $ hg rebase -s 2 -d 4
    babar@Chessy ~/palace $ hg log --graph
    @  changeset:   4:139ead8a540f
    |  tag:         tip
    |  user:        Babar the King <babar@celesteville.com>
    |  date:        Wed Jan 25 16:52:02 2012 +0100
    |  summary:     Add a table in the kichen
    |
    o  changeset:   3:0d1feb1bca54
    |  user:        Babar the King <babar@celesteville.com>
    |  date:        Wed Jan 25 16:51:51 2012 +0100
    |  summary:     Add wall color
    |
    o  changeset:   2:0a5b3d7e4e5f
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:58:23 2012 +0100
    |  summary:     Some bedroom description.
    |
    o  changeset:   1:2afbcfd2af83
    |  user:        Celeste the Queen <Celeste@celesteville.com>
    |  date:        Wed Jan 25 16:41:56 2012 +0100
    |  summary:     We need a kitchen too.
    |
    o  changeset:   0:898889b143fb
       user:        Celeste the Queen <Celeste@celesteville.com>
       date:        Wed Jan 25 16:39:07 2012 +0100
       summary:     First description of the throne room
    

    What is happening here:

    • Changeset 0a5b3d7e4e5f from Celeste was set to the public phase because it was pulled from the outside. The public phase is immutable.
    • Changesets f9f14815935d and bcd4d53319ec (rebased as 0d1feb1bca54 and 139ead8a540f) have been commited locally and haven't been transmitted from this repository to another. As such, they are still in the draft phase. Unlike the public phase, the draft phase is mutable.

    Let's watch the whole action in slow motion, paying attention to phases:

    babar@Chessy ~ $ cat >> ~/.hgrc << EOF
    [ui]
    username=Babar the King <babar@celesteville.com>
    logtemplate='[{phase}] {desc} ({node|short})\\n'
    EOF
    

    First, changesets cloned from a public server are public:

    babar@Chessy ~ $ hg clone --quiet http://hg.celesteville.com/palace
    babar@Chessy ~/palace $ cd palace
    babar@Chessy ~/palace $ hg log --graph
    @  [public] We need a kitchen too. (2afbcfd2af83)
    |
    o  [public] First description of the throne room (898889b143fb)
    

    Second, new changesets committed locally are in the draft phase:

    babar@Chessy ~/palace $ echo The wall shall be Blue >> throne-room
    babar@Chessy ~/palace $ hg ci -m 'Add wall color'
    babar@Chessy ~/palace $ echo In the middle stand a three meters round table >> kitchen
    babar@Chessy ~/palace $ hg ci -m 'Add a table in the kichen'
    babar@Chessy ~/palace $ hg log --graph
    @  [draft] Add a table in the kichen (bcd4d53319ec)
    |
    o  [draft] Add wall color (f9f14815935d)
    |
    o  [public] We need a kitchen too. (2afbcfd2af83)
    |
    o  [public] First description of the throne room (898889b143fb)
    

    Third, changesets pulled from a public server are public:

    babar@Chessy ~/palace $ hg pull --quiet
    babar@Chessy ~/palace $ hg log --graph
    o  [public] Some bedroom description. (0a5b3d7e4e5f)
    |
    | @  [draft] Add a table in the kichen (bcd4d53319ec)
    | |
    | o  [draft] Add wall color (f9f14815935d)
    |/
    o  [public] We need a kitchen too. (2afbcfd2af83)
    |
    o  [public] First description of the throne room (898889b143fb)
    

    Note

    rebase preserves the phase of rebased changesets

    babar@Chessy ~/palace $ hg rebase -s 2 -d 4
    babar@Chessy ~/palace $ hg log --graph
    @  [draft] Add a table in the kichen (139ead8a540f)
    |
    o  [draft] Add wall color (0d1feb1bca54)
    |
    o  [public] Some bedroom description. (0a5b3d7e4e5f)
    |
    o  [public] We need a kitchen too. (2afbcfd2af83)
    |
    o  [public] First description of the throne room (898889b143fb)
    

    Finally, once pushed to the public server, changesets are set to the public (immutable) phase

    babar@Chessy ~/palace $ hg push
    pushing to http://hg.celesteville.com/palace
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 2 changesets with 2 changes to 2 files
    babar@Chessy ~/palace $ hg log --graph
    
    @  [public] Add a table in the kichen (139ead8a540f)
    |
    o  [public] Add wall color (0d1feb1bca54)
    |
    o  [public] Some bedroom description. (0a5b3d7e4e5f)
    |
    o  [public] We need a kitchen too. (2afbcfd2af83)
    |
    o  [public] First description of the throne room (898889b143fb)
    

    To summarize:

    • Changesets exchanged with the outside are public and immutable.
    • Changesets committed locally are draft until exchanged with the outside.
    • As a user, you should not worry about phases. Phases move transparently.

    Preventing premature exchange of history

    credit: Richard Elzey, http://www.flickr.com/photos/elzey/3516256055/

    The public phases prevent user from accidentally rewriting public history. It's a good step forward but phases can go further. Phases can prevent you from accidentally making history public in the first place.

    For this purpose, a third phase is available, the secret phase. To explain it, I'll use the mq extension which is nicely integrated with this secret phase:

    Our fellow user enables the mq extension

    babar@Chessy ~/palace $ vim ~/.hgrc
    babar@Chessy ~/palace $ cat ~/.hgrc
    [ui]
    username=Babar the King <babar@celesteville.com>
    [extensions]
    # enable the mq extension included with Mercurial
    hgext.mq=
    [mq]
    # Enable secret phase integration.
    # This integration is off by default for backward compatibility.
    secret=true
    

    New patches (not general commits) are now created as secret

    babar@Chessy ~/palace $ echo A red carpet on the floor. >> throne-room
    babar@Chessy ~/palace $ hg qnew -m 'add a carpet' carpet.diff
    babar@Chessy ~/palace $ hg log --graph
    
    @  [secret] add a carpet (3c1b19d5d3f5)
    |
    @  [public] Add a table in the kichen (139ead8a540f)
    |
    o  [public] Add wall color (0d1feb1bca54)
    |
    
    

    this secret changeset is excluded from outgoing and push:

    babar@Chessy ~/palace $ hg outgoing
    comparing with http://hg.celesteville.com/palace
    searching for changes
    no changes found (ignored 1 secret changesets)
    babar@Chessy ~/palace $ hg push
    pushing to http://hg.celesteville.com/palace
    searching for changes
    no changes found (ignored 1 secret changesets)
    

    And other users do not see it:

    celeste@Chessy ~/palace $ hg incoming ~babar/palace/
    comparing with ~babar/palace
    searching for changes
    [public] Add wall color (0d1feb1bca54)
    [public] Add a table in the kichen (139ead8a540f)
    

    The mq integration take care of phase movement for the user. Changeset are made draft by qfinish

    babar@Chessy ~/palace $ hg qfinish .
    babar@Chessy ~/palace $ hg log --graph
    @  [draft] add a carpet (2afbcfd2af83)
    |
    o  [public] Add a table in the kichen (139ead8a540f)
    |
    o  [public] Add wall color (0d1feb1bca54)
    |
    
    

    And changesets are made secret again by qimport

    babar@Chessy ~/palace $ hg qimport -r 2afbcfd2af83
    babar@Chessy ~/palace $ hg log --graph
    @  [secret] add a carpet (2afbcfd2af83)
    |
    o  [public] Add a table in the kichen (139ead8a540f)
    |
    o  [public] Add wall color (0d1feb1bca54)
    |
    
    

    As expected, mq refuses to qimport public changesets

    babar@Chessy ~/palace $ hg qimport -r 139ead8a540f
    abort: revision 4 is not mutable
    

    In the next part I'll details how to control phases movement.


  • Generating a user interface from a Yams model

    2012/01/09 by Nicolas Chauvat

    Yams is a pythonic way to describe an entity-relationship model. It is used at the core of the CubicWeb semantic web framework in order to automate lots of things, including the generation and validation of forms. Although we have been using the MVC design pattern to write user interfaces with Qt and Gtk before we started CubicWeb, we never got to reuse Yams. I am on my way to fix this.

    Here is the simplest possible example that generates a user interface (using dialog and python-dialog) to input data described by a Yams data model.

    First, let's write a function that builds the data model:

    def mk_datamodel():
        from yams.buildobjs import EntityType, RelationDefinition, Int, String
        from yams.reader import build_schema_from_namespace
    
        class Question(EntityType):
            number = Int()
            text = String()
    
        class Form(EntityType):
            title = String()
    
        class in_form(RelationDefinition):
            subject = 'Question'
            object = 'Form'
            cardinality = '*1'
    
        return build_schema_from_namespace(vars().items())
    

    Here is what you get using graphviz or xdot to display the schema of that data model with:

    import os
    from yams import schema2dot
    
    datamodel = mk_datamodel()
    schema2dot.schema2dot(datamodel, '/tmp/toto.dot')
    os.system('xdot /tmp/toto.dot')
    
    http://www.logilab.org/file/87002?vid=download

    To make a step in the direction of genericity, let's add a class that abstracts the dialog API:

    class InterfaceDialog:
        """Dialog-based Interface"""
        def __init__(self, dlg):
            self.dlg = dlg
    
        def input_list(self, invite, options) :
            assert len(options) != 0, str(invite)
            choice = self.dlg.radiolist(invite, list=options, selected=1)
            if choice is not None:
                return choice.lower()
            else:
                raise Exception('operation cancelled')
    
        def input_string(self, invite, default):
            return self.dlg.inputbox(invite, init=default).decode(sys.stdin.encoding)
    

    And now let's put everything together:

    datamodel = mk_datamodel()
    
    import dialog
    ui = InterfaceDialog(dialog.Dialog())
    ui.dlg.setBackgroundTitle('Dialog Interface with Yams')
    
    objs = []
    for entitydef in datamodel.entities():
        if entitydef.final:
            continue
        obj = {}
        for attr in entitydef.attribute_definitions():
            if attr[1].type in ('String','Int'):
                obj[str(attr[0])] = ui.input_string('%s.%s' % (entitydef,attr[0]), '')
        try:
            entitydef.check(obj)
        except Exception, exc:
            ui.dlg.scrollbox(str(exc))
    
    print objs
    
    http://www.logilab.org/file/87001?vid=download

    The result is a program that will prompt the user for the title of a form and the text/number of a question, then enforce the type constraints and display the inconsistencies.

    The above is very simple and does very little, but if you read the documentation of Yams and if you think about generating the UI with Gtk or Qt instead of dialog, or if you have used the form mechanism of CubicWeb, you'll understand that this proof of concept opens a door to a lot of possibilities.

    I will come back to this topic in a later article and give an example of integrating the above with pigg, a simple MVC library for Gtk, to make the programming of user-interfaces even more declarative and bug-free.


  • OpenData à Nantes: agrégateur des événements culturels

    2011/12/12 by Arthur Lutz

    Jeudi 8 décembre 2011 nous avons participé à la réunion de travail sur l'ouverture des données événementielles.

    Problématique des licences

    Un premier problème est que la licence proposée par LiberTIC est la CreativeCommons CC-BY, alors que les producteurs de données n'ont souvent pas les droits sur toutes les données qu'ils diffusent (par exemple la photo d'illustration d'un concert). Ils auront donc du mal à les publier en totalité sous licence CC-BY. Espérons que la licence Creative Commons rentre dans les habitudes et que cela ne va pas trop freiner le projet.

    Aujourd'hui, l'utilisation ressemble à du Fair Use: on tolère la ré-utilisation de contenus protégés par le droit d'auteur car cela sert la diffusion de l'information.

    Nous nous sommes demandé s'il est possible de mélanger deux licences dans un flux de données ou s'il faut faire deux flux séparés mais liés.

    https://creativecommons.org/images/license-layers.png

    Problématique d'utilisation

    Un deuxième problème est que les réutilisateurs ne seront pas intéréssés si les données sont trop pauvres et qu'elles n'incluent pas d'image ou de vidéo. Il faut donc trouver un socle commun qui satisfasse les producteurs et les réutilisateurs.

    Import ou gros formulaires qui tâchent ?

    Vu la complexité du modèle de données qui a émergé des discussions (beaucoup de cas particuliers), il a été proposé de fournir un formulaire de saisie d'un événement. A notre avis, la saisie "manuelle" doit rester un cas exceptionnel (un acteur culturel n'ayant pas de site pour publier par exemple), au risque de n'être pour les producteurs qu'un enième site à renseigner lors de la publication de son agenda.

    Un exemple de bonnes pratiques est le très populaire GoodRelations qui offre un formulaire pour qu'un utilisateur qui n'a pas intégré le format à sa boutique en ligne puisse facilement générer son fichier et l'héberger chez lui, favorisant ainsi un modèle décentralisé calqué sur celui des moteurs de recherche.

    Formats

    Il nous semble donc important de se concentrer sur les formats standards qui pourraient être importés et exportés par la plateforme.

    En voici une liste non exhaustive:

    Lectures supplémentaires

    Cherchant à combiner des vocabulaires existants (afin de ne pas réinventer un format qui devra être traduit dans un autre vocabulaire pour être réutilisable) nous sommes tombés sur les articles suivants :

    http://cdn1.iconfinder.com/data/icons/transformers/network-connections.png http://cdn1.iconfinder.com/data/icons/transformers/Internet-Explorer.png http://cdn1.iconfinder.com/data/icons/transformers/entire-network.png

    Conclusion

    Il nous paraît important de ne pas se tromper dans les orientations choisies:

    • utiliser des formats standards et combiner l'utilisation de namespaces existants plutôt que d'inventer un nouveau format
    • proposer plusieurs formats d'export pour différentes utilisations (json, ical, etc) quitte à ne pas inclure tout le contenu disponible si le format ne s'y prête pas
    • ne pas créer une API de plus et choisir de privilégier les standards du web sémantique en publiant du RDF et si possible en fournissant un accès SPARQL
    • préférer la publication distribuée des données par leurs producteurs et leur agrégation par la plate-forme plutôt que d'attendre des producteurs qu'ils remplissent un formulaire de plus.

    Nous attendons avec impatience la suite des travaux. Selon LiberTIC la plateforme sera developpée en logiciel libre avec des outils collaboratifs pour piloter le projet.

    CubicWeb est une plateforme disponible en logiciel libre qui a déjà fait ses preuves et a été conçue pour développer des applications du type de l'aggrégateur décrit ci-dessus: import et export des données sous différents formats, utilisation des technologies standards du web sémantique. Nous espérons que ceux qui auront à réaliser l'agrégateur choisiront CubicWeb comme base technique pour ce projet.


show 316 results