TortuXm a écrit 119 commentaires

Les écrans récents ont probablement tous des protections. Après j'avais eu un souci à l'époque où j'étais sous Windows 98 avec un CRT, un jeu qui me l'avait fait fumer... Faut dire que je l'utilisais souvent à 75Hz en 1024x768 alors qu'il n'en gérait que 60Hz à cette résolution. L'image était distordue, etc. (l'écran affichait quand même un image même si c'était hors normes)


Pour les écrans LCD c'est un peu différent, l'image ne s'affiche juste pas quand il y a un souci.



Mais franchement je doute que ce soit le problème, déjà quand t'auras essayé un autre câble tu auras un début de réponse :)

Si ton driver s'amuse à mettre l'écran à des fréquences impossibles, à allumer puis éteindre de force, etc, il peut abîmer le matériel.

D'ailleurs ça me rappelle l'époque où des virus "cassaient" des disques durs en forçant la lecture de secteurs bien placés, ce qui forçait les têtes de lecture à faire le grand écart.



Par contre dans ton cas, j'ai des doutes. Est-ce que tu as essayé l'écran sur un autre PC ? Et si tu penses qu'il y a un problème, le mode VESA ? Le câble est toujours bon ? (j'ai un câble DVI qui a lâché du jour au lendemain sans raison)

Ah je me souviens d'avoir fait ça il y a un certain temps quand je réinstallaisun PC.

Après l'install de DirectX, la popup n'avait qu'un bouton Redémarrer, la croix pour fermer la fenêtre était grisée et elle était en topmost (en premier plan "permanent")... Donc le temps d'installer le reste pour tout faire en un seul redémarrage, je gardais la popup dans un coin.

Je veux bien que dans son cas ça soit du foutage de gueule, par contre "dans la vraie vie", j'ai déjà eu le cas :

Pour une demande de prêt chez un organisme, j'ai reçu 4 propositions successives différentes. Et à chaque fois, les conditions étaient légèrement différentes. Alors vaut mieux pas partir avec l'a priori qu'elles ne changent pas.

Faut dire que ton troll initial était bien gros, quand même.

Quitte à choisir le meilleur moment, pour moi c'est quand je vais manger (quand le PC est verrouillé et inutilisé mais toujours allumé). Je déteste quand le PC continue de tourner un moment alors que je lui ai demandé de s'éteindre : parfois on a même un message bloquant en rentrant (genre : êtes-vous sûr de vouloir fermer Outlook), alors s'il faut attendre la fin de la MAJ pour être sûr de ne pas retrouver le PC allumé le lendemain matin, ça revient au même.


Sinon pour le fsck quand on éteint le PC, je ne suis pas vraiment fan, pour les mêmes raisons. Je pense qu'on gagnerait beaucoup à pouvoir faire un fsck à chaud, plutôt.

Si tu peux écrire du code dans un langage sans la lib, c'est que ce que tu ajoutes est une bien une librairie.

Par exemple en C, rien ne t'oblige à importer la stdlib, je l'ai déjà fait sur des architectures exotiques. C'est bas niveau et tu peux réécrire une librairie à partir de "rien". Ou même écrire du C sans la stdlib mais avec une autre librairie qui a plus ou moins les mêmes fonctions.



Au contraire si tu ne peux pas te passer de la lib, si le langage lui-même dépend de la lib pour gérer ses propres fonctionnalités, alors c'est un runtime.

Mais les standards dans l'informatique sont autrement plus complexes à implémenter que le standard des écours de 13 ;)

Penser à ODT, HTML (il y a une implémentation de référence pour HTML ?) par exemple.

De plus dans certains cas, en informatique, on peut avoir besoin de n'implémenter qu'une partie d'une norme pour des raisons particulières (espace mémoire limité, faible cpu, etc)



Le problème des standards en informatique, c'est aussi la concurrence sauvage entre les acteurs qui sont persuadés que la non interopérabilité sera un atout pour eux.

On a eu un peu la même chose avec les formats des cassettes il y a longtemps, et la guerre HD-DVD et blueray un peu plus récemment (même si évidemment, dans ces deux cas il y a eu un gagnant, contrairement à l'informatique où on ne se met pas souvent d'accord)

Ah t'as bien fait de préciser, c'est effectivement écrit en début de news mais le temps d'arriver à la partie "lieux et dates de rendez-vous", j'avais déjà oublié.

Je suis assez d'accord avec toi.


Pour mes mails persos, j'utilise KMail. Par contre au boulot, si je veux être averti de la livraison d'un colis / n'importe quel autre mail perso, je suis bloqué : il n'y a que le port 80 qui passe, donc forcément, à moins de bidouiller un proxy http, ce n'est pas possible autrement que par un webmail.

De toute façon, le client mail du boulot est Outlook alors entre roundcube et outlook, le choix est vite fait...

Sous gentoo c'est particulièrement visible en fait.


Quand je devais mettre à jour firefox, j'avais 3 heures de compilation de xulrunner et 30 secondes pour firefox.

Le transient me paraissait une bonne piste, dommage ;)


J'ai déjà eu des problèmes de ce type à l'époque où je faisais du Struts. A mon avis le problème ne se situe pas dans le code que tu as mis...


