alf a écrit 255 commentaires

Avec tout ça, j'ai oublié:

int main(void)

non mais ! ;)
Et comme main est déclarée comme retournant un entier, il est bon d'en retourner vraiment un ! Donc (code non testé):

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>

int
main (void)
{
    char *locale = NULL;
     char *charset = NULL;
     locale = setlocale(LC_ALL, "");
     charset = strchr(locale,'.');
     if (charset == NULL)
     {
         fprintf(stderr, "La locale est %s\n", locale);
     }
     else
     {
         fprintf(stderr, "La locale est %s\n", ++charset);
     }
     return EXIT_SUCCES;
}

Pour me compléter : la locale "C" est la seule définie dans la norme C (pour ce que j'ai trouvé dans le paragraphe 7.11), et elle ne contient pas de point, il serait donc bien de prende en compte au moins ce cas.
Je n'ai pas la norme POSIX sous la main, je ne peux donc vérifier ce qu'elle en dit.

langinfo.h ne fait pas partie du C, il s'agit d'une extension qui peut ne pas être disponible suivant l'environnement de l'utilisateur. La solution proposée par zgnouf et Gérald est la bonne; à une restriction près toutefois : le format de la chaîne retournée par setlocale n'est pas déterminé par la norme C (arrêtez-moi si je me trompe), donc il n'est pas garanti qu'il y ait un point dans cette chaîne. Il faudra donc traiter le cas où il n'y a pas de point séparément (en ajoutant un if (charset == NULL) { /* ... */ } dans le code de Gérald).

D'ailleurs, si quelqu'un sait où le format de la locale est défini (C, POSIX...?)...

en fait,même sans ça, ça compile

Mouais, "ça compile" n'est pas une preuve que le programme soit correct.
main DOIT retourner un int. Point. C'est la norme qui le définit très clairement. Un programme C contenant un main ne retournant pas un entier est incorrect. (je crois qu'en C++ c'est possible, mais en tout cas pas en C).

Ce qui peut changer, ce sont les paramètres de main: soit
int main(void)
si tu t'en fous des arguments, soit
int main(int argc, char *argv[])
si tu en as besoin, soit
int main ( /* autre chose */ )
si tu as envie d'utiliser des extensions fournies par ta plate-forme, mais non portables ("portable" au sens du C).
Les deux premières sont définies dans la norme, et fonctionneront sur toute implémentation du C (enfin, mis à part les cas des freestanding environments, mais on va passer pour l'instant); la troisième est implementation-defined et donc dépend de l'environnement. Par exemple, le
int main(int argc, char *argv[] char *env[])
est une extension commune, qui compilera et fonctionnera sur certaines implémentations, mais n'est pas portable.

Cela dit, un compilateur C a le droit de rejeter un programme définissant main comme retournant void.

Et, en passant, pour compiler un programme C avec GCC, une ligne de commande pour avoir les bons avertissements est
gcc -Wall [ -Wextra | -W ] [ -std=c99 [ -pedantic ]]
-Wextra est défini depuis la 4.0 je crois, avant c'était -W; et -std=c99 est utile (et même recommandé) pour s'assurer que ton code est correct au sens de la norme C99. Note que ce flag désactive certaines extensions (POSIX, GNU ou autres) qui entrent en conflit avec la norme, donc tu ne pourras pas forcément l'utiliser, suivant ce que tu veux faire. Le -pedantic retournant des avertissements supplémentaires de la norme, et rejete toute extension.

En fait, ça fait un moment que je ne l'ai pas lu... et que je n'ai pas touché à make.
Si tu fais référence à l'exemple du paragraphe 7, il ne peut pas compiler les modules ant ou bee séparément; il recompile la cible "prog" en compilant au besoin ce qui a été listé dans SRC et LIBS. Dans son cas, les "modules" ant et bee sont en fait des séparations au niveau source, mais qui permettent d'obtenir un unique binaire "cible".

En effet, si tu veux juste obtenir un seul binaire, tu t'en fiches un peu qu'il recompile tel ou tel module (tant qu'il ne fait que le strict minimum, ce qui est aussi le but de la méthode de l'article).

Si tu entends tes "modules" comme des entités utilisables séparément (ant et bee sont deux exectuables, ou un executable et une bibliothèque, par exemple, et un coup "je veux compiler ant seul", un coup "je veux compiler bee seul"), il faudra une cible par "module".

Je crois, à ce niveau, que l'incompréhension vient de ce que tu entends par "module" n'est pas la même chose que pour l'auteur de l'article: pour lui, un module est un composant intermédiaire, et il n'y a pas de sens à vouloir compiler tel ou tel module, on ne peut vouloir compiler que la cible - ce qui peut nécessiter de compiler tel ou tel autre module si besoin.

Pour organiser le processus de compilation d'un projet consistué de plusieurs modules, il faut faire attention a ne pas faire de make recursifs cf. http://www.pcug.org.au/%7Emillerp/rmch/recu-make-cons-harm.h(...) pour plus d'infos à ce sujet.

Ce que je ne comprends pas, c'est pourquoi, malgré ce papier publié en 1997, qui me semble plutôt convaincant et argumenté, on continue encore à faire des make recursifs... (Je veux dire, à part l'inertie, les "on a toujours fait comme ça"...) L'auteur de l'article se serait-il planté dans les grandes largeurs ? Y a-t-il quelque chose qui m'a échappé et qui invalide son argumentaire ?

J'ai beau lire et relire ton code, autant je suis d'accord pour le traitement pour les entiers (bon, modulo le fait que je ne l'ai pas testé, je suis d'accord sur l'algo), autant je ne comprends pas comment tu veux pouvoir appliquer le même algo à des nombres flottants (quelque soit le type C, d'ailleurs).
Les représentations machine des entiers permettent de prendre des blocs, avec décalages par bits et produits par des puissances de 2, c'est du classique. Mais les représentation machine des flottants... c'est d'un autre niveau, et je ne vois pas d'où tu peux sortir un

while (w --) ret += ((u_quad_t) b[w]) << (w * CHAR_BIT);

pour traiter des flottants...
Je te conseille de regarder plus avant comment le C définit sa représentation des nombres flottants ([1] 6.2.5, 6.2.6., annexe F, et la norme IEC/IEEE qui va bien)... tu verras que c'est très libre comme définition, et que donc un traitement 'binaire' des nombres flottants est loin d'être facile (et je ne parle même pas de portabilité)... Et regarde aussi [2], c'est un doc que j'ai trouvé il y a peu, mais qui est très intéresant sur le calcul flottant (et qui parle assez simplement de la norme IEEE). Ou sinon wikipedia, il doit aussi y avoir de l'info, je suppose...

A vrai dire, je ne sais pas comment c'est représenté en machine, par exemple. dans quel ordres sont mis (ou peuvent être mis) le signe, l'exposant ou la mantisse, ni quelle marge il y a pour les types C associés : la permière page de l'annexe F dit que float et double sont associés exactement à des types IEC, et que long double peut être un parmi plusieurs types IEC, mais je en sais pas comment ces dits types sont définis eux-mêmes - je te laisse le soin de creuser la question... Et, en derniers recours, c'est la doc de ta plate-forme (voire de ton processeur) qui dit comment tu dois faire.

Pour en revenir à ton application, fonctionnellement, pourquoi as-tu besoin de faire de tels traitements ? Ton appli transfère des informations entre différentes machines ? Tu veux parser des fichiers binaires ?

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
[2] http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf

Enfin, le meilleur pour la fin: l'équivalent en floating point ne marche pas... quand je caste b[w] en long double, j'ai gcc qui se roule en position foetale et couine "error: invalid operands to binary <<

Je dirai plutôt qu'il te tape sur les doigts pour avoir essayé une chose infâme. En effet, la norme impose que les deux arguments d'un opérateur de décalage soient des entiers:

6.5.7 Bitwise shift operators
Syntax
1 shift-expression:
additive-expression
shift-expression << additive-expression
shift-expression >> additive-expression
Constraints
2 Each of the operands shall have integer type.

Et de surcroît, dès que je caste mes binaires en float/double ils deviennent tout corrompu de l'intérieur, alors que si je me contente de les copier en tant qu'entier ça passe !

En fait:
memcpy(buf, & monfloat, sizeof(monfloat));
snscanf(buf, sizeof(buf), "%bf", & monfloat); /* foire */
alors que:
snscanf(buf, sizeof(buf), "%bi", & monfloat); /* marche */

Tu peux être plus précis ? Tu obtiens quoi comme résultat, précisément ? Et en quoi ça n'est pas ce que tu veux ?

while (w --) ret += (long long) b[w] << w * 8;

J'ai un doute, là... Tu ne serais pas, par hasard, en train de supposer qu'un unsigned char fait 8 bits ?
Tu définis ta fonction comme retournant un unsigned long long et ensuite tu définis ret comme un long long... Ca tombe bien, vu que le code de ta fonction fait que ret pourra contenir une valeur négative ! (bah oui, s'il y a débordement : overflow sur un entier signé, ça peut faire des dégâts collatéraux) Et la conversion d'un entier signé contenant une valeur négative en un entier non-signé se fait modulo le max de l'entier non signé +1 (cf. 6.3.1.3.-2)

D'où:
unsigned long long ret = 0;
/* ... */
while (w --)
{
    ret += ((unsigned long long) b[w]) << (w * CHAR_BIT);
}
en castant vers un type non signé (c'est plus sûr et évite les comportements indéfinis de certaines limites), et en (sur)parenthésant afin de bien voir ce qu'on fait (toujours faire attention aux règles de priorité des opérateurs...)

J'ai aussi un "invalid storage class" pour _fetch_float() (la même chose qu'au dessus mais avec des casts en fait :) ) si je lui fait renvoyer un long double...

Cf. 6.3.1.4-2; je présume que le domaine de valeurs de long long déborde celle de long double sur ton environnement... et donc, quand tu retournes le contenu de ret, il n'est pas garanti que la conversion se fasse (je n'ai pas trouvé si la norme spécifie que cette conversion doit être ok ou non. Je suppose que c'est undefined...) Ca ne serait pas plus simple de définir ret comme un long double dans ce cas ? Ca éviterait des prises de tête à calculer les écarts entre les bornes de <limits.h>...

void main(void)

main() doit renvoyer un int.
Et, comme main() est censée renvoyer un int, on ajoute

return 0;

à la fin de main()pour signaler à l'OS qu'il n'y a pas de problème. Ou alors

return EXIT_SUCCESS;

qui a la même sémantique (et la même portabilité), mais qui a le mérite d'être plus explicite pour le relecteur (il faut un incldue standard, stdlib.h, je crois).

Il faut régler son compilateur pour être sûr qu'on fait du vrai C. Avec gcc:

gcc -Wall -Wextra -std=c99

est un bon début (ou remplace c99 par c90 ou ce que tu veux, suivant tes besoins). L'option -pedantic est aussi très utile, car rajoute tous les warnings que la norme définit. Voir la doc de gcc pour plus d'infos.

Sinon, passer l'adresse de ton Tab plutôt que Tab est inutile (passer Tab revient à donner un pointeur vers le premier élément de ton tableau, quelles que soient ses dimensions). Mais, si on sait ce qu'on fait (on passe un pointeur vers un tableau, et non un pointeur vers un élément de tableau), alors il n'y a pas de problème ;)

PS:

There are 2 rules of precedence. Multiply before you add and use parentheses everywhere else.

PPS: POSIX spécifie en plus que EXIT_SUCCESS vaut 0, mais en-dehors de POSIX la valeur de la macro peut être quelconque (mais différente de EXIT_FAILURE, évidemment).

offsetof() est définie dans la norme du C...

Autres idées:

http://ramal.free.fr/cc_fr.htm
qui renvoie sur
http://www.csis.hku.hk/~kao/spc/cc_rule.html#introduction
J'ai trouvé d'autres liens, mais peu informatifs...

Le deuxième lien numérote les cases du plateau, mais je pense que le représenter en mémoire sous forme de vecteur de 1 à 121 n'est pas forcément une bonne solution: l'algo qui détermine un coup possible serait très compliqué... Une matrice devrait faire l'affaire: tu perds un peu de mémoire (les coins et une partie des bords ne sont pas utilisés), mais l'algo de déplacement est plus facile à implémenter (et plus rapide probablement), si on fait attention aux bords du plateau. Tu peux considérer que, dans ta matrice, un déplacement à gauche revient à un délacement à gauche sur le plateau, idem à droite, un déplacement en haut sur ta matrice revient à haut-gauche sur le plateau, et prendre la case dans la diagonale haut-droit représente un déplacement haut-droit sur le plateau. idem en bas... C'est bien sûr une représentation, à toi de choisir la tienne (en s'assurant qu'elle soit cohérente (par ex, un coup puis le coup inverse te ramène dans la même case))

Comme je l'ai dit, tu as entre 2 et 6 joueurs, donc tu as 7 possibilités par case. Définir un type contenant un champs de 4 bits serait donc suffisant (je pense que le C++ permet de le faire, non ?). Ensuite, tu établis ta matrice avec ce type comme "base".

Ta fonction d'évaluation doit attribuer le score maximal au plateau où tes 10 cases d'arrivée sont prises par tes propres pions; et un score minimal si un des adversaires remplit son coin. Pour le début, il vaut mieux construire une fonction d'évaluation simple comme je l'ai décrit, mais qui marche; une fois que ton programme fonctionnera, tu pourras la faire évoluer.

D'ailleurs, un petit truc: tu peux créer plusieurs IA dans ton programme. Il suffit de définir un prototype fixe pour ces fonctions, une option de paramétrage de la difficulté, et une fonction appelée par ta boucle de jeu principale qui va appeler la bonne fonction d'évaluation en fonction de la difficulté. (du style: facile -> la fonction f naîve, moyen -> une fonction plus évoluée, difficile -> f plus compliquée, avec plus de demi-coups d'avance). Ca permet, de plus, de faire jouer une IA contre une autre... et donc de vérifier si une IA est plus efficace qu'une autre.

De tête, le prototype peut ressembler à ça:

coup evalue(damier, joueur, profondeur)

où "coup" est le type représentant un coup à jouer, "damier" je te laisse deviner, "joueur" le joueur qui va jouer et "profondeur" le nombre de demi-coups d'avance.

De plus, ça permet de faire en sorte que ta fonction evalue() puisse utiliser n'importe quel algo, même autre-chose que min-max (le paramètre "profondeur" pouvant être utilisé pour régler ton algo d'une autre manière). Tu sépares ta partie IA du reste, donc tu gagnes en modularité. Tu peux même imaginer ensuite une IA pour laquelle une structure de données différente de celle que tu as choisi au départ est optimale: alors la fonction evalue() peut convertir les paramètres dans le bon format de données avant d'executer l'algo "pour de bon". Pas besoin de tout casser le jour où tu auras trouvé la fonction d'évaluation optimale ;)

J'avais fait ça en C pour le othello, en C++ tu peux faire de la même manière en procédural, ou en objet (avec chaque IA représentée par une classe ayant une méthode evalue() )

Oups, pas taper, j'avais lu "jeu de dames", j'avais pas fait gaffe que c'étaient les dames chinoises...

Du coup, il y a un nombre de types de cases un peu différent... 6 joueurs plus la case vide, donc 7 cas, donc quatre bits suffisent.
Et la forme de la table de jeu n'est pas la même, vu que c'est un pavage d'hexagones... Bon, bah tant pis, je m'a gourré. Là, le calcul du déplacement est plus compliqué, en effet.

De plus, la fonction f est un poil plus compliquée: tu as jusqu'à 5 adversaires. Même si tu n'en préfères pas un par rapport aux autres, ça complique un chouia l'algo.

Bon, pour le coup, j'ai ps trop d'idées...

--
alveric qui ferait mieux de lire les questions avant de répondre...

Il y a quelques temps, j'avais dû faire un truc pareil pour le jeu d'othello, j'avais trouvé pas mal de doc sur internet... Je ne sais pas si j'ai encore les liens, mais tu peux regarder sur des sites de jeux de dames (sites de fans, assoc de joueurs...), j'avais trouvé des bouts d'info dessus. Voire des sites d'othello ou d'échecs.

Pour en revenir à ton problème, bah ça dépend. min-max permet de trouver un coup à jouer dans une situation donnée, en maximisant une fonction f, censée indiquer, à partir de l'état de la partie (état de l'échiquier et joueur ayant la main), si la situation est bonne ou pas, en lui associant une valeur numérique.
Le premier problème, avant la structure de données, est donc de définir cette fonction f... et donc de définir ce qui est une bonne situation pour un joueur ! On peut déjà poser qu''elle renvoie +infini pour un échiquier ou le joueur qui a la main gagne, et -infini s'il a perdu. Ensuite, pour les situations où la partie n'est pas encore finie, il faut déterminer si la situation est plutôt bonne (>=0) ou mauvaise (<=0). Et c'est là qu'on doit connaître le jeu, et les différentes stratégies.

