le 09/02/2006 à 23:10
Inverser scrollbar
LupusMic
-
SignatureDéveloppeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
-
Site web
-
Nombre de sujets26
-
Nombre de messages1 684
-
Nombre de commentaires4
-
Nombre de newsAucune
-
Niveau en PHPGourou
Ses derniers messages sur les forums
le 09/02/2006 à 23:06
php et impression
Tu sais, moi aussi j'ai cru au discours marketing de Adobe. Mais ne fait, il n'en est rien. Par contre, c'est vrai que c'est un standard assez efficace, même si on aurait dû lui préférer le dvi.
Mais à part ceux qui installent miktec sur leur bécane, rares sont ceux qui ont un lecteur de DVI ;)
Mais à part ceux qui installent miktec sur leur bécane, rares sont ceux qui ont un lecteur de DVI ;)
le 07/02/2006 à 20:24
php et impression
Pour répondre à bibi, ce n'est pas parce que sur le papier il est marqué qu'on verra partout pareil que c'est vrai. Et le PDF n'échappe pas à cette dure loi de l'informatique.
Et tu as tord. Suivant que tu ai ou non les polices qui vont bien sur ton poste, que le rendu des polices soit plus ou moins bon (qualité de la police, anticrénelage, etc.). J'ai déjà eu affaire à des problèmes d'affichage parce que j'utilise telle ou telle application d'affichage de PDF.
Et deux affirmations bien fausses :-D
Le format PDF n'est pas à proprement parlé ouvert : il n'est pas ouvert à l'évolution, et peut être fermé du jour au lendemain (voir licence d'utilisation de PDF).
Tous les lecteurs n'affichent pas parfaitement les PDF. Comme dis plus, cela dépend du système, des ressources systèmes disponible ainsi que du support du PDF par le lecteur.
(La Globule) Tu m'as grillé :p
Cela se rapproche de très près à une page web en ayant pas l'inconvénient des différences d'affichages...
Et tu as tord. Suivant que tu ai ou non les polices qui vont bien sur ton poste, que le rendu des polices soit plus ou moins bon (qualité de la police, anticrénelage, etc.). J'ai déjà eu affaire à des problèmes d'affichage parce que j'utilise telle ou telle application d'affichage de PDF.
Comme le format pdf est un format ouvert, tous les lecteurs de pdf affichent ce format parfaitement !!!
Et deux affirmations bien fausses :-D
Le format PDF n'est pas à proprement parlé ouvert : il n'est pas ouvert à l'évolution, et peut être fermé du jour au lendemain (voir licence d'utilisation de PDF).
Tous les lecteurs n'affichent pas parfaitement les PDF. Comme dis plus, cela dépend du système, des ressources systèmes disponible ainsi que du support du PDF par le lecteur.
(La Globule) Tu m'as grillé :p
le 06/02/2006 à 22:13
php et impression
L'avantage du pdf ou bien de l'image c'est qu'ils ne dépendent pas du navigateur.
Par contre, ça dépend du lecteur PDF que tu utilises, et du format PDF ainsi que du type de PDF utilisé.
le 30/01/2006 à 16:51
créer des pages à la volée
C'est un peu le principe d'un site dynamique.
le 29/01/2006 à 17:50
c++.....vector
(LeFounard) Tu as un lien ? Parce que jeter le namespace std dans le contexte général c'est franchement pas malin. Tu risques de te retrouver avec des colisions dans tous les sens. De plus, ça supprime tout l'intérêt des espaces de nom.
Par contre, utiliser using namespace std ; à l'intérieur d'un block de code est intelligent, puisque c'est fait pour.
using namespace en global == mal ©
using namespace en local == bien ©
Bon, pour en revenir au problème, il est où le code qui pose problème ?
Par contre, utiliser using namespace std ; à l'intérieur d'un block de code est intelligent, puisque c'est fait pour.
using namespace en global == mal ©
using namespace en local == bien ©
Bon, pour en revenir au problème, il est où le code qui pose problème ?
le 29/01/2006 à 17:36
+1 au compteur
Pour préciser le problème du lock sous Microsoft Windows : le lock des fichiers est en général obligatoire, parce que Apache fonctionne en environnement multithread.
Que PHP fournisse un mécanisme de lock ne veut pas dire qu'il est obligatoire. Posix fourni aussi les locks, mais il faut les demander explicitement.
En lisant le code source de PHP 5.1, on ne voit nul part que PHP lock le fichier avant de le lire et de l'écrire.
En ce qui concerne ton protocole, es-tu certain que la première exécution du script n'était pas finie lors du démarrage du second ? J'ai mis volontairement un nombre important pour m'assurer que j'aurais le temps de lancer les suivants. Mais ça peut ne pas suffire si tu as un processeur supérieur.
Ensuite, le bogue que je constate me fait penser à celui de l'entier incrémenté dans le registre processeur et pas mis à jour dans la RAM, entraînant la nécessité d'utiliser le mot clé « volatile ».
Bon, je vais compléter le script de manière à contrôler le début et la fin de l'exécution, et vous posterais le code dans le Wall.
À+
Que PHP fournisse un mécanisme de lock ne veut pas dire qu'il est obligatoire. Posix fourni aussi les locks, mais il faut les demander explicitement.
En lisant le code source de PHP 5.1, on ne voit nul part que PHP lock le fichier avant de le lire et de l'écrire.
En ce qui concerne ton protocole, es-tu certain que la première exécution du script n'était pas finie lors du démarrage du second ? J'ai mis volontairement un nombre important pour m'assurer que j'aurais le temps de lancer les suivants. Mais ça peut ne pas suffire si tu as un processeur supérieur.
Ensuite, le bogue que je constate me fait penser à celui de l'entier incrémenté dans le registre processeur et pas mis à jour dans la RAM, entraînant la nécessité d'utiliser le mot clé « volatile ».
Bon, je vais compléter le script de manière à contrôler le début et la fin de l'exécution, et vous posterais le code dans le Wall.
À+
le 29/01/2006 à 16:44
+1 au compteur
C'est vrai que j'ai oublié de marquer l'OS sur lequel j'ai fais le tests :p Ben c'est une Debian GNU/Linux Sarge, avec les paquets Dotdeb.
Mais ça me paraissait aussi curieux que le lock ne marchait pas correctement. Je dois avoir un problème de configuration ou pire : un bogue de PHP ou de la libc :o)
Je précise que j'utilise SuExec, c'est peut-être le vilain qui casse tout ?
Je vais enquêter...
Mais ça me paraissait aussi curieux que le lock ne marchait pas correctement. Je dois avoir un problème de configuration ou pire : un bogue de PHP ou de la libc :o)
Je précise que j'utilise SuExec, c'est peut-être le vilain qui casse tout ?
Je vais enquêter...
le 25/01/2006 à 23:59
+1 au compteur
J'aime avoir raison, et je vais prouver que j'ai raison sur ce cas. Bien sûr, je prends un cas extrême, volontairement pour pousser PHP dans ces retranchement :
J'ai lancé six connexions concurrentes sur le même script (même URL). Si PHP attendait la libération du fichier pour écrire dedant, le nombre finale devrait être 6.000.000.
La chaîne contenue dans le fichier counter est : 1147673. Cette valeur n'a aucune signification, si ce n'est qu'on est bien au dessus 600.000 attendus.
Si l'on observe le contenu du fichier counter, on s'aperçoit que le contenu est complètement délirant, pouvant régresser violemment à une valeur franchement inférieure.
Avec le même source, mais en rajoutant :
on obtient : 494271.
En consultant la documentation de flock, on s'aperçoit que les applications Web ne sont pas bien codées, ne sont pas correctement portable car flock est obligatoire sous les Microsoft Windows de la branche NT.
Alors maintenant, ma démarche est peut-être erronée, mais j'aimerais qu'on me le prouve ;)
Ce test prouve simplement qu'il n'est pas pertinent de stocker une information issue de sources concurrentes directement dans un fichier.
Je soupçonne le système d'exploitation de tromper PHP lors de l'accès au fichier.
Il faudrait faire le même essai avec MySQL tient.
Le test a été effectué depuis une machine en ADSL vers un serveur dédié Apache2/PHP5, 512 Mo RAM, Athlon XP 2400.
<?php
for($i=0;$i < 100000;$i++)
{
$fp = fopen('counter', 'r+') ;
if(!$fp) break ;
$count = (integer) fread($fp,15) ;
var_dump($count) ;
++$count ;
fseek($fp, 0) ;
fwrite($fp, (string)$count) ;
flush($fp) ;
fclose($fp) ;
}
var_dump($count) ;
?>
J'ai lancé six connexions concurrentes sur le même script (même URL). Si PHP attendait la libération du fichier pour écrire dedant, le nombre finale devrait être 6.000.000.
La chaîne contenue dans le fichier counter est : 1147673. Cette valeur n'a aucune signification, si ce n'est qu'on est bien au dessus 600.000 attendus.
Si l'on observe le contenu du fichier counter, on s'aperçoit que le contenu est complètement délirant, pouvant régresser violemment à une valeur franchement inférieure.
Avec le même source, mais en rajoutant :
flock($fp, LOCK_EX + LOCK_SH) ;
on obtient : 494271.
En consultant la documentation de flock, on s'aperçoit que les applications Web ne sont pas bien codées, ne sont pas correctement portable car flock est obligatoire sous les Microsoft Windows de la branche NT.
Alors maintenant, ma démarche est peut-être erronée, mais j'aimerais qu'on me le prouve ;)
Ce test prouve simplement qu'il n'est pas pertinent de stocker une information issue de sources concurrentes directement dans un fichier.
Je soupçonne le système d'exploitation de tromper PHP lors de l'accès au fichier.
Il faudrait faire le même essai avec MySQL tient.
Le test a été effectué depuis une machine en ADSL vers un serveur dédié Apache2/PHP5, 512 Mo RAM, Athlon XP 2400.
le 25/01/2006 à 16:37
+1 au compteur
(Bzh) Ça m'étonnerais fort que PHP bloque l'accès à un fichier lorsque tu le lis ou l'écris.
