Mon premier pas en PHP5 ...

loufoque wrote:

Python pas moderne...
On aura tout entendu.

alors ! pas de script php ici ? je suis décu !

http://kl2.free.fr/

John Gallet a dit le 28/09/2004 12:51:

Bien sûr que si, à grand coups de #ifdef dans tous
les coins.
Ça, c'est de la bidouille.

Très bien, sachant que php5 n'a même pas 6 mois et qu'on en est déjà la
deuxième release, moi je ne mets pas en prod.
Le fait que PHP, qui est tout de même une grande "entreprise", sorte une

version finale suffit à dire qu'elle est mature pour la production.
Après, si vous préférez rester avec des dinosaures qui ont fait leur
preuve y'a 10 ans, et qui ne sont donc plus supportées par leur créateur
et qui peuvent contenir des bugs connus, c'est votre problème.
Je croyais que le seul problème qu'il y avait pour passer à PHP5 était
l'éventuelle non compatibilité des scripts existants.

En revanche, si effectivement on a maintenant au moins cette partie là
en véritablement portable (j'aime bien le commentaire "Depending on the
environment, Unix domain sockets may not be available") on aura fait un
pas dans la bonne direction de quelque chose de solide et réfléchi.
Ben oui, on peut pas non plus gérer les sockets unix sous du non-unix,

faut pas rêver non plus.
A quand l'extension COM sous linux ?

Relire ce que j'ai écrit. J'ai écrit que c'est chiant (comprendre :
prône à s'emmêler les crayons) de faire tourner les deux sur la même
machine.
C'est on ne peut plus simple.

PHP, par défaut, compile en cgi et en cli. Si on rajoute l'option pour
le module apache dans le configure, il les compile quand même.
Et les différents binaires ont normalement des php.ini totalement
indépendants.

Et accessoirement je ne fais pas tourner une plateforme de
production web sans safe_mode et sans time_limit activé.
Bon, je répète.

Un deamon ne s'execute pas sur un contexte web.
Ce n'est pas le même binaire qui s'occupe de traiter les pages webs et
les scripts en ligne de commande.

Jamais dit le contraire, et j'ai suffisement d'heures de vol en C pour
en être plus que convaincu.
C'est sûr qu'à gros coups d'#ifdef ça doit être encore pire que la normale.

Non sérieusement, ce serait peut-être pas une mauvaise idée d'utiliser
plutôt un kit multi-plateforme (je ne connais que wxwidgets, mais il
doit bien y en avoir sans les fenêtres).

1) parce que c'est l'une des grandes forces de php que d'être PORTABLE.
Indépendant de l'OS. Quand tu as un programme écrit en C, à chaque
nouvel OS, tu peux avoir des gags (alignement mémoire, big-little
endian, etc...) donc une phase de recettage purement technique est
toujours nécessaire. Même entre un SCO et un AIX ou un Solaris, tu ne
compiles pas pareil et tu es obligé d'avoir des #ifdef différents.
PHP est à peu près 100% portable entre tous les posix et unix-like.

Pour Windows, il fait ce qu'il peut, mais faut pas trop en demander non
plus.
La question que je posais était plutôt dans l'esprit "Pourquoi la
portabilité vers windows est-elle si importante ?"

2) parce que l'auteur de la question LE DEMANDE EXPLICITEMENT. Je
réponds à la question, c'est tout.
Il demande "multi-plateforme".

PHP avec l'extension pcntl reste compatible avec tout sauf windows.

On ne peut pas faire un pcntl_fork() sans utiliser cygwin sous windows ?
Pas à ma connaissance.

Je le sais, bien entendu.

C'était une figure de style...

1) c'est ton opinion, c'est aussi la mienne, mais ça ne répond pas à la
question d'origine.
Je crois bien que la question d'origine, on en est loin.

2) et tes watt-milliards de serveurs de dev ? Tu as une équipe de 20
développeurs tous sous windows (parce que c'est comme ça dans la boite
et t'as pas le choix) tu fais COMMENT pour qu'ils testent leur code dans
se pourrir la vie les uns les autres ? Faut arrêter de voir le
développement informatique par le petit bout de la lorgnette. La réalité
de la vie en entreprise fait que moins on a de contraintes sur le
système d'exploitation, mieux ça vaut
Ils ont qu'à utiliser cygwin. Pour un environnement de dev sous windows,

c'est parfait.
Tiens, on peut même leur donner un executable tout prêt avec la dll
cygwin dedans, ils y verront que du feu.
Et puis bon, c'est pas vraiment des développeurs d'après votre
description. Des développeurs s'y connaissent en info normalement.

3) si tu as un contrat à 2 millions d'euros mais que le client te dit
qu'il veut que ça tourne (aussi) sur micromou, tu peux émettre des
réserves et des recommandations mais je t'assure que ça tournera sous
micromou.
Il suffit simplement de lui dire que PHP ne permet pas de gérer les

