Probleme memoire

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 :)

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

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

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com

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

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

(snip)

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*.

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

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 ?

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é.

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

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com

Bonjour,

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.

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,
--
Olivier Miakinen

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 ???

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 ?

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>

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.

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 ...

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.

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

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 !';

--
sm

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

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com

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);

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.

$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.

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]";

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.

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

Laquelle ?

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.

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 ?