Victor STINNER a écrit 1639 commentaires

Et la ferme de compilation de SourceForge.net ?
http://sourceforge.net/docman/display_doc.php?docid=762&group_i(...)

Et la/les ferme(s) de compilation Debian ? et celles des autres distribs binaires ?
http://buildd.debian.org/(...)

Vous pensiez vraiment qu'un mec se lançait la compilation sur i386, puis AMD64, puis Itanium (ça existe encore ça ?), puis PowerPC, puis ARM, puis aller boire une café, et enfin envoyait les binaires sur le ftp ... rassurez-moi ;-)

Bon, la liberté c'est le choix, et que le meilleur gagne.

Haypo qui sait bien que là c'est pas tout à fait pareil, mais qui voulait quand même rappeler que des pauvres serveurs dans des caves sombres mangent un milliard de fichiers .c par jour (du C en plus, j'vous jure, y'a pas de justice), et aucune association de protection des octets ne s'en soucie :'-(

Ben, j'ai refait différents tests, et je n'ai rien trouvé d'intéressant. J'ai comparé un fichier iCal (de icalshare.com) avec un fichier venu de l'agenda du libre : le format est semblable, les champs sont assez ressemblant, mais ... mais, y'a un truc qui bloque. J'ai tenté de charger le fichier et le renommer en ".ics", mais ça change rien. Par contre, en renommant en ".vcf" (VCalendar), Evolution affiche une erreur (enfin !) : erreur lors du chargement :-)

Thomas : Faudrait relire la norme et voir s'il ne manque pas un champ important !? (exemples : PRODID, X-WR-TIMEZONE, X-WR-RELCALID, SEQUENCE, DTSTAMP)

J'utilise Evolution 2.2.4 (Debian unstable), et je viens de voir qu'il existe le paquet evolution-webcal. Avec ce paquet, je peux m'inscrire à un calendrier en ligne (mais pas de changement pour l'agenda du libre).

Haypo

Parcqu'elle a de très forte chance d'être refusée : c'est une version mineure d'une branche de développement

Euh, ça fait pas depuis sa création que FluxBox est marqué "en développement" ? Pourtant, c'est pas rare de voir des bureaux l'utilisant ! Et perso, je n'ai vu aucune news au sujet de FluxBox, alors la moindre info en première page (pourquoi pas 2e colonne) serait la bienvenue.

Il y a beaucoup de gens qui ne connaissent pas l'existence des journaux !

Bon, si personne ne veut faire de dépêche tant pis. Mais ça vaut la peine d'essayer !

Haypo

Et après y'en a qui râlent : "meuh, ça parle que de HP, Ubuntu, et KDE le site linuxfr :-(". Par contre, je te conseille de virer les détails de config. Le but est que les gens qui lisent l'actualité aient envie de tester FluxBox. Les détails, ça se trouve dans le fichier ChangeLog (ou alors tu mets ça dans la partie du bas pour la brève). Il faut un bon paragraphe qui explique pourquoi FluxBox c'est super (léger, rapide, tout ça), et les trucs sympas qu'on peut faire avec (on peut enboîter plusieurs fenêtres avec des onglets, changer de bureau avec la roulette, etc.). Bon, j'utilise pas FluxBox, j'ai juste testé quelques temps, alors je peux pas trop t'aider.

Exemple : « Les differents mode de focus ont été redéfinis de SloppyFocus, SemiSloppyFocus et ClickToFocus en MouseFocus, ClickFocus, MouseTabFocus et ClickTabFocus » devient « Pour rappel, FluxBox permet nan pas une, ni deux, mais carrément trois méthodes de focus (oh mon dieu!) : par clic, par X ou par Y. » (je capte pas MouseTab ou ClickTab, peut-être ces histoires d'onglets !?). Enfin, tu vois l'idée.

Ne plus oublier les captures d'écran pour le concours "c'est mon bureau le plus beau de tous".

Rappel : On peut gagner des abonnements à LinuxMag, des bouquins Oreilly et Eyrolles.

Haypo

Ça pourrait faire une actualité !

Haypo

Hum, vous pourriez expliquer à des gens qui n'ont utilisé que cvs et subversion (les pauvres), comme moi, l'intérêt de faire des commit en local ? Pour moi, tout l'intérêt de SubVersion est de partager son travail avec l'équipe de développement ...

Peut-être pour avoir un changelog plus précis que "hou là là, je sais plus !" ? :-) Ça m'est déjà arrivé ça, genre commit 2 semaines après et diff bcp trop long, aïe.

