Doom3, en fait, je l'ai acheté après avoir joué à la démo avec les pilotes proprio ATI, et ça marchait bien. Mais c'était avant de rencontrer crash sur crash. Du coup, ben mon doom3 attendra des jours meilleurs. Et j'ai pas trop suivit, mais j'avais lu que doom3 serait sans doute ouvert, comme les quake 1 2 et 3, du coup, je me préparais à pouvoir tester le jour venu (le jeux m'a coûté 5 ou 6€...)
Ensuite, bizarrement, GE sur mon ordi portable (intel intégrée) fait fonctionner GE de manière tout à fait convenable pour ce que j'en fais. Je ne sais pas pourquoi sur mon ordi fixe, ça rame sévère (pourtant, mon portable est un centrino 1.6Ghz d'il y a 4 ou 5ans... Mon fixe est un c2d avec chipset G33...bref). Sur mon eeepc (toujours intel intégrée), GE fonctionne presque assez bien. Je suis peut être dans un "trou" de support, la faute à pas de chance...
J'avais oublié l'existence de marble. J'avais regardé il y a longtemps, mais depuis, ça semble avoir bien progressé, je vais jeter un oeil, merci ! Concernant la carto, c'est pas très grave, et je pourrais toujours compléter avec geoportail ou googlemaps. Par contre, ce dont j'ai vraiment l'utilité, ce sont les reliefs, et j'ai pas l'impression que ça soit présent. Ça me fait penser que je pourrais jeter un oeil à Worldwind de la NASA.
Hmmm, je ne peux pas m'empêcher de te répondre. J'aimerais que tu me dises en quoi je fais preuve d'un intégrisme aveugle ?
Un intégrisme aveugle, il n'utiliserait pas GE, il n'aurait pas acheté Doom3, il n'aurait pas testé les pilotes FireGL, etc. Non ?
J'ai acheté du matériel en espérant pouvoir utiliser du logiciel libre pour le faire fonctionner, et au final, je n'ai trouvé aucune solution correcte (libre ou pas). L'aveugle est allé discuter sur IRC, il a passé plusieurs soirées à essayer de comprendre comment fonctionnent les pilotes, il a lu des pages de BR, etc.
Je trouve qu'on a vite fait de se faire juger sur linuxfr.
Pour toi, tout est binaire ? J'apprécie de pouvoir utiliser des pilotes libres pour mon intel et en plus, ça me simplifie la vie. Avant, j'avais des radeon 8500 puis 9250, et les pilotes libres marchaient bien.
Jusqu'à preuve du contraire, il n'y a pas de logiciel libre équivalent à GE (ou alors, je ne suis pas au courant, et ça m'intéresse), et je ne peux pas vraiment m'en passer. En quoi vouloir tout de même maximiser l'utilisation de logiciel libre te semble contraire à toute logique ? En suivant ton raisonnement, à partir du moment où on utilise un bout de propriétaire, on est contaminé et il est inutile de faire des efforts "vers le libre".
J'aime utiliser autant que possible du libre sur mes machines, c'est si illogique que ça ? Parce que j'ose utilise un soft proprio, je devrais m'asseoir sur ces efforts ?
Si tu peux m'expliquer en quoi ma démarche n'est pas logique et "te dépasse"...
Bon, ben j'ai envie de dire "pareil". J'ai une intel intégrée, et ça marche relativement bien, sauf quand je veux utiliser google earth... Et ça m'arrive relativement souvent. Donc, je me suis dit que j'allais me prendre une carte relativement vieille mais dont les perfs seraient suffisantes pour GE. Tant qu'à faire, j'ai cherché une carte de petite taille et sans ventillateur, avec 2 sorties dont une DVI. Niveau pilote 3D libre, j'avais l'impression que le mieux était intel et ati, donc j'ai investi dans une radeon HD3450. J'ai galéré avec les pilotes libres, pour finalement n'avoir que moins bien qu'avec mon intel (pas de 3D, pas de Xv, ...)... Sans compter les plantages réguliés de X, systématiques lors de la lecture d'une vidéo après une mise en veille (mise en veille qui marchait relativement mal). J'ai testé les pilotes proprio, qui n'ont pas posé plus de problème que ça à l'installation (deb sid). Sauf que plantages encore et encore, pénible lors de certaines mises à jour... Bon, ben du coup, la carte est posée dans un coin de mon bureau. J'ai eu pas mal de soucis à savoir qu'est ce qui est supporté et qu'est ce qui ne l'est pas pour les pilotes libres radeon/radeonhd. Un peu embêtant quand on a déjà du mal à installer (est-ce que ça ne marche pas par ce que ça n'est pas supporté, parce que j'ai mal installé et qu'en passant du temps, ça marchera, parceque j'ai pas pris la bonne branche de dev, parce que je suis un fion, ... ?).
C'est con, car j'avais acheté doom3 dans la foulée... Mais il ne marche évidement pas avec mon intel :(
Intel, c'est peut être pas puissant, mais qu'est ce que c'est agréable de pas avoir à se soucier des pilotes. Dans mon cas, ça juste-marche.
Disons que personnellement, je ne me fierais pas uniquement aux numéros de versions pour prédire si l'assemblage de différents logiciels fonctionnera. C'est un indice, mais ça ne fait pas tout. Dans mon cas, j'ai testé mes logiciels avec certaines bibliothèques (celles de debian sid et ubuntu jaunty), je n'ai aucune certitude que ça fonctionne bien ailleurs. OBS peut vérifier que ça compile, ok. Mais pour le reste, il me faudrait quand même aller tester, voir que ça s'exécute correctement (ou alors que j'écrive des scripts pour automatiser ça, mais ça ne se fait pas en 5min).
Ensuite, il y a des choses qui ne se font pas pareil d'une distrib à l'autre, et je suis incapable d'aller regarder pour chacune comment ça fonctionne. Chez debian, on pose les jvm dans /usr/lib/jvm/, les jar dans /usr/share/java... et chez les autres ? J'ai des modules python et debian automatise la chose à fond, mais je ne sais pas si OBS saura transposer ça pour les autres (installation des .py qqpart et "byte compilation" à l'installation du paquet).
A mon avis, ça ne s'improvise pas... Et de toute façon, je ne cherche pas à couvrir l'ensemble des distributions, je n'ai pas la prétention d'avoir autant d'utilisateur que ça... Par contre, j'aimerais fournir qqch de relativement testé et "robuste" pour les distribs que j'utilise (et pour lesquels je fourni de l'aide).
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é...
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...
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.
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.
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/
"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.
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 !
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).
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 ;)
- 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)
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 !
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).
"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.
"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.
# tailor
Posté par Marc (site web personnel) . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
[^] # Re: Quelques corrections
Posté par Marc (site web personnel) . En réponse à la dépêche Sortie de Django 1.1. Évalué à 2.
J'imagine qu'il manque le "vous", ou alors j'ai un problème de compréhension...
[^] # Re: HD 3450
Posté par Marc (site web personnel) . En réponse au journal ATI (AMD) ou l'effet socialiste!. Évalué à 2.
[^] # Re: HD 3450
Posté par Marc (site web personnel) . En réponse au journal ATI (AMD) ou l'effet socialiste!. Évalué à 3.
Doom3, en fait, je l'ai acheté après avoir joué à la démo avec les pilotes proprio ATI, et ça marchait bien. Mais c'était avant de rencontrer crash sur crash. Du coup, ben mon doom3 attendra des jours meilleurs. Et j'ai pas trop suivit, mais j'avais lu que doom3 serait sans doute ouvert, comme les quake 1 2 et 3, du coup, je me préparais à pouvoir tester le jour venu (le jeux m'a coûté 5 ou 6€...)
Ensuite, bizarrement, GE sur mon ordi portable (intel intégrée) fait fonctionner GE de manière tout à fait convenable pour ce que j'en fais. Je ne sais pas pourquoi sur mon ordi fixe, ça rame sévère (pourtant, mon portable est un centrino 1.6Ghz d'il y a 4 ou 5ans... Mon fixe est un c2d avec chipset G33...bref). Sur mon eeepc (toujours intel intégrée), GE fonctionne presque assez bien. Je suis peut être dans un "trou" de support, la faute à pas de chance...
J'avais oublié l'existence de marble. J'avais regardé il y a longtemps, mais depuis, ça semble avoir bien progressé, je vais jeter un oeil, merci ! Concernant la carto, c'est pas très grave, et je pourrais toujours compléter avec geoportail ou googlemaps. Par contre, ce dont j'ai vraiment l'utilité, ce sont les reliefs, et j'ai pas l'impression que ça soit présent. Ça me fait penser que je pourrais jeter un oeil à Worldwind de la NASA.
[^] # Re: HD 3450
Posté par Marc (site web personnel) . En réponse au journal ATI (AMD) ou l'effet socialiste!. Évalué à 4.
Un intégrisme aveugle, il n'utiliserait pas GE, il n'aurait pas acheté Doom3, il n'aurait pas testé les pilotes FireGL, etc. Non ?
J'ai acheté du matériel en espérant pouvoir utiliser du logiciel libre pour le faire fonctionner, et au final, je n'ai trouvé aucune solution correcte (libre ou pas). L'aveugle est allé discuter sur IRC, il a passé plusieurs soirées à essayer de comprendre comment fonctionnent les pilotes, il a lu des pages de BR, etc.
Je trouve qu'on a vite fait de se faire juger sur linuxfr.
[^] # Re: HD 3450
Posté par Marc (site web personnel) . En réponse au journal ATI (AMD) ou l'effet socialiste!. Évalué à 6.
Jusqu'à preuve du contraire, il n'y a pas de logiciel libre équivalent à GE (ou alors, je ne suis pas au courant, et ça m'intéresse), et je ne peux pas vraiment m'en passer. En quoi vouloir tout de même maximiser l'utilisation de logiciel libre te semble contraire à toute logique ? En suivant ton raisonnement, à partir du moment où on utilise un bout de propriétaire, on est contaminé et il est inutile de faire des efforts "vers le libre".
J'aime utiliser autant que possible du libre sur mes machines, c'est si illogique que ça ? Parce que j'ose utilise un soft proprio, je devrais m'asseoir sur ces efforts ?
Si tu peux m'expliquer en quoi ma démarche n'est pas logique et "te dépasse"...
# HD 3450
Posté par Marc (site web personnel) . En réponse au journal ATI (AMD) ou l'effet socialiste!. Évalué à 1.
C'est con, car j'avais acheté doom3 dans la foulée... Mais il ne marche évidement pas avec mon intel :(
Intel, c'est peut être pas puissant, mais qu'est ce que c'est agréable de pas avoir à se soucier des pilotes. Dans mon cas, ça juste-marche.
[^] # Re: OBS
Posté par Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.
Ensuite, il y a des choses qui ne se font pas pareil d'une distrib à l'autre, et je suis incapable d'aller regarder pour chacune comment ça fonctionne. Chez debian, on pose les jvm dans /usr/lib/jvm/, les jar dans /usr/share/java... et chez les autres ? J'ai des modules python et debian automatise la chose à fond, mais je ne sais pas si OBS saura transposer ça pour les autres (installation des .py qqpart et "byte compilation" à l'installation du paquet).
A mon avis, ça ne s'improvise pas... Et de toute façon, je ne cherche pas à couvrir l'ensemble des distributions, je n'ai pas la prétention d'avoir autant d'utilisateur que ça... Par contre, j'aimerais fournir qqch de relativement testé et "robuste" pour les distribs que j'utilise (et pour lesquels je fourni de l'aide).
[^] # Re: OBS
Posté par Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.
[^] # Re: OBS
Posté par Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.
[^] # Re: OBS
Posté par Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.
[^] # Re: PPA pour debian!
Posté par Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.
[^] # Re: PPA pour debian!
Posté par Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 6.
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 Marc (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.
[^] # Re: Avantage
Posté par Marc (site web personnel) . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 3.
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 Marc (site web personnel) . En réponse au journal Faire un post-doc à l'étranger. Évalué à 1.
++
# Japon
Posté par Marc (site web personnel) . En réponse au journal Faire un post-doc à l'étranger. Évalué à 1.
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 Marc (site web personnel) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.
[^] # Re: ObjectiveC
Posté par Marc (site web personnel) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
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 Marc (site web personnel) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
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 Marc (site web personnel) . En réponse au message création paquet debian avec 1 paquet source pour faire 1 paquet module et 1 "bin". Évalué à 1.
[^] # Re: De toutes façons ...
Posté par Marc (site web personnel) . En réponse à la dépêche Nouveau FormaCD sur GIMP 2.6. Évalué à 3.
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 Marc (site web personnel) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.
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 Marc (site web personnel) . En réponse au message Macro pour définir identifiant uniques. Évalué à 1.
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 Marc (site web personnel) . En réponse au message Macro pour définir identifiant uniques. Évalué à 2.
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