Je ne connais pas trop les stratégies du jeu de dames, mais pour montrer à quoi ça ressemble: dans l'othello, la fonction f "naïve" consiste à compter les pions d'une couleur, puis de l'autre, et à faire la différence. f renvoie tout bêtement le nombre de pions à toi moins le nombre de pions à l'adversaire.
Sauf que le nombre n'est pas sufffisant: un seul coup de l'adversaire peut renverser plusieurs de tes pions, par exemple. Ou, avec un peu de pratique, on se rend compte qu'avoir les coins est important. Or, pour placer ton pion sur le coin, il faut que l'adversaire place un pion sur une case à côté; et inversement tu ne DEVRAIS pas, à moins d'y être obligé, placer un de tes pions sur une case adjacente à un coin libre. On aboutit alors à donner une importance relative à chaque case: les coins valent beaucoup plus que les cases qui leur sont adjacentes; le reste des bords vaut plus que les cases du rang interne (pour la même raison). Je suppose qu'aux dames, on peut arriver à des raisonnement similaires. On peut alors donner une valeur (numérique) à chaque case, et la fonction f ferait la somme des valeurs de cases que tu occupes moins celle des cases qu'occupe l'adversaire.
Il faut ensuite savoir si l'importance relative de chaque case peut évoluer en cours de partie (je sais pas si ça existe, on n'avait pas implémenté ça). Mine de rien, c'est important, vu que toutes les données variables doivent être passées en paramètres récursivement dans ton min-max... et donc ça consomme de la mémoire (et du temps pour les copies de données), alors que les données fixes peuvent être crées une fois pour toutes (il existe aussi l'optimisation de ne garder qu'une copie de l'échiquier, et de jouer les coups directement dessus quand tu fais ton min-max, en annulant le coup à chaque retour. On ne l'avait pas utilisée, parce qu'on pensait qu'elle était trop compliquée à coder, mais c'set une possibilité à envisager).

