Probleme memoire

[Jean-Francois Ortolo]

Bonjour

Je suis en train de terminer un script PHP, assez gros.

Voici les dimensions approximatives:

longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?

Sinon, pensez-vous que ce script pourrait fonctionner avec soit 16Mo,
soit 32Mo configurés dans le fichiers /etc/php.ini de configuration de PHP ?

Le serveur est un serveur dédié, pas de problème pour changer la
configuration.

Le script est relativement peu gourmand en ressources MySQL: Une
grande boucle de lecture, plus un chouïa de lecture par ci par là durant
l'exécution, plus des insert ponctuels non groupés. La boucle principale
de lecture, est la seule dont la mémoire n'est libérée, qu'à la fin de
l'exécution du script, la lecture SQL comme vous le savez, est
bufferisée, et les données lues transitent entre la table SQL lue et la
mémoire, de manière cool en terme d'occupation mémoire.

Ce script n'est pas destiné à un usage intensif, il sert uniquement à
la mise à jour des statistiques sur les pronostics de mon site
partenaire, ces mises à jour auront lieu une fois par jour, et à priori,
ne concerneront que les pronostics de la veille.

Merci beaucoup de vos réponses.

Jean-Francois Ortolo

[Bruno Desthuilliers]

Post by Jean-Francois Ortolo
Bonjour
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par
script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire
allouée ?

Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la
mémoire avec un script de trois/quatres lignes.

[beepee]

Post by Jean-Francois Ortolo
Bonjour
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par
script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire
allouée ?

Je ne pense pas que la taille (en LOC) du script ait une influence majeure
sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec
un script de trois/quatres lignes.

aoué ? fait péter les 4 lignes s'il te plait.

merci d'avance

[Olivier Miakinen]

Post by beepee

Je ne pense pas que la taille (en LOC) du script ait une influence majeure
sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec
un script de trois/quatres lignes.

aoué ? fait péter les 4 lignes s'il te plait.

Je peux jouer ? J'essaierais bien un truc comme ça :

<?php
$str = "blabla";
while(1) { $str = $str.$str; $tableau[$str] = $str; }
?>

[Jean-Francois Ortolo]

Post by Bruno Desthuilliers

Post by Jean-Francois Ortolo
Bonjour
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?

Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la
mémoire avec un script de trois/quatres lignes.

Bonjour Monsieur

Il est vrai que mon script a un certain nombre de variables indicées,
mais il me semble qu'au total, l'occupation mémoire spécifique de ces
variables, devrait au total, rester largement en dessous de 1 Mo.

Le volume occupé par toutes les variables, est relativement constant
au fur et à mesure de l'exécution du script, mais il y a bien libération
de la mémoire avec des unset, au fur et à mesure, ce qui éventuellement
peut poser des problèmes d'allocation mémoire.

Je m'inquitéais surtout à cause de la taille en octets de mon script,
qui fera environ 562500 octets de long. ( un peu plus d'un
demi-méga-octets quand même ).

Je suppose que dans un environnement serveur Linux ( actuellement
RedHat 7.2, bientôt Linux Fedora Core 4 ), la mémoire RAM n'est pas
segmentée, c'est la moindre des choses...

Merci beaucoup de votre réponse.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

[doug713705]

Le vendredi 1 février 2008 19:15, Jean-Francois Ortolo s'est exprimé de la

Post by Jean-Francois Ortolo
Je m'inquitéais surtout à cause de la taille en octets de mon script,
qui fera environ 562500 octets de long. ( un peu plus d'un
demi-méga-octets quand même ).

C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas
passer.

Pour cela, ajuster la variable "max_execution_time" devrait sauver
l'affaire.

[Jean-Francois Ortolo]

Post by doug713705
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas
passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver
l'affaire.

Bonjour Monsieur

Je pense qu'il n'y aura pas de problèmes de ce côté-là, parce que je
peux, pour traiter plus d'une journée de courses, spécifier une date
début et une date fin, donc réduire le traitement de chaque appel au
script, à une seule journée de courses.

Actuellement, le temps limite d'exécution est de 30 secondes.

Il y a un nombre limité de pronostiqueurs ( moins de 10 ), évidemment
un nombre limité de courses et de résultats par jour, et ce qui prendra
du temps à l'exécution, sera au pif, 1/3 ou 1/4 pour le nettoyage des
données en amont ( qui sont effectivement un peu parasitées ), et 2/3 ou
3/4 pour la mise à jour des statistiques, et leur intégration à la base
de données.