processus sur windows sans émulation.
Donc, s'il tient tant à windows et ne veut pas d'émulation, il faut
alors effectivement proposer autre chose que PHP.

J'ai pas dit le contraire. Une verrue c'est une excroissance de code
ajoutée / greffée en vrac là où on peut comme on peut. C'est tout.
Oui, alors c'est bien une verrue.

Mais pour moi, une verrue c'est plutôt un truc immonde dont il faut se
débarasser.

Je n'ai vu aucun ajout de fonctionnalités de base du langage qui m'aient
manquées depuis la 4.1.
Pour vos besoins.

Oui et ? Que rapport avec ce que je disais ? Je faisais remarquer que
ces fonctions ont été introduites relativement tard.
De plus dans la série "revenons les pieds sur terre", j'ai encore des
clients qui tournent en php3.
PHP leur recommande fortement de mettre à jour.

Quel que soit le produit d'ailleurs, il faut toujours mettre à jour.

Tout à fait d'accord. Je n'ai pas eut l'occasion de vraiment vérifier,
en conditions de prod, ce qu'il (php) a dans le ventre et ça
m'étonnerait que j'en ai l'occasion avant un moment.
Pour ce que j'ai testé, ça marche plutôt bien.

Après, reste à trouver une situation où ça vaille vraiment le coup de
faire un daemon en PHP plutôt qu'en C.

PS : quand je parle d'une condition de production, je parle d'une
machine 365/H24 sur laquelle transitent des services payants ne
souffrant d'aucune interruption de service, genre bourse en line ou truc
comme ça. Pas de la gestion de contenu avec backend rss...
Heureusement pour moi, je n'ai pas de machine avec de telles

responsabilités.

marc.quinton-PAS-DE-@-SPAM-aviation-civile.gouv.fr wrote:

loufoque wrote:

Python pas moderne...
On aura tout entendu.

alors ! pas de script php ici ? je suis décu !

http://kl2.free.fr/

vous m'excuserez pour ce message a caractère privé, mais a force de
cotoyer les gens dans ce forum, je pense qu'un petit peu comme tout le
monde j'essaie de voir qui je frequente dans les salons mondains ...

que celui qui ne l'a jamais fait me jete la premiere pierre !

marc.quinton-PAS-DE-@-SPAM-aviation-civile.gouv.fr a dit le 28/09/2004

alors ! pas de script php ici ? je suis décu !

http://kl2.free.fr/
Tiens merci pour l'info, je savais pas que c'était encore en ligne.

Je vais pouvoir utiliser ce compte free pour avoir un petit giga de
données sur le net ;).
C'est très vieux, mais il devait y avoir deux-trois trucs en PHP dessus.

Sinon, si vous cherchez un site à moi récent, je n'ai guère que ceci à
vous proposer :
http://phpmybot.sourceforge.net/
Si vous aimez le PHP, ça ne devrait pas vous décevoir.

vous m'excuserez pour ce message a caractère privé, mais a force de
cotoyer les gens dans ce forum, je pense qu'un petit peu comme tout le
monde j'essaie de voir qui je frequente dans les salons mondains ...
Il doit y avoir bien plus intéressant à propos de moi sur le net.

Je pense par exemple à une certaine vidéo... je n'en dis pas plus.

Enfin bon, ces messages sont sans intérêt et totalement hors sujets.

que celui qui ne l'a jamais fait me jete la premiere pierre !
Je peux ?

Re,

Bien sûr que si, à grand coups de #ifdef dans tous
les coins.
Ça, c'est de la bidouille.

M'enfin ! A ton avis il fait comment le code de PHP pour compiler sur la
quasi totalité des OS disponibles ? Et libtool et autoconf et automake ça
sert à quoi ? Si tu connais un moyen autre que les options de compilation
pour écrire du code C portable, fais vite un communiqué de presse, ça fait
30 ans qu'on essaie de faire mieux.

Juste pour rire :
[php-4.3.8]$ find . -type f -exec grep ifdef {} ; |tr -d ' '|tr -d 't'|sort -u |wc -l
926

Il y a plus de 900 options de compilation diférentes dans le code source
de PHP 4.3.8 (et j'ai même enlevé les espaces et les tabus pour pas les
compter plusieurs fois). Donc selon ton "résonnement" php c'est de la
bidouille ?

