Marc a écrit 2067 commentaires

Un samsung ND10 ? :)
http://www.blogeee.net/2009/08/13/le-samsung-nd10-un-nc10-sa(...)

là par contre je ne sais pas.... désolé

http://progetti.arstecnica.it/tailor/

et avec le lien, c'est mieux!

moi j'avais utilisé tailor pour faire svn->bzr->git et ça marchait pas mal. Il sait faire les conversions dans un peu tous les sens...

«Pour ne rajouter qu'une méthode ou un manager à un modèle existant vous pouvez créer des modèles...»

J'imagine qu'il manque le "vous", ou alors j'ai un problème de compréhension...

Si tu sais pas trouver cette info, c'est toi qui est nouveau :p

Je répond à tes commentaires en 1 seul :)

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.

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/

A quand un PPA pour Debian !

"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).

Bon courage !

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 ;)

(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)

- 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 !

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