TImaniac a écrit 6420 commentaires

En fait le WMP9 pour Mac gère les DRM, MAIS, il y a un mais :

http://www.microsoft.com/windows/windowsmedia/FR/software/macintosh(...)

liste complète des codecs pris en charge
Codecs audio

* Codec Microsoft Windows Media Audio versions 1.0, 2.0, 7 et 8
* Codec G.726

Codecs vidéo

* Codec Microsoft Windows Media Video versions 7 et 8
* Codec Microsoft Windows Media Screen versions 7 et 8
* Codec Microsoft MPEG-4 version 2.0 et 3.0
* Codec vidéo ISO MPEG-4 version 1.0


Les plateformes musicales sont basée sur le codec WMA9...

Ce que vois Virgin c'est ses intérêts, et il voit donc celui de ses clients : le fait est que la compatibilité avec le maximum de périphérique est primordial, sinon le consommateur ne va rien comprendre. Pour celà je suppose qu'ils ont logiquement envisagé de fournir de la musique au format WMA pour les Windowziens et au format AAC pour les Maceux (rien pour les Linuxiens puisqu'il n'ya pas de solutions DRM pour eux). Apple veut garder l'exclusivité sur ses OS (il n'y a pas de support des DRM WMA sous Mac) et Matos, ce que conteste fortement Virgin.
Effectivement ce sont les clients qui en font les frais, mais indirectement ce sont aussi Virgin et Apple puisqu'ils risquent d'en perdre, Apple préférant la solution monopolistique qui risque de ne pas tenir bien longtemps. D'ailleur je prédis que Apple va bientôt vendre des licences ;)

Pas spécialement, le format en soit est universel puisqu'il peut être utilisé par tous le monde et par tous les fabriquants (moyennant licence bien entendu). Si certains fabriquant ou OS ne désirent pas acquérir de licence c'est leur choix.
le "100% compatible" ne veut rien dire puisque ce n'est pas précisé compatible avec quoi.
Après c'est marqué nulle part que le site est 100% compatible.
Voilà je penses qu'ils savent y faire dans le service marketing pour faire en sorte que le message passe sans se faire enmerder pour publicité mensongère.

Je vois ce que tu veux dire, mais dans ton exemple n'importe quel andouille est capable de comprendre qu'elle va bientôt acoucher :) Pour le WMA c'est pareil, le client de base va comprendre qu'il y a beaucoup plus de chance que celà marche qu'avec la solution iTunes.

j'ai une idée : moi je commence par la fin parcque là on arrête pas d'entrer en conflit :)

quand tu peux te permettre de t'acheter un mac, en général tu prend un iPod... Me semble que les utilisateurs de Mac sont au moins autant fanatique que les linuxiens :)
Bref, je penses que ca représente vraiment une infime partie du marché.

euh, réfléchi, lors des négociations Apple te refuse des licences pour utiliser leur format et donc leurs iPod... T'as vraiment envie de faire un site compatible avec leurs clients ?

Disons que sur le marché des lecteur audio numérique, on peut dire que effectivement le WMA est le seul truc pleins de DRM qui soit à peu près universel. En tout cas il est présent sur la plupart des lecteurs récents qui lisent également les mp3. Je penses que PackardBell clame celà pour la même raison que Virgin qui râlent après Apple qui refuse de voir autre chose que le iPod le concurrencer.
Le WMA a quand même l'avantage d'être utilisable par n'importe quel constructeur, et ceci moyennant une licence pas cher si mes souvenirs sont bons par rapports aux autres formats (Apple refusant de céder des licences).
Après effectivement il y aura toujours une minorité, cad en l'occurance les linuxiens, pour râler. Mais faut dire ce qui est : ils veulent des DRM (les acteurs du marché, pas le public), et il n'y a rien qui tourne sous Linux comme alternative (enfin pas qui soit libre ou au moins gratuit à ma connaissance).
Donc effectivement Packardbell a tord, le WMA n'est universel qu'à 90%.
Par contre peut-être que cette exception linuxienne ne tiendra pas longtemps, il me semble que Linspire s'est acquitté de licences pour utiliser les formats Windows Media sous Linux... Là effectivement on pourra râler sur le site de VirginMega ou PackardBell, mais en attendant voilà quoi :)

