GTC : un TIGCC sur votre calculatrice ? - Page 25

> Et toi, tu commences à m'emm*rder sérieusement à t'imaginer toutes sortes de trucs sur moi qui ne sont pas vraies.
Tu devrais te relire alors, la majorité de tes posts sont des ordres ou des déclarations de projets visant à emmerder le kernel/GTC/GraphX/Xlib/PreROM... comme par hazard, tout ce qui ne colle pas à tes modestes opinions.

> 2 personnes qui forkent nos routines
Ohh mon pauvre chou

> Tu préfères un plantage à un message d'erreur, toi ???


> elle consomme nettement moins de place en RAM !
Ha ? eh bien, la prochaine version de GraphX l'intégrera

> On ne va pas mettre 2 versions de la même routine de niveaux de gris dans tigcc.a !
Raison ?

Ha, Uther Lightbringer a dit Il y a pas si longtemps je t'aurais plustot défendu mais entre l'obligation de TIGCC-IDE et l'integration de extagraph en plus de l'acharnement habituel contre tous les projets qui font qu'on utilise pas a 100% TIGCC ca fait beaucoup trop à mon avis.

Je vois que je ne suis pas le seul à trouver que Kevin se prend pour un chef.

Uther Lightbringer
a écrit : entre l'obligation de TIGCC-IDE

Tu seras obligé d'utiliser TIGCC IDE si tu voudras utiliser le débogueur qu'on compte y intégrer. Ça m'a l'air plutôt normal.

et l'integration de extagraph

C'est prévu depuis que ExtGraph existe! Je ne comprends pas ta surprise.

Mais si j'ai bien compris ca va empecher des progs qui tournent normalement bien sur Pedrom de marcher non?

On va voir ce qu'on peut faire pour ce problème. Mais le problème des fonctions qui plantent sous Pedrom devra être résolu d'une manière ou d'une autre au plus tard quand Pedrom sortira officiellement.

le problème c'est que ca ne coute absolument rien de garder extagraph en externe à TICCCLIB

C'est moins pratique.

et que ca va foutre dans la merde Pollux et PpHd.

N'exagère pas! Rien ne les oblige à mettre les routines dans leur fork respectif de TIGCCLIB. Pollux peut les distribuer séparemment comme avant ou alors ne pas les distribuer du tout. PpHd peut les laisser en statique, ça ne changera rien à l'état actuel.

Et encore une fois: je ne parle pas pour l'équipe entière, mais personnellement je n'ai rien à f**tre de ceux qui forkent notre projet, et je ne vois pas pourquoi je devrais les prendre en compte dans mes décisions. Ils forkent le projet, et ils en tirent les conséquences (et la responsabilité de résoudre ce genre de problèmes en fait partie). Ils savaient depuis le départ que l'intégration de ExtGraph est prévue, c'est écrit dans sa documentation depuis qu'elle est sortie pour la première fois!

la je comprend pas bien ce que tu veux dire, tu peux expliquer s'il te plait?

Il suffit de prendre une source d'un programme qui utilise ExtGraph. Tu as:
* soit une copie de extgraph.a et de extgraph.h fournie avec les sources,
* soit 2 liens morts dans le fichier projet du programme.
En intégrant ExtGraph à TIGCCLIB, ce problème est résolu. Et si les auteurs sont d'accord pour l'intégration de leurs routines à TIGCCLIB, il n'y a aucun argument valable contre cette intégration.

> Mais si j'ai bien compris ca va empecher des progs qui tournent normalement bien sur Pedrom de marcher non?
Si on refuse totalement PedroM, oui. Mais je suis absolument contre l'ajout de code à tigcc.a / tipatch.lib pour refuser PedroM, j'ai déjà dit pourquoi.

> le problème c'est que ca ne coute absolument rien de garder extgraph en externe à TICCCLIB et que ca va foutre dans la merde Pollux et PpHd.
Eux, ils foutent déjà la merde... Alors un peu plus ou un peu moins, ça ne changera pas grand chose.