Le fait que PHP, qui est tout de même une grande "entreprise", sorte une
version finale suffit à dire qu'elle est mature pour la production.
Hum ? C'est pour ça qu'il y a déjà deux releases sans doute ? Il y a prod

et prod. Déployer php5 en tant qu'hébergeur de pages persos, pas de
problèmes, même les RC on peut les mettre. OVH l'a fait par exemple. Sauf
faille de sécurité majeure il n'y a pas beaucoup d'autres risques. Quand
toute interruption de service quelle qu'elle soit coûte 2000 ou 3000 euros
de l'heure en pénalités, c'est pas la même musique.

A quand l'extension COM sous linux ?
On a bien chili-asp alors... pourquoi pas.

Relire ce que j'ai écrit. J'ai écrit que c'est chiant (comprendre :
prône à s'emmêler les crayons) de faire tourner les deux sur la même
machine.
C'est on ne peut plus simple.

PHP, par défaut, compile en cgi et en cli. Si on rajoute l'option pour
le module apache dans le configure, il les compile quand même.

Je n'avais jamais remarqué. Mais comme les options de compilation sont
justement différentes pour l'un et l'autre je persiste à penser que c'est
facile de se mélanger les crayons lors de la compilation (pas lors de la
livraison sur la machine de prod, vu qu'en effet, les binaires sont bien
séparés de nom).

Et les différents binaires ont normalement des php.ini totalement
indépendants.
Si tu le dis, je te crois (pas le temps de vérifier) mais il me semblait

avoir joué avec un --with-config-file ou truc du genre.

Et accessoirement je ne fais pas tourner une plateforme de
production web sans safe_mode et sans time_limit activé.
Bon, je répète.

Un deamon ne s'execute pas sur un contexte web.
Ce n'est pas le même binaire qui s'occupe de traiter les pages webs et
les scripts en ligne de commande.

Bon je répète aussi : si je veux avoir les deux sur la même machine, il va
bien falloir que :
- je les compile (ailleurs, pas de compilos sur une machine de prod)
chacun avec les bonnes options de compilation
- je les déploie (facile, pas le même nom)
- je les configure (donc qu'ils pointent vers des php.ini différents).

Jamais dit le contraire, et j'ai suffisement d'heures de vol en C pour
en être plus que convaincu.
C'est sûr qu'à gros coups d'#ifdef ça doit être encore pire que la

normale.

C'est la seule solution que je connaisse en C.

Non sérieusement, ce serait peut-être pas une mauvaise idée d'utiliser
plutôt un kit multi-plateforme (je ne connais que wxwidgets, mais il
doit bien y en avoir sans les fenêtres).

Et tu vas trouver où un "kit" (une librairie) de fonctions bas niveau
(réseau, shared mem, file system etc...) qui prenne en compte VMS + tous
types d'unix plus windows en C ? Je suis preneur si tu as (enfin
maintenant on s'en fout, le développement a comencé en 1996 donc on
va pas tout foutre à la poubelle).

La question que je posais était plutôt dans l'esprit "Pourquoi la
portabilité vers windows est-elle si importante ?"

Pardon, j'avais pas compris. Par exemple parce que c'est une force de ton
produit que de pouvoir dire "Je me fous de savoir ce que vous avez comme
OS et comme SGBD, je suis capable de les utiliser. Je vous conseille un
unix et postgresql, mais je sais gérer tout ce que vous avez à
disposition.". Quand tu arrives dans un grand groupe bancaire qui n'a
**que** du windows+sqlserver, tu ne va pas leur demander de te mettre une
linux+mysql dans un coin, on te rira au nez et on passera à l'audition du
concurrent suivant. **C'est TRES, TRES, TRES CON mais C'EST LA TRISTE
REALITE.** A noter qu'à certains endroits même, ou tu proposes du java ou
de toutes façons tu vas te rhabiller. C'est encore plus débile, mais c'est
comme ça. Dire qu'on est compatible micromou, dans l'esprit de beaucoup de
"décideurs", c'est un gage de "compatibilité" et donc de qualité. Position
techniquement indéfendable, mais c'est comme ça.

Pas à ma connaissance.
Je le sais, bien entendu.

C'était une figure de style...
Je ne suis pas nécessairement au courant des dernières évolutions de

toutes les extensions. Donc cela aurait pu changer.

Ils ont qu'à utiliser cygwin. Pour un environnement de dev sous windows,
c'est parfait.
C'est pas parfait à mon sens mais j'ai vu pire.

