MrTout a écrit 559 commentaires

Mais non, c'est de la haute technologie ergonomique : t'es pas obligé de fermer le pop-up de réponse.

Pour moi qui suis qu'un pauvre ignare, c'est quoi Struts, Cocoon ou XSLT ?

Il y a Winamp 2.81 qui est plus leger http://classic.winamp.com/ Sinon tu peux tester le (re)nouveau de winamp avec la vestion béta de winmap 2.9 http://www.nullsoft.com/cookie/ PS : J'aurais bien proposé xinf mais des tas de gens l'ont fait et je le trouve pas si formidable que ça (mon avi personnel a moi).

Celui-la ? http://www.contrib.andrew.cmu.edu/~tmartin/senken/ Ben, non j'ai pas de modeles 3d libres mais si je peux me permettre juste une petite remarque : pourquoi faire un ville avec des batiments ? Le logiciel libre ne serait-il bon qu'a la recopie ? Quitte a faire un simcity-like, autant essayer d'introduire une sorte d'originalite dans l'univers et les graphisme. Enfin, bon, c'est juste une vague idee comme ca...

Chez un marchand de carte postales à Hanoi par exemple...

Plus serieusement je ne sais pas mais ca m'interesse aussi.

En règle générale, ce n'est pas une bonne idée de faire partie d'une minorité ethnique. Ca ammene que des soucis.

Oui mais peut-être signaler sur la page des journaux un niveau de vote et masquer le contenu si <0 (avec un score un peu plus elevé que 1 par défaut).

Ainsi il a toujours le droit de s'exprimer, il est même toujours en première page des journaux.

enfin, bon, c'est juste une idée comme ça.

Oui, et tous les pays qui on un moineau, un canard ou un manchot comme symbole sont pacifiques.

Comme quoi, on a bien fait de rendre les aigles une espece en voie de disparition.

Mais ! J'y travaille a ton concours, et evite de trop faire du pub bon sang ! J'aimerais gagner le gros lot par absence de concurent.

PN: J'ai quand meme fait circuler l'affiche du concours dans le labo au cas ou...

Je suis bien d'accord mais mon post était en grande partie ironique.

Globalement, un post bien argumenté est plussifié mais en règle génerale, il suffit d'un post mal argumenté sur un avis qui déplait à une majorité pour se retrouver à -213/#234 alors qu'une aussi mauvaise argumentation sur un avis dont une majorité de gens est à priori d'accord pour avoir des bonnes ames qui plussifient les moins, genre 1/#5

Par exemple si je dis :

"Le logiciel libre c'est bien car cela permet une coopération sans limite entre les developpeurs mais aussi une réactivité incroyable des projets vis-à-vis des bugs, trous de sécurité et ajout de fonctinalité"

et si je dis

"Le lociciel propriétaire c'est bien car cela permet a une entité dirigeante de planifier les efforts, d'imposer une vision globale et coherente d'un système et de réduire l'energie perdu à faire des taches redondantes"

Les deux ne sont, amha, pas vraiment argumenté (mais sont quand même un peu logique). Je pense que les linuxfriens n'auront pas le meme comportement au niveau des + et -

Mais je peux me tromper.

oulla ! qu'on ne prenne pas mal mes propos.