>> Ça apporte que les fonctions graphiques feront partie intégrante de tigcc.a
> C'est a dire rien
Tu m'ennuie, Uther Ligthbringer... Il faudra que je dise combien de fois qu'ExtGraph va être plus performante dans une prochaine version ? Et on a déjà posté des benchs, avec des routines non finies en plus...

ExtGraph est prévue pour aller dans TIGCCLIB, ça fait depuis le départ.
MAIS, une raison pour ne pas inclure ExtGraph dans tigcc.a, est qu'ExtGraph est open-source, et permet à à peu près n'importe qui de modifier les routines pour son propre usage. Par exemple, si on ne dessine que dans LCD_MEM, on supprime le paramètre plane, et on remplace le move d(sp),an par un lea... Si on n'a que des sprites de 8x8, pas la peine de laisser le paramètre h... etc


Thibaut, je trouve que tes posts sont peu constructifs...

[dernier post vu: #722, Kevin]

Vous n'avez pas moyen de le faire en deux archives : tigcclib.a et extgraph.a ?
GCC permet bien qu'on lui donne plusieurs archives où piocher les fonctions ?

> Tu m'ennuie, Uther Ligthbringer... Il faudra que je dise combien de fois qu'ExtGraph va être plus performante dans une prochaine version ? Et on a déjà posté des benchs, avec des routines non finies en plus...

Quel rapport avec l'intégration ?

Pourquoi faire 2 archives quand une suffit? Personne n'empêche à Pollux et PpHd de couper l'archive en 2!

Tu seras obligé d'utiliser TIGCC IDE si tu voudras utiliser le débogueur qu'on compte y intégrer. Ça m'a l'air plutôt normal.

Oui mais on pourra toujours utiliser sans l'IDE alors? Dans ce cas la ca ne me dérange pas du tout.

C'est prévu depuis que ExtGraph existe! Je ne comprends pas ta surprise.

He bien disons que je me suis pas trop attardé sur la doc.

Il suffit de prendre une source d'un programme qui utilise ExtGraph. Tu as:
* soit une copie de extgraph.a et de extgraph.h fournie avec les sources, * soit 2 liens morts dans le fichier projet du programme

C'est bien ce que je pensait, je n'appelle vraiment pas ca un problème

je n'ai rien à f**tre de ceux qui forkent notre projet

Tu fais ce que tu veux mais bon ca vas emerder pas mal de monde c'est tout.

Kevin : moué :/

Uther Lightbringer > ca vas emerder pas mal de monde c'est tout
C'est le but de Kevin : il fait tout pour écraser sa concurrence

> C'est a dire rien Tu m'ennuie, Uther Ligthbringer... Il faudra que je dise combien de fois qu'ExtGraph va être plus performante dans une prochaine version ? Et on a déjà posté des benchs, avec des routines non finies en plus...

He je n'ai pas critiqué Extragraph j'ai juste dis que les fonctions soient a l'extérieur ou a l'interieur de Tigcclib ca ne change rien

Uther Lightbringer
a écrit : Oui mais on pourra toujours utiliser sans l'IDE alors?

Compiler, oui, comme maintenant. Déboguer, non.

Tu fais ce que tu veux mais bon ca vas emerder pas mal de monde c'est tout.

Tu pense vraiment que ça les embêtera tant que ça? Personne ne les empêche de couper leur librairie en 2.

Tu pense vraiment que ça les embêtera tant que ça? Personne ne les empêche de couper leur archive en 2.

Oui mais se retrouver avec un TIGCCLIB.89z de 64Ko, ca deviens dessuite beaucoup moins intéréssant. et ca fait bien moins de place pour la prog on-calc.

Ouais, mais il y a quand même un problème: en intégrant ExtGraph dans TIGCCLIB, on perd en partie la modification facile des routines pour les adapter à une situation particulière...
Peut-être qu'il faudrait intégrer le source d'ExtGraph au zip des binaries. Mais il restera le problème de la double définition des fonctions (un attribute spécial pourrait peut-être arranger ça, peut-être weak, mais weak n'existe plus)...

> Oui mais se retrouver avec un TIGCCLIB.89z de 64Ko, ca deviens de suite beaucoup moins intéréssant. et ca fait bien moins de place pour la prog on-calc.
Qui est intéressé par faire de gros programmes avec une grosse librairie on-calc ?


Pollux ne veut peut-être pas contribuer ses routines à TIGCCLIB. C'est son choix. Mais c'est un peu dommage... Ca me donne un peu l'impression (peut-être fausse) qu'il ne veut pas faire des choses pour TOUTE la communauté, ce qui est pourtant, de loin, le plus fin...

XDanger a écrit :
Ouais, mais il y a quand même un problème: en intégrant ExtGraph dans TIGCCLIB, on perd en partie la modification facile des routines pour les adapter à une situation particulière... Peut-être qu'il faudrait intégrer le source d'ExtGraph au zip des binaries.

Je pense qu'il suffit de les mettre dans le ZIP des sources. Je ne vois pas de raison pourquoi ceux qui veulent les sources des routines ne devraient pas télécharger le ZIP des sources.

Mais il restera le problème de la double définition des fonctions (un attribute spécial pourrait peut-être arranger ça, peut-être weak, mais weak n'existe plus)...

Je pense que weak n'a jamais été supporté correctement. Mais:
1. ld-tigcc n'importe un symbole d'une archive que quand les objets du programme ne le définissent pas, donc la préférence est automatiquement donnée aux symboles redéfinis.
2. Si ça ne marche quand-même pas, il suffit de changer le nom.

XDanger : Soit plus objectif ! Je prend un exemple : TILTmaze. Il est compilé sans problème par GTC. Ce n'est pas un petit programme et il aurait pû exploiter ExtGraph pour les sprites.

Ah, donc votre problème, c'est que vous pensez que plus de programmes vont effectivement utiliser les routines si on les intègre à TIGCCLIB... Ben, soit il est totalement inutile de les intégrer, soit plus de programmes que maintenant les utiliseront si elles sont intégrées, mais pas les deux. Tu te contredis, Thibaut. Il faudra que tu te décides.

Tiens, il y a un message qui m'a échappé avec le saut de page...

Thibaut a écrit :
> Et toi, tu commences à m'emm*rder sérieusement à t'imaginer toutes sortes de trucs sur moi qui ne sont pas vraies. Tu devrais te relire alors, la majorité de tes posts sont des ordres ou des déclarations de projets visant à emmerder le kernel/GTC/GraphX/Xlib/PreROM... comme par hazard, tout ce qui ne colle pas à tes modestes opinions.

Les projets que j'annonce ne visent pas du tout à emm*rder qui ou quoi que ce soit! S'ils créent des problèmes d'interopérabilité avec d'autres projets, ce n'est pas voulu et je n'y peux rien.

> 2 personnes qui forkent nos routines Ohh mon pauvre chou

Ce n'est pas drôle.
Et s'ils forkent nos routines, c'est qu'ils ne sont pas contents avec nous et qu'ils veulent faire leur projet à eux. Alors qu'ils le fassent, mais ils ne doivent pas compter sur notre support. Nous prenons nos décisions en fonction de ce qui est le mieux pour notre projet, pas pour les forks.

> Tu préfères un plantage à un message d'erreur, toi ???

Ben, c'est à ça que revenait ton commentaire que j'avais cité...

> On ne va pas mettre 2 versions de la même routine de niveaux de gris dans tigcc.a ! Raison ?

2 fois l'effort de maintenance, aucun intérêt. Et on peut très bien faire une librairie graphique avec les routines de niveaux de gris actuelles, cf. ExtGraph.

demain ???#espoir#

Le deuxième effort de maintenance, c'est moi qui le fait
Tu es de mauvaise foi !!! C'est désagréable de discuter avec toi. D'ailleurs, avec toi on ne discute pas...

Si on "forke" tes petites routines chéries, c'est pas parcequ'on n'est pas content de ton travail, mon chou. C'est parcequ'on en a besoin pour ce qu'on veut faire. Par exemple moi, je n'avais pas d'autre moyen pour réaliser mon TSB.
Si ton caractère de <il est innomable > fait que ça ne te donne pas envie d'aimer GraphX, c'est bien dommage et c'est là le problème avec toi : tu emmerdes tous ceux qui ont des idées différentes des tiennes

Pour le post #736, t'as rien compris. Relis ce à quoi je répondais. Tu me fais rire sur ce coup là

XDanger : Soit plus objectif ! Je prend un exemple : TILTmaze. Il est compilé sans problème par GTC. Ce n'est pas un petit programme et il aurait pû exploiter ExtGraph pour les sprites.

Il a été écrit avant qu'ExtGraph existe, et il n'a pas été mis à jour depuis l'arrivée d'ExtGraph. C'est aussi bête que ça...
Au fait: j'avais commencé à améliorer TiltMaze, entre autres en utilisant les routines de sprite d'ExtGraph... Ca fera 1 an mardi que je n'ai pas touché à ce projet...
Les jeux sont en bas de la todo list. Plus haut, il y a tant de choses: ExtGraph, la TIGCC Tools Suite...

Mais je n'ai pas le temps d'en faire plus: pas de vacances ou de temps libre avant cet été (fin juin - début juillet). C'est en partie de ma faute (je n'ai pas commencé mes cours par correspondance à une vitesse très élevée), mais pas seulement (cours qui commencent tard, les "livres" arrivent seulement fin octobre; le planning des devoirs est pour le moins mal fait...)

> Je pense qu'il suffit de les mettre dans le ZIP des sources. Je ne vois pas de raison pourquoi ceux qui veulent les sources des routines ne devraient pas télécharger le ZIP des sources.
Très peu de personnes téléchargent les sources de TIGCC. C'est un fichier de 4 MO... Par contre, beaucoup de personnes modifient pour leur usage personnel les routines, de la façon décrite plus haut. Je souhaiterais donc que les sources d'ExtGraph soient une exception dans les binaries de TIGCC, au cas (pas très improbable) où ExtGraph serait intégrée à TIGCCLIB.

Je pense que weak n'a jamais été supporté correctement. Mais:
1. ld-tigcc n'importe un symbole d'une archive que quand les objets du programme ne le définissent pas, donc la préférence est automatiquement donnée aux symboles redéfinis. 2. Si ça ne marche quand-même pas, il suffit de changer le nom.

Je préfère nettement la première solution. A ce moment-là, la redéfinition des fonctions devrait être assez facile (si les sources sont fournis dans les binaries)...

Si weak n'existe plus, il faut corriger la doc de l'attribute alias (note: j'utilise toujours une version qui n'est pas à jour de TIGCC, ça a peut-être été fait dans des versions plus récentes).

Réponse a la page 19 :

Kevin Kofler a écrit :
Et enfin montre-moi un éditeur qui gère la coloration syntaxique pour le Quill Adventure Writer de Zeljko Juric. TIGCC IDE est le seul que je connais. (Et les fonctionnalités pour Quill sont bien cachées: installe Quill comme décrit dans sa documentation, et les fonctions de style "New Quill File" apparaîtront automatiquement. )

Quel mauvais exemple !

Se format de fichier ne touche que 0.1% des programmeur de la planette !!

Et puis rien ne t'empeche de faire un fichier "plugin" pour n'importe quel editeur EVOLUE (se que TIGCC-IDE n'est pas) pour gerer se type de fichier !

Ensuite imposer un IDE est de tresz mauvais gout, ou alors il faut qu'il soit parfait ! (ie: Visual C est "parfait" a mon gout, il est totalement integré aux outils de MS, se qui n'est pas le cas de TIGCC IDE, ne serait que le manque cruel d'un débuggeur, mais bon la sa dépasse un peu le stade du projet amateur, c'est vrai.)

Ensuite l'integration du "clic qui fait tt" les ide genre ultra edit, etc.. permettent aussi de le faire ! (il sont configurable)

Meme Rhide avec un peu de parametrage peu permetre de compiler avec TIGCC !

Il te manque quoi? Et surtout: s'il te manque de trucs, pourquoi ne pas soumettre des patches? Tu sais programmer, n'est-ce pas?

Personnelement j'aime pas le pascal/Delphi/Kylix, et c une tres bonne raison pour ne pas proposer de patches

Tu n'as pas dû essayer une version assez récente. La coloration syntaxique est beaucoup plus rapide que lors des premières versions.

N'empeche qu'il met au moins 2x a 3x plus de temps que les IDE "normaux" pour charger un fichier...

C'est loin d'offrir les fonctionnalités de l'IDE. Surtout du point de vue gestion des projets et test automatique.

Se n'est oas a un IDE de fournir se genre de fonctionnalité. Il existe make, c pas pour les chiens...

Vous êtes un peu pénibles, tous ceux qui n'aiment pas l'IDE. Vous n'avez qu'à en réécrire un, ça sera bénéfique pour toute la communauté... Ah, c'est vrai, j'oubliais, beaucoup de personnes n'ont rien à faire de la communauté...

Je profite de ce post pour remercier une nouvelle fois ceux qui m'aident/contribuent des routines pour/à ExtGraph: jackiechan, Ximoon, ExtendeD... Sans eux, la prochaine release se ferait nettement plus tard... Bon, il faut que je me reprenne toutes les routines, car je n'ai pas spécifié que je préférais le format GNU as et que je n'aimais pas trop les tabs. C'est ma faute. Mais tout le boulot qu'ils font m'aide grandement !

godzil
a écrit : Et puis rien ne t'empeche de faire un fichier "plugin" pour n'importe quel editeur EVOLUE (se que TIGCC-IDE n'est pas)

TIGCC IDE est un IDE conçu spécialement pour TIGCC. Tu ne t'attends pas à pouvoir éditer du TI-BASIC avec l'IDE de VC++, n'est-ce pas?

Ensuite imposer un IDE est de tresz mauvais gout, ou alors il faut qu'il soit parfait ! (ie: Visual C est "parfait" a mon gout, il est totalement integré aux outils de MS, se qui n'est pas le cas de TIGCC IDE, ne serait que le manque cruel d'un débuggeur, mais bon la sa dépasse un peu le stade du projet amateur, c'est vrai.)

L'IDE ne sera "imposé" que si tu voudras utiliser le débogueur intégré (qui, je te le rappelle, est toujours prévu). Si tu veux juste pouvoir compiler ton projet, il y aura toujours tigcc.exe.

Ensuite l'integration du "clic qui fait tt" les ide genre ultra edit, etc.. permettent aussi de le faire ! (il sont configurable)

Il te faudra coder un programme pour l'envoi de touches à VTI. VTI ne comprend pas la ligne de commande.

N'empeche qu'il met au moins 2x a 3x plus de temps que les IDE "normaux" pour charger un fichier...

Parce qu'il prépare la coloration syntaxique pour aller plus vite par la suite.

Se n'est oas a un IDE de fournir se genre de fonctionnalité. Il existe make, c pas pour les chiens...

Si. Tout IDE qui se respecte s'occupe de la gestion des projets. Sinon, ce n'est pas un IDE, c'est un éditeur. Et make est beaucoup plus compliqué à utiliser que la gestion de projets d'un IDE.

Kevin Kofler a écrit :
TIGCC IDE est un IDE conçu spécialement pour TIGCC. Tu ne t'attends pas à pouvoir éditer du TI-BASIC avec l'IDE de VC++, n'est-ce pas?

Ben pourquoi pas ?
L'iDE de VisualStudio est pas reservé au C/C++ !
ON peu editer de l'html et d'autre type de fichier avec un colloration syntaxique, pour supoprter d'autre format, suffit de faire un plugin pour !

Il te faudra coder un programme pour l'envoi de touches à VTI. VTI ne comprend pas la ligne de commande.

On est pas obligé d'utiliser VTI ! Pourquoi on utiliserait pas un emu integré a l'ide/compilo

Et puis VTI permet pas de débugger du C, mais uniquement de l'asm...
D'ailleur les sources de VTI sont dispo, rien n'empeche de les changer !

Parce qu'il prépare la coloration syntaxique pour aller plus vite par la suite.

Ben alors je sais pas comment il fait sa coloration syntaxique, mais des editeur genre UltraEdit, Jext, ou autre ne font pas sa a l'ouverture de fichier (c bien sensible si le fichier est gros)

Si. Tout IDE qui se respecte s'occupe de la gestion des projets. Sinon, ce n'est pas un IDE, c'est un éditeur. Et make est beaucoup plus compliqué à utiliser que la gestion de projets d'un IDE.

Make est pas compliqué a utiliser, et un IDE peut utiliser MAKE (KDevelop par ex) généré un fichier Make est pas compliqué, loin de la.

godzil a écrit :
Ben pourquoi pas ?
L'iDE de VisualStudio est pas reservé au C/C++ ! ON peu editer de l'html et d'autre type de fichier avec un colloration syntaxique, pour supoprter d'autre format, suffit de faire un plugin pour !

Ah, carrément? Vive le bloatware de chez M$! Les IDE ne sont plus ce qu'ils étaient.

On est pas obligé d'utiliser VTI ! Pourquoi on utiliserait pas un emu integré a l'ide/compilo

C'est plus ou moins ce qu'on compte faire pour le futur débogueur intégré à l'IDE. Et je ne vois pas du tout le rapport avec le contexte, qui était l'utilisation d'un autre IDE que le nôtre.

Et puis VTI permet pas de débugger du C, mais uniquement de l'asm...

Le "run" sert pour tester plus que pour "déboguer" au sens strict. Un débogueur C est sur notre liste TODO. J'attends surtout que TiEmu soit compilable correctement sous MinGW pour qu'on puisse commencer à l'adapter. Roms a travaillé là-dessus, il faut d'ailleurs que j'aille voir où on en est. (Et: non, nous n'utiliserons pas MSVC, BCB ou un autre compilateur C non-GNU.)

D'ailleur les sources de VTI sont dispo, rien n'empeche de les changer !

Mais il y a quelque chose à programmer si tu veux pouvoir tester avec VTI en un clic. Alors que si tu utilises TIGCC IDE, c'est déjà fait.

Ben alors je sais pas comment il fait sa coloration syntaxique, mais des editeur genre UltraEdit, Jext, ou autre ne font pas sa a l'ouverture de fichier (c bien sensible si le fichier est gros)

Tu préfères attendre une fois à l'ouverture ou en permanence pendant l'édition?
Et c'est devenu beaucoup plus rapide qu'au départ. Quelle est la dernière version que tu as testée? Contrairement à ce que certains ici ont l'air de penser, Sebastian a fait pas mal d'efforts pour accélerer la coloration syntaxique.

Make est pas compliqué a utiliser, et un IDE peut utiliser MAKE (KDevelop par ex) généré un fichier Make est pas compliqué, loin de la.

Quel est l'avantage par rapport à un système de dépendances intégré directement à l'IDE comme c'est le cas dans TIGCC IDE (et dans tous les IDE classiques)? Et ne me dis pas la portabilité. Je sais que le tprbuilder laisse à désirer en son état actuel (par exemple, il recompile à chaque fois tout au lieu de gérer les dépendances), mais le système de projets .tpr n'a rien de non-portable. Et un système de dépendances intégré à l'IDE est necessairement plus rapide que la génération d'un fichier (Makefile) et l'appel d'un autre outil (make) qui travaille sur ce fichier.

--- errreur ---

godzil : je sais pas ce qui te motive, mais je trouve que tu exagères

L'IDE de TIGCC est très rapide et très puissante (beaucoup de fonctions).
Il lui manque encore pas mal de choses très utiles, c'est sûr, mais il faut laisser le temps à son auteur...

Si vous ne voyez pas de quoi je parle, téléchargez le dernier DevC++, il est GE-NIAL

Liste non-exhaustive de ce qu'il a de très pratique et de plus que TIGCC :
- très beau ()
- explorateur de classes (qui prend en charge aussi les structures et unions),
- paramétrage du compilo par des simples cases à cocher,
- complétion de code,
- thèmes prédéfinis pour les couleurs de l'IDE,
- modèles de code,
- gouttière où s'affichent les numéros des lignes,
- comptage du nombre de lignes DE CODE dans un fichier,
- fonction mettre en comentaire, fonction indenter,
- accès à la déclaration d'un symbole par un clic dessus tout en pressant [ctrl],
- visualisation du type d'une variable quand on laisse le pointeur de la souris au-dessus,
- ...

DevC++ devient (est déjà ?) aussi bien que l'IDE de Borland C++ Builder
Je crois que c'est ce que tu utilises, Kevin, pour compiler sous Window$. Tu penses que toutes ces fonctionnalités arriveront un jour dans TIGCC IDE ?

Kevin Kofler a écrit :
Ah, carrément? Vive le bloatware de chez M$! Les IDE ne sont plus ce qu'ils étaient.

Parlon pas de TIGCC-IDE qui se veux editer 5 (ou 6) type de fichier
Un IDE correcte DOIT permetre d'ajouter des type de fichiers non prévu a la base !

Le "run" sert pour tester
plus que pour "déboguer" au sens strict. Un débogueur C est sur notre liste TODO. J'attends surtout que TiEmu soit compilable correctement sous MinGW pour qu'on puisse commencer à l'adapter. Roms a travaillé là-dessus, il faut d'ailleurs que j'aille voir où on en est. (Et: non, nous n'utiliserons pas MSVC, BCB ou un autre compilateur C non-GNU.)

