Jar Jar Binks a écrit 1200 commentaires

Petit rappel :
http://lists.debian.org/debian-user-french/2002/debian-user-french-(...)
où l'on voit Eurogiciel spammer sans vergogne debian-user et debian-user-french. Sachant que de plus c'est un logiciel non libre (et écrit en Java), ça a bien fait rire.

Rappel : normalement, la publicité sur ces listes est soumise à un don de 1000 dollars à SPI. Ont-ils été envoyés ? (Note : les 1000 $, c'est un gros marronier, tout le monde les réclamant mais personne n'ayant jamais envoyé de facture...)

Et le bug tracking system de chez Debian ?
Au moins, il est parfaitement adapté aux petits comme aux gros systèmes, et son interface est infiniment plus pratique que celle de bugzilla.

C'est très clair. À moins que le portage des drivers OSS vers ALSA soit très facile, il faudra absolument garder l'architecture OSS. D'ailleurs, ça ne devrait poser aucun problème d'avoir les modules OSS et les modules ALSA en même temps, et de laisser discover/kudzu/harddrake/l'utilisateur charger ce qu'il juge le meilleur.

Raaaah, oui, je veux !
Enfin, déjà qu'il n'est pas full OSS-compliant, celui-là... J'espère que l'API d'Alsa permet d'intégrer correctement toutes les fonctions de ce driver sans faire d'extensions à la con.

Ah, merci, je ne savais pas.
Ça doit être bigrement pratique, si c'est aussi bien fait que le reste de la SDL.

Ils ont surtout dit que pour le grand public, ce n'était pas la peine, parce que c'était trop difficile à installer.

Le grand public va donc être conforté dans son utilisation de Windows XP. Espérons pour eux qu'ils n'auront pas à le réinstaller...

ID développe en OpenGL, ça leur permet de porter facilement leurs jeux sur plusieurs plate-formes.

ID est une perle rare.

OpenGL (pour la 3D) assorti de SDL pour le reste est une solution de choix (sinon la meilleure) pour développer des jeux, et ce sur n'importe quelle plate-forme.

Mais le fait est que pour l'instant, les fabricants de jeux ne le font pas, ils font le choix de développer sur une bibliothèque non pérenne, en risquant de devoir refaire complètement leur moteur à chaque nouveau jeu. C'est pour ça que je pense qu'avoir ce genre de bibliothèques est une très bonne chose.

Sauf que SDL, c'est pour la 2D. Effectivement, pour la 2D, ça rend les portages faciles, c'est même plus simple à utiliser que DirectX. Mais il manque l'équivalent pour la 3D : porter un jeu Direct3D en OpenGL est beaucoup plus difficile... Donc les solutions de ce type sont moins intéressantes qu'une vraie bibliothèque universelle, mais elles le sont nettement plus que la situation actuelle ! C'est l'espoir de voir marcher nativement sous linux une large majorité des jeux Windows.

Je crois que voilà la meilleure nouvelle que les gamers sous linux aient jamais entendue. Si ce machin marche correctement, il devrait être assez facilement portable sous linux, vu que les implémentations OpenGL sont plutôt bien écrites.
Après, reste la partie difficile, mixer ça à Wine, et ça serait royal. Le mieux serait bien entendu que les développeurs de jeux sous DX8 utilisent directement ce wrapper pour porter leurs jeux, ça devrait quand même leur faciliter la tâche.

Ah non, ça c'est la voix du démon ! Dieu ne sort pas du chaos, c'est lui qui l'a créé.

cat /vmlinuz > /dev/dsp

Les niveaux de Puzzle Bobble étaient faits d'une façon bien particulière. On a un paquet de niveaux relativement difficiles, entrecoupés de quelques niveaux qui peuvent être finis en 3 coups si on vise bien.

La raison d'être de tout ça, c'est le décompte des points. Il y a moyen de gagner plein de points sur ces quelques niveaux, mais pour les mettre bout à bout il faut finir les niveaux entre les deux sans se planter ! Comme il n'y a pas ce décompte des points dans Frozen-bubble, ça perd de l'intérêt.

