Larry Cow a écrit 5011 commentaires

De manière générale, il a toujours adoré les micro-noyaux :)

On me fait signe que Emma Steed n'a souhaité faire aucun commentaire quant au décès de son époux.

(je sors)

D'après le site, gforge est inclus dans debian unstable.

Pour "rappel", si l'on en croit le sondage ifop disponible sur http://www.jaimemaboite.com/(...(...)) , on a 12% de chances de tomber amoureux sur le lieu de travail. Et faut pas se leurrer, c'est pô en restant enfermé(e) dans la salle machine que ça risque d'arriver !


Ca dépend, on n'a pas précisé qu'il fallait tomber amoureux d'une personne physique. Les rencontres de caramail IRC, ça compte aussi.

Ben en fait, je pourrais éventuellement faire quelque-chose: je suis actuellement coincé sous Windows, j'aime bien python et j'ai fait du C dans mon jeune temps.

Par contre, j'ai pas la moindre foutue idée de comment on peut combiner tout ça sous Windows :/

De toutes façons, j'ai pas vraiment le temps avant au moins un mois, hélas.

Le second LBA était partiellement en 3D. Les intérieurs reprennaient le moteur du premier, alors que les extérieurs bénéficiaient d'une caméra dynamique.

C'est d'ailleurs à mon sens le tour de force énorme de ce jeu: beaucoup de suites n'ont pour seul argument qu'une amélioration technique, et communiquent à fond dessus. Pour LBA2, l'amélioration technique était tellement discrète que, même en ayant énormément joué aux deux, on en vient à se rappeller qu'on avait oublié que les deux n'avaient pas le même moteur. Cette éclipse de la technique par les autres qualités du jeu m'a toujours sidéré.

(oui je sais, c'est pas très très clair tout ça)

En fait, Soya est quasi-parfait. Il ne lui manque plus qu'une toute petite chose (mais si chiante à implémenter): la portabilité sous Windows.

Ca peut paraître bizarre comme remarque, surtout ici, mais tant que celui qui l'utilise s'impose un public limité à celui des utilisateurs de linux/bsd/macosx, ca freinera son adoption.

D'ailleurs, les gens qui tournent autour de Soya, c'est prévu à terme ou pas?

Il y avait un projet visant à recoder le moteur en libre. La dernière fois que j'ai testé, il a près d'un an, permettait de se balader dans le jeu de manière assez réussie. On pouvait se déplacer, changer de mode de déplacement et sauter. Et même filer des mandales aux NPC, si j'ai bonne mémoire. Bon c'est sur que c'est un peu limité par rapport au "vrai" jeu, mais c'était très prometteur. Et puis apparement le développeur a changé de centre d'intérêt, et est parti vers un recodage du moteur d'Alone in the dark.

Malheureusement, le site (yaz0r.net) ou il hébergeait lbarecode ne répond plus. Mais ça pourrait être sympa de regarder tout ça et de voir ce qu'il resterait à faire.

C'est à partir de combien, une ligne longue? C'est pas que j'ai des problèmes de synchro, mais bon... ;)

Quand ils ne s'engueuleront plus sur des questions de syntaxes de code, ils se prendront la tête sur des questions de sémantique UML (ou autre norme de modélisation qui prendrait le relai).

Si tu lis ton code depuis autre chose que ton éditeur, c'est dommage. Typiquement, tu essaies de comprendre un bout de code depuis le viewcvs d'un projet, t'es bien embêté.

Avoir des aides au niveau de l'éditeur est bien entendu une bonne chose, mais (dans ce cas précis) je vois ça un peu comme une rustine, un moyen de combler une défficience du langage.

Le rotor de la centri contient donc des nacelles munies d'emplacements qui peuvent contenir des échantillons. Il y aurait moyen de décomposer un peu plus le traitement, mais je trouve que ça se lit déjà très bien comme ça...

... parce que tu sais de quoi ça parle. Si je te sors un compute_values(str, valx, valy, 0) hors contexte, tu risques fort d'avoir du mal à comprendre la logique sous-jacente (en plus c'est un exemple pris au hasard, mais bon).

Le fait de nommer les paramêtres, que ce soit façon SmallTalk/ObjC ou façon python, permet d'améliorer grandement la lisibilité du code.

En plus, dans le cas d'ObjC, les étiquettes des paramêtres sont pris en compte dans la signature de la fonction. Ca permet une forme de polymorphisme paramêtrique, mais totalement désambiguïsée.

Je dis peut-être une énorme connerie, mais il n'y aurait pas moyen de faire un NSMovie qui encapsule ffmpeg au lieu de QuickTime (ou mieux, GStreamer, mais bonjour les dépendances).

Je n'ai aucune idée de ce que fait le NSMovie de GNUstep actuellement, ni de la charge de travail nécessaire pour encapsuler ffmpeg dedans, mais ça fournirait un moyen relativement portable de travailler avec des vidéos.

