Je suis sur un grand projet sous Visual Studio 6.0 Professionnel.
En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque
(plus de modification,defilement possible) sans que l'interface devient
blanc pendant que je défile ou travaille la source du projet , je dois le
redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le
redemarrer, de plus je perd tous les modifications si je n'ai pas
sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas
exister
Le bug est t'il corrigé sous MSVC 2000 ? je pense pas ; bug pas important !
Aucun bug de compilation encontré ! depuis ce jour
Merci des réponse pour contrer l'instabilité de l'interface MSVC
Je n'en doute pas: si c'est utilisé dans l'installation de tant de logiciels, c'est que cela doit quand même rendre des service. Bon, ceci étant dit, il y a aussi pas mal de gens qui trouvent que le s
autotools sont une bouse d'un autre temps, et qui ont développé des alternatives (ant, cons, scons, ...) mais je n'ai pas essayé (sauf ant, un tout petit peu), je ne peux pas juger.
Ce qui me dérange en particulier dans les autotools, c'est que les "Makefiles" générés font des appels récursifs à "make" pour des cendre dans les sous-répertoires et tout le monde sait que c'est Mal - voir <http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html> et <http://aegis.sourceforge.net/auug97.pdf>. Je ne sais cependant pas dire si cela est vraiment dû aux autotools ou seulement à la façon dont les gens s'en servent habituellement.
Falk
Matthieu Moy wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Je n'en doute pas: si c'est utilisé dans l'installation de
tant de logiciels, c'est que cela doit quand même rendre
des service.
Bon, ceci étant dit, il y a aussi pas mal de gens qui trouvent que le s
autotools sont une bouse d'un autre temps, et qui ont développé des
alternatives (ant, cons, scons, ...) mais je n'ai pas essayé (sauf
ant, un tout petit peu), je ne peux pas juger.
Ce qui me dérange en particulier dans les autotools, c'est que les
"Makefiles" générés font des appels récursifs à "make" pour des cendre
dans les sous-répertoires et tout le monde sait que c'est Mal - voir
<http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html>
et <http://aegis.sourceforge.net/auug97.pdf>. Je ne sais cependant
pas dire si cela est vraiment dû aux autotools ou seulement à la
façon dont les gens s'en servent habituellement.
Je n'en doute pas: si c'est utilisé dans l'installation de tant de logiciels, c'est que cela doit quand même rendre des service. Bon, ceci étant dit, il y a aussi pas mal de gens qui trouvent que le s
autotools sont une bouse d'un autre temps, et qui ont développé des alternatives (ant, cons, scons, ...) mais je n'ai pas essayé (sauf ant, un tout petit peu), je ne peux pas juger.
Ce qui me dérange en particulier dans les autotools, c'est que les "Makefiles" générés font des appels récursifs à "make" pour des cendre dans les sous-répertoires et tout le monde sait que c'est Mal - voir <http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html> et <http://aegis.sourceforge.net/auug97.pdf>. Je ne sais cependant pas dire si cela est vraiment dû aux autotools ou seulement à la façon dont les gens s'en servent habituellement.
Falk
Matthieu Moy
Falk Tannhäuser writes:
Ce qui me dérange en particulier dans les autotools, c'est que les "Makefiles" générés font des appels récursifs à "make" pour descendre dans les sous-répertoires et tout le monde sait que c'est Mal
Si seulement le monde était tout blanc ou tout noir ;-). Bah non, le make récursif « considered harmfull » n'est pas une vérité absolue, c'est plutôt de l'ordre de la guerre de religion en fait.
Ce qui me dérange en particulier dans les autotools, c'est que les
"Makefiles" générés font des appels récursifs à "make" pour descendre
dans les sous-répertoires et tout le monde sait que c'est Mal
Si seulement le monde était tout blanc ou tout noir ;-). Bah non, le
make récursif « considered harmfull » n'est pas une vérité absolue,
c'est plutôt de l'ordre de la guerre de religion en fait.
Ce qui me dérange en particulier dans les autotools, c'est que les "Makefiles" générés font des appels récursifs à "make" pour descendre dans les sous-répertoires et tout le monde sait que c'est Mal
Si seulement le monde était tout blanc ou tout noir ;-). Bah non, le make récursif « considered harmfull » n'est pas une vérité absolue, c'est plutôt de l'ordre de la guerre de religion en fait.
Je n'en doute pas: si c'est utilisé dans l'installation de tant de logiciels, c'est que cela doit quand même rendre des service.
Bon, ceci étant dit, il y a aussi pas mal de gens qui trouvent que les autotools sont une bouse d'un autre temps, et qui ont développé des alternatives (ant, cons, scons, ...) mais je n'ai pas essayé (sauf ant, un tout petit peu), je ne peux pas juger.
Ce qui me dérange en particulier dans les autotools, c'est que les "Makefiles" générés font des appels récursifs à "make" pour descendre dans les sous-répertoires et tout le monde sait que c'est Mal - voir <http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html> et <http://aegis.sourceforge.net/auug97.pdf>. Je ne sais cependant pas dire si cela est vraiment dû aux autotools ou seulement à la façon dont les gens s'en servent habituellement.
Personnellement, je n'aime pas les autotools, car ils font pas mal de tests excessivement lents. Par contre je suis un fan de l'utilisation récursive de make. Le découpage d'un projet en modules, avec chaque modules dans un sous-répertoire, a une logique organisationnelle. Je n'ai jamais vu les problèmes de dépendences exposés dans l'article de Miller, et je ne trouve pas cela spécialement lent.
-- Richard
Matthieu Moy wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Je n'en doute pas: si c'est utilisé dans l'installation de
tant de logiciels, c'est que cela doit quand même rendre
des service.
Bon, ceci étant dit, il y a aussi pas mal de gens qui trouvent que les
autotools sont une bouse d'un autre temps, et qui ont développé des
alternatives (ant, cons, scons, ...) mais je n'ai pas essayé (sauf
ant, un tout petit peu), je ne peux pas juger.
Ce qui me dérange en particulier dans les autotools, c'est que les
"Makefiles" générés font des appels récursifs à "make" pour descendre
dans les sous-répertoires et tout le monde sait que c'est Mal - voir
<http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html>
et <http://aegis.sourceforge.net/auug97.pdf>. Je ne sais cependant
pas dire si cela est vraiment dû aux autotools ou seulement à la
façon dont les gens s'en servent habituellement.
Personnellement, je n'aime pas les autotools, car ils font pas mal de
tests excessivement lents. Par contre je suis un fan de l'utilisation
récursive de make. Le découpage d'un projet en modules, avec chaque
modules dans un sous-répertoire, a une logique organisationnelle. Je
n'ai jamais vu les problèmes de dépendences exposés dans l'article de
Miller, et je ne trouve pas cela spécialement lent.
Je n'en doute pas: si c'est utilisé dans l'installation de tant de logiciels, c'est que cela doit quand même rendre des service.
Bon, ceci étant dit, il y a aussi pas mal de gens qui trouvent que les autotools sont une bouse d'un autre temps, et qui ont développé des alternatives (ant, cons, scons, ...) mais je n'ai pas essayé (sauf ant, un tout petit peu), je ne peux pas juger.
Ce qui me dérange en particulier dans les autotools, c'est que les "Makefiles" générés font des appels récursifs à "make" pour descendre dans les sous-répertoires et tout le monde sait que c'est Mal - voir <http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html> et <http://aegis.sourceforge.net/auug97.pdf>. Je ne sais cependant pas dire si cela est vraiment dû aux autotools ou seulement à la façon dont les gens s'en servent habituellement.
Personnellement, je n'aime pas les autotools, car ils font pas mal de tests excessivement lents. Par contre je suis un fan de l'utilisation récursive de make. Le découpage d'un projet en modules, avec chaque modules dans un sous-répertoire, a une logique organisationnelle. Je n'ai jamais vu les problèmes de dépendences exposés dans l'article de Miller, et je ne trouve pas cela spécialement lent.
-- Richard
Aurelien Regat-Barrel
Je suis sur un grand projet sous Visual Studio 6.0 Professionnel. En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque (plus de modification,defilement possible) sans que l'interface devient blanc pendant que je défile ou travaille la source du projet , je dois le redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le redemarrer, de plus je perd tous les modifications si je n'ai pas sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Un ami l'a eu récemment, sauf que ça bloquait "seulement" pendant quelques secondes. Mais c'est très lourd. C'était dû à l'intellisense (analyse du code source) qui sur un projet en particulier partait en vrille. Il l'a désactivé et depuis c'est bon (un truc genre aide à la saisie du code...). J'ai quelques rares fois eu ce problème sous VC++ 7.0, et jamais sous VC++ 7.1.
Au passage, je crois que personne n'a dit que c'était le mauvais endroit pour ce genre de questions. => microsoft.public.fr.vc par exemple.
-- Aurélien Regat-Barrel
Je suis sur un grand projet sous Visual Studio 6.0 Professionnel.
En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque
(plus de modification,defilement possible) sans que l'interface devient
blanc pendant que je défile ou travaille la source du projet , je dois le
redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le
redemarrer, de plus je perd tous les modifications si je n'ai pas
sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Un ami l'a eu récemment, sauf que ça bloquait "seulement" pendant
quelques secondes. Mais c'est très lourd.
C'était dû à l'intellisense (analyse du code source) qui sur un projet
en particulier partait en vrille. Il l'a désactivé et depuis c'est bon
(un truc genre aide à la saisie du code...).
J'ai quelques rares fois eu ce problème sous VC++ 7.0, et jamais sous
VC++ 7.1.
Au passage, je crois que personne n'a dit que c'était le mauvais endroit
pour ce genre de questions.
=> microsoft.public.fr.vc par exemple.
Je suis sur un grand projet sous Visual Studio 6.0 Professionnel. En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque (plus de modification,defilement possible) sans que l'interface devient blanc pendant que je défile ou travaille la source du projet , je dois le redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le redemarrer, de plus je perd tous les modifications si je n'ai pas sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Un ami l'a eu récemment, sauf que ça bloquait "seulement" pendant quelques secondes. Mais c'est très lourd. C'était dû à l'intellisense (analyse du code source) qui sur un projet en particulier partait en vrille. Il l'a désactivé et depuis c'est bon (un truc genre aide à la saisie du code...). J'ai quelques rares fois eu ce problème sous VC++ 7.0, et jamais sous VC++ 7.1.
Au passage, je crois que personne n'a dit que c'était le mauvais endroit pour ce genre de questions. => microsoft.public.fr.vc par exemple.
-- Aurélien Regat-Barrel
Aurelien Regat-Barrel
D'où l'intérêt de savoir faire un Makefile pour gérer un projet... voir mieux utiliser les autotools (autoconf, automake, etc...)
Le prochain VC++ 8 utilisera le même format pour ses fichiers projets de l'IDE que celui du nouveau système de build de MS : msbuild. C'est d'ailleurs ce système qui est utilisé en interne par l'IDE pour compiler un projet.
-- Aurélien Regat-Barrel
D'où l'intérêt de savoir faire un Makefile pour gérer un projet... voir
mieux utiliser les autotools (autoconf, automake, etc...)
Le prochain VC++ 8 utilisera le même format pour ses fichiers projets de
l'IDE que celui du nouveau système de build de MS : msbuild. C'est
d'ailleurs ce système qui est utilisé en interne par l'IDE pour compiler
un projet.
D'où l'intérêt de savoir faire un Makefile pour gérer un projet... voir mieux utiliser les autotools (autoconf, automake, etc...)
Le prochain VC++ 8 utilisera le même format pour ses fichiers projets de l'IDE que celui du nouveau système de build de MS : msbuild. C'est d'ailleurs ce système qui est utilisé en interne par l'IDE pour compiler un projet.
-- Aurélien Regat-Barrel
David Geldreich
Bonjour
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas exister
Déjà il faut installer les derniers service pack pour VC6.
Si tu veux que ça remarche, efface les fichiers utilisés par intellisense, le class browser, ...:
1) tu arrêtes visual studio
2) tu effaces *.opt *.ncb (c'est souvent ce fichier qui est en cause)
3) Eventuellement, tu effaces auusi tout ce qui est généré à la compilation et qui se trouve normalement dans les répertoires Debug et Release (*.obj, *.pch, *.ilk, *.exe, *.pdb, ...)
A suivre
Bonjour
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas
exister
Déjà il faut installer les derniers service pack pour VC6.
Si tu veux que ça remarche, efface les fichiers utilisés par
intellisense, le class browser, ...:
1) tu arrêtes visual studio
2) tu effaces
*.opt
*.ncb (c'est souvent ce fichier qui est en cause)
3) Eventuellement, tu effaces auusi tout ce qui est généré à la
compilation et qui se trouve normalement dans les répertoires Debug et
Release (*.obj, *.pch, *.ilk, *.exe, *.pdb, ...)
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas exister
Déjà il faut installer les derniers service pack pour VC6.
Si tu veux que ça remarche, efface les fichiers utilisés par intellisense, le class browser, ...:
1) tu arrêtes visual studio
2) tu effaces *.opt *.ncb (c'est souvent ce fichier qui est en cause)
3) Eventuellement, tu effaces auusi tout ce qui est généré à la compilation et qui se trouve normalement dans les répertoires Debug et Release (*.obj, *.pch, *.ilk, *.exe, *.pdb, ...)
A suivre
Sivaller
"David Geldreich" a écrit dans le message de news:4347a894$0$21225$
Bonjour
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas exister
Déjà il faut installer les derniers service pack pour VC6. Oui les trouver ?
Si tu veux que ça remarche, efface les fichiers utilisés par intellisense, le class browser, ...: 1) tu arrêtes visual studio Oui
2) tu effaces *.opt *.ncb (c'est souvent ce fichier qui est en cause)
3) Eventuellement, tu effaces auusi tout ce qui est généré à la compilation et qui se trouve normalement dans les répertoires Debug et Release (*.obj, *.pch, *.ilk, *.exe, *.pdb, ...)
A suivre
"David Geldreich" <david.geldreich-xxx@xxx-free.fr> a écrit dans le message
de news:4347a894$0$21225$626a54ce@news.free.fr...
Bonjour
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas
exister
Déjà il faut installer les derniers service pack pour VC6.
Oui les trouver ?
Si tu veux que ça remarche, efface les fichiers utilisés par
intellisense, le class browser, ...:
1) tu arrêtes visual studio
Oui
2) tu effaces
*.opt
*.ncb (c'est souvent ce fichier qui est en cause)
3) Eventuellement, tu effaces auusi tout ce qui est généré à la
compilation et qui se trouve normalement dans les répertoires Debug et
Release (*.obj, *.pch, *.ilk, *.exe, *.pdb, ...)
"David Geldreich" a écrit dans le message de news:4347a894$0$21225$
Bonjour
Ou trouver un patch qui corrige cet instabilité de MSVC ? Il ne dois pas exister
Déjà il faut installer les derniers service pack pour VC6. Oui les trouver ?
Si tu veux que ça remarche, efface les fichiers utilisés par intellisense, le class browser, ...: 1) tu arrêtes visual studio Oui
2) tu effaces *.opt *.ncb (c'est souvent ce fichier qui est en cause)
3) Eventuellement, tu effaces auusi tout ce qui est généré à la compilation et qui se trouve normalement dans les répertoires Debug et Release (*.obj, *.pch, *.ilk, *.exe, *.pdb, ...)
A suivre
Sivaller
Comment désactiver Intellisense ?
"Aurelien Regat-Barrel" a écrit dans le message de news:4344f723$0$22387$
Je suis sur un grand projet sous Visual Studio 6.0 Professionnel. En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque (plus de modification,defilement possible) sans que l'interface devient blanc pendant que je défile ou travaille la source du projet , je dois le
redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le redemarrer, de plus je perd tous les modifications si je n'ai pas sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Un ami l'a eu récemment, sauf que ça bloquait "seulement" pendant quelques secondes. Mais c'est très lourd. C'était dû à l'intellisense (analyse du code source) qui sur un projet en particulier partait en vrille. Il l'a désactivé et depuis c'est bon (un truc genre aide à la saisie du code...). J'ai quelques rares fois eu ce problème sous VC++ 7.0, et jamais sous VC++ 7.1.
Au passage, je crois que personne n'a dit que c'était le mauvais endroit pour ce genre de questions. => microsoft.public.fr.vc par exemple.
-- Aurélien Regat-Barrel
Comment désactiver Intellisense ?
"Aurelien Regat-Barrel" <nospam.aregatba@yahoo.fr> a écrit dans le message
de news:4344f723$0$22387$626a14ce@news.free.fr...
Je suis sur un grand projet sous Visual Studio 6.0 Professionnel.
En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque
(plus de modification,defilement possible) sans que l'interface devient
blanc pendant que je défile ou travaille la source du projet , je dois
le
redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le
redemarrer, de plus je perd tous les modifications si je n'ai pas
sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Un ami l'a eu récemment, sauf que ça bloquait "seulement" pendant
quelques secondes. Mais c'est très lourd.
C'était dû à l'intellisense (analyse du code source) qui sur un projet
en particulier partait en vrille. Il l'a désactivé et depuis c'est bon
(un truc genre aide à la saisie du code...).
J'ai quelques rares fois eu ce problème sous VC++ 7.0, et jamais sous
VC++ 7.1.
Au passage, je crois que personne n'a dit que c'était le mauvais endroit
pour ce genre de questions.
=> microsoft.public.fr.vc par exemple.
"Aurelien Regat-Barrel" a écrit dans le message de news:4344f723$0$22387$
Je suis sur un grand projet sous Visual Studio 6.0 Professionnel. En moyenne tous les 3 minutes MSVC (Microsoft Visual Studio) se bloque (plus de modification,defilement possible) sans que l'interface devient blanc pendant que je défile ou travaille la source du projet , je dois le
redemarrer sans cesse et ça devient GOONNNNFLAAANNNNNTTTT à force de le redemarrer, de plus je perd tous les modifications si je n'ai pas sauvegardé, je dois sauvegarder tous les 2 minutes dans ce cas là.
Avez vous déjà eu ce bug sur les gros projet de MSVC ++ ? Oui !!
Un ami l'a eu récemment, sauf que ça bloquait "seulement" pendant quelques secondes. Mais c'est très lourd. C'était dû à l'intellisense (analyse du code source) qui sur un projet en particulier partait en vrille. Il l'a désactivé et depuis c'est bon (un truc genre aide à la saisie du code...). J'ai quelques rares fois eu ce problème sous VC++ 7.0, et jamais sous VC++ 7.1.
Au passage, je crois que personne n'a dit que c'était le mauvais endroit pour ce genre de questions. => microsoft.public.fr.vc par exemple.
