Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
function Stop_() {
cond = false;
texte = texte + i;
document.formu.cadran.value = texte;
}
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
function Stop_() {
cond = false;
texte = texte + i;
document.formu.cadran.value = texte;
}
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
function Stop_() {
cond = false;
texte = texte + i;
document.formu.cadran.value = texte;
}
<HTML>
<BODY>
<FORM NAME="formu">
<INPUT NAME="cadran" TYPE="text" SIZE="32" VALUE="0" READONLY>
</FORM>
<SCRIPT LANGUAGE="JavaScript">
var cond = true;
var i = 0;
var id = null;
var texte = "";
id = setTimeout("Stop_();",10);
while (cond) {
i++;
}
function Stop_() {
cond = false;
texte = texte + i;
document.formu.cadran.value = texte;
}
</SCRIPT>
</BODY> </HTML>
<HTML>
<BODY>
<FORM NAME="formu">
<INPUT NAME="cadran" TYPE="text" SIZE="32" VALUE="0" READONLY>
</FORM>
<SCRIPT LANGUAGE="JavaScript">
var cond = true;
var i = 0;
var id = null;
var texte = "";
id = setTimeout("Stop_();",10);
while (cond) {
i++;
}
function Stop_() {
cond = false;
texte = texte + i;
document.formu.cadran.value = texte;
}
</SCRIPT>
</BODY> </HTML>
<HTML>
<BODY>
<FORM NAME="formu">
<INPUT NAME="cadran" TYPE="text" SIZE="32" VALUE="0" READONLY>
</FORM>
<SCRIPT LANGUAGE="JavaScript">
var cond = true;
var i = 0;
var id = null;
var texte = "";
id = setTimeout("Stop_();",10);
while (cond) {
i++;
}
function Stop_() {
cond = false;
texte = texte + i;
document.formu.cadran.value = texte;
}
</SCRIPT>
</BODY> </HTML>
Ok je vois, mais alors là c'est moi qui aimerais comprendre pourquoi
cette ligne rajoutée dans la fonction est bien exécutée ?function Stop_() {
cond = false;
alert("coucou tout le monde !");texte = texte + i;
document.formu.cadran.value = texte;
}
Ok je vois, mais alors là c'est moi qui aimerais comprendre pourquoi
cette ligne rajoutée dans la fonction est bien exécutée ?
function Stop_() {
cond = false;
alert("coucou tout le monde !");
texte = texte + i;
document.formu.cadran.value = texte;
}
Ok je vois, mais alors là c'est moi qui aimerais comprendre pourquoi
cette ligne rajoutée dans la fonction est bien exécutée ?function Stop_() {
cond = false;
alert("coucou tout le monde !");texte = texte + i;
document.formu.cadran.value = texte;
}
Le 22/12/2010 23:03, Newsreader a écrit :Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Ok je vois, mais alors là c'est moi qui aimerais comprendre pourquoi
cette ligne rajoutée dans la fonction est bien exécutée ?function Stop_() {
cond = false;
alert("coucou tout le monde !");texte = texte + i;
document.formu.cadran.value = texte;
}
Le 22/12/2010 23:03, Newsreader a écrit :
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Ok je vois, mais alors là c'est moi qui aimerais comprendre pourquoi
cette ligne rajoutée dans la fonction est bien exécutée ?
function Stop_() {
cond = false;
alert("coucou tout le monde !");
texte = texte + i;
document.formu.cadran.value = texte;
}
Le 22/12/2010 23:03, Newsreader a écrit :Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Ok je vois, mais alors là c'est moi qui aimerais comprendre pourquoi
cette ligne rajoutée dans la fonction est bien exécutée ?function Stop_() {
cond = false;
alert("coucou tout le monde !");texte = texte + i;
document.formu.cadran.value = texte;
}
- OK avec toi pour dire que la méthode que je propose n'est pas valable
pour un test de performance exactement pour les raisons que tu évoques
(opérations 'connexes' au sein de la boucle); c'était juste pour donner
un exemple "quick and dirty" de la fonctionalité.
- La raison pour laquelle cond n'est jamais mise à false : pour le
comprendre, il faudrait déjà commencer par comprendre la nature de
javascript ...
Contrairement à d'autres langages qui sont "multi-tâches", javascript
est un langage interprété "mono-tâche" (single-threaded). Pour faire
simple, l'interpreteur n'execute qu'une seule instructtion à la fois et
de manière séquentielle au cours d'une "boucle d'évènements" (event
loop). Les actions "asynchrones" comme les callback et les timers sont
aussi exécutées de manière séquentielle, c'est à dire lorsque
l'instruction précédente est terminée.
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Voilà ce que, avec ma très faible connaissance du sujet, je voulais dire
en faisant allusion au "script" de javascript. Mais je n'apprend sans
doute rien à un expert comme toi.
- OK avec toi pour dire que la méthode que je propose n'est pas valable
pour un test de performance exactement pour les raisons que tu évoques
(opérations 'connexes' au sein de la boucle); c'était juste pour donner
un exemple "quick and dirty" de la fonctionalité.
- La raison pour laquelle cond n'est jamais mise à false : pour le
comprendre, il faudrait déjà commencer par comprendre la nature de
javascript ...
Contrairement à d'autres langages qui sont "multi-tâches", javascript
est un langage interprété "mono-tâche" (single-threaded). Pour faire
simple, l'interpreteur n'execute qu'une seule instructtion à la fois et
de manière séquentielle au cours d'une "boucle d'évènements" (event
loop). Les actions "asynchrones" comme les callback et les timers sont
aussi exécutées de manière séquentielle, c'est à dire lorsque
l'instruction précédente est terminée.
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Voilà ce que, avec ma très faible connaissance du sujet, je voulais dire
en faisant allusion au "script" de javascript. Mais je n'apprend sans
doute rien à un expert comme toi.
- OK avec toi pour dire que la méthode que je propose n'est pas valable
pour un test de performance exactement pour les raisons que tu évoques
(opérations 'connexes' au sein de la boucle); c'était juste pour donner
un exemple "quick and dirty" de la fonctionalité.
- La raison pour laquelle cond n'est jamais mise à false : pour le
comprendre, il faudrait déjà commencer par comprendre la nature de
javascript ...
Contrairement à d'autres langages qui sont "multi-tâches", javascript
est un langage interprété "mono-tâche" (single-threaded). Pour faire
simple, l'interpreteur n'execute qu'une seule instructtion à la fois et
de manière séquentielle au cours d'une "boucle d'évènements" (event
loop). Les actions "asynchrones" comme les callback et les timers sont
aussi exécutées de manière séquentielle, c'est à dire lorsque
l'instruction précédente est terminée.
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Voilà ce que, avec ma très faible connaissance du sujet, je voulais dire
en faisant allusion au "script" de javascript. Mais je n'apprend sans
doute rien à un expert comme toi.
On 22/12/10 21:51, Newsreader wrote:- OK avec toi pour dire que la méthode que je propose n'est pas valable
pour un test de performance exactement pour les raisons que tu évoques
(opérations 'connexes' au sein de la boucle); c'était juste pour donner
un exemple "quick and dirty" de la fonctionalité.
J'aime pas le Q&D ;)- La raison pour laquelle cond n'est jamais mise à false : pour le
comprendre, il faudrait déjà commencer par comprendre la nature de
javascript ...
Contrairement à d'autres langages qui sont "multi-tâches", javascript
est un langage interprété "mono-tâche" (single-threaded). Pour faire
simple, l'interpreteur n'execute qu'une seule instructtion à la fois et
de manière séquentielle au cours d'une "boucle d'évènements" (event
loop). Les actions "asynchrones" comme les callback et les timers sont
aussi exécutées de manière séquentielle, c'est à dire lorsque
l'instruction précédente est terminée.
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Voilà ce que, avec ma très faible connaissance du sujet, je voulais dire
en faisant allusion au "script" de javascript. Mais je n'apprend sans
doute rien à un expert comme toi.
Je n'ai jamais rencontré de documentation qui mentionne se
fonctionnement. Si tu as un lien vers une source qui explique ce
fonctionnement, je suis preneur. Parce que j'ai eu bon parcourir le
standard d'Ecmascript et tenté de Googler, je ne suis pas tomber sur
quelque chose de pertinent. Ceci dit, ce que tu décris expliquerais bien
pourquoi cond n'est pas mis à jour pendant que la boucle est exécutée.
On 22/12/10 21:51, Newsreader wrote:
- OK avec toi pour dire que la méthode que je propose n'est pas valable
pour un test de performance exactement pour les raisons que tu évoques
(opérations 'connexes' au sein de la boucle); c'était juste pour donner
un exemple "quick and dirty" de la fonctionalité.
J'aime pas le Q&D ;)
- La raison pour laquelle cond n'est jamais mise à false : pour le
comprendre, il faudrait déjà commencer par comprendre la nature de
javascript ...
Contrairement à d'autres langages qui sont "multi-tâches", javascript
est un langage interprété "mono-tâche" (single-threaded). Pour faire
simple, l'interpreteur n'execute qu'une seule instructtion à la fois et
de manière séquentielle au cours d'une "boucle d'évènements" (event
loop). Les actions "asynchrones" comme les callback et les timers sont
aussi exécutées de manière séquentielle, c'est à dire lorsque
l'instruction précédente est terminée.
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Voilà ce que, avec ma très faible connaissance du sujet, je voulais dire
en faisant allusion au "script" de javascript. Mais je n'apprend sans
doute rien à un expert comme toi.
Je n'ai jamais rencontré de documentation qui mentionne se
fonctionnement. Si tu as un lien vers une source qui explique ce
fonctionnement, je suis preneur. Parce que j'ai eu bon parcourir le
standard d'Ecmascript et tenté de Googler, je ne suis pas tomber sur
quelque chose de pertinent. Ceci dit, ce que tu décris expliquerais bien
pourquoi cond n'est pas mis à jour pendant que la boucle est exécutée.
On 22/12/10 21:51, Newsreader wrote:- OK avec toi pour dire que la méthode que je propose n'est pas valable
pour un test de performance exactement pour les raisons que tu évoques
(opérations 'connexes' au sein de la boucle); c'était juste pour donner
un exemple "quick and dirty" de la fonctionalité.
J'aime pas le Q&D ;)- La raison pour laquelle cond n'est jamais mise à false : pour le
comprendre, il faudrait déjà commencer par comprendre la nature de
javascript ...
Contrairement à d'autres langages qui sont "multi-tâches", javascript
est un langage interprété "mono-tâche" (single-threaded). Pour faire
simple, l'interpreteur n'execute qu'une seule instructtion à la fois et
de manière séquentielle au cours d'une "boucle d'évènements" (event
loop). Les actions "asynchrones" comme les callback et les timers sont
aussi exécutées de manière séquentielle, c'est à dire lorsque
l'instruction précédente est terminée.
Dans le cas qui nous intéresse, le timer est bien enregistré mais n'est
jamais exécuté puisque la boucle d'exécution (event loop) ne sort jamais
de la boucle while.
Voilà ce que, avec ma très faible connaissance du sujet, je voulais dire
en faisant allusion au "script" de javascript. Mais je n'apprend sans
doute rien à un expert comme toi.
Je n'ai jamais rencontré de documentation qui mentionne se
fonctionnement. Si tu as un lien vers une source qui explique ce
fonctionnement, je suis preneur. Parce que j'ai eu bon parcourir le
standard d'Ecmascript et tenté de Googler, je ne suis pas tomber sur
quelque chose de pertinent. Ceci dit, ce que tu décris expliquerais bien
pourquoi cond n'est pas mis à jour pendant que la boucle est exécutée.
Ca ne marche pas parce que tu ne ressort jamais de la boucle
while(cond) { i++; } puisque cond est toujours true.
Ben à 10 ms, il y a la fonction Stop_ qui devrait se déclencher
Je crois que cette logique serait valable dans d'autres langages comme Java par exemple.
Ca ne marche pas parce que tu ne ressort jamais de la boucle
while(cond) { i++; } puisque cond est toujours true.
Ben à 10 ms, il y a la fonction Stop_ qui devrait se déclencher
Je crois que cette logique serait valable dans d'autres langages comme Java par exemple.
Ca ne marche pas parce que tu ne ressort jamais de la boucle
while(cond) { i++; } puisque cond est toujours true.
Ben à 10 ms, il y a la fonction Stop_ qui devrait se déclencher
Je crois que cette logique serait valable dans d'autres langages comme Java par exemple.
Citation: 'Dans le monde, il y a deux types de personnes qui lisent la
spécification Ecmascript: ceux qui connaissent JavaScript sur le bout
des doigts et espèrent y découvrir quelquechose qu'ils ne connaitraient
pas encore, et ceux qui ne connaissent rien à JavaScript et espèrent y
retrouver quelquechose qu'ils connaissent déjà."
Je te conseillerais donc de remettre les specs Ecmascript dans un
placard et de réorienter tes lectures vers des ouvrages qui te seront
vraiment utiles pour apprende le langage : "JavaScript pour les nuls"
(280 pages, Editions First) serait peut être un bon début.
Citation: 'Dans le monde, il y a deux types de personnes qui lisent la
spécification Ecmascript: ceux qui connaissent JavaScript sur le bout
des doigts et espèrent y découvrir quelquechose qu'ils ne connaitraient
pas encore, et ceux qui ne connaissent rien à JavaScript et espèrent y
retrouver quelquechose qu'ils connaissent déjà."
Je te conseillerais donc de remettre les specs Ecmascript dans un
placard et de réorienter tes lectures vers des ouvrages qui te seront
vraiment utiles pour apprende le langage : "JavaScript pour les nuls"
(280 pages, Editions First) serait peut être un bon début.
Citation: 'Dans le monde, il y a deux types de personnes qui lisent la
spécification Ecmascript: ceux qui connaissent JavaScript sur le bout
des doigts et espèrent y découvrir quelquechose qu'ils ne connaitraient
pas encore, et ceux qui ne connaissent rien à JavaScript et espèrent y
retrouver quelquechose qu'ils connaissent déjà."
Je te conseillerais donc de remettre les specs Ecmascript dans un
placard et de réorienter tes lectures vers des ouvrages qui te seront
vraiment utiles pour apprende le langage : "JavaScript pour les nuls"
(280 pages, Editions First) serait peut être un bon début.
On 23/12/10 09:54, NewsReader wrote:Je te conseillerais donc de remettre les specs Ecmascript dans un
placard et de réorienter tes lectures vers des ouvrages qui te seront
vraiment utiles pour apprende le langage : "JavaScript pour les nuls"
(280 pages, Editions First) serait peut être un bon début.
Si c'est ça ta référence, j'aurais du mal à prendre au sérieux le
moindre de tes dires.
Et j'attends toujours une source de ce que tu avances. Pour ma part,
j'ai trouvé quelque chose qui va dans ton sens. Ceci dit, l'auteur
précise bien que ça concerne les implémentations côté client de
Javascript :
http://books.google.ie/books?id=2weL0iAfrEMC&lpg=PT277&ots=_82znxW-bG&dq=client%20side%20javascript%20threading%20model&pg=PT277#v=onepage&q=client%20side%20javascript%20threading%20model&fúlse
Mais ça ne me convient pas, ça ne fait pas référence à une autre
documentation qui ferait autorité (comme une spécification).
On 23/12/10 09:54, NewsReader wrote:
Je te conseillerais donc de remettre les specs Ecmascript dans un
placard et de réorienter tes lectures vers des ouvrages qui te seront
vraiment utiles pour apprende le langage : "JavaScript pour les nuls"
(280 pages, Editions First) serait peut être un bon début.
Si c'est ça ta référence, j'aurais du mal à prendre au sérieux le
moindre de tes dires.
Et j'attends toujours une source de ce que tu avances. Pour ma part,
j'ai trouvé quelque chose qui va dans ton sens. Ceci dit, l'auteur
précise bien que ça concerne les implémentations côté client de
Javascript :
http://books.google.ie/books?id=2weL0iAfrEMC&lpg=PT277&ots=_82znxW-bG&dq=client%20side%20javascript%20threading%20model&pg=PT277#v=onepage&q=client%20side%20javascript%20threading%20model&fúlse
Mais ça ne me convient pas, ça ne fait pas référence à une autre
documentation qui ferait autorité (comme une spécification).
On 23/12/10 09:54, NewsReader wrote:Je te conseillerais donc de remettre les specs Ecmascript dans un
placard et de réorienter tes lectures vers des ouvrages qui te seront
vraiment utiles pour apprende le langage : "JavaScript pour les nuls"
(280 pages, Editions First) serait peut être un bon début.
Si c'est ça ta référence, j'aurais du mal à prendre au sérieux le
moindre de tes dires.
Et j'attends toujours une source de ce que tu avances. Pour ma part,
j'ai trouvé quelque chose qui va dans ton sens. Ceci dit, l'auteur
précise bien que ça concerne les implémentations côté client de
Javascript :
http://books.google.ie/books?id=2weL0iAfrEMC&lpg=PT277&ots=_82znxW-bG&dq=client%20side%20javascript%20threading%20model&pg=PT277#v=onepage&q=client%20side%20javascript%20threading%20model&fúlse
Mais ça ne me convient pas, ça ne fait pas référence à une autre
documentation qui ferait autorité (comme une spécification).
