Obi MO a écrit 297 commentaires

C'est super d'avoir identifié les liens wikipedia. En revanche je trouve que la façon de le faire perturbe la lecture, surtout quand il y a de nombreux liens wikipedia dans une phrase, par exemple http://linuxfr.org/2010/06/17/27001.html .
Je te propose de changer le :before{content: "W -";} en :after { content: "(W)";}, le mettre à la fin et entre parenthèses (ou crochets) le rend moins intrusif et on sait sur quoi il porte.
En tout cas superbe boulot, j'ai adopté !
Merci !

ocaml ?

Pareil, il faut encourager ce genre d'initiatives. En plus j'avais adoré la démo de world of goo, comme ça je l'aurai en entier.

De la bouse ?

Les éléments bitmaps présents dans les formats vectoriels sont dûs au fait que le moteur de rendu [http://mapnik.org/] ne supporte pas les emblèmes vectoriels. Libre à qui se sent de le faire d'envoyer un patch, et les gens d'OSM se feront un plaisir d'utiliser des emblèmes svg au lieu de rasters PNG...

Manque dans l'offre:
*Compétences IPOT indispensables...

hu, en effet, avec un simple
$kvm -cdrom /dev/cdrom -no-quit -m 800 -usb ~/vmware/winXP.img
tout passe bien.
Merci 1000 fois, ça me sauve une belle jambe de bois.

En fait la combinaison inkscape + scribus permet de travailler en CMJN car ils implémentent tous deux la gestion des profils colorimétriques. Pour peu que tu te limites à l'utilisation du sous ensemble SVG supporté par scribus (en gros pas de filtres), ça marche très bien. Tu entres dans inkscape tes valeurs en CMJN qui sont transformées en RVB d'une façon bien précise (le rpofil colorimétrique sert à ça). Quand tu fais ton import dans scribus, il te suffit d'aller dans la table des couleurs et de transformer toutes les couleurs RBG en CMJN. Comme le même profil colorimétrique est utilisé, la transformation inverse te redonne les valeurs CMJN que tu as entrées originalement dans inkscape.
Voici un exemple de résultat obtenu avec cette technique:
http://www.esterel-technologies.com/files/data-sheets/SCADE-(...)

C'était ça, ça marche beaucoup mieux du coup. Merci beaucoup !

Hargh !
Bon, faut que je me penche sur les normales, merci !

Sur une zone couverte avec une bonne résolution par yahoo (comme Toulouse par exemple), pas besoin de GPS. Tu utilises potlatch et "décalques" les rues. Ensuite tu t'imprimes ce que tu as fait et va chercher les noms des rues sur place que tu ajoutes par la suite. J'en fais un peu quand je vais dans des nouveaux coins de Toulouse (il vaut quand même mieux connaître un peu l'endroits que tu cartographies parceque la vue satellite ne montre pas tout).

ho, je savais pas, j'étais persuadé que le bug tracker de ubuntu était forcément libre. Et en effet, j'y trouve pas de license... Ca me fait mal qu'inkscape y soit passé alors :/

Bon sinon j'ai bien apprécié TRAC, déjà mensionné...

launchpad marche pas mal:
https://bugs.launchpad.net/

Sauf que l'agriculture dite "raisonnée" c'est un truc du lobbie des gros producteurs pour se refaire une image. Pas de cahier des charges derrière, aucun contrôle, aucune contrainte supplémentaire sur le mode de production, juste deux trois bricoles en termes de tracabilité. La façon dont sa se traduit concrêtement chez le producteur: zero, nada, zilch, peau de balle. Les textes disent en gros ( http://www.legifrance.gouv.fr/WAspad/UnTexteDeJorf?numjo=AGR(...) ) pour faire de l'agriculture raisonnée, faut pas abîmer la nature, c'est pas bien.
Je dis pas non plus que la bio c'est la panacée universelle et qu'on ne doit faire que ça, mais au moins c'est concret, avec un vrai cahier des charges et des contrôles. C'est sûrement perfectible, mais ça a le mérite de partir sur de bonnes bases.

Dans le domaine de l'embarqué critique (certifié comme tu l'as précisé) à ma connaissance on utilise très peu l'orienté objet, bien que certains ( Rhapsody http://modeling.telelogic.com/modeling/products/rhapsody/ind(...) ) essayent d'explorer cette voie. En tout cas le "model based design" a le vent en poupe, des trucs comme SCADE ( http://www.esterel-technologies.com/products/scade-suite/ ) sont fréquemments utilisés dans le domaine. L'idée c'est d'aller jusqu' à la génération du code embarqué avec des compilateurs qualifiés. Sans être du fonctionel, le language est purement déclaratif et a toutes les propriétés qui vont bien ( basé sur LUSTRE, il doit y avoir des compilos libres disponibles http://www-verimag.imag.fr/~synchron/index.php?page=lang-des(...) ) pour l'embarqué critique.

Donc out le formalisme vague d'UML, on peut parler de haut niveau et d'architecture, et dans le même formalisme descendre jusqu'au code embarqué. Les diffs sont gérés au niveau sémantique (pour la notation graphique)

Pour répondre à tes trois dernières questions:
>- comment faites-vous votre conception logicielle ?
J'utilise SCADE pour l'embarqué. ocaml + ocamldoc pour ce qui ne l'est pas.
>- quelles sont les limites des systèmes du genre de Doxygen ?
En interne on travaille sur ce type d'outils (ocamldoc), et on retrouve l'idée du "model-based": un seul "document", central, et tout est généré à partir de ça. Dire que ton code commenté comme il faut est le modèle, et générer docs, tracabilité, executable, schémas d'architecture, ça roxe. Attention au problèmes de granularité des fichiers cependant, la gestion de conf peut vite poser problème.
>- que pensez-vous d'UML ?
Bullshit ? Non, sans rire, c'est sympa pour s'échanger trois crobards, discuter au tableau et "brainstormer". Les préliminaires quoi. Quand on passe aux choses sérieuses, ça peut encore servir de feuille de route, mais rien de contractuel/officiel. Ensuite en rétro-documentation + retouche manuelle pour avoir quelque chose de présentable, ou pour plonger dans un gros projet qu'on ne connâit pas.

tiens, j'aurais dit &adresse ...

En effet, j'aurais dû revenir voir ici plus souvent, j'ai trouvé mais une heure après ton post.
Merci pour tout en tous cas ;)

Je voudrais bien, on fait comment ?

Allez Luilla !!!
Trouvé, mauvais paramètres en blend func, j'aurais du utiliser
glBlendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA;
pour faire l'anti aliasing comme il faut.
Super ! je vais pouvoir m'attaquer aux stencils maintenant :o/

Bonne nuit !

Il y a un bug dans le code ci dessus où tous les z des shapes est forcé à 100.0. En sortant de l'axe pour voir ce qui se passe, j'ai pu corriger pas mal de problèmes de profondeur et de glfrustum mal ajusté, et ça donne ça:

http://www.flickr.com/photos/15812694@N00/1367027345/

Beaucoup mieux donc, mais les lignes ne sont pas de la bonne couleur (phénomène d'écran évoqué plus haut). Je continue à chercher ...

En effet: mes données en entrée sont de la forme: un polygone passant par les points [p1;p2;p3;p4;p5] de couleur de remplissage cr avec un contour de couleur cc de largeur L. Dessiner un polygone à coups de lignes me semble légèrement sous-optimal, non ? Par exemple dans la spec que j'affiche dans la capture, il y a un triangle peint en noir avec un bord rosâtre, ou le losange gris plein centre. Je peux aussi avoir à afficher des disques ou des couronnes, avec les mêmes contraintes (remplissage + bordure). Sinon c'est peut-être dû à mes bindings, mais j'en doute ( http://glcaml.sourceforge.net/ ). Sinon je t'ajoute aussi le code qui fait effectivement le rendu (le point d'entrée est la dernière fonction: render) :

module Gl = Glcaml 

type line_cmd = | Lines | LineLoop |LineStrip 
type color = float * float * float * float
type width = float
type depth = float
type point = float * float
type shape_cmd = | Quad | Polygon
type matrix_cmd = | Translate of float * float |Scale of float*float | Rotate of float 
type cmd = 
    |Line of line_cmd * point list * color * width * depth
    |Shape of shape_cmd * point list * color * depth
    |Matrix of matrix_cmd list * cmd list

let color = function |(r,g,b,a)->Gl.glColor4f r g b a
let set_alpha a = function |(r,g,b,_)->(r,g,b,a)
let width w = Gl.glLineWidth w
let line_prim = function | Lines -> Gl.GL_LINES | LineLoop -> Gl.GL_LINE_LOOP | LineStrip -> Gl.GL_LINE_STRIP
let shape_prim = function | Quad -> Gl.GL_QUADS | Polygon -> Gl.GL_POLYGON 
let vertex depth p2D = match p2D with | (x,y)-> Gl.glVertex3f x y depth
let push_matrix transfos =
  let trans = function 
    | Translate(dx,dy) -> Gl.glTranslatef dx dy 0.
    | Scale (sx,sy) -> Gl.glScalef sx sy 0.
    | Rotate angle -> Gl.glRotatef angle 0. 0. 0.
  in
    begin 
      Gl.glPushMatrix ();
      List.iter trans transfos;
    end
let pop_matrix () = Gl.glPopMatrix ()
let rec render_line= function 
  |Line(prim,pts,c,w,d) -> 
     begin
       color c ; 
       width w ;
       Gl.glBegin (line_prim prim);
       List.iter (vertex d) pts;
       Gl.glEnd ();
     end
  |Shape _ -> ()
  |Matrix(transfos, subshapes) -> begin 
      push_matrix transfos;
      List.iter render_line subshapes; 
      pop_matrix ()
    end

let rec render_shape= function 
  |Line _ -> () 
  |Shape(prim,pts,c,d) -> 
     begin
       color c ; 
       Gl.glBegin (shape_prim prim);
       List.iter (vertex (100.)) pts;
       Gl.glEnd ();
     end
  |Matrix(transfos, subshapes) -> begin 
      push_matrix transfos;
      List.iter render_shape subshapes; 
      pop_matrix ()
    end

let render cmd_list = 
  begin
    List.iter render_line cmd_list;
    List.iter render_shape cmd_list; 
  end

Toutes les couleurs. Capture d'écran icitte :
http://farm2.static.flickr.com/1320/1364676845_d55da56ae2_o.(...)

L'init du code incriminé est là
http://www.flickr.com/photos/15812694@N00/1364676845/

J'ai un glLinewidth entre 2 et 4 suivant les lignes.
J'ai découpé le rendering en 2 phases, d'abord les lignes, puis les remplissages. Dans ce cas, les lignes sensées être recouvertes par des fills ne le sont pas (ex sur la capture les L allongés figurant les ailes de l'avion ont un z plus proche que la ligne d'horizon, pourtant cette dernière passe devant la forme, mais bien derrière son contour.)

Si j'inverse l'ordre de dessin, les lignes ne sont pas dessinées alors qu'elles ont un z plus proche (!). Toujours en ordre de dessin inversé, si je supprime les remplissages, je vois les lignes, mais si je rends les remplissages partiellement transparents, je ne vois pas les lignes derrière.

J'ai inversé tous les z, je n'ai aucun changement dans ce qui est affiché.

Si je mets tous les z à 0 et que je fais les appels dans le bon ordre (les lignes puis les remplissages) la géométrie passe bien (le choses qui doivent se cacher se cachent), mais j'ai toujours le même problème d'anti alias.


Je pense que je n'ai pas tout compris au depth buffer ...

Perdu, désactiver le mask_depth fait un effet "écran", un trait noir par exemple ne se voit plus. grrr ...

OK, trouvé, il faut mettre le glDepthMask à false avant de dessiner les lignes.

Je me doute, mais je ne trouve pas.
J'ai bien trouvé GL_CULL_FACE pour ne pas dessiner les faces cachées, mais en fait ça ne m'intéresse pas (je fais de la 2D). Je continue à chercher alors ...