Limitation de délai dans des scripts (IE)

Bonjour,

"Sylvain SF" <sylvain@boiteaspam.info> a écrit dans le message de news:483bf805$0$931$ba4acef3@news.orange.fr...

CriCri wrote on 27/05/2008 12:13:
>
> Merci pour ta réponse - enfin à la question posée (et non pas d'autres!).

si tu penses que compter le nombre de statements JS exécutés - dépendent
de la freq. du CPU - et que forcer chaque visiteur à modifier sa BdR
est la solution à ton problème, c'est - je le crains - que tu ne te
poses pas les bonnes questions.

donc merci pour ceux qui avaient fait l'effort de dépasser la mauvaise
question posée pour apporter une aide utile.

T'inquiète, tôt ou tard, il sera obligé d'y venir à une de nos solutions,
le tout est qu'il prenne la peine de réfléchir sérieusement au problème.

PS:Cela va lui en faire des déplacements s'il doit changer la BdR de tout
ceux qu'ils vont consulter sa page, surtout au prix du baril actuellement.

Salut

Michel_D a écrit :

Non, c'est l'action de l'utilisateur qui arrête la tempo, s'il ne
fait rien la tempo se poursuit d'ou le setInterval() pour le test de
l'action de l'utilisateur.

Mais je veux qu'après une éventuelle choix initiale du délai,
l'utilisateur n'ait plus aucune action à faire...


--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net

Sylvain SF a écrit :

si tu penses que compter le nombre de statements JS exécutés -
dépendent de la freq. du CPU - et que forcer chaque visiteur à
modifier sa BdR est la solution à ton problème, c'est - je le crains
- que tu ne te poses pas les bonnes questions.

Pas de pb - c'est pour un usage interne.
A propos, on s'en fiche aussi si ça occupe le processeur à 99% parce que
pendant la démo l'ordinateur n'aura rien d'autre à faire.

donc merci pour ceux qui avaient fait l'effort de dépasser la
mauvaise question posée pour apporter une aide utile.

Oui - en effet, merci bien pour l'effort; mais la solution - je la
cherche encore, parce que je ne crois pas que celles proposées
s'avéreront utiles.

@+

--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net

Salut

Sylvain SF a écrit :
>
>> La faille est que ni setTimeout() ni setInterval() bloque le script,
>
> ils ne bloquent pas et c'est ce que l'on attend d'eux

C'est précisément le problème: il n'y a pas la fonction habituelle
wait() qui permet à un thread (script) de suspendre sa propre exécution
jusqu'à ce qu'une certaine condition est remplie (laps de temps dans le
cas présent...).

> quelle exécution serait continuée ??

En fait je n'ai fait qu'esquisser le mode de fonctionnement.
Il n'y a pas de séparation entre le calcul et l'affichage: le résultat
est affiché en temps réel, correspondant aux valeurs actuelles des
données. Ça fait qu'il est illisible car il change trop vite (c'est
voulu, donnant du mouvement à la démonstration); d'où la nécessité de
geler l'exécution le temps d'visualiser l'étape courante.

Je ne veux que l'une des 3 possibilités:
- l'utilisateur choisit le délai au début (ma préférence car aucune
intervention ultérieure est nécessaire de sa part, et il peut y avoir
plusieurs personnes regardant en même temps.)
- il clique sur "Continuer" ou appuie sur une touche quand il est prêt.

> à la sortie de 'affiche' l'exécution de affiche est arrétée. à la
sortie de 'afficheEtape' l'exécution de afficheEtape est arrétée.

Les deux sont intimement imbriqués; et pour les dissocier il faudrait
repenser l'algorithme entier en créant des structures de données
(tableaux) statiques pour enregistrer chaque étape à afficher.
Actuellement l'unique fonction est récursive (les appels atteignent une
profondeur de plus de 15000) et toutes les variables sont locales (donc
stockées brièvement sur la pile). Difficile donc de marquer un point,
arrêter puis y retourner.