A un moment où il n'y avait comme fonctionnalité, que le nettoyage
des données, j'avais un temps d'exécution limite correspondant à un peu
plus d'un mois de courses ( donc 30 jours ). Je pense donc que
proportionnellement parlant, il ne devrait pas y avoir de difficultés
pour, au pire, mettre à jour les stats une journée à la fois.

L'appel à ce script PHP se fera à partir d'un script Shell qui
lancera répétitivement le programme curl avec les paramètres qui vont
bien, les dates début et fin seront calculées dans le script Shell de
manière adéquate, et il y aura même une procédure automatique de reprise
sur incident, au cas où le script n'arrive pas jusqu'au bout de son
exécution ( annulation et retour à l'état antérieur des données en base
de données. )

Merci beaucoup de votre réponse, qui m'apporte effectivement
également la réponse au problème du temps limite d'exécution.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

[doug713705]

Le samedi 2 février 2008 13:14, Jean-Francois Ortolo s'est exprimé de la

Post by Jean-Francois Ortolo
L'appel à ce script PHP se fera à partir d'un script Shell qui
lancera répétitivement le programme curl avec les paramètres qui vont
bien

Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ?
Si le script ne fait que des insertions/mises à jour/suppressions de données
et aucun d'affichage, une tâche cron et hop ca roulaize, non ?

[Jean-Francois Ortolo]

Post by doug713705
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ?
Si le script ne fait que des insertions/mises à jour/suppressions de données
et aucun d'affichage, une tâche cron et hop ca roulaize, non ?

A vrai dire...

J'ai besoin que le script me rende quelque chose disant qu'il est
allé jusqu'au bout sans problème.

Je fais çà en lui faisant afficher la chaîne: "OK" en fin de script.

Je me suis arrangé pour que le script Shell prenne automatiquement en
compte l'absence ou la présence de cette chaîne rendue par le script,
pour faire un traitement de reprise sur incident ( annulation des
opérations sur bdd ) si cette chaîne n'est pas envoyée par le script.

Sinon, je sais pas comment le processus Shell de l'interpréteur PHP
en mode CLI, pourrait rendre un numéro interprétable par le script
Shell, en sortie du script PHP.

Je sais que quand on lance une commande dans un script Shell, la
variable $? rend le code de retour de la commande. Mais je ne sais pas
comment agir sur le code de retour du script PHP, quand il est
interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.

Merci beaucoup de ta réponse.

Amicalement.

Jean-Francois Ortolo

[Mickael Wolff]

Post by Jean-Francois Ortolo
Je sais que quand on lance une commande dans un script Shell, la
variable $? rend le code de retour de la commande. Mais je ne sais pas
comment agir sur le code de retour du script PHP, quand il est
interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.

exit((integer) $code) ;

Tout simplement :)

[Jean-Francois Ortolo]

Post by Mickael Wolff

Post by Jean-Francois Ortolo
Je sais que quand on lance une commande dans un script Shell, la
variable $? rend le code de retour de la commande. Mais je ne sais pas
comment agir sur le code de retour du script PHP, quand il est
interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.

exit((integer) $code) ;
Tout simplement :)

Merci beaucoup Monsieur

Voilà, j'ai la réponse à toutes mes questions sur la faisabilité du
projet. Y a plus qu'à...

Hé bé, aux dernières nouvelles, voici ce que contient le programme
source en PHP:

longueur: 596.540 octets ( caractères ascii ),
nbre de lignes: 23.136 lignes

Le nombre de lignes va encore augmenter, il me reste à calculer les
variables statistiques finales, à partir des variables statistiques
temporaires. Peut-être 200 lignes de plus...

En passant, est-ce que quelqu'un pourrait me donner la définition en
Informatique, du mot "usine à gaz" ?

Compte tenu de ce que l'on pourrait pompeusement appeler le "cahier
des charges" du programme, savoir ses fonctionnalités, je ne pense pas
que l'on puisse faire autant, avec moins d'octets. ;)

Mon programme est très complexe, mais j'en ai testé les composantes
préliminaires de nettoyage des données en amont ( qui sont parasitées ),
il n'y a pas de problème. Ces composantes occupent beaucoup de place
dans le programme.

Merci beaucoup pour votre réponse.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

[Bruno Desthuilliers]

Post by Bruno Desthuilliers

Post by Jean-Francois Ortolo
Bonjour
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?

Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-)