Par ailleurs, au jeu de dames, on a 5 états pour une case: reine blanche, pion blanc, vide, pion noir et reine noire. On peut leur affecter, par ex, des valeurs +N, +1, 0, -1 et -N. Il faut donc aussi choisir la valeur relative d'un pion et d'une reine, le N (en othello, c'était plus simple de ce côté ;-).

On arrive donc à donner dans chaque case deux infos: une importance (numérique), et un état. Et f pourrait, par exemple, parcourir le damier et sommer le produit de la valeur de chaque case par sa "couleur" (ou autre variante).

Au damier, contrairement à l'othello et aux échecs, seulement une moitié du terrain est utile... donc une matrice 10x10 ferait perdre de la mémoire, un bête vecteur de taille 50 peut suffire, sauf que l'algo de déplacement serait un poil plus compliqué. Après, il faut étudier la consommation mémoire vs. le temps de calcul. Même avec alpha-bêta, descendre à 5 ou 6 demi-coups avec othello rend le programme peu "réactif", et ça empire vite (je ne me souviens plus de la complexité exacte du min-max avec élagage alpha-beta, mais c'est beaucoup).
Pour la "couleur" : 3 bits suffisent pour dire si une case est reine blanche/pion blanc/vide/pion noir/reine noire (un bit qui dit si la case est vide, l'autre qui dit la couleur, et le dernier si c'est pion ou reine). Tu peux donc utiliser, par ex:
- un long[5] :un long tient sur au moins 32 bits, si je me souviens bien. Or, 10*3 = 30 bits, tu peux donc coder deux lignes entières dans un long, donc les 10 lignes dans un long[5]. Question mémoire, c'est presqu'optimal, mais ça complique la difficulté d'implémentation (décalages et masque binaires...)
- ou un vecteur de 50 structures avec des champs de bits. La perte mémoire par rapport à la première solution ne doit pas être énorme, et le codage est probablement plus simple.

Pour les valeurs repectives des cases, ça dépend du nombre de valeurs différentes que tu veux donner. Si ces valeurs n'évoluent pas durant la partie, tu n'en gardes qu'une en mémoire, et donc tu n'es pas obligé de rogner des bits de partout ;) Tu prends juste le type C qui est le plus adapté à tes calculs en terme de vitesse (int ?). Si elles évoluent... Tu peux établir à l'avance une liste finie de tableaux que tu crées une fois pour toutes, ce n'est pas beaucoup plus compliqué.

Par ailleurs, ça ne joue pas sur la structure de données, mais la fonction f peut aussi compter le nombre de coups possibles: si tu peux forcer ton adversaire à choisir à chaque fois entre un faible nombre de coups possibles, tu as un avantage sur lui.

Après, mais vraiment après, on peut encore optimiser en gardant en mémoire les résultats d'évaluation (état du damier, joueur ayant la main, nombre de demi-coups calculés), par exemple avec une table de hachage. Mais ça sort du cadre de ta question... (sans parler de l'effet d'horizon, tout ça)

puis pense au controle de retour de malloc ... c rigolo comme fonction.

+1
Et pense aussi à ne pas caster le retour de *alloc()... En C++, c'est une habitude (et même obligatoire, il me semble, je ne connais pas trop le C++) mais, en C, c'est non seulement inutile, mais dangereux (peut cacher le fait que stdlib n'est pas inclus).

On peut imaginer une méthode qui prenne en entrée un java.util.Date et le compare avec des java.sql.Date trouvées dans une BDD... (quoique, vu qu'il y a héritage, ne déclarer que des java.util.Date pourrait suffire. Faudrait que je teste ça, quand j'aurais un peu de temps)

Nan en fait le seul problème éventuel que tu peux rencontrer, c'est des conflits de noms entre des classes qui ont le même nom "court" mais pas le même nom long

Comme la classe Date qui fait partie de java.util et de javax.sql (je donne les packages de tête, c'est peut-être d'autres noms)...

tu dois faire saisie=(char*)malloc(80*sizeof(char))

Non:

saisie = malloc(80)

Car:
1) sizeof(char) fait 1 par définition dans la norme du C.
2) caster le retour de malloc en C non seulement inutile (un void * est casté automatiquement en T*), mais aussi dangereux (ça peut cacher une inclusion d'en-tête manquante).

cf. http://mapage.noos.fr/emdel/

atoi est dépréciée en C99, il faut lui préférer les strto(u)(l)l. (atoi() ne permet pas un contrôle très "fin" des erreurs, c'est le moins que l'on puisse dire...)

Pour l' "ayant droit", je conseille un bon dico (que je n'ai point sous la main présentement) ou un coup d'oeil sur des sites sérieux traitant de la langue française (ce que je te laisse faire).