D'une part je pense que jeu video ne doit pas etre synonyme de 3D. Il existe des tas de bons exemples de jeux formidables* qui sont en 2D et je pense (mais je peux me tromper) que l'argument marketting de la 3D a toutes les sauces n'a que peu d'impact pour un jeu sans considération commerciales (je n'oppose pas ici libre a commercial, les trolls dehors).

Et d'autre part, la prise en charge de l'acceleration 3D est pas un point fort de Linux (il me semble que d'autres plateformes libres sont encore moin bien lotis).

Malgrè ces deux points, j'ai l'impression que tous les projets de jeux qui me semblent inovants ou ludiques sur mon pingouin préféré sont en 3D (là encore c'est peut-être simplement une impression)

Bien sur, en contre partie, avoir une offre forte de lociciels efficaces en 3D pourait eventuellement inciter les fabriquants à donner les informations sur le materiel mais je ne pense pas que cela la raison principale du choix de la 3D pour tous ces projets

* de Heroes of Migth & Magic à Final Fantasy (avant le 7) en passant par Frozen Bobble et Bomber NIAC.

oin !

Pourquoi les jeux demandent plein de 3D alors que les drivers de cartes graphiques qui gerent l'acceleration materielle sont pas libres (au mieux) ou n'existent pas (au pire, et c'est mon cas) ?

J'ai vu des images dans le meme genre. mais qui nous dit que c'est pas un theme quelconque...

De toute facon c'etait pour faire de l'identification visuelle sur des photos satellites, pas pour guider des missiles ou jouer a frozen bobble (bobble ou bubble, je sais jamais)

T'as qu'a poster des messages consensuels ou au pire ne risquant de ne déplaire qu'a une minorité de gens.

Et puis en regle génerale : ne jamais écrire en majuscules, ne jamais critiquer le travail des gens et ne jamais utiliser trois fois de suite le mot jamais.

Si le monsieur il te dit qu'il est un gros nul en informatique, il doit mieux le savoir que toi bon sang ! C'est dingue comme certaines personnes ne peuvent pas accepter le point de vue des autres.

"(j'ai trouvé http://www.linuxgraphic.org/ qui est pas mal) " Tu as du chercher bien loin :p N'empeche, il faut du mérite pour trouver quelque chose qui est en permanance en haut de (preque ?) toutes les pages web d'un site...

Moi je m'envois des mails

$ mail memo
Acheter du pain
.
$

Les végeta*iens c'est comme beaucoup de choses, on tombe facilement sur des extrémistes pour qui seul compte le dogme et pour qui les gens doivent être convertis de gré ou de force (évangélisés ou répendus). Et malheureusement c'est ceux qui crient le plus fort :(

Il en va de même pour des tas de choses, de la religion aux logiciels libres. On trouve des extrémistes (et des méchants) partout. Mais le végéta*isme touche de près à la vie, la mort et la souffrance ce qui, amha, rend les extrémistes encore plus suceptibles et convaincus de la justesse de leur dogme.

La très grande majorité des végéta*iens respectent le choix des autres, parfois essayent d'exposer leur point de vue avec calme et sans brusquer les gens et en exposant leur vision des choses sans considérer qu'elle est parfaite et la seule digne d'être.

ooops, excuse, j'ai compris ton post precedent comme un cochon.

"substitution => contravariance "

Je suis d'accord avec toi. Mais je voulais éviter de tomber dans des regles de typages fonctionelles. Les fonctions n'etant pas des objets de premiere classes dans Nosica, je ne pense pas qu'il soit necessaire de sortir l'artillerie lourde :)

par contre je comprend plus le

"surcharge => covariance"

je vois pas le sens de "surcharge" au niveau des types... mais il est tard, ceci expliquant peut-etre cela.

ben, il me semble que le typage reste fort sauf que le systeme de type décharge sa responsabilité sur l'utilisateur.

OCaml est pas un langage tout objet il me semble (je ne le connais pas bien du tout). En regardant en diagonale j'ai juste vu une implementation des objets lourdingues et intégré à la va-vite. Il m'en est reste un impression de "Oui, nous aussi on fait des objets, on est Aware !" mais je peux (j'espere) me tromper.

Covariance

class Animal { foo(Nouriture) }
class Vache { foo(Herbe)}
Animal :> Vache et Nouriture :> Herbe d'ou covariance car le sens de :> est le meme

:> est le symbole du sous-typage. moyen memotechnique 1 : le sens de la flèche est inverse de celui des graphes UML. moyen memotechnique 2 : le sens est celui de l'intension (avec un s) c'est-a-dire le nombre d'instances (les instances de Vache sont aussi instances de Animal).

Contravariance (exemple pas réel car le monde réel ne l'est pas) :

class A { foo(Herbe) }
class B extend A { foo(Nouriture) }

On a A :> B mais Herbe <: Nouriture d'ou contravariance

Invariance

class Animal { foo(Nouriture) }
class Vache { foo(Nouriture) }
On a Animal :> Vache et Nouriture = Nouriture donc invariance


Euh, sinon mon avis sur nosica.

1) Eviter de faire la meme grosse erreur que Java : tableaux pas homogenes avec le reste du langage. les tableaux en java c'est ni un type primitif, ni un objet et en plus il est covariant (alors que le reste du langage ne l'est pas)
j'avais un exemple mais je le retrouve plus

2) Un truc qui est bien en general est d'unifier la syntaxe attribut / methode sans parametre.
ecrire a.foo au lieu de a.foo()

3) Eviter d'etre trop verbeux si l'objectif n'est pas de faire un langage de production (ada, eiffel)
Je veux dire ne pas devoir ecrire de choses redondantes ou de declarer des choses un peu inutiles

4) faire sauter le ; en fin d'instruction. c'est une honte de trainer encore ca.

5) avoir une reflection plus profonde pour que le langage ait quelque chose en plus. :)