Et pourquoi vous utiliseriez pas des compilo non GNU ?
Que je sache MSVC est largement supérieur a GCC, ne serait-ce qu'au niveau optimisation est fonctionnalité (ne serait-ce que le support des header précompilé qui est présent depuis de nombreuse année, pour cite que sa, qui va entrer en stade expérimental dans gcc)
En plus VisualC++ ou C++ Builder sont bien mieux optimisé pour windows que tt les compilo basé sur GCC

Tu préfères attendre une fois à l'ouverture ou en permanence pendant l'édition?
Et c'est devenu beaucoup plus rapide qu'au départ. Quelle est la dernière version que tu as testée? Contrairement à ce que certains ici ont l'air de penser, Sebastian a fait pas mal d'efforts pour accélerer la coloration syntaxique.

En permanance ! Ta jamais du utiliser un IDE digne de se nom !
La majorité des IDE colorient a la volée ! et se ne se ressent pas du tout a l'utilisation. Sauf dans un seul cas, si la coloration est legerement buggé sur un point en remontant/descendant sa permet souvent de "corriger" le bug

J'ai testé la derniere version officielle en date (0.94SP4)

Quel est l'avantage par rapport à un système de dépendances intégré directement à l'IDE comme c'est le cas dans TIGCC IDE (et dans tous les IDE classiques)? Et ne me dis pas la portabilité. Je sais que le tprbuilder laisse à désirer en son état actuel (par exemple, il recompile à chaque fois tout au lieu de gérer les dépendances), mais le système de projets .tpr n'a rien de non-portable. Et un système de dépendances intégré à l'IDE est necessairement plus rapide que la génération d'un fichier (Makefile) et l'appel d'un autre outil (make) qui travaille sur ce fichier.

Justement SI, la portabilité, si on utilise pas l'ide on a toujour le makefile. Sous les Unices, que je sache TIGCC Ide n'a pas encore été porté, vous faites comment alors ?
Vous etes allé jusqua reinventé la roue pour "rester compatible" avec la version WIN ?
Quelle perte de temps...

Et puis tu viens de glisser le doigts sur une des grosse faille de votre format. sont incapacité a recompiler correctement. Dans certain cas sa fait bugger toute la compilation, voir meme il recompile rien (sa m'est deja arrivé plusieurs fois) et on envois 15fois de suite a VTI la meme chose en comprennant pas pq il fait tjrs la meme erreur alors qu'on a commenté (par ex) la partie en cause

J'ai bien envie d'ajouter 3 trucs à ma petite liste du post #747
- gestion CVS,
- exportation des sources au format HTML,
- importation de projets M$ Visual C++ ()