Tiens, on peut même leur donner un executable tout prêt avec la dll
cygwin dedans, ils y verront que du feu.
Et puis bon, c'est pas vraiment des développeurs d'après votre
description. Des développeurs s'y connaissent en info normalement.

Et si l'informatique interne ne te permet même pas d'installer un
exécutable sur ta bécane, que tu as déjà dû batailler pour avoir un CD
d'install de certaines applications tu fais comment ?
Je crois qu'il y a un malentendu assez violent : je ne dis pas des choses
pour me faire mousser, je ne fais que donner des retours d'expérience de
la vraie vie en entreprise, où parfois il faut déjà se battre pour avoir
de quoi bosser. Quand je dis quelque chose c'est parce que j'ai déjà été
confronté au problème, pas pour le plaisir de faire bouger des électrons.

Quel que soit le produit d'ailleurs, il faut toujours mettre à jour.
Oui et non. La course à la version ne fait qu'amener des emmerdements et

c'est bien comme ça que micromou se fait des c.. en or (mais je m'égare).

Tout à fait d'accord. Je n'ai pas eut l'occasion de vraiment vérifier,
en conditions de prod, ce qu'il (php) a dans le ventre et ça
m'étonnerait que j'en ai l'occasion avant un moment.
Pour ce que j'ai testé, ça marche plutôt bien.

C'est bon à savoir.

Après, reste à trouver une situation où ça vaille vraiment le coup de
faire un daemon en PHP plutôt qu'en C.
Ca fait des années que je le répète, ici et ailleurs : à chaque besoin la

solution qui lui est la plus adaptée. Donc si c'est fiable, il y a
probablement des situations où ce serait approprié.

PS : quand je parle d'une condition de production, je parle d'une
machine 365/H24 sur laquelle transitent des services payants ne
souffrant d'aucune interruption de service, genre bourse en line ou
truc comme ça. Pas de la gestion de contenu avec backend rss...
Heureusement pour moi, je n'ai pas de machine avec de telles

responsabilités.

C'est peut-être justement là la différence d'approche du sujet que nous
avons... Les circonstances ne sont pas les mêmes.

a++
JG

marc.quinton-PAS-DE-@-SPAM-aviation-civile.gouv.fr a dit le 28/09/2004

alors ! pas de script php ici ? je suis décu !

http://kl2.free.fr/

Tiens merci pour l'info, je savais pas que c'était encore en ligne.
Je vais pouvoir utiliser ce compte free pour avoir un petit giga de
données sur le net ;).
C'est très vieux, mais il devait y avoir deux-trois trucs en PHP dessus.

Sinon, si vous cherchez un site à moi récent, je n'ai guère que ceci à
vous proposer :
http://phpmybot.sourceforge.net/
Si vous aimez le PHP, ça ne devrait pas vous décevoir.

tres joli travail ! ca ne me sert a rien, mais c'est tres bien documenté
et tres bien fait. Bravo.

est-ce que tu as regardé la classe Pear : Net:Irc ?

pourquoi est-ce que tu as fait ceci :

function Message()
{
$args = func_get_args();
call_user_func_array(array(&$this, '__construct'), $args);
}



et pourquoi pas un tout simple $this->construct() ?

petite remarque : la liste des define est tres propre, mais apres
son usage n'est pas forcément tres propice a la creation d'une
hérarchie d'objets ayant chacun un role précis a jouer. Et par voie
concéquence tu te retrouve avec un immence switch dans

Message::__construct().

facile a dire, mais maintenant je ne saurais pas te dire comment faire
sans s'y plonger un peu plus.

encore bravo pour ce joli travail.

Marc a dit le 29/09/2004 08:52:

tres joli travail ! ca ne me sert a rien, mais c'est tres bien documenté
et tres bien fait. Bravo.
C'est bien documenté ? La documentation est pourtant quasi-inexistante non ?

est-ce que tu as regardé la classe Pear : Net:Irc ?
J'ai voulu créer mon propre truc.

J'ai regardé, et effectivement c'est un peu pareil mais mon API est bien
plus puissante (enfin bon, c'est mon truc aussi, alors c'est adapté à
mes besoins).

pourquoi est-ce que tu as fait ceci :
[...]
Simplement pour m'affranchir de la méthode Message.

Si jamais je veux modifier les arguments passés à __construct(), je n'ai
alors pas à remodifier Message.

Pour le "parsing" des messages, je n'ai pas vraiment de meilleure idée.

Python est sorti aprés php si je ne m'abuse.

euh non, pas vraiment (je faisais du python en 1996 !)

a+