Haypo

Perso, j'ai 8 millards de bookmarks : aucun plantage depuis longtemps :-D (google.com) Nan, plus sérieusement, la version Debian plante parfois, mais c'est rare, et souvent que je titille le panda avec du javascript costaux.

Par contre, mon père a perdu ses favoris lors d'une màj automatique sous Mac OSX. Enfin, apparement il les a retrouvé ...

Haypo

Bof, apparement, pas grand chose de neuf avec JavaScript 1.6 :
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6(...)

- Parser XML intégré à JavaScript (ça peut être pratique ça)
- Quelques fonctions pour travailler sur les tableaux (array)

Ou alors tout n'est pas noté sur cette url ?

Au passage, le portal JavaScript de Mozilla (que je ne connaissais pas) :
http://developer.mozilla.org/en/docs/JavaScript(...)

Haypo

Oui, c'est un fichier XUL (format XML) qui n'est pas valide (pas de bol). D'ailleurs, j'ai souvent faire un rm -rf ~/.mozilla en lachant une larme (malgré les sauvegardes, je perdais beaucoup de ma config), alors qu'un bête firefox --safe-mode est là pour ça (ne charge pas les extensions).

Haypo

Salut,

Le programme hdparm est ton ami pour changer les options d'un disque (dur, cdrom, etc.). Pour le DMA :

hdparm -d 1 /dev/hdc

(Euh, oui, en root c'est mieux)

Haypo

Est-ce qu'il sera toujours possible de compiler Totem en activant le backend Xine, ou est-ce que ce dernier est définitivement abandonné, comme il l'a été pour Rhythmbox ?

Je vois pas pourquoi on ne pourrait plus utiliser le backend Xine. La liberté, c'est le choix d'utiliser la lib qu'on veut ;-)

Haypo

Un truc comme ça tu le jettes à la poubelle, hop !

Haypo

Il a l'air un peu moisi : il recharge toute la page (popup) toutes les secondes. Enfin, à coup de Ajax ou iframe, ça pourrait être un peu plus transparent ;-) Sinon oui, ça m'a l'air très pratique. Il est où le bouton pour annuler un upload ? :-)

Haypo

Merci pour cette bonne tranche de rigolware Adrien :-) (tsss, y'a des gens qui ont aucun humour ici, j'vous jure !)

Haypo

Merci France Telecom d'avoir pu permettre à nos hommes, d'ajouter au bruit de la ville et des klaxons, la douce sonnerie du téléphone ! (Tryo)

Parole complete :
http://www.paroles.net/chansons/15238.htm(...)

Haypo

Wiki utilisant MySQL ou des fichiers textes, ça change rien à la pérénité. L'essentiel du wiki étant le contenu des pages ! Dans MediaWiki par exemple, c'est un champ d'une table (en l'occurance, wiki_cur.cur_text de type « mediumtext », texte codé en UTF-8). L'intérêt de MySQL (ou autre SGBD) est que c'est plus optimisé que des accès à des fichiers textes standards (exemple : recherche plein texte, tri selon différents critères, etc.). Le désavantage est qu'il faut un serveur.

Pour rappel, les bases de donnée ont été inventées pour palier aux défauts des systèmes basés uniquement sur des fichiers ...

Pour moi, un wiki c'est plus que des documents : y'a la gestion des utilisateur, gestion de l'historique, recherche, ...

Faire des sauvegardes : pas de pb. MySQL permet de faire un dump, et d'ailleurs avec les tables au format InnoDB on peut avoir un dump alors qu'on est en train de modifier la base parallèlement. Un p'tit script bash avec sauvegarde de la base + sauvegarde des fichiers (images) et puis c'est tout.

Haypo

Cool, Inotify qui remplace Dnotify pour surveiller en temps réel les événements concernant le système de fichiers

Je vais pouvoir réinstaller famd, le truc qui m'empêchait d'éjecter un cd-rom quand Nautilus l'avait parcouru (=> je killais Nautilus pour pouvoir éjecter mes cd).

