Combien de temps vas-tu passer pour débugger ? A mettre dans la balance également.
En l'occurrence, ce que je débuggue, c'est le couple apache2 + mon CGI. En simulant du CGI normal, c'est à dire en passant les arguments GET via $QUERY_STRING et les arguments POST ( pardon pour les grossiers raccourcis ) via GET, je n'ai aucun problème, ce qui m'a aussi permis de mettre en place des tests unitaires.
Je ne prétends pas que le bug viens d'apache, juste que j'ai dû rater un détail, et pour le trouver, gdb m'aiderait pas mal.
Quand ce sera le cas, je ferais un TU pour pas qu'il revienne :)
Et juste par curiosité, tu utilises quel langage ?
C++. En utilisant le dernier standard ( C++11 ).
Peut-être pas ce qu'il y a de plus simple, peut-être, mais dès l'instant que je peux manipuler des chaînes de caractères correctement et facilement ( et le dernier standard aide pas mal pour ça ), avoir un langage avec typage statique ( oui j'y tiens ), me permettant d'utiliser à la fois la POO et la RAII, qui soit standardisé par un organisme qui aime la compatibilité ascendante ( C++ dans 10 ans compilera toujours mon programme, c'est important car il risque effectivement d'être utilisé pendant plusieurs années, sans avoir besoin d'être modifié ) et avec lequel je suis à l'aise... je pense que dans les contraintes que j'ai, ce n'est pas le pire.
A ce que j'ai lu a divers endroits, python, par exemple pourrais poser des problèmes ( certains se sont plains ici et là de ne pas pouvoir utiliser du code ancien sans devoir le modifier, notamment. Pas acceptable dans mon cas. ).
D'autres langages, comme php, ne sont pas typés, ou très faiblement, et je veux un truc ou l'outil qui lit mon code me dise que je vais avoir un problème. D'autres encore, genre perl, produisent du code qui, dans mon humble opinion, est peu lisible ( je m'y suis déjà essayé ).
Je ne dis pas que C++ est la panacée, mais qu'il me semble adapté à mon besoin actuel en fonction de mes contraintes actuelles.
Sans parler du fait que je préfère éviter de multiplier les technos employées en prod, et qu'a l'heure actuelle, php et C++ sont les 2 seuls langages utilisés.
C'est pas du web interactif ça ?
J'imagine que ça dépends de la définition d'interactif. Pour moi, interactif, ça veut dire qu'au cours de l'exécution du programme, l'utilisateur peut envoyer de nouvelles requêtes ( au sens général du terme ) à un logiciel qui se souviens du contexte. Ce qui implique un mécanisme d'identification de l'utilisateur ( pour interagir, on doit savoir identifier son interlocuteur ), par exemple les cookie pour le web.
Si on faisait le parallèle avec les applications sur terminal, on peut entendre par interactif une application qui pose des questions ( scanf, pour du C ) de façon bloquante ou non ( non bloquant impliquant soit que l'on mets un timeout sur les entrées, soit que l'on joue dans la cours du multi-thread ).
Genre aptitude, ncmpcpp, apt-get ( pas ncurses, mais il me semble qu'apt-get pose des questions via scanf ) ...
Alors que non interactif serait plutôt les applications qui une fois invoquées ne font que traiter la requête ( en général en utilisant uniquement les arguments passés via ligne de commande, vu que lorsqu'elles lisent l'entrée standard, il arrive qu'elles puissent interagir, comme less ) sans pouvoir être interrompues ( vu que les signaux sont plus une façon de résoudre le problème d'une application trop lente... ou trop bugguée. En général. ).
Http est prévu, à ce que j'en sais ( cf prochaine parenthèse ), pour ne pas être interactif, mais les cookies, entres autres ( phpssessid aussi, ou un truc du genre? suis mauvais en dev web...) , sont un workaround qui permets de le rendre interactif.
voir un des liens que je t'ai proposé comme piste de départ
J'ai commencé à lire tes liens, il y a des chances que ça me mette sur des pistes sympa. La config d'apache n'est vraiment pas simple à gérer à mon niveau malheureusement. ( mais bon, c'est ça qui est en prod... )
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
En l'occurrence, ce que je débuggue, c'est le couple apache2 + mon CGI. En simulant du CGI normal, c'est à dire en passant les arguments GET via $QUERY_STRING et les arguments POST ( pardon pour les grossiers raccourcis ) via GET, je n'ai aucun problème, ce qui m'a aussi permis de mettre en place des tests unitaires.
Je ne prétends pas que le bug viens d'apache, juste que j'ai dû rater un détail, et pour le trouver, gdb m'aiderait pas mal.
Quand ce sera le cas, je ferais un TU pour pas qu'il revienne :)
C++. En utilisant le dernier standard ( C++11 ).
Peut-être pas ce qu'il y a de plus simple, peut-être, mais dès l'instant que je peux manipuler des chaînes de caractères correctement et facilement ( et le dernier standard aide pas mal pour ça ), avoir un langage avec typage statique ( oui j'y tiens ), me permettant d'utiliser à la fois la POO et la RAII, qui soit standardisé par un organisme qui aime la compatibilité ascendante ( C++ dans 10 ans compilera toujours mon programme, c'est important car il risque effectivement d'être utilisé pendant plusieurs années, sans avoir besoin d'être modifié ) et avec lequel je suis à l'aise... je pense que dans les contraintes que j'ai, ce n'est pas le pire.
A ce que j'ai lu a divers endroits, python, par exemple pourrais poser des problèmes ( certains se sont plains ici et là de ne pas pouvoir utiliser du code ancien sans devoir le modifier, notamment. Pas acceptable dans mon cas. ).
D'autres langages, comme php, ne sont pas typés, ou très faiblement, et je veux un truc ou l'outil qui lit mon code me dise que je vais avoir un problème. D'autres encore, genre perl, produisent du code qui, dans mon humble opinion, est peu lisible ( je m'y suis déjà essayé ).
Je ne dis pas que C++ est la panacée, mais qu'il me semble adapté à mon besoin actuel en fonction de mes contraintes actuelles.
Sans parler du fait que je préfère éviter de multiplier les technos employées en prod, et qu'a l'heure actuelle, php et C++ sont les 2 seuls langages utilisés.
J'imagine que ça dépends de la définition d'interactif. Pour moi, interactif, ça veut dire qu'au cours de l'exécution du programme, l'utilisateur peut envoyer de nouvelles requêtes ( au sens général du terme ) à un logiciel qui se souviens du contexte. Ce qui implique un mécanisme d'identification de l'utilisateur ( pour interagir, on doit savoir identifier son interlocuteur ), par exemple les cookie pour le web.
Si on faisait le parallèle avec les applications sur terminal, on peut entendre par interactif une application qui pose des questions ( scanf, pour du C ) de façon bloquante ou non ( non bloquant impliquant soit que l'on mets un timeout sur les entrées, soit que l'on joue dans la cours du multi-thread ).
Genre aptitude, ncmpcpp, apt-get ( pas ncurses, mais il me semble qu'apt-get pose des questions via scanf ) ...
Alors que non interactif serait plutôt les applications qui une fois invoquées ne font que traiter la requête ( en général en utilisant uniquement les arguments passés via ligne de commande, vu que lorsqu'elles lisent l'entrée standard, il arrive qu'elles puissent interagir, comme less ) sans pouvoir être interrompues ( vu que les signaux sont plus une façon de résoudre le problème d'une application trop lente... ou trop bugguée. En général. ).
Http est prévu, à ce que j'en sais ( cf prochaine parenthèse ), pour ne pas être interactif, mais les cookies, entres autres ( phpssessid aussi, ou un truc du genre? suis mauvais en dev web...) , sont un workaround qui permets de le rendre interactif.
J'ai commencé à lire tes liens, il y a des chances que ça me mette sur des pistes sympa. La config d'apache n'est vraiment pas simple à gérer à mon niveau malheureusement. ( mais bon, c'est ça qui est en prod... )