pyrollo a écrit 560 commentaires

Et choisissez un cirque avec que des travailleurs volontaires, c'est à dire sans animaux (qui sont la plupart du temps très mal traités et jamais partants). Il y en a de très bons.

En fait je ne parlais pas du côté technique (ça me semble en effet normal que des politiciens n'y comprennent pas grand chose) mais du côté constitutionnel.

Comment des professionnels font ils pour pondre des trucs qui ne tiennent pas debout ?

Je me suis toujours demandé s'ils sont de redoutables réthoricens ou de parfaits crétins... je suis perdu là.

Je perds foi en la politique.

Tu confonds politique et politiciens, ça n'a rien à voir !

Merci pour le retour, je vais tâcher de trouver un moyen de me joindre plus facilement (il doit toujours y avoir moyen de me joindre par DLFP en attendant).

Cette doc est un premier jet, j'avoue ne pas l'avoir attentivement relue. Par contre, dans la phrase que tu cites, je ne crois pas que ce soit une faute car le sujet est le rectangle (même si ce n'est peut être pas clair).

Avec un transfo se situant à plusieurs mètres, derrière deux murs de béton. Et comme la puissance d'un rayonnement décroît avec le cube de la distance à la source, l'intensité de l'exposition est absolument négligeable comparée au fil qui court à un mètre.

qu'est-ce qui ne faut pas lire

Je ne sais pas ce qu'il ne faut pas lire, mais ce qu'il fallait lire pour comprendre c'est : qui comporte un ballaste pour une habitation

1) Il me semble que l'on a pas encore tout découvert dans les domaines de la biologie, de la chimie et de la physique. Il serait donc intéressant de se pencher sur l'interaction onde electromagnétique - organisme biologique. Malheureusement, les études effectuées se bornent à étudier les effets thermiques de type micro-onde. Il existe pourtant d'autres interactions connues, comme par exemple des organismes capable de sentir le champs magnétique terrestre.

2) L'utilisation de courant continu, par exemple, fait que les fils n'émettent pas d'onde à 50Hz. Il reste bien sûr un champs statique, mais le phénomène est très différent.

Tout comme les rayons X, les UV et les rayons Gamma... Pourtant, si le phénomène est le même, les effets sont très différents. Ce n'est pas parce que la lumière verte ou l'onde radio 1000Hz sont réputées sans danger que l'ensemble du spectre est inoffensif.

Le il fait référence au procédé. C'est le procédé qui s'applique au XML, pas le brevet effectivement.

Mais, lors du traitement d'un fichier XML on peut très bien enfreidre ce brevet si, à un moment ou un autre, on sépare la structure du contenu. Comme tu dis, c'est ridicule.

Je suis allé directement sur l'USPTO (équivalent INPI aux US) et on le trouve ici : http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec(...)

Je me suis tapé une bonne partie du texte (c'est franchement pas amusant à lire).

En fait, le procédé breveté est celui de stocker le contenu d'un fichier et sa structure dans deux zones différentes. Il s'applique à tous les fichiers dont le format comprend des marqueurs (métacodes), donc XML mais aussi HTML et bien d'autres formats.

La zone content contient le texte brut du fichier et la zone map contient la liste des metacodes associés à des pointeurs vers les zone texte concernées.

Le brevet concerne aussi les méthodes de transformation du format avec métacodes vers le format content/map et inversement.

Cela pourrait donc concerner un paquet de bibliothèques si elles ont le malheur, un moment ou un autre, de créer une carte des metacodes du ficher séparée du contenu.

C'est pas une invention bien astucieuse, je pense que beaucoup de développeurs peuvent avoir utilisé ce procédé sans même avoir pensé qu'il était digne d'intérêt d'être protégé.

Pour avoir fait des trucs comme ça au boulot sous logiciel propriétaire, l'avantage d'un outil graphique par rapport à un éditeur d'interface c'est que :

- Tu peux facilement mettre des données dedans, même des données compliquées
- Tu peux dessiner des widgets que tu n'as pas encore développé (y a qu'à dessiner)

C'est surtout intéressant quand tu veux présenter un truc à un client en espérant lui faire comprendre ce que l'appli fera.