Bah oué c'est ça le problème, c'est que ca marche avec certaines clé mais comme par hasard pas avec la mienne :-/

oué effectivement mes conseils ne change pas grand chose à tes problèmes :)
Pour les fonctions, ne pas les mettres dans un .h surtout, ça ne sert pas à celà :)
Le corps des fonctions dois toujours être placé dans des fichiers .c. Dans le .h tu déclare juste les prototypes.
Je m'explique :
dans fonctions.h :
void mafonction(int a); // c'est juste une déclaration (.h --> header --> en-tête)

dans fonctions.c :
#include "fonctions.h" // j'indique ici les déclarations histoire que le compilo vérifie que ca colle bien

void mafonction(int a){
ici je fais le boulot
}

dans autre.c :
#include "fonctions.h" // j'indique ici que je veux utiliser les fonctions dont les signatures sont dans fonctions.h

à la compilation :
gcc -c fonctions.c --> créer le module compilé fonctions.o
gcc -c autre.c --> créer le module compilé autre.o
gcc -o monprogram fonctions.o autre.o --> créer le programme final à partir des 2

Un conseil, achète un bouquin de C ;)

Pour ce qui est de l'IA, il existe des algo sur le net déjà écrit en C... je penses que tu pourras les utiliser. Voici un exemple de code source de programme d'échec :
http://tict.ticalc.org/downloads/Chess-5.00.zip(...)
http://tict.ticalc.org/downloads/crafty179.zip(...)
tu as surement moyen de réutiliser les algos...

sinon l'algo le plus simple, algo du minmax :
- tu calcules tous les coups possibles et tu prends le meilleur. (manger une tour est meilleur que manger un pion, etc. : il faut classer les coups)
- tu calcules la même chose pour le coup de l'humain en ayant supposer un coup pour la machine : celà te permet d'aller voir un coup en avant, d'anticiper. Tu peux normalement faire celà de manière récursive sur n-coup pour anticiper le plus loins possible dans le temps, avec toujours à chaque fois la même technique : tu choisis le meilleur coup que tu es trouvé.

essai de mieux structurer ton code, et de bien te mettre à la place du programme :
par exemple tu fais plusieurs comparaisons à la suite comme ca :
if (coup[0]==84) piece=2; /*ici une tour*/
if (coup[0]==67) piece=3; /*ici un cavalier*/
if (coup[0]==70) piece=4; /*ici un fou*/
if (coup[0]==68) piece=5;
etc.
ton programme va faire chaque test à chaque fois alors que toi tu sais qu'il n'y aura qu'un seul cas de possible...

tu peux améliorer en faisant celà :
if (coup[0]==84) piece=2; /*ici une tour*/
else if (coup[0]==67) piece=3; /*ici un cavalier*/
else if (coup[0]==70) piece=4; /*ici un fou*/
else if (coup[0]==68) piece=5;

ou encore plus propre :
switch(coup[0]){
case 67: piece=3;break;
case 70: piece=4;break;
case 68: piece=5;break;
etc.
default://met ici les autres cas bizzare.
}

tu peux ajouter de la lisibilité plutôt que de mettre des commentaires, par exemple :
au début du programme :
#define TOUR 84
#define CAVALIER 67
#define FOU 70

et dans le code :

switch(coup[0]){
case TOUR: ...
case CAVALIER: ...

etc.

sinon la boucle infinie, tu peux mettre while(1)

un dernier conseil : essai de faire des fonctions pour bien séparer les différences parties de ton code.

Avec tous ces conseils tu devrais déjà avoir un code plus lisible et beaucoup plus facilement débuguable !

Tu sembles débuter en programmation, mais surtout ne te décourage pas, on est tous passsés par là ;)