> c'est le but de setTimeout(afficheEtape, delaiUtilisateur);

Non, le but de setTimeout() est de déclencher une action indépendamment
de l'exécution du script en cours.

> et autant n'utilise pour cela un boucle bloquante - enfin pas depuis
plus de 10 ans et la génération de la programmation évènementielle.

Même il y a beaucoup plus de 10 ans dans n'importe quel environnement
multi-tâche (ou non) il y avait un gestionnaires d'évènements et/ou une
fonction wait() non-bloquants.
En tout cas on est toujours 'événementiel' même si on est 'orienté
objet': on ne passe pas quand même son temps à interroger chaque objet à
tour de rôle pour savoir s'il a envie de quelque chose, mais sommeille
en attendant un message...

Christophe

--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net

Salut

Sylvain SF a écrit :

La faille est que ni setTimeout() ni setInterval() bloque le
script,

ils ne bloquent pas et c'est ce que l'on attend d'eux

C'est précisément le problème: il n'y a pas la fonction habituelle
wait() qui permet à un thread (script) de suspendre sa propre exécution
jusqu'à ce qu'une certaine condition est remplie (laps de temps dans le
cas présent...).

quelle exécution serait continuée ??

En fait je n'ai fait qu'esquisser le mode de fonctionnement.
Il n'y a pas de séparation entre le calcul et l'affichage: le résultat
est affiché en temps réel, correspondant aux valeurs actuelles des
données. Ça fait qu'il est illisible car il change trop vite (c'est
voulu, donnant du mouvement à la démonstration); d'où la nécessité de
geler l'exécution le temps d'visualiser l'étape courante.

Je ne veux que l'une des 3 possibilités:
- l'utilisateur choisit le délai au début (ma préférence car aucune
intervention ultérieure est nécessaire de sa part, et il peut y avoir
plusieurs personnes regardant en même temps.)
- il clique sur "Continuer" ou appuie sur une touche quand il est prêt.

à la sortie de 'affiche' l'exécution de affiche est arrétée. à la
sortie de 'afficheEtape' l'exécution de afficheEtape est arrétée.

Les deux sont intimement imbriqués; et pour les dissocier il faudrait
repenser l'algorithme entier en créant des structures de données
(tableaux) statiques pour enregistrer chaque étape à afficher.
Actuellement l'unique fonction est récursive (les appels atteignent une
profondeur de plus de 15000) et toutes les variables sont locales (donc
stockées brièvement sur le tas). Difficile donc de marquer un point,
arrêter puis y retourner.

c'est le but de setTimeout(afficheEtape, delaiUtilisateur);

Non, le but de setTimeout() est de déclencher une action indépendamment
de l'exécution du script en cours.

et autant n'utilise pour cela un boucle bloquante - enfin pas depuis
plus de 10 ans et la génération de la programmation évènementielle.

Même il y a beaucoup plus de 10 ans dans n'importe quel environnement
multi-tâche il y avait un gestionnaires d'évènements et/ou une fonction
wait() non-bloquants.
En tout cas on est toujours 'événementiel' même si on est 'orienté
objet': on ne passe pas quand même son temps à interroger chaque objet à
tour de rôle pour savoir s'il a envie de quelque chose, mais sommeille
en attendant un message...

Christophe

--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net

CriCri wrote on 27/05/2008 17:42:

C'est précisément le problème: [...]

quand on veux pas comprendre ...

Il n'y a pas de séparation entre le calcul et l'affichage [...]
d'où la nécessité de geler l'exécution le temps d'visualiser

et donc tout le monde mettrait ici le settimeout

Je ne veux que l'une des 3 possibilités:
- l'utilisateur choisit le délai au début (ma préférence car aucune
intervention ultérieure est nécessaire de sa part, et il peut y avoir
plusieurs personnes regardant en même temps.)

dans mon exemple 'afficheEtape' peut lire un input field
que l'utilisateur a le droit de modifier à tout moment.