Après relecture (un zero m'avait échappé) : quoique dans ton cas, je ne
me hasarderai pas au moindre pronostic, n'ayant *jamais* vu une pareille
monstruosité.

[Thierry B.]

--{ Jean-Francois Ortolo a plopé ceci: }--

Post by Jean-Francois Ortolo
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

J'y crois pas, c'est impossible. C'est un troll patatoïde.

[Jean-Francois Ortolo]

Post by Thierry B.
--{ Jean-Francois Ortolo a plopé ceci: }--

Post by Jean-Francois Ortolo
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

J'y crois pas, c'est impossible. C'est un troll patatoïde.

Bonjour Monsieur

Je vous garantis, que je suis bien en train de mettre au point (
terminer de programmer ) ce script, qui a actuellement, pour être
précis, les dimensions suivantes:

longueur : 562423 caractères ascii ( ou octets si vous préférez ),
nbre lignes : 21781 lignes

Je n'ai pas encore testé ce script, pour la simple raison qu'il n'est
pas entièrement terminé. Cependant, j'ai testé et mis au point ce script
à un moment où il était réduit à une fraction de ses fonctionnalités, à
savoir le nettoyage en amont des données qu'il traite. Il a ensuite été
complété par le calcul des variables statistiques. Je maîtrise bien la
structure du script, et il compile par faitement bien, ce qui je le
reconnais, ne veut pas dire qu'il n'y a pas quelques erreurs
d'orthographe de variables...

Ces données traitées, sont lues dans une table SQL dans la boucle la
plus externe, c'est le traitement SQL qui nécessite le plus de mémoire,
puisque le buffer n'est libéré qu'à la fin de l'exécution du script.

Les dimensions actuelles du script, sont motivées par le fait que ces
données font l'objet d'un traitement sophistiqué de calcul, pour
calculer les données statistiques temporaires, puis finales.

Ces données statistiques temporaires puis finales, sont contenues
dans des variables indicées à deux et à trois indices, dont j'ai déjà
dit, que leur volume global est certainement inférieur à 1Mo.

Cependant, le fait que certaines variables temporaires voient leur
mémoire libérée en cours de route ( par des unset ), fait que la mémoire
effectivement allouée, peut être supérieure à l'addition des mémoires de
toutes les variables.

Je reconnais qu'un script aussi important est peu courant en PHP, mais
il n'y a pas d'autre solution pour calculer des statistiques qui
doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait
d'impact négatif sur la justesse des statistiques.

D'autre part, il sera possible, avec cette approche, d'afficher des
stats en choisissant soit des catégories de stats ( nom du pronostiqueur
par exemple puisque ce sont des stats de pronostics de courses de
chevaux ), soit des périodes prise en compte des stats ( exemple les 6
premier mois de 2006, ou toute l'année 2007, etc... ).

Celà dit, si une telle dimension de script est si inhabituelle,
est-il possible à priori, de répondre à la question que je me pose, qui
conditionne la faisabilité de ce projet ?

Merci beaucoup de votre réponse.

Jean-Francois Ortolo

[Bruno Desthuilliers]

Post by Jean-Francois Ortolo

Post by Thierry B.
--{ Jean-Francois Ortolo a plopé ceci: }--

Post by Jean-Francois Ortolo
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

J'y crois pas, c'est impossible. C'est un troll patatoïde.

Bonjour Monsieur
Je vous garantis, que je suis bien en train de mettre au point (
terminer de programmer ) ce script, qui a actuellement, pour être
longueur : 562423 caractères ascii ( ou octets si vous préférez ),
nbre lignes : 21781 lignes

(snip)

Post by Jean-Francois Ortolo
Je reconnais qu'un script aussi important est peu courant en PHP,

C'est un euphémisme. pas qu'il n'y ait pas de programmes PHP qui
atteignent ou dépassent cette taille (il y en a un bon paquet qui font
largement 5 fois plus), *mais pas en un seul script*.

Post by Jean-Francois Ortolo
mais
il n'y a pas d'autre solution pour calculer des statistiques qui
doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait
d'impact négatif sur la justesse des statistiques.

Si, heureusement. Il serait temps de lire la doc de include().

Enfin bon, bonne chance pour la maintenance, hein...

[Jean-Francois Ortolo]

Post by Bruno Desthuilliers

Post by Jean-Francois Ortolo
mais
il n'y a pas d'autre solution pour calculer des statistiques qui
doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait
d'impact négatif sur la justesse des statistiques.

Si, heureusement. Il serait temps de lire la doc de include().
Enfin bon, bonne chance pour la maintenance, hein...

Bonjour Monsieur

Je ne peux pas faire des include, car pratiquement tout le programme,
est occupé par une seule fonction.

Bon, effectivement il y a un certain nombre d'autres fonctions ( une
dizaine environ ), mais proportionnellement, l'espace occupé par ces
fonctions est très réduit, par rapport à la fonction principale ( On se
demande pourquoi j'ai appelé cette fonction principale Remplissage()
d'ailleurs... ;) )

Et puis, quel intérêt de scinder le contenu avec des include, puisque
de toute façon, l'espace occupé par le script est celui de tous les
script inclus et incluant.

Même si j'utilisais des require, le fait que les fonctions sont
appelées souvent, ferait que l'espace occupé serait l'espace maximum, et
en plus, il y aurait des problèmes d'offset de remplissage de mémoire,
par le fait que les fonctions appelées, se chargeraient les unes après
les autres.

A moins que ma mémoire me fasse défaut, et que je confonde les
require et les include.

Merci beaucoup pour votre réponse.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

[Olivier Miakinen]

Bonjour,

Post by Jean-Francois Ortolo
Je ne peux pas faire des include, car pratiquement tout le programme,
est occupé par une seule fonction.

S'il y a une chose qui me semble plus monstrueuse qu'un fichier source
de vingt mille lignes, c'est bien une fonction de vingt mille lignes !

En dehors du cas d'un immense « switch() » dans lequel chaque « case »
fait 20 ou 30 lignes au maximum, j'ai pour habitude d'écrire des
fonctions qui tiennent sur une page d'écran, soit environ 65 lignes
de 80 colonnes maximum.

Post by Jean-Francois Ortolo
Et puis, quel intérêt de scinder le contenu avec des include, puisque
de toute façon, l'espace occupé par le script est celui de tous les
script inclus et incluant.

Le seul intérêt, c'est la lisibilité et la maintenabilité du programme.
Mais cet intérêt me semble primordial, même au risque de perdre un peu
en performances.

Cordialement,

[BertrandB]

Post by Olivier Miakinen
Bonjour,

Post by Jean-Francois Ortolo
Je ne peux pas faire des include, car pratiquement tout le programme,
est occupé par une seule fonction.

S'il y a une chose qui me semble plus monstrueuse qu'un fichier source
de vingt mille lignes, c'est bien une fonction de vingt mille lignes !
En dehors du cas d'un immense « switch() » dans lequel chaque « case »
fait 20 ou 30 lignes au maximum, j'ai pour habitude d'écrire des
fonctions qui tiennent sur une page d'écran, soit environ 65 lignes
de 80 colonnes maximum.

Dans quel cas un automate serait le bienvenue ce qui impliquerait donc
l'écriture de fonctions de 20 ou 30 lignes ;)

[Bruno Desthuilliers]

Post by Jean-Francois Ortolo

Post by Bruno Desthuilliers

Post by Jean-Francois Ortolo
mais
il n'y a pas d'autre solution pour calculer des statistiques qui
doivent pouvoir être mises à jour quotidiennement, sans que celà
n'ait d'impact négatif sur la justesse des statistiques.

Si, heureusement. Il serait temps de lire la doc de include().
Enfin bon, bonne chance pour la maintenance, hein...

Bonjour Monsieur
Je ne peux pas faire des include, car pratiquement tout le programme,
est occupé par une seule fonction.

De 23000 lignes ???

Post by Jean-Francois Ortolo
Bon, effectivement il y a un certain nombre d'autres fonctions ( une
dizaine environ ), mais proportionnellement, l'espace occupé par ces
fonctions est très réduit, par rapport à la fonction principale ( On se
demande pourquoi j'ai appelé cette fonction principale Remplissage()
d'ailleurs... ;) )
Et puis, quel intérêt de scinder le contenu avec des include,

Heu... le rendre un minimum maintenable ?

Post by Jean-Francois Ortolo
puisque
de toute façon, l'espace occupé par le script est celui de tous les
script inclus et incluant.

<bis>
La consommation mémoire d'un script n'est que très marginalement liée au
nombre de lignes.
</bis>

Post by Jean-Francois Ortolo
Même si j'utilisais des require, le fait que les fonctions sont
appelées souvent, ferait que l'espace occupé serait l'espace maximum, et
en plus, il y aurait des problèmes d'offset de remplissage de mémoire,
par le fait que les fonctions appelées, se chargeraient les unes après
les autres.

mouarfffff.


Merci pour ce cours d'informatique, Docteur.

[SAM]

Post by Jean-Francois Ortolo
Je ne peux pas faire des include, car pratiquement tout le programme,
est occupé par une seule fonction.

Je ne connais rien au PHP, mais à mon idée, une fonction peut toujours
être subdivisée ...

Post by Jean-Francois Ortolo
Et puis, quel intérêt de scinder le contenu avec des include, puisque
de toute façon, l'espace occupé par le script est celui de tous les
script inclus et incluant.

J'imagine qu'une même fonction peut être appelée plusieurs fois ?
ou que l'une doit attendre la fin de l'autre pour donner son sésultat ?

Sinon, ce n'est pas très grave, l'essentiel est de pouvoir s'y retrouver
dans la création de son script. De le couper en tronçon peut bien aider.

Post by Jean-Francois Ortolo
Même si j'utilisais des require, le fait que les fonctions sont
appelées souvent, ferait que l'espace occupé serait l'espace maximum, et
en plus, il y aurait des problèmes d'offset de remplissage de mémoire,
par le fait que les fonctions appelées, se chargeraient les unes après
les autres.

Si les fonctions sont appelées souvent ce n'est que mieux de les avoir
en-dehors, non ?
à mon idée : pas besoin des les includer à chaque besoin.

On appelle la fonction, elle mouline et fait son boulot, en fin
d'ouvrage je suppose que le php ou sa mémoire ne garde pas trace de tout
ça ?
hop! un peu + loin on la sollicite encore et ... pareil : finie et
libérée, prête pour ré-emploi

Post by Jean-Francois Ortolo
A moins que ma mémoire me fasse défaut, et que je confonde les require
et les include.

Y a qu'à faire un include, comme ça pas besoin d'y revenir.
(bien qu'il parait que ce sont la même chose, seule l'erreur diffèrerait
en cas d'absence)


'truc.inc' :
function truc($argt) { echo $argt; }

'fonctions.php' :
<?php
include('truc.inc');
function choisir($item) {
switch($item) {
case 'mor': truc('Stephane Moriaux'); break;
case 'ort': truc('Jean-Francois Ortolo'); break;
default : truc('y a personne'); break;
}
}
choisir('des');
?>

je ne vais tt de même pas faire :

function choisir($item) {
switch($item) {
case 'mor': require('truc.inc');
truc('Stephane Moriaux');
break;
case 'ort': require('truc.inc');
truc('Jean-Francois Ortolo');
break;
default : require('truc.inc');
truc('y a personne');
break;
}
}
choisir('ort');


bien que les 2 exemples fonctionnent (même résultat)

et que ce serait mieux :

function choisir($item) {
switch($item) {
case 'mor': truc('Stephane Moriaux');
break;
case 'ort': truc('Jean-Francois Ortolo');
break;
default : truc('y a personne');
break;
}
}
if($truc_ok = @include('truci.inc'))
choisir('mor');
else
echo 'erreur : fonction inexistante';


// appel suivant à la fonction truc :
if($truc_ok) truc('pour voir');
else echo 'toujours HS ce truc !';

[Jean-Francois Ortolo]

Finalement...

A l'aide d'un message de ce ng situé dans un thread plus bas, il me
suffit de spécifier les quelques instructions ci-dessous, au début du
script, pour ne pas avoir de problème de mémoire ( et peut-être de temps
d'exécution ):

ini_set('display_errors', true);
ini_set('post_mas_size', '32M');
ini_set('max_execution_time', '300');
error_reporting(E_ALL);


Les première et dernières instructions, permettent d'afficher toutes
les erreurs, même les warnings et les notice. Inutile de dire que j'en
ai un paquet...

A vrai dire, je ne sais pas si c'est possible d'augmenter le temps
maximum d'exécution, celui par défaut ( 30 secondes ) est dépassé par
mon premier essai. C'est très probable, car le Safe Mode est à Off sur
le serveur. Mais je trouve déjà une erreur, où une variable n'est même
pas alimentée.

Et puis, chose bizarre, j'ai mis les instructions suivantes en début
de script:

$tmp_time = mktime(12, 0, 0, $month, $day, $year);
// Je veux la date du lendemain.
// la valeur rendue par mktime()
// est théoriquement en secondes.
$tmp_time += (24 * 60 * 60);
$first_date = getdate($tmp_time);

$jour = $first_date[mday];
$mois = $first_date[mon];
$an = $first_date[year];

Et là, il me donne une notice, comme quoi les arguments mday , mon et
year ne sont pas des constantes déclarées.

Pourtant j'ai regardé dans le PHP Manual sur les commentaires en
Américain, c'est la bonne syntaxe, sans guillemets, ce qui m'étonne,
puisque $first_date devrait être une array avec ces chaînes de
caractères comme arguments ( "mday" , "mon" et "year" ).

Quand je met des guillemets autour de ces arguments, j'ai une notice
aussi.

Celà veut-il dire que la valeur de $tmp_time n'est pas valable ?

Pour terminer, le temps limite d'exécution, dépassé, qui est une
erreur fatale, est bien indiquée à l'affichage, alors que c'est une
erreur fatale... Le PHP Manual dit que les erreurs fatales ne peuvent
pas être affichées, car le script est déjà arrêté... Qui a raison ?

Merci beaucoup de vos réponses.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

[Olivier Miakinen]

Post by Jean-Francois Ortolo
Et puis, chose bizarre, j'ai mis les instructions suivantes en début
$tmp_time = mktime(12, 0, 0, $month, $day, $year);
// Je veux la date du lendemain.
// la valeur rendue par mktime()
// est théoriquement en secondes.
$tmp_time += (24 * 60 * 60);

En principe, sauf changement d'heure (été/hiver), ceci devrait être
équivalent à :
$tmp_time = mktime(12, 0, 0, $month, $day + 1, $year);
(même le 31 décembre)

Et comme tu ne récupères pas l'heure, tu te fiches des passages été/hiver.

Post by Jean-Francois Ortolo
$first_date = getdate($tmp_time);
$jour = $first_date[mday];
$mois = $first_date[mon];
$an = $first_date[year];
Et là, il me donne une notice, comme quoi les arguments mday , mon et
year ne sont pas des constantes déclarées.

Normal.

Post by Jean-Francois Ortolo
Pourtant j'ai regardé dans le PHP Manual sur les commentaires en
Américain, c'est la bonne syntaxe, sans guillemets,

Par hasard, dans les commentaires en question, il n'y aurait pas des
guillemets autour de l'ensemble de l'expression ? Un truc du genre :
$date = "$first_date[mday]/$first_date[mon]/$first_date[year]";

Post by Jean-Francois Ortolo
ce qui m'étonne,
puisque $first_date devrait être une array avec ces chaînes de
caractères comme arguments ( "mday" , "mon" et "year" ).

Oui.

Post by Jean-Francois Ortolo
Quand je met des guillemets autour de ces arguments, j'ai une notice
aussi.

Laquelle ?

Post by Jean-Francois Ortolo
Celà veut-il dire que la valeur de $tmp_time n'est pas valable ?

Je ne pense pas. Quelle que soit la valeur de l'entier qui lui est
passé, getdate() est censé retourner un tableau correct. Tu peux
essayer avec var_dump pour vérifier.

Post by Jean-Francois Ortolo
Pour terminer, le temps limite d'exécution, dépassé, qui est une
erreur fatale, est bien indiquée à l'affichage, alors que c'est une
erreur fatale... Le PHP Manual dit que les erreurs fatales ne peuvent
pas être affichées, car le script est déjà arrêté... Qui a raison ?

Il dit qu'elles ne peuvent pas être affichées, ou bien qu'elles peuvent
ne pas être affichées ?

[Jean-Francois Ortolo]

Bonjour Monsieur

Finalement...

Le script va très bien avec seulement 8Mo de mémoire, et s'exécute
entièrement en une seconde ou deux pour une période de une semaine de
courses.

Je n'ai plus qu'à vérifier patiemment que les résultats sont
corrects, mais malheureusement, quand j'affiche toutes les serreurs même
minimes, il y a quelques variables non alimentées.

Et puis, les gains des tiercés sont toujours à 0, ce qui n'est pas
normal, mais devrait être facile à détecter.

Dans l'ensemble, je suis très heureux de constater, que la complexité
très forte de ce programme, ne l'enmpêche pas apparemment, de
fonctionner ( tant bien que mal quand même ).

Yahouuu ! C'est parti pour la gloire !

Bien à vous.

Amicalement.

Jean-Francois Ortolo