Il doit bien y avoir de solides raisons autre que la "paresse" pour que les gens développent gtk+, gnome, KDE, ... alors qu'il y a déjà OpenStep. Nier ce fait, c'est aussi faire preuve "d'une étroitesse d'esprit affolante".

Tu aurais une "solide" raison pour justifier le manque d'intérêt de la communauté pour OCaml? C'est pourtant un langage libre, fiable (typage fort et strict et tout), performant (la version compilée n'a pas à rougir devant C++), souple (possibilité de choisir entre du bytecode, de l'interpreté pur ou du natif), interopérable (via le C, notamment), et j'en passe.

La seule raison que je vois à ce manque d'intérêt, c'est qu'il prône un mode de pensée qui n'est pas beaucoup répandu: le fonctionnel. Sans aller jusqu'à taxer les gens du libre de paresse, il faut bien admettre que quand on n'a pas l'habitude, on a du mal à s'y mettre. Et moi-même, malgré tout l'intérêt que je porte à ce langage, je me tourne de plus en plus vers python.

C'est, il me semble, un phenomène similaire qui frappe Openstep et ObjectiveC. J'ignore quel est l'aspect qui "dérange" (à mon avis, c'est dû à son approche du paradigme objet très éloignée de la vision C++/Java), mais je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.

C'était Gilbert?

(je suis déjà dehors)

Pour Windows, je vais être un peu plus précis (j'ai testé récemment). Ca demande un peu de boulot pour le compiler (via MinGW), pas vraiment à la portée du néophyte. Par contre, si ton but est de packager une application GNUstep spécifique à destination de Windows, ça ne devrait pas poser de problème. Dans l'ensemble, à part quelques bugs agaçants, GNUstep fonctionne de manière similaire à la version Linux.

Par contre, certaines applications GNUstep (GWorkspace, notament) font certaines assertions sur la plateformes sous-javente (en gros, ils considèrent qu'ils ont affaire à un Unix-like). Résultat, ça ne compile même pas sous Windows. Mais c'est, à mon avis, quelque-chose qu'on retrouve surtout dans des applis très liées au système (ce qui, pour moi, est le cas d'un shell graphique).

En fait, la grande question de GNUstep sous Win, c'est son utilité. Du fait des problèmes avec GWorkspace, utiliser un bureau GNUstep complet sous Win n'est pas actuellement envisageable. Et déployer une seule application bien spécifique est rendu un peu délicat par le look "détonnant" de GNUstep.

Cette situation n'est aucunement définitive, et il y a des développeurs soucieux d'améliorer le support de la plateforme Microsoft, et il y a des développeurs (coucou Rio) soucieux d'apporter les thèmes à GNUstep. Mais pour le moment, pour une appli graphique, c'est un peu prématuré.

2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
c'est d'une connerie et d'une étroitesse d'esprit affolante.

Sans compter que c'est grosso-modo l'argument du fan-club des produits Microsoft.

"Franchement, si Linux c'était vraiment mieux que Windows, y'a longtemps qu'on n'utiliserait plus que ça."

Chapeau bas, messieurs.

Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".

Sauf que (au moins pour Caml, je connais pas Eiffel) ce qui "concurrence grandement le C", c'est pas l'aspect objet d'OCaml. Un programme en OCaml contre un programme en C, y'a pas photo.

Oui, il est excessivement prometteur, je trouve. J'ai pas trop de temps à y consacrer en ce moment, mais je compte bien garder un oeil là-dessus ;)

Y'a déjà (au moins) une tentative en ce sens, c'est Unununium. A part le fait que ça démarre à peine et que le nom est particulièrement pas cool à prononcer, ça peut être intéressant.

http://unununium.org/(...)

Dingue ça. Et la VM Java elle est codée en quoi, en REBOL? ;)

Quelle différence avec un cluster "normal" ?

[...]

Quelle différence avec des modules noyau ?

La même qu'entre un langage impératif "classique" et un langage "objet" (oublions C++, à la limite): ça permet de faire la chose, donc pourquoi s'emmerder avec l'objet? Pourtant, on peut pas dire que l'objet soit un concept utopique, on pourrait même croire que c'est assez implanté dans les mentalités (même si pour beaucoup de gens, l'objet se limite à la version statique et gripée de l'objet C++ien)

Il me semble que ça existe... pour le Hurd :)

(je sors)

Si tu avais essayé le soft, tu aurais vu la "fenêtre avertissant". Elle t'explique le pourquoi de la chose, te propose d'envoyer le "ping" ('OK'), de ne pas l'envoyer ('Annuler') et même de consulter les statistiques récoltées.

Si après avoir lu la-dite fenêtre, tu décides malgré tout de ne pas envoyer de "ping", c'est ton droit le plus strict, et personne ne t'en voudra.

MMmmh, garantir une seconde "dans la plupart des cas", c'est effectivement du ressort du Linux moyen. Garantir une seconde "dans tous les cas" (le seul intérêt de la garantie, finalement), c'est déjà beaucoup plus siouxe. Arriver à rendre un Linux plus réactif du tout, c'est encore faisable, il me semble.