Je vais m'amuser avec Beagle du coup ;-)
http://www.beaglewiki.org/Inotify_Kernel(...)

Y'a d'autres outils sympas dans ce genre là ?

Haypo

Oué, quand un CPU est bogué (oups), il faut rapatrier tout ça en urgence. Ca coûte bonbon. Voir le bug de la division dans les Penitum ...
http://fr.wikipedia.org/wiki/Bogue_de_la_division_du_Pentium(...)

Bon, apparement pour l'instruction FDIV bogué (Pentium < 100 MHz), seules les personnes ayant demandé le remplacement ont reçu un nouveau CPU. Et comme le bug apparait que dans des cas particuliers, ça touchait pas grand monde.

Pour la petite histoire, lors du passage au Pentium, Intel a développé un calcul optimisé avec une table de précalcul pour la division. Malheureusement cette table était erronée (genre une ou deux valeurs fausses, arf). Du coup, l'arrondit du résultat n'était pas bon. Quand on aligne de nombreux de calculs, ça peut faire des dégats (genre un missile qui se gourre de cible).

Haypo

Mon but serait d'avoir un moteur de jeu capable d'accueillir Wormux, mais j'en suis très loin. Je vais commencer à me faire les dents sur des trucs plus softs comme Gorillas, jeu de Dames, Awalé avant d'attaquer un truc aussi gros que Wormux.

Si ça se trouve, je n'y arriverai jamais, mais ça pourra servir pour d'autres jeux ...

Voir aussi mon commentaire sur la news sur Wormux 0.6 beta :
http://linuxfr.org/2005/08/25/19460.html#619130(...)

Victor

-des worms ... on a des peieuvres, des aliens mais pas des worms.

L'image suivante te dit rien ?
http://www.wormux.org/skins_non_free/images/worm.png(...)