On a deux problèmes indépendant : changement climatique et radioactivité.

C'est difficile de dire si l'un est plus grave que l'autre. Mais ce qui semble sûr, c'est qu'il y en a un plus urgent que l'autre.

Maintenant, le nucléaire, en dehors de la radioactivité, pose d'autres problèmes : incitation à une consommation constante (donc incitation à une consommation) et énergie non renouvelable tant qu'il s'agit de fission (le minerai est épuisable).

« Les ménages ne doivent en aucun cas avoir l’impression de contribuer au bon fonctionnement de l’économie et au fonctionnement des entreprises. Ca serait une catastrophe. »

Il voulait peut être dire que ce serait une catastrophe que les ménages comprennent leur contribution à l'économie car ça changerait radicalement leur manière de consommer.

Je dirais qu'il vaut mieux commencer par Python, car Django est un framework écrit en Python.

Une fois la base de Python acquise, le site de Django propose un bon tutorial ici : http://docs.djangoproject.com/en/dev/intro/tutorial01 (a lire en faisant ce qui est demandé, sinon ça perd son intérêt)

Le reste de la doc est plutôt bien foutue, et puis, tu as les sources !

J'ai commencé à faire de la doc, car impossible d'avancer sans. Mais je me laisse vite prendre à écrire une thèse sur l'Apple II. Donc stop, je me suis concentré sur le développement. Mais oui, je vais arranger le côté doc.

Pour les sources sont accessible ici : http://vinace.svn.sourceforge.net/viewvc/vinace/trunk/ ou par SVN.

J'ai voulu faire un émulateur en orienté objet, et ce, je l'avoue, au détriment des performances. Mais comme je l'ai indiqué, il s'agissait surtout d'un exercice et de s'amuser. Donc j'espère que les sources sont intéressants car j'ai essayé de coller le plus possible à la réalité de la machine.

Mais ça je vais l'expliquer dans les docs... aller ! faut que j'aille faire ma rédaction !

Avec les bases de données les problèmes de lenteur peuvent venir d'un très grand nombre de causes. Question taille de la base, le nombre d'octets ne signifie pas grand chose, ça va plutôt être le nombre d'enregistrements qui va être déterminant. Quelques pistes :

Il faut bien séparer la lecture et l'écriture (qui sont de nature totalement différente pour les BDD) et savoir laquelle est lente. Une optimisation de la lecture a tendance à dégrader l'écriture et vice versa.

Souvent, il s'agit de quelques requêtes en lecture qui ralentissent tout. Ça peut se guérir par l'ajout d'indexes bien placés ou la réécriture des requêtes.

Inversement, si c'est l'écriture qui est lente, ça peut être dû à un excès d'indexes (il faut écrire dans la table et dans chacun des indexes).