- il clique sur "Continuer" ou appuie sur une touche quand il est prêt.

pas clair.

à la sortie de 'affiche' l'exécution de affiche est arrétée. à la
sortie de 'afficheEtape' l'exécution de afficheEtape est arrétée.

et c'est le but, arrété entre 0 ms et ce que tu veux avec la GROSSE
différence que le browser remets le compteur de temps d'exécution à
zéro entre chaque appel fait par settimeout.

Les deux sont intimement imbriqués; et pour les dissocier il faudrait
repenser l'algorithme entier en créant des structures de données
(tableaux) statiques pour enregistrer chaque étape à afficher.
Actuellement l'unique fonction est récursive (les appels atteignent une
profondeur de plus de 15000) et toutes les variables sont locales (donc
stockées brièvement sur le tas). Difficile donc de marquer un point,
arrêter puis y retourner.

la récursivité n'est jamais obligeatoire - ie il existe toujours
un algo non récursif pour faire la même chose.
il suffira alors de mettre les variabes en globales pour ne pas
perdre l'état courant.

c'est le but de setTimeout(afficheEtape, delaiUtilisateur);

Non, le but de setTimeout() est de déclencher une action indépendamment
de l'exécution du script en cours.

tu sors cette définition interprétée et restrictive d'où ?
ça sert à déclencher une action avec un retard paramétré, point.

Même il y a beaucoup plus de 10 ans dans n'importe quel environnement
multi-tâche il y avait un gestionnaires d'évènements et/ou une fonction
wait() non-bloquants.

et un navigateur est un tel env. multi-tache ? non !
il fait plusieurs trucs distincts (charger n images via n urls)
plus ou moins en même temps, ce ne fait pas du tout un système
avec gestion fine des threads.

En tout cas on est toujours 'événementiel' même si on est 'orienté
objet': on ne passe pas quand même son temps à interroger chaque objet à
tour de rôle pour savoir s'il a envie de quelque chose, mais sommeille
en attendant un message...

relire settimeout ! on n'interroge pas personne, le script (un
script membre d'un object JS) demande lui-même d'être appellé.

Sylvain.

Salut

Sylvain SF a écrit :

quand on veux pas comprendre ...

Oui. Apparemment tu ne veux pas comprendre qu'il manque à JavaScript une
fonction importante: celle de pouvoir attendre une échéance sans bloquer
(ou tout au moins ralentir) l'exécution d'autre tâches...

et donc tout le monde mettrait ici le settimeout

Apparemment tu n'as toujours pas saisi le fait que setTimeout() n'a
_aucun_ effet que ce soit sur l'exécution du script qui l'appelle.

dans mon exemple 'afficheEtape' peut lire un input field que
l'utilisateur a le droit de modifier à tout moment.

Dans mon exemple l'utilisateur n'a le droit de _rien_ modifier: il n'a
qu'à regarder ce qui s'affiche...

- il clique sur "Continuer" ou appuie sur une touche quand il est
prêt.

pas clair.

...ou tout au plus s'il s'ennuie trop il peut précipiter le passage à la
prochaine étape.

et c'est le but, arrété entre 0 ms et ce que tu veux avec la GROSSE
différence que le browser remets le compteur de temps d'exécution à
zéro entre chaque appel fait par settimeout.

Encore une fois, _rien_ du tout ne s'arrête: c'est ça la GROSSE différence.

la récursivité n'est jamais obligeatoire - ie il existe toujours un
algo non récursif pour faire la même chose.

Ouais, ouais - au lieu d'appeler la même fonction récursivement tu en
écris 36000 quasiment identiques pour faire exactement la même chose.
Comme tu le dis la récursivité n'est jamais obligatoire mais c'est très
souvent le solution la plus concise et élégante.

il suffira alors de mettre les variabes en globales pour ne pas
perdre l'état courant.