Skins non libres (les données sont libres, mais c'est carrément trop ressemblant au jeu original) pour Wormux :
http://www.wormux.org/fr/skins_non_free.php(...)

(y'a aussi les personnages de Mario Bros, les Schtroumpf, etc.)

Haypo

ClanLib 0.7.8 n'est pas PPC-friendly. Un autre linuxfrien a écrit des patchs, contacte-le (encre) :
http://linuxfr.org/comments/615998.html#615998(...)

Haypo

Salut,

Je suis à l'origine du projet HappyBoom lancé en avril 2005. Le but est d'écrire un nouveau moteur de jeu qui serait utilisable pour Wormux. J'ai TOUT remis à plat, et j'ai essayé de ne plus reproduire les même erreurs :
- Langage Python plutôt que C++ : je trouve que le temps de compilation (et de débogage) est trop important avec C++. Et Python est tellement sympa
- Le jeu est découpé physique en trois partie : logique du jeu (server), entrée clavier/souris (input) et affichage (view).
- Génie logiciel : je sais pas si je vais survivre à la torture de Damien (l'autre développeur), mais on va essayer d'écrire de vrais documents de spécification AVANT de coder :-)
- Le réseau est la première chose qui a été développée (et non la dernière)
- SVN plutôt que CVS (on me dit dans mon oreillette que Wormux a aussi fait le bon choix tout récement)

Il en ressort de nombreux avantages :
- On peut écrire des clients dans de nombreux langages et avec divers librairies (ex: client en Perl utilisant GTK, client en Python utilisant pygame, etc.). J'aimerai tenter l'expérience d'être capable d'avoir plusieurs "vues" d'une même partie en texte, 2D et 3D simultanément. C'est possible pour d'autres types de jeu (Awalé, en cours de gestation), mais peut-être pas pour Wormux (trop axé sur le rendu 2D).
- On peut avoir un serveur décentralisé (serveur "dédié"), mais aussi avoir client+serveur sur le même PC
- On peut imaginer des clients "fantomes" qui ne font que visionner une partie sans interagir (pour voir une finale sur écran géant par ex.)
- Une intelligence artificielle s'intègre super facilement vu que le client envoie des actions (genre "tirer", "changer d'arme", ...) plutôt que des touches claviers. Et vu qu'en plus on peut utiliser n'importe quel langage, on peut imaginer une IA sur un PC dédié écrit en Prolog ou autre langage plus orienté IA ;-)

L'écriture d'un client est simplifiée par le fait qu'il peut ne pas gêrer toutes les fonctionnalités (ex: ignorer tout ce qui concerne le chat). On lui envoie également que le strict nécessaire. Un client "IA pure" ne recevra rien concernant le rendu à l'écran par ex. => économie de bande passante.

Aujourd'hui, HappyBoom, c'est :
- un jeu "BoomBoom" presque jouable : crée pour tester le moteur, et surtout la partie réseau (ce qui m'a obligé à passer par UDP pour garder une bonne fluidité dans le suivi d'un objet en mouvement constant)
- un site web MediaWiki
- un document de spécification version 0.2 toujours au stade de brouillon
- une marmite d'idée qui bouillone

Les deux développeurs étaient en vacances, mais ça va beaucoup s'accélérer vu qu'on va se retrouver (je prend un appart au dessus de Damien) et que j'ai enrolé un 3e développeur (à vérifier) ... J'ai pensé à un jeu Awalé, ça serait sympa ça (j'ai une idée d'IA costaux en tête). Et peut-être aussi un jeu de Dames ...

Site web de HappyBoom (on s'est fait plaisir, on s'est pris un .org chez OVH) :
http://www.happyboom.org/Accueil(...)

Pour les développeurs :
http://developer.berlios.de/projects/happyboom/(...)

Haypo

SDL est largement testé et maintenu. Ce qui est loin d'être le cas pour ClanLib.

SDL est multi-plateforme. Ce qui est loin d'être le cas de ClanLib (ex: Mac OSX, cf. quelques commentaires plus haut).

SDL est performant en 2D sans accélération matérielle. ClanLib 0.7+ oblige l'utilisation d'OpenGL (la détection de l'accélération matérielle est boguée pour les pilotes proprio d'Ati et Nvidia d'ailleurs) et est inutilisable en rendu "logiciel".

Il existe de nombreuses contributions pour SDL, comme par exemple le rendu de police TTF.

J'ai cru en ClanLib très longtemps, car l'idée est géniale : couche au-dessus de DirectX, SDL, et autre (multi-plateforme & multi-librairie graphique), API génialissime, etc. Mais le développement est très lent, donc inutilisable pour un jeu.

Haypo

Il parait que c'est a cause de la clanlib

ClanLib est à l'origine de nombreux problèmes, mais c'est quand même pas TOUJOURS sa faute :-) Pour le cas du segfault en quittant, la faute est partagée. ClanLib est un peu trop optimisé. Du coup, il manque deux-trois if pour les cas un peu tordus. Ici, on détruit d'abord l'objet "écran" et après les objets graphiques. Or, les objets graphiques ont besoin de l'objet écran lorsqu'ils sont détruits. Bref, ça bloque.

La faute du côté de Wormux est qu'il faudrait détruire manuellement chaque objet graphique (faire image = CL_Surface(); => objet vide, pointeur NULL à la manière ClanLib) avant de détruire l'objet écran (CL_Display::deinit() je crois bien).

D'ailleurs, Wormux a tendance à conserver trop longtemps les objets graphiques en mémoire. D'où une consommation excessive de la mémoire vidéo. Problème corrigé dans la derniè version béta si j'ai bien compris.

Haypo

Merci pour les critiques, c'est toujours d'en avoir ;-)

- dans un terain en plain air, le joueur ne devrait pas mourrir lorsqu'il sort du terrain ... et on devrait pouvoir scroller avec une suffisament grande marge sur les cotés et le haut(...)

Y'a un pb de conception là. Tout ce qu'ont voit à l'écran est en fait une très grosse image (ou plutôt deux : avant et arrière-plan). Il faudrait retoucher un peu le code pour ça.

- il manque l'eau qui permet d'avoir de la marge vers le bas pour pouvoir scroller ... et mieux voir l'action

C'est pas très clair. Il y a déjà de l'eau dans Wormux (terrain Grenouilles par ex.).

- remarque déja faite mais parfois on ne sait pas quel ver est en train de jouer car il est hors-caméra

Par défaut, la caméra suit le personnage actif. Si on scrolle manuellement, il n'y a plus de "tracking". Il faut retaper "C" pour réactiver ça.

Haypo