pas besoins de se faire chier avec un makefile et des '.h'. Tu peux trouver que ça n'est pas fondamentale mais qu'est ce que c'est agréable à l'usage !
ah...
batyann811 wrote:
pas besoins de se faire chier avec un makefile et des '.h'. Tu peux trouver
que ça n'est pas fondamentale mais qu'est ce que c'est agréable à l'usage !
pas besoins de se faire chier avec un makefile et des '.h'. Tu peux trouver que ça n'est pas fondamentale mais qu'est ce que c'est agréable à l'usage !
ah...
JKB
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC) JKB a écrit :
Le 26-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats : > >> Disons que j'ai un soft qui est un serveur en java et qui >> tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu >> ne veux pas que le truc se mette à bouffer toute la mémoire avec >> des connexions TCP (et donc des threads) mortes qui continuent à >> polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre >> de gag. >> > > Des serveurs d'application java qui tournent 24h/24 ce n'est pas > exceptionnel. Je ne vois pas dans quel cas des connexions TCP > pourraient être conservées comme ça. Tu as un exemple (sur un > serveur d'application ou un serveur que tu écris toi-même, qui est > peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java effectivement développé par une équipe maison (qui connaît parfaitement ces technos). Le truc était utilisé entre la France et des pays à accès internet aléatoires que je ne citerais pas. Il a fallu bricoler tout un système pour faire le ménage dans les threads morts sur des timeout de sockets et des trucs plus bizarres encore. Au début, ça se soldait par un redémarrage du truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est stabilisée, mais ça n'a pas été simple. La solution a été de coller un thread de surveillance qui 'pingue' le client. Si le client ne répond pas à trois ping consécutifs, sa session sur le serveur est libérée. Tous les mécanismes prévus par Java fonctionnaient parfaitement avec une socket locale, mais plus avec une socket réseau dès lors que l'accès était de mauvaise qualité.
C'est le délai d'attente (timeout) de la connexion qui ne marche pas ? Ou le client n'est plus connecté mais l'objet de connexion sur le serveur ne le signale pas ?
Hum... dans tous les cas on s'est éloigné de la gestion de la mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions TCP lorsque l'accès réseau est de mauvaise qualité.
>> Le problème de cette gestion des ressources, c'est que ça >> cache tout et que le programmeur qui n'est pas passé par la case C >> ne sait plus exactement ce qui se passe. >> >> JKB >> > > Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un truc comme java ?
JKB
"Directement", ça veut dire sans apprendre à programmer ;) ?
Ça veut dire sans passer par un autre langage où on doit tout faire à la main. Ça permet de fixer les idées avant d'attaquer des langages objets ou à garbage collector.
Pour gérer la mémoire en java, il faut en gros simplement savoir que tout ce qui n'est plus accessible de nulle part est automatiquement libéré. Ca me paraît beaucoup plus facile d'accès que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand il veut. J'ai des exemples d'applications maison où j'ai rajouté un bouton pour forcer son passage et qui libère souvent plus de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça passe encore, la mémoire est rendue au système. Sous Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu qu'à l'application.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 30-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC)
JKB <knatschke@koenigsberg.fr> a écrit :
Le 26-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
>
>> Disons que j'ai un soft qui est un serveur en java et qui
>> tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu
>> ne veux pas que le truc se mette à bouffer toute la mémoire avec
>> des connexions TCP (et donc des threads) mortes qui continuent à
>> polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre
>> de gag.
>>
>
> Des serveurs d'application java qui tournent 24h/24 ce n'est pas
> exceptionnel. Je ne vois pas dans quel cas des connexions TCP
> pourraient être conservées comme ça. Tu as un exemple (sur un
> serveur d'application ou un serveur que tu écris toi-même, qui est
> peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java
effectivement développé par une équipe maison (qui connaît
parfaitement ces technos). Le truc était utilisé entre la France et
des pays à accès internet aléatoires que je ne citerais pas. Il a
fallu bricoler tout un système pour faire le ménage dans les threads
morts sur des timeout de sockets et des trucs plus bizarres encore.
Au début, ça se soldait par un redémarrage du truc tous les jours à
6h00 du matin. Aujourd'hui, la chose est stabilisée, mais ça n'a pas
été simple. La solution a été de coller un thread de surveillance qui
'pingue' le client. Si le client ne répond pas à trois ping
consécutifs, sa session sur le serveur est libérée. Tous les
mécanismes prévus par Java fonctionnaient parfaitement avec une
socket locale, mais plus avec une socket réseau dès lors que l'accès
était de mauvaise qualité.
C'est le délai d'attente (timeout) de la connexion qui ne marche pas ?
Ou le client n'est plus connecté mais l'objet de connexion sur le
serveur ne le signale pas ?
Hum... dans tous les cas on s'est éloigné de la gestion de la mémoire
par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions
TCP lorsque l'accès réseau est de mauvaise qualité.
>> Le problème de cette gestion des ressources, c'est que ça
>> cache tout et que le programmeur qui n'est pas passé par la case C
>> ne sait plus exactement ce qui se passe.
>>
>> JKB
>>
>
> Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un
truc comme java ?
JKB
"Directement", ça veut dire sans apprendre à programmer ;) ?
Ça veut dire sans passer par un autre langage où on doit tout faire
à la main. Ça permet de fixer les idées avant d'attaquer des
langages objets ou à garbage collector.
Pour gérer la mémoire en java, il faut en gros simplement savoir que
tout ce qui n'est plus accessible de nulle part est automatiquement
libéré. Ca me paraît beaucoup plus facile d'accès que savoir faire ça
correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand
il veut. J'ai des exemples d'applications maison où j'ai rajouté un
bouton pour forcer son passage et qui libère souvent plus de 50 % de
la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça
passe encore, la mémoire est rendue au système. Sous Solaris, c'est
souvent beaucoup plus drôle, la mémoire n'est rendu qu'à
l'application.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC) JKB a écrit :
Le 26-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats : > >> Disons que j'ai un soft qui est un serveur en java et qui >> tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu >> ne veux pas que le truc se mette à bouffer toute la mémoire avec >> des connexions TCP (et donc des threads) mortes qui continuent à >> polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre >> de gag. >> > > Des serveurs d'application java qui tournent 24h/24 ce n'est pas > exceptionnel. Je ne vois pas dans quel cas des connexions TCP > pourraient être conservées comme ça. Tu as un exemple (sur un > serveur d'application ou un serveur que tu écris toi-même, qui est > peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java effectivement développé par une équipe maison (qui connaît parfaitement ces technos). Le truc était utilisé entre la France et des pays à accès internet aléatoires que je ne citerais pas. Il a fallu bricoler tout un système pour faire le ménage dans les threads morts sur des timeout de sockets et des trucs plus bizarres encore. Au début, ça se soldait par un redémarrage du truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est stabilisée, mais ça n'a pas été simple. La solution a été de coller un thread de surveillance qui 'pingue' le client. Si le client ne répond pas à trois ping consécutifs, sa session sur le serveur est libérée. Tous les mécanismes prévus par Java fonctionnaient parfaitement avec une socket locale, mais plus avec une socket réseau dès lors que l'accès était de mauvaise qualité.
C'est le délai d'attente (timeout) de la connexion qui ne marche pas ? Ou le client n'est plus connecté mais l'objet de connexion sur le serveur ne le signale pas ?
Hum... dans tous les cas on s'est éloigné de la gestion de la mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions TCP lorsque l'accès réseau est de mauvaise qualité.
>> Le problème de cette gestion des ressources, c'est que ça >> cache tout et que le programmeur qui n'est pas passé par la case C >> ne sait plus exactement ce qui se passe. >> >> JKB >> > > Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un truc comme java ?
JKB
"Directement", ça veut dire sans apprendre à programmer ;) ?
Ça veut dire sans passer par un autre langage où on doit tout faire à la main. Ça permet de fixer les idées avant d'attaquer des langages objets ou à garbage collector.
Pour gérer la mémoire en java, il faut en gros simplement savoir que tout ce qui n'est plus accessible de nulle part est automatiquement libéré. Ca me paraît beaucoup plus facile d'accès que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand il veut. J'ai des exemples d'applications maison où j'ai rajouté un bouton pour forcer son passage et qui libère souvent plus de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça passe encore, la mémoire est rendue au système. Sous Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu qu'à l'application.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
>> Pour te fixer un peu les idées et enfoncer le clou, le >> recours à un goto signifie quasiment toujours que tu essaies de >> récupérer un cas que tu as oublié de traiter, c'est un cataplasme >> sur une jambe de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT >> TOUJOURS. Je le mets en majuscules parce que ta comprenette est >> bouchée à l'émeri. > > C'est pour ca qu'a chaque fois que je vois des goto, ils sont > toujours dans des series de conditions et pointent tous vers un > point unique.
Va jusqu'au bout de ton raisonnement et tu verras que c'est justement l'utilisation du goto la plus mauvaise qui soit. Je ne vais pas essayer de t'expliquer, il me faudrait beaucoup trop de temps, tu prendras une éternité pour comprendre et je n'en ai pas la patience.
Mais par exemple quand tu veux tester le résultat d'une série de fonctions que tu appelles (cas où elles renvoient une valeur indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca évite d'imbriquer des appels qui sont séquentiels juste pour gérer les erreurs.
Je fais généralement ça avec des inline quelque chose et des return. Il n'y a pas de goto dans le code et pas d'imbrication de if () {}.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 30-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
>> Pour te fixer un peu les idées et enfoncer le clou, le
>> recours à un goto signifie quasiment toujours que tu essaies de
>> récupérer un cas que tu as oublié de traiter, c'est un cataplasme
>> sur une jambe de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT
>> TOUJOURS. Je le mets en majuscules parce que ta comprenette est
>> bouchée à l'émeri.
>
> C'est pour ca qu'a chaque fois que je vois des goto, ils sont
> toujours dans des series de conditions et pointent tous vers un
> point unique.
Va jusqu'au bout de ton raisonnement et tu verras que c'est
justement l'utilisation du goto la plus mauvaise qui soit. Je
ne vais pas essayer de t'expliquer, il me faudrait beaucoup trop de
temps, tu prendras une éternité pour comprendre et je n'en ai pas la
patience.
Mais par exemple quand tu veux tester le résultat d'une série de
fonctions que tu appelles (cas où elles renvoient une valeur
indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca
évite d'imbriquer des appels qui sont séquentiels juste pour gérer
les erreurs.
Je fais généralement ça avec des inline quelque chose et des return.
Il n'y a pas de goto dans le code et pas d'imbrication de if () {}.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
>> Pour te fixer un peu les idées et enfoncer le clou, le >> recours à un goto signifie quasiment toujours que tu essaies de >> récupérer un cas que tu as oublié de traiter, c'est un cataplasme >> sur une jambe de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT >> TOUJOURS. Je le mets en majuscules parce que ta comprenette est >> bouchée à l'émeri. > > C'est pour ca qu'a chaque fois que je vois des goto, ils sont > toujours dans des series de conditions et pointent tous vers un > point unique.
Va jusqu'au bout de ton raisonnement et tu verras que c'est justement l'utilisation du goto la plus mauvaise qui soit. Je ne vais pas essayer de t'expliquer, il me faudrait beaucoup trop de temps, tu prendras une éternité pour comprendre et je n'en ai pas la patience.
Mais par exemple quand tu veux tester le résultat d'une série de fonctions que tu appelles (cas où elles renvoient une valeur indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca évite d'imbriquer des appels qui sont séquentiels juste pour gérer les erreurs.
Je fais généralement ça avec des inline quelque chose et des return. Il n'y a pas de goto dans le code et pas d'imbrication de if () {}.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 30-11-2009, ? propos de Re: go, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Yliur wrote:
Mais par exemple quand tu veux tester le résultat d'une série de fonctions que tu appelles (cas où elles renvoient une valeur indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca évite d'imbriquer des appels qui sont séquentiels juste pour gérer les erreurs.
Le Monsieur te dit que c'est de la programmation de merde. Il prefere imbriquer les if jusqu'a plus soif.
Pourtant, c'est evident que le goto permet de gerer proprement ce genre de cas et c'est d'ailleur dans ce genre de contexte qu'il est habituellement utilise.
J'aime bien le _proprement_.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 30-11-2009, ? propos de
Re: go,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Yliur wrote:
Mais par exemple quand tu veux tester le résultat d'une série de
fonctions que tu appelles (cas où elles renvoient une valeur
indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca
évite d'imbriquer des appels qui sont séquentiels juste pour gérer
les erreurs.
Le Monsieur te dit que c'est de la programmation de merde. Il prefere
imbriquer les if jusqu'a plus soif.
Pourtant, c'est evident que le goto permet de gerer proprement ce genre
de cas et c'est d'ailleur dans ce genre de contexte qu'il est
habituellement utilise.
J'aime bien le _proprement_.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 30-11-2009, ? propos de Re: go, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Yliur wrote:
Mais par exemple quand tu veux tester le résultat d'une série de fonctions que tu appelles (cas où elles renvoient une valeur indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca évite d'imbriquer des appels qui sont séquentiels juste pour gérer les erreurs.
Le Monsieur te dit que c'est de la programmation de merde. Il prefere imbriquer les if jusqu'a plus soif.
Pourtant, c'est evident que le goto permet de gerer proprement ce genre de cas et c'est d'ailleur dans ce genre de contexte qu'il est habituellement utilise.
J'aime bien le _proprement_.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
il y a quoi de chiant dans l'utilisation d'un Makefile ?
batyann811
debug this fifo a écrit :
il y a quoi de chiant dans l'utilisation d'un Makefile ?
Ce n'est pas l'utilisation du Makefile qui est chiante. C'est la fait de devoir en écrire un pour pouvoir compiler un projet en C (à moins d'utiliser un IDE bien sûr). En pascal ou en ADA tu tapes un truc genre 'fpc monprog.pas' ou 'gnatmake monprog' et le compilateur va se démerder à compiler tout ce qui est nécessaire. En C avant de pouvoir compiler un projet modulaire tu dois apprendre un autre outil (Make, CMake, Scons, ...).
debug this fifo a écrit :
il y a quoi de chiant dans l'utilisation d'un Makefile ?
Ce n'est pas l'utilisation du Makefile qui est chiante. C'est la fait de
devoir en écrire un pour pouvoir compiler un projet en C (à moins
d'utiliser un IDE bien sûr). En pascal ou en ADA tu tapes un truc genre
'fpc monprog.pas' ou 'gnatmake monprog' et le compilateur va se démerder
à compiler tout ce qui est nécessaire. En C avant de pouvoir compiler un
projet modulaire tu dois apprendre un autre outil (Make, CMake, Scons,
...).
il y a quoi de chiant dans l'utilisation d'un Makefile ?
Ce n'est pas l'utilisation du Makefile qui est chiante. C'est la fait de devoir en écrire un pour pouvoir compiler un projet en C (à moins d'utiliser un IDE bien sûr). En pascal ou en ADA tu tapes un truc genre 'fpc monprog.pas' ou 'gnatmake monprog' et le compilateur va se démerder à compiler tout ce qui est nécessaire. En C avant de pouvoir compiler un projet modulaire tu dois apprendre un autre outil (Make, CMake, Scons, ...).
batyann811
Stephane TOUGARD a écrit :
C'est pas un truc un peu specifiquement C++ le inline ?
C'est une des "nouveautés" du C99.
Stephane TOUGARD a écrit :
C'est pas un truc un peu specifiquement C++ le inline ?
C'est pas un truc un peu specifiquement C++ le inline ?
C'est une des "nouveautés" du C99.
JKB
Le 30-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
Stephane TOUGARD a écrit :
C'est pas un truc un peu specifiquement C++ le inline ?
C'est une des "nouveautés" du C99.
Dis, est-ce que tu as vu à qui tu t'adresses ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 30-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
Stephane TOUGARD a écrit :
C'est pas un truc un peu specifiquement C++ le inline ?
C'est une des "nouveautés" du C99.
Dis, est-ce que tu as vu à qui tu t'adresses ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 30-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
Stephane TOUGARD a écrit :
C'est pas un truc un peu specifiquement C++ le inline ?
C'est une des "nouveautés" du C99.
Dis, est-ce que tu as vu à qui tu t'adresses ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