- primo les variables globales sont toujours à éviter autant que
possible - par principe.
- deuzio elles prennent de la place (disque et mémoire) - mais de nos
jours on en a tant que tout le monde s'en fout à un point pas possible.

tu sors cette définition interprétée et restrictive d'où ?

Je la sors de la définition du langage (désolé pour l'english):
"The setTimeout() method evaluates an expression or calls a function
after a specified amount of time...

...setTimeout() does not stall the script. The script continues
immediately (not waiting for the timeout to expire). The call simply
schedules a future event."

Càd qu'un appel à setTimeout() n'a absolument aucun effet que ce soit
sur l'exécution ininterrompue d'un script; mais ne fait que programmer
un évènement futur - lié ou non au script qui l'appelle.

et un navigateur est un tel env. multi-tache ? non !

Une page HTML est normalement un environnement 'non-modal' qui contient
habituellement maintes éléments (objets) dont chacun peut être associé à
une action (le principe DOM) non-bloquante.
Par exemple, à partir de boutons, de menus ou d'autres objets quelconque
tu peux lancer plusieurs tâches indépendamment dans d'autres frames de
la même fenêtre ou bien dans de nouvelles fenêtres différentes.

il fait plusieurs trucs distincts (charger n images via n urls) plus
ou moins en même temps, ce ne fait pas du tout un système avec
gestion fine des threads.

Aucun système mono-processeur n'exécute des tâches autrement que "plus
ou moins en même temps". Le temps est toujours partagé: donc il n'y a
aucune différence de fond.
Un SE multi-tâche le gère à sa façon selon des priorités définies et de
la préemption ou pas: pour un navigateur c'est plus compliqué - ça
dépend de l'envoi de paquets intercalés et le délai d'arrivée des
réponses de serveurs différents. Tu as certainement raison que la
gestion n'est pas fine.

relire settimeout ! on n'interroge pas personne, le script (un script
membre d'un object JS) demande lui-même d'être appellé.

Comprends pas du tout ce que tu veux dire par là.

Christophe

--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net

Le mercredi 28 mai 2008 00:47, CriCri s'est exprimé de la sorte sur
fr.comp.os.ms-windows :

Oui. Apparemment tu ne veux pas comprendre qu'il manque à JavaScript une
fonction importante: celle de pouvoir attendre une échéance sans bloquer
(ou tout au moins ralentir) l'exécution d'autre tâches...

Javascript ne peut pas exécuter plusieurs tâches en même temps.

--
@+
Doug - Linux user #307925 - Gentoo rocks ;-)
[ Plus ou moins avec une chance de peut-être ]

Salut

Doug713705 a écrit :

Javascript ne peut pas exécuter plusieurs tâches en même temps.

Bien sûr que si: il peut exécuter une tâche dans Internet Explorer, une
tâche dans SeaMonkey, une tâche dans Opéra...

Mais sans blague, pourquoi ne peut-il pas exécuter une tâche dans
chacune de plusieurs fenêtres du même navigateur?
J'avoue que je n'y avais jamais pensé, mais sur le coup ça me paraîtrait
normal...

Et encore tu me fais réfléchir - p. ex. un script différent peut être
associé indépendamment à chaque objet dans une seule fenêtre: qu'est-ce
qui empêche un thread d'être créé pour chacun?

Ensuite: la fameuse fonction setTimeout(): le script qui l'appelle
continue à s'exécuter dans l'attente du lancement de la fonction
programmée; mais le moment venu il ne s'arrête pas quand cette fonction
démarre.

Donc il me semble que c'est une bonne question à approfondir.

Amicalement
CriCri

--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net

CriCri wrote on 28/05/2008 00:47:

et donc tout le monde mettrait ici le settimeout

Apparemment tu n'as toujours pas saisi le fait que setTimeout() n'a
_aucun_ effet que ce soit sur l'exécution du script qui l'appelle.

arrête l'arrogance et essaie de comprendre / lire les docs.
sinon inutile de demander conseil.

heureusement que settimeout n'a AUCUN effet sur le code appelant
ce n'est pas son but, apparement tu n'as pas compris que settimeout
rien *immédiatement* la main, il poste uniquement un équivalent
d'event timer.

pour la dernière fois, tu dois gérer ton affichage comme la
séquence:

- un affichage limité (un pas d'animation ou je ne sais quoi)
- rien du tout
- un affichage limité (un pas d'animation ou je ne sais quoi)
- rien du tout
- un affichage limité (un pas d'animation ou je ne sais quoi)

le rien du tout étant le temps, potentiellement nul, où
settimeout rapelle à nouveau ta méthode.

Encore une fois, _rien_ du tout ne s'arrête: c'est ça la GROSSE différence.

ce n'est pas mon problème si ça s'arrête ou pas.

la récursivité n'est jamais obligeatoire - ie il existe toujours un
algo non récursif pour faire la même chose.

Ouais, ouais - au lieu d'appeler la même fonction récursivement tu en
écris 36000 quasiment identiques pour faire exactement la même chose.

tu programmes depuis plus d'une semaine pour dire une telle annerie ??

Comme tu le dis la récursivité n'est jamais obligatoire mais c'est très
souvent le solution la plus concise et élégante.

oui mais la plus couteuse en heap et la moins parallélisable (tu parlais
pas de multi-threading ?)

il suffira alors de mettre les variabes en globales pour ne pas perdre
l'état courant.

- primo les variables globales sont toujours à éviter autant que
possible - par principe.

j'adore les principes appris par coeur !

ton appli est du JS dans un browser, non ?
tu sais que 'document', 'window', etc, etc sont des globales
dans cet environnement ? globales ne veut pas dire spaghetti
à la mode basic, ça signifie que tu as *une* référence non
volatile.

- deuzio elles prennent de la place (disque et mémoire) - mais de nos
jours on en a tant que tout le monde s'en fout à un point pas possible.

ne recites pas tout ce qui est hors sujet et/ou mal compris.

tu sors cette définition interprétée et restrictive d'où ?

Je la sors de la définition du langage (désolé pour l'english):
"The setTimeout() method evaluates an expression or calls a function
after a specified amount of time...

ce qui n'est pas du tout ce que tu avais indiqué ... tiens on dirait
que tu as effacé ton post précédent, c'est marrant ...

Une page HTML est normalement un environnement 'non-modal' qui contient
habituellement maintes éléments (objets) dont chacun peut être associé à
une action (le principe DOM) non-bloquante.

évidence sans rapport - si ce n'est qu'un script infini est un
comportement modal, donc interdit, comme tu l'indiques.

il fait plusieurs trucs distincts (charger n images via n urls) plus
ou moins en même temps, ce ne fait pas du tout un système avec
gestion fine des threads.

Aucun système mono-processeur n'exécute des tâches autrement que "plus
ou moins en même temps". Le temps est toujours partagé: donc il n'y a
aucune différence de fond.

t'as rien compris, "charger n images via n urls plus ou moins en même
temps" signifie que certaines taches comme le chargement d'une source
quelconque est multi-thread MAIS contraint par les ressources de l'OS
et les choix du navigateur, si une page contient 1000 images (1000 URL
différentes), un browser peut ouvrir 1000 connexions simultanées mais
il a aussi le droit d'ouvrir 1 connexion à la fois 1000 fois de suite.

parce que tu ne peux rien présumer ce de multi-threading jamais tu ne
pourras explicitement yielder un thread, le geler, le reprendre, etc
toutes ces notions sont complètement étrangères à JS.


dans un autre fil tu parles d'appli mono-utilisateur, associé au fait
qu'elle fasse surtout de l'affichage (et sûrement du calcul) il n'y a
apparemment aucun intérêt à la coder en JS, ni de la placer dans un
browser, fais la en C et tu auras un wait().

Sylvain.