Marc a écrit 2074 commentaires

  • [^] # Re: OBS

    Posté par (page perso) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.

    ok, alors je creuserais :) Dans mon cas, je ne cherche pas à couvrir un max de distrib, simplement car je serais bien incapable de tester si les paquets sont utilisables (dépendances et cie). Je suis bien d'accord pour dire que PPA est limité, car ubuntu-only, moi je veux juste ubuntu+debian... Le reste, je n'en ai pas l'utilité... Et j'imagine qu'une fois que t'as un ppa 'ubuntu', avoir la même chose pour debian ne doit pas être très compliqué...
  • [^] # Re: OBS

    Posté par (page perso) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.

    Bon, j'ai un peu regardé, et OBS vaut la peine d'être testé. Donc je me suis fait un compte, fait un projet, tout ça tout ça. Mais après, pour créer des paquets .deb, je coince. La doc demande quand même de prendre le paquets "debianizé" et de le changer: http://en.opensuse.org/Build_Service/Deb_builds . Je fais fausse route ? On ne peut pas simplement envoyer le orig.tar.gz, dsc, changes et diff.gz ? Moi ça m'embête un peu d'avoir à modifier les trucs avant de les envoyer sur OBS...
  • [^] # Re: OBS

    Posté par (page perso) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.

    si c'est pour construire les paquets, ça ne pose pas de soucis, il suffit d'avoir un chroot par exemple. Je t'accorde que OBS semble pas mal, je testerai peut être. Mais PPA fait plus que simplement construire, il fait aussi tout ce qui va après la construction: hébergement, suppression des paquets obsolètes, ... Si je me retrouve avec des .deb, c'est retour case départ: j'en fais quoi ? Ça devient vite pénible quand t'as 10 paquets différents à gérer.
  • [^] # Re: PPA pour debian!

    Posté par (page perso) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.

    Intéressant ! Mais bon, c'est pas tout à fait ce que je recherche... Là, tu peux pas utiliser les outils debian car leur système prend encore un autre format en entrée. Visiblement, le contenu du rep debian/ est réarrangé (debian.rules, debian.changelog, ...). La beauté du PPA, c'est que tu te prends pour un vrai mainteneur de paquet. Tu peux modifier un paquet "officiel" pour y incorporer tes propres choses, etc. Si ça existait pour Debian, ça serait génial, mais quand on voit le prix à payer pour avoir le tampon "debian developer (cf http://www.lucas-nussbaum.net/blog/?p=349 par ex), je sais pas si ça fait parti des choses envisagée. Dommage... Ça semble une bonne façon de former les petites mains, de voir qui sait vraiment faire de choses... C'est sûr que pour devenir "ubuntero", il suffit de dire "oui j'ai lu", il n'y a pas d'examen en 50 questions sur des points précis de licences & cie. J'avoue que ça donne 'achement plus envie de contribuer à Ubuntu que Debian.
  • [^] # Re: PPA pour debian!

    Posté par (page perso) . En réponse à la dépêche Launchpad libéré !. Évalué à 6.

    Pardon :)
    Personnal Package Archive: https://help.launchpad.net/Packaging/PPA

    Tu envoies tes paquets sources, et ils sont compilés sur les machines de canonical. En gros, c'est la même chose que ce qu'il se passe pour les "vrais" package, sauf que là, c'est ouvert à tout le monde. En gros, tu te charges juste de créé le paquet, launchpad se charge du reste:
    - compilation
    - hébergement
    - diffusion
    Par exemple, mon ppa pour ubuntu: https://launchpad.net/~marc-poulhies#ppas
    Si je pouvais avoir la même chose pour debian, ça serait juste super. Parce que actuellement, si tu veux avoir un truc propre pour diffuser des paquets debian, tu dois le faire à la main, ou installer des softs pas forcément facile de prise en main. Avec les ppa, tu te concentre juste sur ton package, et ça juste-marche \o/
  • # PPA pour debian!

    Posté par (page perso) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.

    A quand un PPA pour Debian !
  • [^] # Re: Avantage

    Posté par (page perso) . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 3.

    "En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême. (Il existe un débuggeur ligne par ligne en python ? Un gdb pour python, en fait)"

    pdb par exemple ?

    Perso, quand il faut faire une appli, je passe beaucoup moins de temps à la faire en python qu'en C/C++. Le langage se fait moins sentir et je peux me concentrer sur ce que je veux faire et pas comment je vais pouvoir le faire avec le langage. C'est mon resenti perso.Mais par exemple, je voulais intéragir avec l'API de vimeo pour envoyer des vidéos. En 30min j'avais un premier trucs qui fonctionnait, fait à "la bite et au couteau", sans utiliser de module pour REST & cie. Ben en C, je sais que j'aurais mis plus de temps.
  • [^] # Re: Japon

    Posté par (page perso) . En réponse au journal Faire un post-doc à l'étranger. Évalué à 1.

    Attention avec les JSPS et les dates. Certains labos ont leurs propres dates butoirs avant d'envoyer à la JSPS. C'est le cas du JRL à Tsukuba. Leurs dates butoirs sont presque un mois avant celle de la JSPS. Et si tu passes par le CNRS pour faire ton dossier, c'est encore d'autres dates... Un peu la galère quoi :( Enfin bon, de toute façon, pour moi, c'est resté à l'état de rêve... Je te souhaite de trouver un post-doc qui te plait !

    ++
  • # Japon

    Posté par (page perso) . En réponse au journal Faire un post-doc à l'étranger. Évalué à 1.

    Pour le japon, tu n'est pas obligé de passé par la JSPS, même si c'est le plus pratique et que c'est bien payé. Je voulais le faire, mais j'ai du abandonné pour des raisons annexes. Mais un ami est allé y passer presque une année (novembre08->aout09) en se faisant financer directement par le labo d'accueil (NII à Tokyo). Pour y parvenir, il a contacté directement le prof... Plus tard, ce prof est venu faire une présentation de son labo en France, et il a *vivement* encouragé les thésard ou futur post-doc à venir.
    Si la durée de 2ans te parait trop longue, tu peux faire un 'short term' JSPS (dont la DL est aout il me semble, avec réponse autour de décembre).

    Bon courage !
  • [^] # Re: ObjectiveC

    Posté par (page perso) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.

    Aucune idée. Je sais qu'à l'époque où j'avais regardé, POC n'utilisait pas tout le système de typage de objc (c'est vague ce que je dis, normal, je m'en souviens plus très bien). Le truc à retenir, c'est que c'est faisable... Donc dire "on a refait un truc et pas continuer dans le sens objc parce que nous on génère du C donc on est plus portable", c'est pas bon. Après, je doute pas qu'il existe plein d'autres raisons valables ;)
  • [^] # Re: ObjectiveC

    Posté par (page perso) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.

    (c'était juste pour info... sur le reste, j'ai pas d'avie pertinent à donner)

    il parait même que ça s'écrit avis. Trop fou.

    (ah, et bien vu la geekscote lors de la détection de l'auto-réponse :D)
  • [^] # Re: ObjectiveC

    Posté par (page perso) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.

    - Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.

    gcc inclue un frontal objc. Donc ton approche pourrait se justifier pour les cibles où gcc n'est pas porté, mais pour laquelle un autre compilo C existe. Mais là, on peut répondre qu'il existe des s2s objc->c (comme POC: http://users.telenet.be/stes/compiler.html ).

    (c'était juste pour info... sur le reste, j'ai pas d'avie pertinent à donner)
  • # ?

    Posté par (page perso) . En réponse au message création paquet debian avec 1 paquet source pour faire 1 paquet module et 1 "bin". Évalué à 1.

    bon, je comprend pas... Mais visiblement, il y avait un truc "en cache" qui faisait que ça ne fonctionnait pas... J'ai refais un checkout propre, et ça fonctionne correctement... Étrange !
  • [^] # Re: De toutes façons ...

    Posté par (page perso) . En réponse à la dépêche Nouveau FormaCD sur GIMP 2.6. Évalué à 3.

    Ah bon ? chezmoiçamarche-pourtant.com

    gimp:
    Installed: 2.6.6-1
    Candidate: 2.6.6-1
    Version table:
    *** 2.6.6-1 0
    500 http://ftp.fr.debian.org sid/main Packages
  • [^] # Re: Pour faire dans le constructif

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.

    Concernant les listes, c'est effectivement utile. J'ai pris une solution à peu prêt similaire quand j'ai eu besoin de liste "générique" à la compilation (voir http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/think/exp(...) ).

    Pour l'utilisation de __FILE__, j'avais envisagé la chose aussi, le soucis étant que les différentes versions du sources commencent par un passage du cpp sur le fichier d'origine, donc __FILE__ est toujours le même.

    Ce qui est dommage, c'est de ne pas pouvoir obtenir par exemple la date d'appel du cpp dans une forme sympa (genre YYYYDDMMHHMMSS).

    Merci quand même d'avoir essayer :)

    Marc
  • [^] # Re: pas compris l'interet

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.

    "Le coup des templates, c'est sympa quand tu codes un compilo, mais quand tu le fais à la main, t'as intérêt à être super balèze pour arriver à faire un truc correct. Les indications que tu donnes montre bien que la plate-forme n'est pas encore tout à fait au point ..."

    Je t'ai donné un exemple avec les templates. Pour notre utilisation, ce que nous faisons marche relativement bien. Bien sûr, tout n'est pas parfait, surtout quand il faut jouer avec du C dont la grammaire est toufu et souvent étendu par chaque compilateur. Un projet qui a la base est de la recherche n'a pas vraiment vocation à "être au point". Si on désire obtenir un truc qui "est au point" et clean, on ne demande pas à des thésards & cie d'écrire le code, on demande à des développeurs dont c'est le travail.

    "Pour le fait à l'arrache, OK, tu fais un proto, mais t'admets que tu le fais à l'arrache."

    Pour être plus précis, je fais un proto qui étend le compilateur Think de base. Je ne suis pas presta, je suis simple thésard, et la qualité du code, même si c'est une qualité en soit, ça n'est pas du tout un résultat de recherche. Un proto qui marche oui, car il permet d'illustrer une méthode. Dans ce cadre, "fait à l'arrache" n'est pas un problème vis à vis du résultat. Ça risque d'être un problème si tu comptes en faire autre chose après.

    "mais tu voudrais que je dise quoi ? "
    Il est tout à fait possible de faire passer ses idées sans commencer par des attaques qui n'ont aucun rapport (tu remarquera que je n'ai pas relevé ton attaque où tu me dis clairement que tu me prends pour un con), cf ton premier message sur orange, cf ton 2ème message où tu ne donnes aucun argument, juste des (je raccourcis, mais tu m'accordera que c'était l'idée) "c'est complètement con ce que tu fais". En fait, en étant plus diplomate, les idées passent même souvent mieux. Surtout quand visiblement, on ne connaît ni les buts, ni le contexte, juste en se basant sur une question n'ayant aucun rapport avec le projet.

    Concernant ELSE, je connais aussi ce projet, j'ai utilisé un peu (FTinux & cie). Je t'avoue que je n'ai jamais vraiment compris l'intérêt du projet. Ça n'enlève rien aux autres projets, qui même s'ils ont un tampon 'Orange' ne sont pas forcément pilotés par les même personnes. Le projet Think a des rapports avec plusieurs autres entreprise du bassin Grenoblois, commence à faire son apparition dans quelques cours à l'université, etc. C'est du logiciel libre, 99,99% du dev se fait sur le svn hébergé par le consortium OW2. Plusieurs laboratoires de recherche (à l'INRIA, à l'INPG/UJF, univ de Pau, sans doute d'autres dont j'oublie le nom) utilise ces outils.
    Le projet est suffisamment mature pour être utilisé comme tel (sans avoir à mettre les mains dans le cambouis). Voir par exemple le proto ayant été développé dans le cadre d'une thèse: http://senseandsensitivity.rd.francetelecom.com/ .

    Bref. Tout ça pour dire que je t'avais trouvé très rapide pour décrété qu'un projet dans son ensemble était bancal et mal fichu. Certains points le sont, je suis pas le dernier à le dire. Mais dans l'ensemble, le résultat n'est pas si mal.
  • [^] # Re: pas compris l'interet

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 2.

    "Une archi bancale : prendre le même source pour générer plusieurs autres un peu différents, qu'on va assembler ensemble après .... j'ai jamais vu ça et je trouve que c'est _très_ bancal."

    as tu déjà regardé comment fonctionne un compilateur? Quand tu codes avec les templates C++, tu crois pas que pendant une phase de compil ton template ne vas pas être spécialisé suivant les types dont tu te sers pour le configurer ? Moi je pense que si. C'est la même idée. Ou prend du C++ pour lequel tu ne veux pas payer le prix d'un pointeur vers les metadata, tu vas être obligé de spécialiser le code pour chaque instance.

    "- Contraintes étranges : pas de define en ligne de commande, pas de static, bref on peut toucher à rien ; c'est pour un concours de contraintes ?"

    Biensûr que tu peux mettre spécifier des macro au cas par cas, c'est d'ailleurs ce que j'ai fini par faire. Mais de manière général, ces macros ne devraient être utiliser pour piloter la compilation du code

    "Fait à l'arrache : vu comme t'es obligé de bidouiller" : mon utilisation oui. Je vais pas te raconter ma vie, mais j'ai besoin de faire un truc rapidement, un prototype. Aucun rapport avec le projet. Je peux faire un truc dégueux en C, ça ne dit rien sur le compilateur que j'utilise. Si ? Par exemple, et ça arrive souvent, tu regardes ce que crache gcc au niveau asm, et dans ton code C tu vas aller jouer avec des pointeurs relatif sur la pile écrit en dur. C'est crade, c'est fragile. Mais si le but est juste de faire un proto, une preuve de concept. En aucun cas je peux dire que gcc est "fait à l'arrache".

    "Pour Orange : bah au hasard ELSE,". Ok. Donc tu connais un projet dont tu n'es pas content, et t'en déduis que tous les projets où orange intervient sont mal gérés ?

    Tu sais, si c'est le mot orange qui te file des boutons, c'est ton droit. Je ne suis pas payé par Orange, je le prendrai pas personnelement. Par contre, quand tu veux argumenter sur des points techniques, ça serait bien de faire plus que du troll. Quand je te demande qu'est ce qui est bancal, ta réponse est juste de pointer du doigt un élément, sans dire autre chose que "je trouve ça bancal".

    Pour le reste, je vais en rester là. Si tu es curieux, je t'invite quand même à aller regarder comment ça fonctionne. Y'a du bon et du moins bon. C'est un projet de recherche, pas de la prod. En plus, ça t'évitera d'avoir des avis un peu trop tranché rapidement.

    Bonne fin de journée
  • [^] # Re: pas compris l'interet

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 2.

    "une architecture bancale"

    Peux tu développer ?

    "contraintes que je trouve très étranges"

    De quelles contraintes tu parles ?

    "le projet est fait à l'arrache"

    Sur quoi tu te bases pour dire ça ? J'ai rarement vu comme définition de pragmatique : à l'arrache. Le choix du langage C pour quand tu vises des micro contrôleurs 8bits avec qqs KiB de RAM, ça me semble pas très surprenant non plus et c'est là que tu trouvera le plus de doc et de code.

    "Orange (enfin, FT) bien connu pour ses projets efficaces et bien faits"

    Peux tu cités les projets issus de Orange Labs (FT R&D) auxquels tu penses ? De plus, si tu avais pris 5min pour regarder, tu aurais vu que Orange est le principal acteur du projet, mais pas le seul.

    Tu m'excuses, mais soit tu cherches juste à troller, soit t'es un peu à côté de la plaque. J'imagine que c'est la première solution.
  • [^] # Re: pas compris l'interet

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.

    Là on s'écarte un peu de ma question initiale, mais pas grave ;)
    Le compilateur (qui prend entre autres, des fichiers C en entrée et produit du C en sortie) est relativement "complexe". Par complexe, c'est juste que c'est pas un script de 10 lignes de bash. C'est une application assez lourde, écrite en Java avec un fw à composant. Du coup, intégrer du sed/awk dedans, pas possible (d'autant plus qu'il doit fonctionner sur autre chose que des unix, windows en particulier, et dépendre de cygwin & cie, bof bof).

    Pour détailler un peu plus, le code C va être intégralement analyser pour construire un ASG. ASG qui est manipulé pour effectuer différentes taches:
    - créer un code partagé par plusieurs instances d'un même composants. Ca va demander de faire des structure pour stocker les données d'instances et potentiellement modifier le code donné en entrée pour utiliser cette structure.
    - optimisation du code produit (fortement dépendant de l'architecture que tu compiles... est-ce que tu peux changer les composants à chaud ? Certaines liaisons peuvent elles changer ?)
    - etc

    Du coup, la manip du code n'est pas vraiment simple. Parfois, on aimerait bien faire certaines chose pas très bien, comme c'est le cas pour moi. Je fais une hypothèse sur le code produit, et je m'en sers pour écrire le code d'entrée. C'est mal, mais dans certains cas, on a pas trop le choix. En l'occurrence ici, j'aimerais que certaines fonctions dans le code final généré reflète des noms qui sont données dans le langage qui décrit l'architecture du système.

    On se concentre sur du code en C (pour plein de raisons, mais la plus grande étant les cibles qu'on vise n'ont pas toujours un compilateur C++, et il est plus facile de maîtriser ce qui fini sur ta plate-forme en utilisant du C qu'autre chose. J'ai pas dit que c'était une vérité absolue, mais parfois, faut faire des choix pragmatique pour arriver à quelque chose qui fonctionne), du coup, l'utilisation d'un langage OO n'est pas possible. On a des travaux visant à intégrer des composants écris en C++, on sait récupérer du code objet, etc.

    Et pour finir, la question était aussi pour nourrir ma curiosité, car je suis souvent surpris par ce qu'on peut faire avec les macros et le cpp, et je pensais qu'ici, j'aurais le plus de chance de trouver des as de ce dialecte. J'avoue avoir été un peu déçu d'avoir comme réponse:
    "j'ai pas fait de C depuis des lustres, mais ça sert à rien ce que tu fais"
    "projet sponso par orange, normal que ça soit de la merde"
  • [^] # Re: pas compris l'interet

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.

    puisque visiblement, ce commentaire fort sympathique passe à 6, je me dis que j'ai peut être mal formulé quelques chose. Néanmoins, dans mon message initial, il est bien indiqué:
    "le cpp va passer plusieurs fois pour créer plusieurs version du code."

    Donc, en sortie, j'ai bien des sources différents. Il faut penser au fichier original comme un template. Bref.
  • [^] # Re: option -D

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 0.

    Que répondre à un message faisant preuve d'une si grande expertise en compilation.
  • [^] # Re: option -D

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.

    là ça demande de changer la méthode de compilation, et c'est pas possible. Comme je le disais plus haut, tout ça est intégré dans un compilateur qui prend du C en entrée, le manipule et recrache du C en sortie.

    Du coup, je m'en suis sorti en faisant un hack à la Q&D. Pour info, c'est en rapport avec http://think.ow2.org

    Merci pour les coups de main ;)
    Marc
  • [^] # Re: option -D

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.

    je voulais éviter l'utilisation d'une ligne de compilation spécifique à chaque instance (cf message initial...)
  • [^] # Re: pas compris l'interet

    Posté par (page perso) . En réponse au message Macro pour définir identifiant uniques. Évalué à -4.

    j'ai simplifié... Je travaille avec un canevas à composant. Chaque composant peut être vu comme une classe si tu veux, et un compilateur prend ça et va créer un code spécifique pour chaque instance de composant. Si vraiment tu veux des détails, je peux t'en donner autant que tu veux, mais c'est pas trop la question ici.

    Si tes cours de C remontent à longtemps, peut être que tu devrais prendre plus de précautions avant de ne pas répondre à la question posée et mettre en doute l'intérêt de la chose.

    Marc
  • [^] # Re: my 2 cents

    Posté par (page perso) . En réponse à la dépêche Test d'Ubuntu Jaunty (9.04). Évalué à 1.

    pas eu l'occasion de tester, mon colloc et mon labo utilisant cette technologie ultra-moderne : le WEP /o\