J'utilise le programme "asy" pour compiler du code Asymptote.
Le résultat de la compilation est un fichier dont le format dépend du
code lui-même ou des options passées à "asy"; il est donc quasi
indispensable d'utiliser l'option -V de "asy" qui permet de visualiser
dans la foulée le fichier de sortie avec le programme adapté (gv ou
acroread ou ImageMagick).
Si je lance la commande "asy -V essai.asy &" dans Konsole tout
fonctionne parfaitement.
En revanche dans Emacs:
M-! asy -V essai.asy &
fonctionne mal du fait de l'esperluette (processus asynchrone):
parfois la visualisation ne s'effectue pas, parfois il faut
réactualiser le "visualisateur".
Mon but est de créer un raccourci clavier qui exécute grosso modo:
(compile (concat "asy -V " buffer-file-name))
pour la gestion des erreurs (C-x `).
Là encore le processus est asynchrone et fonctionne mal.
J'ai constaté que les commandes:
(compile "asy -V essai.asy && sleep x")
(shell-command "( asy -V essai.asy && sleep x ) &")
fonctionnent avec une valeur de x dépendant de la taille du fichier
généré...
Le film http://membres.lycos.fr/gdclef/emacs-shell.mpeg
permet peut-être de mieux comprendre le problème.
Est-ce un problème dans le programme "asy" (et de quel ordre) ou
y-a-t-il un moyen de résoudre ce problème dans Emacs ?
--
Merci de votre attention,
Philippe Ivaldi.
http://home.tele2.fr/phivaldi/index.html
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lhabert
Ph. Ivaldi :
J'utilise le programme "asy" pour compiler du code Asymptote. Le résultat de la compilation est un fichier dont le format dépend du code lui-même ou des options passées à "asy"; il est donc quasi indispensable d'utiliser l'option -V de "asy" qui permet de visualiser dans la foulée le fichier de sortie avec le programme adapté (gv ou acroread ou ImageMagick). Si je lance la commande "asy -V essai.asy &" dans Konsole tout fonctionne parfaitement. En revanche dans Emacs: M-! asy -V essai.asy & fonctionne mal du fait de l'esperluette (processus asynchrone): parfois la visualisation ne s'effectue pas, parfois il faut réactualiser le "visualisateur".
Emacs a l'air de faire des read sur la sortie du terminal, pour tester si il y a encore des programmes qui tournent dedans. Il faudrait lancer asy sans « & », et s'arranger pour lui faire exécuter son viewer en « </dev/null > /dev/null 2>&1 & ».
Ph. Ivaldi :
J'utilise le programme "asy" pour compiler du code Asymptote.
Le résultat de la compilation est un fichier dont le format dépend du
code lui-même ou des options passées à "asy"; il est donc quasi
indispensable d'utiliser l'option -V de "asy" qui permet de visualiser
dans la foulée le fichier de sortie avec le programme adapté (gv ou
acroread ou ImageMagick).
Si je lance la commande "asy -V essai.asy &" dans Konsole tout
fonctionne parfaitement.
En revanche dans Emacs:
M-! asy -V essai.asy &
fonctionne mal du fait de l'esperluette (processus asynchrone):
parfois la visualisation ne s'effectue pas, parfois il faut
réactualiser le "visualisateur".
Emacs a l'air de faire des read sur la sortie du terminal, pour tester si il
y a encore des programmes qui tournent dedans. Il faudrait lancer asy sans
« & », et s'arranger pour lui faire exécuter son viewer en « </dev/null >
/dev/null 2>&1 & ».
J'utilise le programme "asy" pour compiler du code Asymptote. Le résultat de la compilation est un fichier dont le format dépend du code lui-même ou des options passées à "asy"; il est donc quasi indispensable d'utiliser l'option -V de "asy" qui permet de visualiser dans la foulée le fichier de sortie avec le programme adapté (gv ou acroread ou ImageMagick). Si je lance la commande "asy -V essai.asy &" dans Konsole tout fonctionne parfaitement. En revanche dans Emacs: M-! asy -V essai.asy & fonctionne mal du fait de l'esperluette (processus asynchrone): parfois la visualisation ne s'effectue pas, parfois il faut réactualiser le "visualisateur".
Emacs a l'air de faire des read sur la sortie du terminal, pour tester si il y a encore des programmes qui tournent dedans. Il faudrait lancer asy sans « & », et s'arranger pour lui faire exécuter son viewer en « </dev/null > /dev/null 2>&1 & ».
Ph. Ivaldi
Le 31 décembre 2006 à 21h27:30, (Luc Habert) écrivit :
Emacs a l'air de faire des read sur la sortie du terminal, pour tester si il y a encore des programmes qui tournent dedans.
Un `set-process-sentinel' ?
Il faudrait lancer asy sans « & », et s'arranger pour lui faire exécuter son viewer en « </dev/null > /dev/null 2>&1 & ».
Dans le fichier de configuration de Asymptote j'ai mis psviewer="/home/pi/bin/asy-gv";
où /home/pi/bin/asy-gv contient: #!/bin/sh
kghostview $1 </dev/null 2>&1>/dev/null &
(kghostview pour être sûr que la configuration est prise en compte).
M-! asy -V essai.asy fonctionne correctement au détail près qu'il ne rend pas la main tant que le "viewer" tourne (sous "konsole" ça rend toujours la main immédiatement après avoir généré le .eps). Le plus grave est que M-: (compile "asy -V essai.asy") ou M-! asy -V essai.asy & ne lance plus le "visionneur".
Je me suis décidé à exposer ces problèmes aux développeurs d'Asymptote histoire qu'ils voient s'il n'y a pas un moyen de modifier la commande asy. -- Philippe Ivaldi. http://home.tele2.fr/phivaldi/index.html
Le 31 décembre 2006 à 21h27:30,
lhabert@clipper.ens.fr (Luc Habert) écrivit :
Emacs a l'air de faire des read sur la sortie du terminal, pour tester
si il y a encore des programmes qui tournent dedans.
Un `set-process-sentinel' ?
Il faudrait
lancer asy sans « & », et s'arranger pour lui faire exécuter son
viewer en « </dev/null > /dev/null 2>&1 & ».
Dans le fichier de configuration de Asymptote j'ai mis
psviewer="/home/pi/bin/asy-gv";
où /home/pi/bin/asy-gv contient:
#!/bin/sh
kghostview $1 </dev/null 2>&1>/dev/null &
(kghostview pour être sûr que la configuration est prise en compte).
M-! asy -V essai.asy
fonctionne correctement au détail près qu'il ne rend pas la main tant
que le "viewer" tourne (sous "konsole" ça rend toujours la main
immédiatement après avoir généré le .eps).
Le plus grave est que M-: (compile "asy -V essai.asy") ou
M-! asy -V essai.asy &
ne lance plus le "visionneur".
Je me suis décidé à exposer ces problèmes aux développeurs d'Asymptote
histoire qu'ils voient s'il n'y a pas un moyen de modifier la commande
asy.
--
Philippe Ivaldi.
http://home.tele2.fr/phivaldi/index.html
Le 31 décembre 2006 à 21h27:30, (Luc Habert) écrivit :
Emacs a l'air de faire des read sur la sortie du terminal, pour tester si il y a encore des programmes qui tournent dedans.
Un `set-process-sentinel' ?
Il faudrait lancer asy sans « & », et s'arranger pour lui faire exécuter son viewer en « </dev/null > /dev/null 2>&1 & ».
Dans le fichier de configuration de Asymptote j'ai mis psviewer="/home/pi/bin/asy-gv";
où /home/pi/bin/asy-gv contient: #!/bin/sh
kghostview $1 </dev/null 2>&1>/dev/null &
(kghostview pour être sûr que la configuration est prise en compte).
M-! asy -V essai.asy fonctionne correctement au détail près qu'il ne rend pas la main tant que le "viewer" tourne (sous "konsole" ça rend toujours la main immédiatement après avoir généré le .eps). Le plus grave est que M-: (compile "asy -V essai.asy") ou M-! asy -V essai.asy & ne lance plus le "visionneur".
Je me suis décidé à exposer ces problèmes aux développeurs d'Asymptote histoire qu'ils voient s'il n'y a pas un moyen de modifier la commande asy. -- Philippe Ivaldi. http://home.tele2.fr/phivaldi/index.html
lhabert
Ph. Ivaldi :
kghostview $1 </dev/null 2>&1>/dev/null &
Tu fais les redirections dans le mauvais sens : le fd 2 pointe vers ce vers quoi pointait le fd 1 (c'est-à-dire la sortie du tty), et le fd 1 pointe vers /dev/null. Il faut le faire dans l'autre sens « >/dev/null 2>&1 », pour qu'il n'y ait plus rien qui pointe vers la sortie du tty.
Ph. Ivaldi :
kghostview $1 </dev/null 2>&1>/dev/null &
Tu fais les redirections dans le mauvais sens : le fd 2 pointe vers ce vers
quoi pointait le fd 1 (c'est-à-dire la sortie du tty), et le fd 1 pointe
vers /dev/null. Il faut le faire dans l'autre sens « >/dev/null 2>&1 », pour
qu'il n'y ait plus rien qui pointe vers la sortie du tty.
Tu fais les redirections dans le mauvais sens : le fd 2 pointe vers ce vers quoi pointait le fd 1 (c'est-à-dire la sortie du tty), et le fd 1 pointe vers /dev/null. Il faut le faire dans l'autre sens « >/dev/null 2>&1 », pour qu'il n'y ait plus rien qui pointe vers la sortie du tty.
Ph. Ivaldi
Le 02 janvier 2007 à 23h19:45, (Luc Habert) écrivit :
Ph. Ivaldi :
kghostview $1 </dev/null 2>&1>/dev/null &
Tu fais les redirections dans le mauvais sens : le fd 2 pointe vers ce vers quoi pointait le fd 1 (c'est-à-dire la sortie du tty), et le fd 1 pointe vers /dev/null. Il faut le faire dans l'autre sens « >/dev/null 2>&1 », pour qu'il n'y ait plus rien qui pointe vers la sortie du tty.
Je retiens la leçon du passé. Après renseignement, il semble que l'on puisse utiliser &> /dev/null (moins ambiguë pour ma petite cervelle). Malheureusement, dans le cas présent, ça ne change rien. J'ai, dès le départ, copié/collé ce que tu m'as suggéré; ensuite j'ai bidouillé, pensant qu'il y avait une erreur dans la redirection. Merci de ton aide. -- Philippe Ivaldi. http://home.tele2.fr/phivaldi/index.html
Le 02 janvier 2007 à 23h19:45,
lhabert@clipper.ens.fr (Luc Habert) écrivit :
Ph. Ivaldi :
kghostview $1 </dev/null 2>&1>/dev/null &
Tu fais les redirections dans le mauvais sens : le fd 2 pointe vers ce
vers quoi pointait le fd 1 (c'est-à-dire la sortie du tty), et le fd 1
pointe vers /dev/null. Il faut le faire dans l'autre sens « >/dev/null
2>&1 », pour qu'il n'y ait plus rien qui pointe vers la sortie du tty.
Je retiens la leçon du passé.
Après renseignement, il semble que l'on puisse utiliser &> /dev/null
(moins ambiguë pour ma petite cervelle).
Malheureusement, dans le cas présent, ça ne change rien.
J'ai, dès le départ, copié/collé ce que tu m'as suggéré; ensuite j'ai
bidouillé, pensant qu'il y avait une erreur dans la redirection.
Merci de ton aide.
--
Philippe Ivaldi.
http://home.tele2.fr/phivaldi/index.html
Le 02 janvier 2007 à 23h19:45, (Luc Habert) écrivit :
Ph. Ivaldi :
kghostview $1 </dev/null 2>&1>/dev/null &
Tu fais les redirections dans le mauvais sens : le fd 2 pointe vers ce vers quoi pointait le fd 1 (c'est-à-dire la sortie du tty), et le fd 1 pointe vers /dev/null. Il faut le faire dans l'autre sens « >/dev/null 2>&1 », pour qu'il n'y ait plus rien qui pointe vers la sortie du tty.
Je retiens la leçon du passé. Après renseignement, il semble que l'on puisse utiliser &> /dev/null (moins ambiguë pour ma petite cervelle). Malheureusement, dans le cas présent, ça ne change rien. J'ai, dès le départ, copié/collé ce que tu m'as suggéré; ensuite j'ai bidouillé, pensant qu'il y avait une erreur dans la redirection. Merci de ton aide. -- Philippe Ivaldi. http://home.tele2.fr/phivaldi/index.html
Ph. Ivaldi
Le 30 décembre 2006 à 15h43:55, Ph. Ivaldi écrivit :
Bonjour,
J'utilise le programme "asy" pour compiler du code Asymptote. Le résultat de la compilation est un fichier dont le format dépend du code lui-même ou des options passées à "asy"; il est donc quasi indispensable d'utiliser l'option -V de "asy" qui permet de visualiser dans la foulée le fichier de sortie avec le programme adapté (gv ou acroread ou ImageMagick). Si je lance la commande "asy -V essai.asy &" dans Konsole tout fonctionne parfaitement. En revanche dans Emacs: M-! asy -V essai.asy & fonctionne mal du fait de l'esperluette (processus asynchrone): parfois la visualisation ne s'effectue pas, parfois il faut réactualiser le "visualisateur".
Mon but est de créer un raccourci clavier qui exécute grosso modo: (compile (concat "asy -V " buffer-file-name)) pour la gestion des erreurs (C-x `). Là encore le processus est asynchrone et fonctionne mal.
J'ai constaté que les commandes: (compile "asy -V essai.asy && sleep x") (shell-command "( asy -V essai.asy && sleep x ) &") fonctionnent avec une valeur de x dépendant de la taille du fichier généré... Le film http://membres.lycos.fr/gdclef/emacs-shell.mpeg permet peut-être de mieux comprendre le problème.
Est-ce un problème dans le programme "asy" (et de quel ordre) ou y-a-t-il un moyen de résoudre ce problème dans Emacs ?
Voici ce que m'a répondu un des développeurs d'Asymptote:
8<------8<------8<------8<------8<------8<------8<------8<------8<------ I looked further into the issue about asy children getting killed and indeed the following example indicates that this is the case. I don't know for sure who is responsible, but it really does look like an emacs bug. I don't think it can be asy since asy has already exited at this point:
Donc, a priori, Emacs tuerait les processus enfants dès que le processus initial est terminé; est-ce vraiment un comportement souhaité et souhaitable ou est-ce un bogue ? -- Philippe Ivaldi. http://home.tele2.fr/phivaldi/index.html
Le 30 décembre 2006 à 15h43:55,
Ph. Ivaldi <piv_pasde@pub_tele2.fr> écrivit :
Bonjour,
J'utilise le programme "asy" pour compiler du code Asymptote.
Le résultat de la compilation est un fichier dont le format dépend du
code lui-même ou des options passées à "asy"; il est donc quasi
indispensable d'utiliser l'option -V de "asy" qui permet de visualiser
dans la foulée le fichier de sortie avec le programme adapté (gv ou
acroread ou ImageMagick).
Si je lance la commande "asy -V essai.asy &" dans Konsole tout
fonctionne parfaitement.
En revanche dans Emacs:
M-! asy -V essai.asy &
fonctionne mal du fait de l'esperluette (processus asynchrone):
parfois la visualisation ne s'effectue pas, parfois il faut
réactualiser le "visualisateur".
Mon but est de créer un raccourci clavier qui exécute grosso modo:
(compile (concat "asy -V " buffer-file-name))
pour la gestion des erreurs (C-x `).
Là encore le processus est asynchrone et fonctionne mal.
J'ai constaté que les commandes:
(compile "asy -V essai.asy && sleep x")
(shell-command "( asy -V essai.asy && sleep x ) &")
fonctionnent avec une valeur de x dépendant de la taille du fichier
généré...
Le film http://membres.lycos.fr/gdclef/emacs-shell.mpeg
permet peut-être de mieux comprendre le problème.
Est-ce un problème dans le programme "asy" (et de quel ordre) ou
y-a-t-il un moyen de résoudre ce problème dans Emacs ?
Voici ce que m'a répondu un des développeurs d'Asymptote:
8<------8<------8<------8<------8<------8<------8<------8<------8<------
I looked further into the issue about asy children getting killed and
indeed the following example indicates that this is the case. I don't
know for sure who is responsible, but it really does look like an emacs
bug.
I don't think it can be asy since asy has already exited at this point:
Donc, a priori, Emacs tuerait les processus enfants dès que le processus
initial est terminé; est-ce vraiment un comportement souhaité et
souhaitable ou est-ce un bogue ?
--
Philippe Ivaldi.
http://home.tele2.fr/phivaldi/index.html
Le 30 décembre 2006 à 15h43:55, Ph. Ivaldi écrivit :
Bonjour,
J'utilise le programme "asy" pour compiler du code Asymptote. Le résultat de la compilation est un fichier dont le format dépend du code lui-même ou des options passées à "asy"; il est donc quasi indispensable d'utiliser l'option -V de "asy" qui permet de visualiser dans la foulée le fichier de sortie avec le programme adapté (gv ou acroread ou ImageMagick). Si je lance la commande "asy -V essai.asy &" dans Konsole tout fonctionne parfaitement. En revanche dans Emacs: M-! asy -V essai.asy & fonctionne mal du fait de l'esperluette (processus asynchrone): parfois la visualisation ne s'effectue pas, parfois il faut réactualiser le "visualisateur".
Mon but est de créer un raccourci clavier qui exécute grosso modo: (compile (concat "asy -V " buffer-file-name)) pour la gestion des erreurs (C-x `). Là encore le processus est asynchrone et fonctionne mal.
J'ai constaté que les commandes: (compile "asy -V essai.asy && sleep x") (shell-command "( asy -V essai.asy && sleep x ) &") fonctionnent avec une valeur de x dépendant de la taille du fichier généré... Le film http://membres.lycos.fr/gdclef/emacs-shell.mpeg permet peut-être de mieux comprendre le problème.
Est-ce un problème dans le programme "asy" (et de quel ordre) ou y-a-t-il un moyen de résoudre ce problème dans Emacs ?
Voici ce que m'a répondu un des développeurs d'Asymptote:
8<------8<------8<------8<------8<------8<------8<------8<------8<------ I looked further into the issue about asy children getting killed and indeed the following example indicates that this is the case. I don't know for sure who is responsible, but it really does look like an emacs bug. I don't think it can be asy since asy has already exited at this point:
Donc, a priori, Emacs tuerait les processus enfants dès que le processus initial est terminé; est-ce vraiment un comportement souhaité et souhaitable ou est-ce un bogue ? -- Philippe Ivaldi. http://home.tele2.fr/phivaldi/index.html