Est-ce que tu as essayé de mettre un point d'arrêt dans le setter pour voir s'il est appelé pendant la phase de rendering ? (ou mettre des logs dans le setter, dans le cas où l'argument est null)


As-tu un champ qui est censé remplir ta valeur tab ? Comme on n'a pas de jsp je ne fais qu'imaginer mais ça se trouve, tu résoudras ton problème en utilisant un getter indexé plutôt qu'un getter sur ta liste ?


Personnellement j'aurais tendance à éliminer d'office le garbage collector, à moins que tu viennes de découvrir un bug dans la JVM : il n'y a pas de raison qu'une partie de tes objets soit libérée et que ton objet soit mis à jour pour refléter ces changements.

J'en ai fait remarcher un juste en attendant un certain temps. Je sais plus la référence exacte du portable mais c'était un HP qu'on m'avait donné parce qu'il ne fonctionnait plus et faisait partie d'une série noire.



Je l'ai laissé allumé longtemps sur batteries pour décharger la pile, au bout d'un moment il s'est mis à faire plusieurs séries de bips, puis le bios s'est affiché... Et depuis il fonctionne correctement. Je ne comprends pas vraiment pourquoi ça a fait ça.

Je ne sais pas si tu es sérieux, j'espère que non, en fait.


J'imagine déjà les gens qui n'ont pas de moyens, payer pour recevoir leurs factures, ça va les faire marrer ton idée.

Même expérience pour ma part, sauf que j'ai réussi à m'arranger pour que ma voisine récupère le colis. Et même conclusion, plus jamais de commande via UPS.


Je préfère largement le système du dépôt-retrait dans un bistrot du coin (même si dans mon cas, il faut que je fasse 5 Km pour y aller), au moins il n'y a pas de chantage du genre "prenez un jour de congé ou on renvoie le colis à l'expéditeur"

Dans mon ex-boîte, on n'avait pas le droit d'emmener son propre café.

Soit disant c'était à cause des normes d'hygiène, en fait je crois plutôt que ça avait un rapport avec le contrat entre le CE et les fournisseurs de machines à café.


Enfin toujours est-il qu'on n'a pas forcément le droit d'avoir du bon café au boulot.

Tu peux changer le décorateur si tu veux ça.


Rien ne t'empêche de faire un "self.set_target(f)" au lieu de f(self) dans ce cas.



Pour autoriser le passage de paramètres, une possibilité est de changer le type de valeurs de la queue pour stocker un tuple (fonction, arguments) plutôt que juste une fonction. Mais il y a peut-être plus simple.


Dans tous les cas, le code ci-dessus contient tout ce qui faut au niveau threading : le reste n'est que de la programmation "classique" à coller par-dessus.


PS : pour le kill_all, il y a bien une fonction, mais de mémoire elle n'est pas recommandée. Je n'ai pas la doc sous les yeux donc je ne peux pas te donner le nom exact... mais elle est dans la doc de base du module threading il me semble.

Le pire que j'ai vu pour l'instant, c'était un code coréen. Les noms de variables/classes/fonctions étaient du coréen écrit avec l'alphabet romain "classique" et les commentaires avec les symboles coréens (qui n'apparaissaient même pas correctement dans l'IDE que je devais utiliser à l'époque, Visual Studio).

Super facile à prendre en main, rien que reconnaître les variables entre elles, c'était super dur ;)

Pour ceux qui utilisent le web à titre perso encore plus au boulot que chez eux, peut-être.

Pareil je suis bien content de mon eeePC 701. Le seul reproche que je lui fais c'est la taille de l'écran, qui est limite pour coder et pour visiter certains sites internet.


En hauteur en fait, il y a trop d'applis qui ne passent pas en 480 pixels de haut...


Sinon il y a la touche M qui est trop petite (c'est une touche peu utilisée en QWERTY je crois), c'est un peu énervant pour prendre des rapports. Par contre le fait de pouvoir finir un rapport dans le bus, et de le montrer au client en arrivant avec une présentation OpenOffice sur un grand écran, c'est priceless :)

Avant d'être numericable, ça s'appellait noos. Le nom avait été changé à cause de la réputation. Ils vont pas refaire le coup à chaque fois ;)

D'ailleurs en regardant la vidéo, on se rend bien compte que c'est exactement la fonctionnalité dont on parle.

Il me semble que tout simplement, après un "close", la socket n'est plus valide en Python, comme avec les fonctions C de base.


Concrètement, en C ton objet socket est un file descriptor, qui est fermé par close. Si tu veux rouvrir une autre socket, tu doit rappeler la fonction socket, c'est-à-dire, vu le binding fait en Python, recréer un nouvel objet.


Cf des exemples sur les sockets : http://broux.developpez.com/articles/c/sockets

Super, j'avais voulu faire juste un script côté client et j'avais pas trouvé.

Je n'avais pas pensé à mettre envoyer commandes à ssh...

Je suis bien d'accord avec l'avantage que tu cites.

Pour le RAII, j'ai toujours beaucoup apprécié cette façon de faire : cela mixe très bien les avantages de l'allocation par la pile et permet de ne rien avoir à faire pour bien gérer les exceptions, tout ça sans fuite de mémoire et de façon "clean".

Certaines utilisations nécessitent d'avoir un contrôle fin de la mémoire. C++ va jusqu'à permettre de contrôler où on alloue ses objets avec le placement new, si on veut gérer réserver une grande zone de mémoire que l'on va gérer soi même.