Sinon, pendant qu'on y est, et no offense meant :
qui règlementeront l’usage de certain logiciels -> certains

ceux qui permettent d’échanger des fichiers et/ou de télécharger, par exemple, les images ISO des distributions GNU/Linux

Pourquoi "et/ou" ? une image ISO est un fichier, non ? (C'est même là une partie du problème: on partage des fichiers, sachant qu'un fichier peut contenir n'importe quoi... mais je n'apprends sûrement rien à personne ici) Je propose plutôt une formulation comme

ceux qui permettent d'échanger des fichiers, comme par exemple les images ISO des distributions GNU/Linux

Encore que la formulation ne soit pas très claire (on pourrait comprendre que "on" réglemente ces logiciels parce qu'ils permettent la distribution de GNU/Linux...)

Or ces projets de lois sont élaborés par des personnes qui semblent totalement dépassées par les technologies informatiques et par conséquent promptes à prêter une oreille attentive au premier venu.

J'aurais mis quelques virgules... Après le "Or", et autour du "par conséquent".

Mais également à préserver les intérêts économiques (...)

Je ne vois pas du tout d'où sort le "à"... Il manque un verbe, semble-t-il ? Idem dans la phrase suivante "Et cela au détriment (...)".

Est-il la peine de rappeler que Le droit à la copie privée est inscrit dans la loi au titre de l’article L. 122-5 du code de la propriété intellectuelle. Et qu’à ce jour, ce droit existe encore ?

On ne met pas de majuscule à un article en milieu de phrase. Ou alors il s'agit d'une citation, et dans ce cas c'est deux points et ouvrez les guillemets. Et encore, le deux-points ne signifie pas la fin d'une phrase, donc je ne mettrais pas non plus de majuscule. De plus, tu construis ta première phrase sur le ton (mode ? forme ? style ?) interrogatif, mais il n'y a pas de point d'interrogation à la fin. Soit tu fais deux phrases, avec à chaque fois un point d'interrogation, soit tu enlèves le point et la majuscule qui suit (et pas de virgule à la place, même si une "virgule d'Oxford" est parfois nécessaire). Et j'aurais mis "et que, à ce jour, (...)"

Est-il la peine de rappeler, que le 4 Novembre 2003

Une virgule est mal placée: "de rappeler que, le 4 novembre (...)" (et on ne met pas de majuscule aux mois en langue française, à moins que je ne me gourrasse).

fut enregistré (...) l’affirmation suivante

Argh ! "enregistrée" !

Y a t-il le moindre précédent

"a-t-il" me semble plus juste.

qui nous laisse, ne serait-ce qu’espérer, qu’une taxe imposée

Virgule en trop ! (voire "virgules en trop")

Comment ce fait-il

Il se fait que ce fait est indéniable.

l’apreté au gain

Il faut mettre l'accent sur leur âpreté.

La difficulté à prouver une infraction doit-elle conduire à la comdamnation par défaut ?

condamnation.
Par ailleurs, je mettrais des traits d'union à hors-la-loi.

la justice française ordonne à l’état de payer

"Etat" avec une majuscule (accentuée qui plus est, mais je suis sous Windows et j'ai la flemme de sortir la table de caractères).

faîtes savoir à nos représentants politiques, que si de telles lois sont approuvées et imposées, alors

Mis à part la majuscule qui est présente en début des lignes précédentes mais absente de celle-ci (oubli ou discrimination délibérée ?), je pense qu'une virgule doit être déplacée après le "que": "politiques que, si de telles lois(...)".

Bon, ces corrections de pure forme très rapidement faites (j'ai lu le texte une fois, et encore seulement par bouts, pour faire cette liste), je m'étonne que personne n'ai tiqué avant moi... Ou alors certaines erreurs sont-elles issues de corrections ultérieures à la première publication ? Ou verrais-je des erreurs là où il n'y en a point ?

Pour le 6e morceau (Scars Prime - Cerebellum Landscapes), le lien vers le fichier ogg est mauvais: il pointe sur un fichier mp3 ! (alors que le fichier ogg existe, j'ai vérifié en tapant l'url manuellement)

Bonne musique, je garde dans ma playlist ;)

Ou un beat-them-all a la Double Dragon ? (ah, souvenirs... Ca nous rajeunit pas, tout ca)

Comme tu as dit plus haut, une balise <second degre> aurait ete utile pour eviter le malentendu... Tu passais d'un texte totalement premier degre, et sur lequel je suis d'accord (quelque chose de bien pouvait sortir de ce G8, et ca risque de foirer), pour finir dans la foulee et sans transition sur une allusion a la CIA. Sans smiley ou autre avertissement, bah c'etait facile de croire que la derniere phrase etait aussi au premier degre.

Au temps pour moi, donc. Comme quoi la communication sur internet n'est pas facile tous les jours.

Pour toi, j'hesite entre un cynisme extreme ou une connerie bien trop banale...
Ok, il y a des gens a la Maison blanche ou a la CIA qui meriteraient d'aller au tribunal, et d'autres chez le psy pour se faire soigner, mais de la a imaginer que les USA vont expres assassiner des dizaines d'anglais, alors que les anglais sont leurs plus proches allies...

Yahoo a repris d'autre depeches...
et les premieres photos
http://uk.search.yahoo.com/search/news?meta=vc%3D&c=news_photos(...)

ou
http://news.independent.co.uk/uk/crime/article297443.ece(...)
http://www.cnn.com/2005/WORLD/europe/07/07/london.tube/index.html(...)

http://news.bbc.co.uk/1/hi/uk/4659331.stm(...)
http://news.bbc.co.uk/1/hi/uk/4659093.stm(...)