oué enfin on est rendu au 2.6.8 et le bug est répertorié depuis un moment dans le bugzilla du kernel...

Je partage ton avis pour certains point :
je branche ma clé usb sur un kernel 2.4.X : nickel
je branche la même clé sur un kernel 2.6.X : DTC.
on a parfois l'impression comme ca d'aller en arrière, mais au moins on cherche à comprendre pourquoi et on apprend pleins de trucs :) Bon à l'arriver la clé marche toujours pas mais bon :-(

Alors DocBook est pour toi, car il passe par un fichier TeX avant de générer un PDF, PS, etc.
il me semble que c'est le format FO qui sert de format intermédiaire, pas TeX. En tout cas c'est ce que font les feuilles XSLT officielles de Norman... ensuite un coup de FOP et zou on a un PDF.

en même temps Mozilla n'a jamais été une référence dans le support XML/XSLT...

DocBook répond à toutes tes attentes :
c'est fait pour les documents scientifiques
c'est 100% XML
c'est vraiment orienté contenu, beaucoup plus que LaTeX qui mélange encore un peu de présentation
c'est extensible au MathML et SVG
tu peux te faire une feuille de transformation XSLT --> LaTeX si ca t'amuse.
après pour les outils je te conseille d'utiliser DocBook Tool Chain Manager qui gère tout de A à Z à la seule condition que ton document XML soit en UTF-8.

et cerise sur le gateau, bien que je n'ai pas essayé :
DocBook to LaTeX using Perl
http://dblup.sourceforge.net/(...)

- Microsoft est une entreprise
- Bill Gates est un humain
Leurs buts ne sont pas les même, et les pratiques non plus.

- Il ne faut pas dire que Microsoft c'est bien parcque la fondation Gates fait dans l'humanitaire
- il ne faut pas dire que Gates est un connard parcque ca boite a des méthodes peu scrupuleuses.

Le service Pack 2 qui débarquent dans 2 semaines va changer ce comportement par défaut.

Moi y'a quelquechose qui me turlupine :
- SuSE est orienté KDE (en tout cas c'est l'environnement mis en avant, un peu comme Gnome sous RedHat)
- Ximian est orienté Gnome (que ce suit Ximian Desktop bien sûr, ou encore Red-Carpet et surtout Mono)

Alors quand ils disent :
nous allons regrouper le meilleur de Suse Desktop et de Ximian en un même produit

Quesqu'ils vont nous pondrent à votre avis ?

Concrêtement ? Réutiliser une classe (par exemple je veux me faire un contrôle personnalisé) et changer l'implémentation d'une méthode...
Je fais un contrôle MonButtonAmélioré
celui qui considère que c'est un bouton de base, il aura accès aux méthodes comme si c'était un bouton, la classe bouton n'ayant pas autorisé la virtualisation, l'utilisateur n'est pas perdu. L'utilisateur qui considère que c'est une instance de MonButtonAmélioré appelera ma méthode qui fait des trucs en plus, et là il saura à quoi s'attendre puisque c'est lui qui a demandé explicitement une référence vers cette sous-classe.
En gros je crois qu'il faut voir celà comme ca :
1 - tu peux toujours redéfinir une méthode dans une classe qui hérite d'une autre
2 - soit la classe mère veut que ce soit la classe fille qui définisse une méthode précise, auquelle cas le développeur la met virtual. Sinon dans tous les autres cas le comportement ne change pas, il faut que le développeur fasse une référence explicite au type exacte de la classe pour obtenir le comportement différent si c'est une classe hérité avec une méthode new.

On retrouve le même principe pour les interfaces :
class A : InterfaceB {
interfaceB.methode(){

}
}
là il faut utiliser explicitement une référence à l'intefaceB (par exemple (new A() as InterfaceB).methode(); ) pour pouvoir en utiliser une méthode.
Je trouve à la limite ce comportement plus cohérent pour l'utilisateur...
Imagines le cas suivant :
class Véhicule{
private nom = "voiture" //ca pourrait évoluer
public ToString(){
Console.WriteLine(nom);
}
}