substitution => invariance

la vrai implémentation de la contravariance pose les memes problemes que la covariance au niveau de la surcharge statique...

En fait, tu connais l'Invariance, la Contravariance n'est implémenté ni dans C++ ni dans Java car cela n'est pas sémantiquement utile.

Contravariance signifie que les paramètres se spécialisent dans le sens contraire du receveur. C'est vachement bien au niveau de la théorie des types mais ca n'a aucun interet :p

A propos, pour finir l'explication, la covariance du type de retour est type safe et est d'ailleurs dans la norme de C++ (mais pas en Java, pourtant en Java ca coute rien a implémenter à cause de l'héritage simple. En C++ c'est beaucoup plus difficile mais tu peux essayer avec g++ par exemple de redéfinir le type de retour d'une méthode pour avoir un résultat amusant (plus un message d'excuse qu'un message d'erreur))

Sinon, dans la pratique pure. ben, des fois c'est plutot pratique de pouvoir spécialiser les paramètres et surtout les attributs. Ca évite bien des casts inutiles et des déclarations de variables intermédiaires temporaires.

La surcharge statique est d'après certains le coté obscur de la force, plus facile, plus pratique, etc... mais c'est sur que cela rend plus difficile l'implementation de la covariance.

Ben, que cela soit par covariance ou par cast, les erreurs de type sont inévitables.
Mais on peut toujours prévenir à la compilation via des méthodes globales :
- si l'erreur de type est systématique : signaler une erreur
- si des erreur de types sont potentielles : compiler un test de type, si ca passe pas, lever une exception au runtime
- si aucune erreur de type est possible : pas besoin de compiler un test de type

SmartEiffel à une bonne approche de la chose avec des options de compilation pour choisir un niveau de compilation entre sécurité et efficacité du code compilé.

Le 2nd probleme que pose la covariance et qu'elle est incompatible avec la surcharge statique (des methodes de meme nom mais de signature differente, foo(int) et foo(string) par exemple)

D'ailleurs, de nombreuse personnes n'aiment pas la surcharge statique car la sélection de la méthode a appliquer dépend du type statique des paramètre et non du type dynamique.

class A {
foo(Animal) {}
foo(Vache) {}
test() {
Animal a = new Vache;
foo(a);
}
}

et c'est un argument qui peut se valoir selon moi.

"Oui bon, effectivement, les methodes, les boucles ne sont pas objets. Quand je disais tout, je voulais dire les objets..."
Donc, tu veux dire pas la que tous les objets sont des objets... hum, je comprends :)

"Ceci dit je ne vois pas trop pourquoi ca va rendre inutile la genericite"
En Eiffel on peut ancrer les types sur des features (attribut ou retour de fonctions) ce qui fait des trucs du genre

class Pile {
public:
like element pop() {return i>0 ? tabl[i--] : NULL;}
void push(o: like element) {}
private:
Object element;
int i;
like element tab[12]
}

class PileDAssiettes extend pile {
private:
Assiette element;
}

Bon, c'est un exemple un peu moyen mais c'est pour montrer l'idée.

sinon ton argument pour la delegation est pas mal :p