Et puis on ne voit pas tous les points qui tombent quand les bulles explosent, c'est bien dommage (de même que la musique... tududum tum tuuuuu dam ! tududum tum taaaaa dam ! Aaaaaaarrrgh ! GnnnararfffffgrzzzziohfZUOau seczoioihZIOH

C'est vrai que la programmation reste principalement impérative. Mais on pourrait distinguer plusieurs formes de programmation impérative. Par exemple, le C a apporté la programmation structurée. Ça représente une très petite différence par rapport au Fortran, mais ça change quand même bien la façon dont on écrit son programme. La programmation objet est une autre étape du même type.

À nouveau, MDI tire à boulets rouges sur les plate-formes de développement actuelles. C'est oublier qu'après tout elles ne fonctionnent pas si mal.
Pour ma part, je pense qu'il serait mieux de continuer à faire de bonnes bibliothèques permettant de programmer à plus haut niveau (la GLib est un excellent exemple), plutôt que de croire qu'on va tout révolutionner en essayant une fois de plus de réinventer la roue. Le côté « réutilisation de code », je n'y crois pas une seconde. Ce sont les bonnes bibliothèques (voire uniquement les très bonnes) qu'on réutilise, pas les bouts de code qui traînent.

Par exemple, Java n'a rien révolutionné. Cette plate-forme voulait prendre le meilleur des langages interprétés et le meilleur des langages compilés, elle se retrouve surtout avec les défauts des deux. Et quand on parle à nouveau d'une révolution dans le monde de le programmation, permettez-moi de garder un regard sceptique. La programmation n'a pas vraiment changé depuis les premiers compilateurs COBOL et FORTRAN. On a juste trouvé des astuces de compilation, des meilleures syntaxes, des meilleures sémantiques, une meilleure gestion des variables...

Bref, si C# est un bon langage, alors faire un compilateur pour ce langage me paraît une excellente idée. Mais je n'en attends pas plus que ce que j'attendrais d'un bon langage.

Meuh non meuh non.

http://www.bewarethesith.com/jar-jar.html(...)

Hop -1.

Le paquet debian est fini, et peut être téléchargé sur :
deb http://www.ens-lyon.fr/~jmouette/debian(...) ./

(il paraît qu'il y a des problèmes avec le firewall et qu'il refuse certaines connexions, je demanderai à webmaster ce qu'il en pense)

À mon dh_make, et que ça saute.

Tu n'as pas plutôt des arguments ? Explique, puisque ça a l'air si génial.

Memes si ces défauts disparaissent progressivement (ca devrait finir par aller plus vite que du code compilé par exemple)

Ce sont des petites marmottes qui vont exécuter le bytecode ?

Désolé de répondre 2 fois au même message, j'ai la tête dans le cul.

Imaginons que t'as une super biblio d'algo en C++ qui te permet de faire des calculs sur des surfaces a n dimensions (genre un truc pousse en math).

Ce genre de systèmes est totalement exclu pour tout calcul numérique. Je te rappelle que pour ce genre d'applications, les performances sont absolument critiques. On ne va pas s'amuser à les foutre dans une machine virtuelle pour gagner 5 minutes sur le développement de la GUI...

Ce que propose .NET, c'est que ce genre de chose n'aura aucun cout.

Outre le coût financier du truc, je me permets de douter qu'une quelconque méthode utilisant une machine virtuelle n'ait aucun coût en matière de vitesse et d'utilisation mémoire.

Admettons (perl c'est fait pour les psychopathes de toute façon).

Mais tu ne m'as pas expliqué l'intérêt, si tu fais un programme en C++ et une interface en python, d'appeler l'interface depuis le programme au lieu de faire le contraire. C'est plus sale et plus compliqué.

Je dois être con, mais je ne vois toujours pas l'intérêt.

"The DotGNU project was originally started in reaction to Microsoft's .NET strategy, for which it will be a complete replacement (and not just a Free Software implementation)."

Donc rien à voir avec Mono, ça veut dire que c'est complètement autre chose, et que ça ne sera pas compatible (et de toute façon, on s'en fout).

Tu peux aussi éviter d'utiliser 15 langages différents, c'est le meilleur moyen d'avoir des tonnes de bugs.

En plus, l'intérêt de réutiliser des classes C++ en Python est assez évident pour moi. L'intérêt de réutiliser des classes python en C++ est totalement nul.