S'il y a déjà beaucoup d'indexes, comme il y a beaucoup d'écriture, il peut y avoir un problème de déséquilibre des indexes. Pour faire simple, c'est un peu comme la fragmentation des disques. Il existe des opération rééquilibrant les indexes (la plus brutale, supprimer l'index et le recréer).

Il faut aussi vérifier que c'est bien programmé. Si le programme rapatrie toute la base à chaque requête, c'est le réseau qui doit pécher.

J'ai souvent entendu dire que MySQL était bon en lecture mais pas en écriture. C'est à vérifier, mais pas facile de tester une autre base comme ça (en fait j'ai travaillé longtemps avec Oracle mais chaque base est spécifique).

Autre chose, il est souvent bon de répartir les données accédées simultanément sur plusieurs disques. Par exemple, la table sur un disque et son index sur un autre. Ainsi on gagne beaucoup en temps d'aller retour table-index.

Peut être que MySQL possède des outils de monitoring qui peuvent te renseigner sur ce sur quoi elle dépense son temps.

C'était quelques pistes mais c'est quasiment impossible de diagnostiquer un problème de performance sans une quantité monstrueuse de données.

Je pensais la même chose, mais finalement je crois que c'est plus facile.

Il faut bien sûr bien connaître la machine à émuler. C'était mon cas et de plus cela fait un an que j'ai récupéré quelques modèles réels et surtout les documentations de l'époque (c'est ça qui m'a donné envie je crois). Et les docs de l'époque, c'est bluffant, il y a les schémas électroniques , le listing des ROMs et tout et tout !

Question programmation, en fait, c'est bien plus simple que d'aborder un problème nouveau. En fait, la modélisation du problème (son découpage et les choix de conception) a été faite lorsque la machine a été créée. Il suffit de calquer le modèle du programme sur celui de la machine.

Dernière chose, l'émulateur ne fait que reproduire des circuits logiques bêtes, l'intelligence est dans les programmes qui sont en ROM et en RAM. On a donc assez rapidement la satisfaction de voir des choses complexes fonctionner.

Maintenant, il faut que je me calme, j'ai envie d'écrire en assembleur 8 bits...

Oui, tu as raison, mais je n'avais plus son nom exact en tête. Quand à ses actions et ses choix...

Je n'ai pas fait de comparaison.

Je pense que c'est un peu lent, mais ce n'est ni le client, ni le serveur ni le protocole qui peuvent être mis en cause car pratiquement rien ne circule, c'est une sorte de télécommande. Il s'agit donc uniquement des performances du Gimp.

Ah si, il y a un truc qui est plutôt lent, c'est le démarrage du serveur (ça doit revenir à lancer le Gimp en mode silencieux). Mais, pour un outil de traitement d'image par lot, cela ne m'a pas géné.

... ceux qui pensent que le partage c'est de la non vente et donc du manque à gagner et ceux qui pense que le partage c'est de la publicité gratuite et donc une économie.

Autre chose : GRATUIT = NON REMUNERATION est une assertion totalement fausse bien que séduisante par sa simplicité réductrice.

Exemple : j'allume mon poste de radio, je ne paye pas (en tout cas je ne paye pas plus cher en l'ayant allumé), mais l'artiste est rémunéré.

On peut donc affirmer que l'on est pour la gratuité ET pour la rémunération. Il faut bien faire attention à ne pas se faire avoir par les amalgames.

C'est vrai que c'est un outil merveilleux.

Mais, d'une part, il ne s'agit là que de représentation des modèles et pour ma part, je n'ai aucun problème de complexité avec les modèles (en fait j'ai une solide expérience en bases de données, ça aide).

D'autre part, j'ai un peu de mal avec la génération automatique de schéma. En effet, je pense qu'un bon schéma est un schéma non systématique. En effet, le schéma est destiné à représenter le problème aux humains alors que le code est destiné aux machines. Un bon schéma doit donc, à mon avis, faire quelques impasses et comporter quelques imprécisions pour améliorer sa lisibilité.

Ce qui est intéressant dans ces statistiques c'est de remarquer la progression. Par exemple, dans la page que tu cites, on peut remarquer que Linux est passé de 0,95% en Mars à 1,16% en Aout, soit +22% en six mois.

Ce faible score (de l'ordre de 1%) avec une progression me fais penser aux scores de Mozilla il y a maintenant bien longtemps. Je me souviens la joie de le voir passer à 3% et à l'incrédulité de le voir dépasser les 5%.

Je ne sais pas s'il s'agit du même :

http://www.pcinpact.com/actu/news/50834-hadopi-jeanpierre-go(...)

Tu veux dire Bouygues Brother non ?

Allez tant pis, je ne voulais pas faire de pub.

Je suis tombé, presque par hasard (prêt immobilier) chez le Crédit Mutuel. Je suis peut être tombé sur la bonne agence et/ou la bonne conseillère mais dès le premier entretient, j'ai fini par poser la question : Comment ça se fait que dans les autres banques les conseillers tentent de me placer plein de produits alors que vous m'en avez retiré ?. C'est là qu'elle m'a expliqué pour les primes.

J'ai un nouveau conseiller depuis plusieurs mois. Celui-ci ne m'a pas encore convoqué comme le faisaient les autres dans les autres banques. C'est peut être bon signe.

Il y a peut être d'autres banques dans ce cas. D'autres banques mutuelles ? Le Crédit Mutuel a peut être aussi d'autres inconvénients.