a écrit dans le message de
news:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En
Ha! je suis surpris, edition+compilation
debug s'enchainant sur simplement
par l'action de touche de fonctions, me semblait le paradis du
développeur.
revanche, il faudrait que le « IDE » s'integre bien avec le
système de gestion des versions. Il y a des packages emacs qui le
font, par exemple, au moins pour des outils de gestion des
versions qui fonction un peu comme CVS.
Effectivement. ( cela me fait penser que pressé par le temps je n'ai
pas regarder du coté de 'SourceSafe', a priori, cela devrait
marcher... ).
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte
cher en temps.
Oui, 'essuyer les platres', lorsque tant de choses restent à faire,
coûte du temps, sans parler du coup au moral quand on arrive à un
constat d'echec...
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0411170214.17ce6135@posting.google.com...
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En
Ha! je suis surpris, edition+compilation
debug s'enchainant sur simplement
par l'action de touche de fonctions, me semblait le paradis du
développeur.
revanche, il faudrait que le « IDE » s'integre bien avec le
système de gestion des versions. Il y a des packages emacs qui le
font, par exemple, au moins pour des outils de gestion des
versions qui fonction un peu comme CVS.
Effectivement. ( cela me fait penser que pressé par le temps je n'ai
pas regarder du coté de 'SourceSafe', a priori, cela devrait
marcher... ).
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte
cher en temps.
Oui, 'essuyer les platres', lorsque tant de choses restent à faire,
coûte du temps, sans parler du coup au moral quand on arrive à un
constat d'echec...
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
a écrit dans le message de
news:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En
Ha! je suis surpris, edition+compilation
debug s'enchainant sur simplement
par l'action de touche de fonctions, me semblait le paradis du
développeur.
revanche, il faudrait que le « IDE » s'integre bien avec le
système de gestion des versions. Il y a des packages emacs qui le
font, par exemple, au moins pour des outils de gestion des
versions qui fonction un peu comme CVS.
Effectivement. ( cela me fait penser que pressé par le temps je n'ai
pas regarder du coté de 'SourceSafe', a priori, cela devrait
marcher... ).
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte
cher en temps.
Oui, 'essuyer les platres', lorsque tant de choses restent à faire,
coûte du temps, sans parler du coup au moral quand on arrive à un
constat d'echec...
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
wrote:Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
template<class FSM, template <class, class> class NodeCont,
template <class, class> class ArcCont>
typename StateSpace<FSM, NodeCont, ArcCont>::statespace_arc_iterator
StateSpace<FSM, NodeCont, ArcCont>::arcsBegin() {
.....
}
template<class FSM, template <class, class> class NodeCont,
template <class, class> class ArcCont>
bool
StateSpace<FSM, NodeCont, ArcCont>::find(
const typename StateSpace<FSM, NodeCont, ArcCont>::NodeInfo& info,
typename StateSpace<FSM, NodeCont, ArcCont>::StateSpaceNode* &theNode) {
.....
}
et avec macros
SS_TEMPLATE
statespace_arc_iterator STATE_SPACE::arcsBegin() {
....
}
SS_TEMPLATE
bool STATE_SPACE::find(const NodeInfo& info, StateSpaceNode* &theNode) {
....
}
kanze@gabi-soft.fr wrote:
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
template<class FSM, template <class, class> class NodeCont,
template <class, class> class ArcCont>
typename StateSpace<FSM, NodeCont, ArcCont>::statespace_arc_iterator
StateSpace<FSM, NodeCont, ArcCont>::arcsBegin() {
.....
}
template<class FSM, template <class, class> class NodeCont,
template <class, class> class ArcCont>
bool
StateSpace<FSM, NodeCont, ArcCont>::find(
const typename StateSpace<FSM, NodeCont, ArcCont>::NodeInfo& info,
typename StateSpace<FSM, NodeCont, ArcCont>::StateSpaceNode* &theNode) {
.....
}
et avec macros
SS_TEMPLATE
statespace_arc_iterator STATE_SPACE::arcsBegin() {
....
}
SS_TEMPLATE
bool STATE_SPACE::find(const NodeInfo& info, StateSpaceNode* &theNode) {
....
}
wrote:Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
template<class FSM, template <class, class> class NodeCont,
template <class, class> class ArcCont>
typename StateSpace<FSM, NodeCont, ArcCont>::statespace_arc_iterator
StateSpace<FSM, NodeCont, ArcCont>::arcsBegin() {
.....
}
template<class FSM, template <class, class> class NodeCont,
template <class, class> class ArcCont>
bool
StateSpace<FSM, NodeCont, ArcCont>::find(
const typename StateSpace<FSM, NodeCont, ArcCont>::NodeInfo& info,
typename StateSpace<FSM, NodeCont, ArcCont>::StateSpaceNode* &theNode) {
.....
}
et avec macros
SS_TEMPLATE
statespace_arc_iterator STATE_SPACE::arcsBegin() {
....
}
SS_TEMPLATE
bool STATE_SPACE::find(const NodeInfo& info, StateSpaceNode* &theNode) {
....
}
Compilation comme avec emacs, j'aime bien: il ne m'impose rien sur la
structure de mes projets. Pour ce que j'ai vu des IDE c'est
generalement difficile de le faire fonctionner avec un projet deja
structure dont la structure ne correspond pas a celle prevue par les
Meme sans essuyer les platres. Pour voir si un IDE est utile, il faut
commencer apparemment par restructurer le projet pour etre compatible
avec l'IDE... et comme on a des projets qui sortent sur 11 plateformes
(Sun 32 et 64, HP 32 et 64, IBM 32 et 64, x86, IA64, amd64) il faut
quelque chose qui non seulement soit confortable sur les plateformes
de developpement (mixte Solaris/Linux pour le moment avec quelques
rares exceptions -- et toujours des projets ayant peu de
dependances --
sur Windows mais je ne connais que deux personnes qui
commencent sur un tel projet et pour le moment il n'ont pas vu
d'avantage reel a VC++) mais permette aussi de travailler sur les
autres.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
Comme?
Compilation comme avec emacs, j'aime bien: il ne m'impose rien sur la
structure de mes projets. Pour ce que j'ai vu des IDE c'est
generalement difficile de le faire fonctionner avec un projet deja
structure dont la structure ne correspond pas a celle prevue par les
Meme sans essuyer les platres. Pour voir si un IDE est utile, il faut
commencer apparemment par restructurer le projet pour etre compatible
avec l'IDE... et comme on a des projets qui sortent sur 11 plateformes
(Sun 32 et 64, HP 32 et 64, IBM 32 et 64, x86, IA64, amd64) il faut
quelque chose qui non seulement soit confortable sur les plateformes
de developpement (mixte Solaris/Linux pour le moment avec quelques
rares exceptions -- et toujours des projets ayant peu de
dependances --
sur Windows mais je ne connais que deux personnes qui
commencent sur un tel projet et pour le moment il n'ont pas vu
d'avantage reel a VC++) mais permette aussi de travailler sur les
autres.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
Comme?
Compilation comme avec emacs, j'aime bien: il ne m'impose rien sur la
structure de mes projets. Pour ce que j'ai vu des IDE c'est
generalement difficile de le faire fonctionner avec un projet deja
structure dont la structure ne correspond pas a celle prevue par les
Meme sans essuyer les platres. Pour voir si un IDE est utile, il faut
commencer apparemment par restructurer le projet pour etre compatible
avec l'IDE... et comme on a des projets qui sortent sur 11 plateformes
(Sun 32 et 64, HP 32 et 64, IBM 32 et 64, x86, IA64, amd64) il faut
quelque chose qui non seulement soit confortable sur les plateformes
de developpement (mixte Solaris/Linux pour le moment avec quelques
rares exceptions -- et toujours des projets ayant peu de
dependances --
sur Windows mais je ne connais que deux personnes qui
commencent sur un tel projet et pour le moment il n'ont pas vu
d'avantage reel a VC++) mais permette aussi de travailler sur les
autres.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
Comme?
In article , drkm wrote:Marc Boyer writes:wrote:J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
[...]
Ah, c'est donc de là qu'elle venait, la macro StateSpaceNode ?-)
Oui, et comme un imbécile, j'ai cédé à mon vieux réflexe:
dans un .cpp, on peut définir toutes les macros qu'on veut,
ça reste local.
Sauf qu'en attendant export, ben, je fais un #include du .cpp.
In article <wksm79j51s.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
kanze@gabi-soft.fr wrote:
J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
[...]
Ah, c'est donc de là qu'elle venait, la macro StateSpaceNode ?-)
Oui, et comme un imbécile, j'ai cédé à mon vieux réflexe:
dans un .cpp, on peut définir toutes les macros qu'on veut,
ça reste local.
Sauf qu'en attendant export, ben, je fais un #include du .cpp.
In article , drkm wrote:Marc Boyer writes:wrote:J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
[...]
Ah, c'est donc de là qu'elle venait, la macro StateSpaceNode ?-)
Oui, et comme un imbécile, j'ai cédé à mon vieux réflexe:
dans un .cpp, on peut définir toutes les macros qu'on veut,
ça reste local.
Sauf qu'en attendant export, ben, je fais un #include du .cpp.
Marc Boyer wrote in message
news:<cncvi2$nlk$...In article , drkm wrote:Marc Boyer writes:wrote:J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
[...]
Ah, c'est donc de là qu'elle venait, la macro StateSpaceNode ?-)
Oui, et comme un imbécile, j'ai cédé à mon vieux réflexe:
dans un .cpp, on peut définir toutes les macros qu'on veut,
ça reste local.
Sauf qu'en attendant export, ben, je fais un #include du .cpp.
Alors, même à la fin d'un .cpp : #undef. Les macros n'ont pas de scope.
Alors, on la simule.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cncvi2$nlk$2@news.cict.fr>...
In article <wksm79j51s.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
kanze@gabi-soft.fr wrote:
J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
[...]
Ah, c'est donc de là qu'elle venait, la macro StateSpaceNode ?-)
Oui, et comme un imbécile, j'ai cédé à mon vieux réflexe:
dans un .cpp, on peut définir toutes les macros qu'on veut,
ça reste local.
Sauf qu'en attendant export, ben, je fais un #include du .cpp.
Alors, même à la fin d'un .cpp : #undef. Les macros n'ont pas de scope.
Alors, on la simule.
Marc Boyer wrote in message
news:<cncvi2$nlk$...In article , drkm wrote:Marc Boyer writes:wrote:J'espère que non. J'appelle ça l'obfuscation.
Pour donner un exemple issu de mon code, sans macro, cela donne:
[...]
Ah, c'est donc de là qu'elle venait, la macro StateSpaceNode ?-)
Oui, et comme un imbécile, j'ai cédé à mon vieux réflexe:
dans un .cpp, on peut définir toutes les macros qu'on veut,
ça reste local.
Sauf qu'en attendant export, ben, je fais un #include du .cpp.
Alors, même à la fin d'un .cpp : #undef. Les macros n'ont pas de scope.
Alors, on la simule.
Marc Boyer wrote in message
news:<cncgu6$l3m$...wrote:
SS_TEMPLATE
bool STATE_SPACE::find(const NodeInfo& info, StateSpaceNode* &theNode) {
....
}
Et si j'ouvre le fichier à une de ces fonctions, qu'est-ce que je suis
censé à comprendre.
Je suis d'accord que ce que veut le langage, c'est outrement verbeux.
Mais c'est le langage. Je sais le parser. Tandis que SS_TEMPLATE et
STATE_SPACE, c'est quoi ?
À la rigueur, c'est jouable si, et seulement si, c'est une règle de
codage imposé à tout le monde, partout, de façon à ce qu'il soit garanti
que tout le monde qui travaille sur le code le connaît.
Et même dans ce
cas-là, j'aimerais des préfixes sur les macros, qui indiquent bien ce
qu'ils font (et qui empèche toute risque de conflit avec d'autre
symboles).
Et évidemment, un #undef quand tu as fini avec eux. (Je me sers des
macros aussi de temps en temps. Régarde par exemple à la fin de
Format.hh, sur ma site.)
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cncgu6$l3m$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
SS_TEMPLATE
bool STATE_SPACE::find(const NodeInfo& info, StateSpaceNode* &theNode) {
....
}
Et si j'ouvre le fichier à une de ces fonctions, qu'est-ce que je suis
censé à comprendre.
Je suis d'accord que ce que veut le langage, c'est outrement verbeux.
Mais c'est le langage. Je sais le parser. Tandis que SS_TEMPLATE et
STATE_SPACE, c'est quoi ?
À la rigueur, c'est jouable si, et seulement si, c'est une règle de
codage imposé à tout le monde, partout, de façon à ce qu'il soit garanti
que tout le monde qui travaille sur le code le connaît.
Et même dans ce
cas-là, j'aimerais des préfixes sur les macros, qui indiquent bien ce
qu'ils font (et qui empèche toute risque de conflit avec d'autre
symboles).
Et évidemment, un #undef quand tu as fini avec eux. (Je me sers des
macros aussi de temps en temps. Régarde par exemple à la fin de
Format.hh, sur ma site.)
Marc Boyer wrote in message
news:<cncgu6$l3m$...wrote:
SS_TEMPLATE
bool STATE_SPACE::find(const NodeInfo& info, StateSpaceNode* &theNode) {
....
}
Et si j'ouvre le fichier à une de ces fonctions, qu'est-ce que je suis
censé à comprendre.
Je suis d'accord que ce que veut le langage, c'est outrement verbeux.
Mais c'est le langage. Je sais le parser. Tandis que SS_TEMPLATE et
STATE_SPACE, c'est quoi ?
À la rigueur, c'est jouable si, et seulement si, c'est une règle de
codage imposé à tout le monde, partout, de façon à ce qu'il soit garanti
que tout le monde qui travaille sur le code le connaît.
Et même dans ce
cas-là, j'aimerais des préfixes sur les macros, qui indiquent bien ce
qu'ils font (et qui empèche toute risque de conflit avec d'autre
symboles).
Et évidemment, un #undef quand tu as fini avec eux. (Je me sers des
macros aussi de temps en temps. Régarde par exemple à la fin de
Format.hh, sur ma site.)
Matthieu Moy writes:writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Je ne vois pas le rapport.
Comme ecrit par ailleur, generalement j'attache le debuggeur au
process que j'ai lance a part. (Et j'utilise soit emacs+dbx soit
workshop+dbx -- et je ne vois gere d'avantage a etre avec workshop
par rapport a emacs)
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
Dans les deux cas le source est visible dans emacs.
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> writes:
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Je ne vois pas le rapport.
Comme ecrit par ailleur, generalement j'attache le debuggeur au
process que j'ai lance a part. (Et j'utilise soit emacs+dbx soit
workshop+dbx -- et je ne vois gere d'avantage a etre avec workshop
par rapport a emacs)
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
Dans les deux cas le source est visible dans emacs.
Matthieu Moy writes:writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Je ne vois pas le rapport.
Comme ecrit par ailleur, generalement j'attache le debuggeur au
process que j'ai lance a part. (Et j'utilise soit emacs+dbx soit
workshop+dbx -- et je ne vois gere d'avantage a etre avec workshop
par rapport a emacs)
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
Dans les deux cas le source est visible dans emacs.
"Jean-Marc Bourguet" a écrit dans le message de
news:Compilation comme avec emacs, j'aime bien: il ne m'impose rien sur la
structure de mes projets. Pour ce que j'ai vu des IDE c'est
generalement difficile de le faire fonctionner avec un projet deja
structure dont la structure ne correspond pas a celle prevue par les
[....]
Meme sans essuyer les platres. Pour voir si un IDE est utile, il faut
commencer apparemment par restructurer le projet pour etre compatible
avec l'IDE... et comme on a des projets qui sortent sur 11 plateformes
(Sun 32 et 64, HP 32 et 64, IBM 32 et 64, x86, IA64, amd64) il faut
quelque chose qui non seulement soit confortable sur les plateformes
de developpement (mixte Solaris/Linux pour le moment avec quelques
rares exceptions -- et toujours des projets ayant peu de
dependances --
Les problématiques que j'ai rencontrées sont, à première vue, d'un
ordre de grandeur moindre, et l'effort pour le passage sous l'IDE
consentit sans aucune retenu .
sur Windows mais je ne connais que deux personnes qui commencent
sur un tel projet et pour le moment il n'ont pas vu d'avantage
reel a VC++) mais permette aussi de travailler sur les autres.
Bon, pourquoi pas ... ( Etant devenu un accro de l'IDE, je pense
qu'il sont passés à coté de quelque chose ... mais mon point de vue
est fortement dévié )
Malheureusement, le risque est de rester coincer, ( comme je
peux, quotidiennement, le constater autour de moi ) avec des
outils complétements dépassés.
Comme?
J'ai autour de moi des personnes qui continuent comme 'aux temps
anciens' d'utiliser leur traitement de texte préféré datant d'avant
le graphique,
de compiler à grands coups de batch, ou de scripts,
de mettre au point (du moins sous windows) sans utiliser un debugger
symbolique.
Cela, au nom du poids de l'historique,
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:pxblld0slf6.fsf@news.bourguet.org...
Compilation comme avec emacs, j'aime bien: il ne m'impose rien sur la
structure de mes projets. Pour ce que j'ai vu des IDE c'est
generalement difficile de le faire fonctionner avec un projet deja
structure dont la structure ne correspond pas a celle prevue par les
[....]
Meme sans essuyer les platres. Pour voir si un IDE est utile, il faut
commencer apparemment par restructurer le projet pour etre compatible
avec l'IDE... et comme on a des projets qui sortent sur 11 plateformes
(Sun 32 et 64, HP 32 et 64, IBM 32 et 64, x86, IA64, amd64) il faut
quelque chose qui non seulement soit confortable sur les plateformes
de developpement (mixte Solaris/Linux pour le moment avec quelques
rares exceptions -- et toujours des projets ayant peu de
dependances --
Les problématiques que j'ai rencontrées sont, à première vue, d'un
ordre de grandeur moindre, et l'effort pour le passage sous l'IDE
consentit sans aucune retenu .
sur Windows mais je ne connais que deux personnes qui commencent
sur un tel projet et pour le moment il n'ont pas vu d'avantage
reel a VC++) mais permette aussi de travailler sur les autres.
Bon, pourquoi pas ... ( Etant devenu un accro de l'IDE, je pense
qu'il sont passés à coté de quelque chose ... mais mon point de vue
est fortement dévié )
Malheureusement, le risque est de rester coincer, ( comme je
peux, quotidiennement, le constater autour de moi ) avec des
outils complétements dépassés.
Comme?
J'ai autour de moi des personnes qui continuent comme 'aux temps
anciens' d'utiliser leur traitement de texte préféré datant d'avant
le graphique,
de compiler à grands coups de batch, ou de scripts,
de mettre au point (du moins sous windows) sans utiliser un debugger
symbolique.
Cela, au nom du poids de l'historique,
"Jean-Marc Bourguet" a écrit dans le message de
news:Compilation comme avec emacs, j'aime bien: il ne m'impose rien sur la
structure de mes projets. Pour ce que j'ai vu des IDE c'est
generalement difficile de le faire fonctionner avec un projet deja
structure dont la structure ne correspond pas a celle prevue par les
[....]
Meme sans essuyer les platres. Pour voir si un IDE est utile, il faut
commencer apparemment par restructurer le projet pour etre compatible
avec l'IDE... et comme on a des projets qui sortent sur 11 plateformes
(Sun 32 et 64, HP 32 et 64, IBM 32 et 64, x86, IA64, amd64) il faut
quelque chose qui non seulement soit confortable sur les plateformes
de developpement (mixte Solaris/Linux pour le moment avec quelques
rares exceptions -- et toujours des projets ayant peu de
dependances --
Les problématiques que j'ai rencontrées sont, à première vue, d'un
ordre de grandeur moindre, et l'effort pour le passage sous l'IDE
consentit sans aucune retenu .
sur Windows mais je ne connais que deux personnes qui commencent
sur un tel projet et pour le moment il n'ont pas vu d'avantage
reel a VC++) mais permette aussi de travailler sur les autres.
Bon, pourquoi pas ... ( Etant devenu un accro de l'IDE, je pense
qu'il sont passés à coté de quelque chose ... mais mon point de vue
est fortement dévié )
Malheureusement, le risque est de rester coincer, ( comme je
peux, quotidiennement, le constater autour de moi ) avec des
outils complétements dépassés.
Comme?
J'ai autour de moi des personnes qui continuent comme 'aux temps
anciens' d'utiliser leur traitement de texte préféré datant d'avant
le graphique,
de compiler à grands coups de batch, ou de scripts,
de mettre au point (du moins sous windows) sans utiliser un debugger
symbolique.
Cela, au nom du poids de l'historique,
Jean-Marc Bourguet writes:Matthieu Moy writes:writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Je ne vois pas le rapport.
J'édite toto.cpp, et je veux le débugger.
Chez moi (Emacs+gdb), c'est M-x gdb RET gdb toto RET, puis C-x SPC
pour mettre le breakpoint là ou je suis déjà.
Si j'utilisais un déboggueur lancé à part de mon éditeur, ça serait :
1) lancer le déboggueur
2) ouvrir toto.cpp
3) mettre le breakpoint.
En utilisant un déboggueur lancé directement depuis l'éditeur,
j'économise donc le 2).
Comme ecrit par ailleur, generalement j'attache le debuggeur au
process que j'ai lance a part. (Et j'utilise soit emacs+dbx soit
workshop+dbx -- et je ne vois gere d'avantage a etre avec workshop
par rapport a emacs)
Là, c'est moi qui ne vois pas le rapport ;-) La phrase à laquelle je
réponds n'est pas Emacs Vs Workshop, mais « déboggueur lancé depuis
l'editeur » Vs « reste du monde ».
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
Dans les deux cas le source est visible dans emacs.
Oui, mais si tu utilise un déboggeur lancé à part de ton éditeur
(c'est la question à laquelle je répondais, pour rappel), il faut
ouvrir le fichier dans Emacs à moins qu'il ne soit déjà ouvert. Si tu
as un déboggueur dans ton Emacs, le fichier est de toute façons déjà
ouvert à la bonne ligne. (sauf si c'est en débogguant toto.cpp que tu
réalise qu'il y a un bug dans titi.h, mais là, c'est un peu tordu ;-)
Jean-Marc Bourguet <jm@bourguet.org> writes:
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> writes:
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Je ne vois pas le rapport.
J'édite toto.cpp, et je veux le débugger.
Chez moi (Emacs+gdb), c'est M-x gdb RET gdb toto RET, puis C-x SPC
pour mettre le breakpoint là ou je suis déjà.
Si j'utilisais un déboggueur lancé à part de mon éditeur, ça serait :
1) lancer le déboggueur
2) ouvrir toto.cpp
3) mettre le breakpoint.
En utilisant un déboggueur lancé directement depuis l'éditeur,
j'économise donc le 2).
Comme ecrit par ailleur, generalement j'attache le debuggeur au
process que j'ai lance a part. (Et j'utilise soit emacs+dbx soit
workshop+dbx -- et je ne vois gere d'avantage a etre avec workshop
par rapport a emacs)
Là, c'est moi qui ne vois pas le rapport ;-) La phrase à laquelle je
réponds n'est pas Emacs Vs Workshop, mais « déboggueur lancé depuis
l'editeur » Vs « reste du monde ».
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
Dans les deux cas le source est visible dans emacs.
Oui, mais si tu utilise un déboggeur lancé à part de ton éditeur
(c'est la question à laquelle je répondais, pour rappel), il faut
ouvrir le fichier dans Emacs à moins qu'il ne soit déjà ouvert. Si tu
as un déboggueur dans ton Emacs, le fichier est de toute façons déjà
ouvert à la bonne ligne. (sauf si c'est en débogguant toto.cpp que tu
réalise qu'il y a un bug dans titi.h, mais là, c'est un peu tordu ;-)
Jean-Marc Bourguet writes:Matthieu Moy writes:writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur, la première chose que tu fais, c'est de mettre un
breakpoint (sauf pour débugger un segfault ...). Or, en général, à
ce moment là, j'ai déjà mon éditeur ouvert sur le bon fichier au bon
endroit ...
Je ne vois pas le rapport.
J'édite toto.cpp, et je veux le débugger.
Chez moi (Emacs+gdb), c'est M-x gdb RET gdb toto RET, puis C-x SPC
pour mettre le breakpoint là ou je suis déjà.
Si j'utilisais un déboggueur lancé à part de mon éditeur, ça serait :
1) lancer le déboggueur
2) ouvrir toto.cpp
3) mettre le breakpoint.
En utilisant un déboggueur lancé directement depuis l'éditeur,
j'économise donc le 2).
Comme ecrit par ailleur, generalement j'attache le debuggeur au
process que j'ai lance a part. (Et j'utilise soit emacs+dbx soit
workshop+dbx -- et je ne vois gere d'avantage a etre avec workshop
par rapport a emacs)
Là, c'est moi qui ne vois pas le rapport ;-) La phrase à laquelle je
réponds n'est pas Emacs Vs Workshop, mais « déboggueur lancé depuis
l'editeur » Vs « reste du monde ».
Ensuite, quand tu as bien utilisé le déboggueur, en général, tu
trouves un bug, et tu cherches à le corriger. Et là, si ton
déboggueur tourne dans ton éditeur, tu es déjà au bon endroit pour
pouvoir editer le source.
Dans les deux cas le source est visible dans emacs.
Oui, mais si tu utilise un déboggeur lancé à part de ton éditeur
(c'est la question à laquelle je répondais, pour rappel), il faut
ouvrir le fichier dans Emacs à moins qu'il ne soit déjà ouvert. Si tu
as un déboggueur dans ton Emacs, le fichier est de toute façons déjà
ouvert à la bonne ligne. (sauf si c'est en débogguant toto.cpp que tu
réalise qu'il y a un bug dans titi.h, mais là, c'est un peu tordu ;-)