class Mercedes : Véhicule{
public new ToString(){
Console.WriteLine("Mercedes Class A");
}
}

Maitenant on prend toujours le cas où c'est la Mercedes qui est instanciée, mais la référence est pas la même.
Je veux lister mes véhicules pour aovir leur types :
j'obtiendrai en C# quelque chose comme ca en utilisant que des références de

Véhicule :
voiture
camion
voiture
4x4

en Java il obtiendrait celà :
voiture
Mercedes Class A
camion
Ford Focus 1.4l

Bref le new est là pour ne pas brider le développeur qui a besoin d'un nom particulier, mais lui empêche tout de même de changer le comportement qui peut être attendu par l'utlisateur qui ne s'attend peut être pas à une redéfinission de la méthode. C'est celui qui développe la super classe qui décide de mettre virtual ou pas.

tu peux aussi allez jeter un coup d'oeil par là, surtout si tu connais déjà Java :
http://www.dotnetguru.org/article.php?sid=18(...)
sinon tu peux aussi allez chez ton libraire, il existe des peits bouquins à 5-6 euros qui permette d'avoir un résumé concis d'un langage, surtout si tu n'es pas débutant c'est bien pratique et amplement suffisant.

using System;

class MainClass
{
public static void Main(string[] args)
{
A a = new B();
B b = new B();
a.d();
b.d();
}
}

class A{
public void d(){
Console.WriteLine("Je suis une voiture");
}
}

class B : A{
public new void d(){
Console.WriteLine("Je suis une ford");
}
}

on obtient effectivement :
Je suis une voiture
Je suis une ford

Je vois effectivement ce que tu veux dire.
Le compilateur se base sur la définition stricte de a et fait dès lors exécuter d de A. Le compilateur n'a pas tenu compte du véritable type de a. Considérons une instruction if et imaginons qu'en fonction de l'évaluation de la condition, on assigne dans a soit un objet A, soit un object B. Le compilateur lui-même ne peut savoir que a contient réellement un objet B. Ce n'est qu'en cours d'exécution de programme que cette constatation peut-être faite, et, par défaut, le compilateur ne génère pas de code permettant de faire cette constatation. (sinon on aurait les même problème de perfs qu'avec les virtual)
Effectivement celà peut-être troublant, mais bon, ce n'est pas non plus vraiment génant à mon goût... celui qui développe la classe sait explicitement ce qu'il fait, il redéfini une méthode d'une classe alors que normalement il ne peut pas (elle n'est pas virtual), donc celà paraît normal qu'il ne puisse pas en modifier le comportement... Je pense que celà permet de redéfinir une méthode, et, en connaisssant le type exact on peut appeler cette version de la méthode. (pour contourner le fait que les méthodes ne sont pas virtual par défaut).
Enfin perso je me souvient pas avoir rencontrer le problème.

Le compilateur a effectivement accès au bytecode des autres classes... Mais je comprend pas trop comment il peut se permettre de faire des inlines comme ça... la classe qu'il référencie est toujours dans un autre assembly (.dll), et imagine que tu changes l'assembly, par exemple pour réparer un bug, ben toutes tes fonctions inlinées ne vont pas en profiter... Et c'est une situation classique en .NET d'avoir des classes dans des assemblies différentes...
Et puis les scénarios de chargement dynamique au runtime sont de plus en plus courant, ne serais-ce que pour faire une architecture de plugin, on parcourt un assembly au runtime et on créé des instances à la volée... Enfin tout ca pour dire que les cas où le compilateur peut faire son boulot trankilou il est rare...
Je me trompes peut-être complètement :)

qu'entend tu par "changer de configuration graphique" ?

tu as pleins d'infos par là : http://lea-linux.org/reseau/(...)
bon courage et n'hésite pas à mettre la main dans le camboui ;)