utilisation de TI-GCC - Page 2

Godzil (./30) :
Et puis excuse moi, mais je ne peut appeler TIGCC-IDE (sic) comme un IDE,

C'est quoi alors? Un lion sauvage?

surtout quand on compare avec de vrai IDE qui ont au moins 10ans d'age,

Alors déjà je ne vois pas en quoi l'âge aurait la moindre importance ici. Et ensuite, TIGCC IDE a plus de 7 ans déjà, ce n'est pas non plus le nouveau du bloc.

de vrai utilisateurs,

Je suis sûr que les utilisateurs de TIGCC IDE et KTIGCC seront contents d'apprendre qu'ils ne sont pas de "vrais" utilisateurs. (<- ironie ) Et ce sont des IDEs spécialisés pour TIGCC, c'est normal qu'un produit "niche" ne soit pas aussi utilisé qu'un produit grand public. Ça ne veut pas dire que c'est mauvais.

qui n'ont pas un espece de dictateur derriere qui joue l'immobilisme

Déjà, nous n'avons aucun développeur Delphi depuis le départ de Sebastian, j'ai plusieurs fois demandé de l'aide sur ce point, mais les quelques personnes ayant les connaissances et le compilateur n'ont pas eu le temps ou la motivation. Donc je ne vois pas comment TIGCC IDE peut évoluer à part pour les petits correctifs de bogues que je fais. KTIGCC 2, la version multiplateforme (KDE 4) de KTIGCC, me permettra plus de souplesse. L'"immobilisme" n'est pas le résultat d'une "dictature".

Et ensuite, je ne vois pas trop quels grands changements apporter. Gérer les groupes de projets est une idée que je vais garder en tête pour KTIGCC 2 ou 3. Mais AMHA c'est loin d'être essentiel.

au point d'aller faire une copie 1:1 en portant le truc sur une nouvelle plateforme

J'ai fait ça car:
* interface connue pour ceux passant de l'une version de TIGCC à l'autre,
* possibilité de réutiliser la documentation (et aussi les tutoriaux etc.) sans modifications,
* AMHA, l'interface de TIGCC IDE est très bonne et très pratique!

plutot que de tenter de le mettre a jour

La mise à jour y a bien été, par exemple KTIGCC a géré TiEmu pour le débogage en premier (code porté ensuite vers TIGCC IDE en Delphi), et ça utilise aussi les tilibs pour la liaison avec les calculatrices réelles, ce qui permet de gérer les nouveaux câbles (la version Win32 devra attendre KTIGCC 2 pour ça).

et de faire un truc bien

AMHA TIGCC IDE et KTIGCC sont des "trucs bien", ce sont des IDEs parfaitement adaptés à TIGCC alors que vos IDEs génériques offrent une interface peu adaptée (pas d'options spécifiques TIGCC, et aussi plein d'options et fonctionnalités qui soit ne marchent pas avec TIGCC, soit ne servent strictement à rien pour un projet pour calculatrice).

sans aucune options digne d'un IDE

L'essentiel (compilation, erreurs cliquables, débogage, ...) y est.

pas de refactoring

C'est très loin d'être indispensable, surtout vu la taille moyenne d'un projet TI.

pas de completion digne de ce nom

Ah bon? Et la complétion qu'on a, c'est quoi alors?

incapable de gerer plusieurs projets simultanéement

Comme déjà dit, je note la suggestion, mais c'est loin d'être indispensable. Normalement, un projet TI linke tout dans le même exécutable et donc on n'a besoin que d'un seul projet.

et avec des fenetres d'options digne du pire film d'horreur...

Et concrètement? Parce que là c'est de la provocation destructive. Qu'est-ce qui ne va pas? Les fenêtres sont trop chargées? Alors tu proposes de présenter les options comment? TIGCCLIB est très flexible, donc il y a de nombreuses options réglables.

L'essentiel (compilation, erreurs cliquables, débogage, ...) y est.

Sa de nombreux utilitaire (qu'on ne peut appeler IDE) possedent ce genre d'options. C'est pas vraiment ça qui permet de différencier...

Martial Demolins (./32) :

Kevin Kofler (./31) :
Normalement, un projet TI linke tout dans le même exécutable et donc on n'a besoin que d'un seul projet.

Sauf pour les formats de fichier modernes.

"Modernes" comme Fargo de 1996.
Les nouveaux programmes sont censés être _nostub, si TIGCC gère encore le mode kernel, c'est surtout pour la compatibilité antérieure, ce n'est carrément pas conseillé.

Martial; chacun est (malgres tout) libre de penser ce qu'il veux, et de dire ce qu'il veux, il n'a pas porté atteinte a quelqu'un de vivant. Si sa te choque pose toi des questions... Sinon je vois pas en quoi ça devrait te choquer...

./35>
c'est de l'humour ton post ou t'es serieux? (regulierement? )
et pour ta gouverne, c'est une expression tres repandue, sisi, vraiment (et de toutes c'etait pas vraiment l'interet premier la hein.. pff...)

tiens, vu que ton ./35 etait limite une invitation a poster une connerie en guise de reponse, et vu que je suis un faible, une autre expression tres repandue, mais en image \o/
-> [zeph] image supprimée...

J'ai pas trop compté, mais ça suffit pas un peu, là ?
(si, en fait, ça suffit... )

./39 > Oui, j'allais pas dire mieux...Mis à part que pendant qu'on parle de ca, PpHd nous a sorti PreOs 1.0.5
(Bien sympa d'ailleurs toutes ces nouvelles sur T3 )

Et, non : pour une fois je ne participerai pas a tous ces trolls

Kevin Kofler (./31) :
Et concrètement? Parce que là c'est de la provocation destructive.

...
Si tu ne souhaite pas ce genre de remarques effectivement gratuites et bêtes, commence par t'abstenir d'en faire quand des gens discutent de GFA Basic ou de GTC.

"GTA Basic"? C'est le BASIC de la mafia? Ou un croisement entre ETP et GFA?

Ou comment esquiver subtilement le fond du message...

t1 c'est une date historique, je me suis marré avec une blague de Kevin

Martial Demolins (./49) :
Une chose aussi, il faudrait un raccourci clavier à TIGCC pour avoir un accès à la ligne de commande (F4 comme Konqueror?).

L'intérêt de TIGCC IDE / KTIGCC est que justement on n'a pas besoin de la ligne de commande.

(dernier message lu: ./51.)

[cite=Kevin]L'"immobilisme" n'est pas le résultat d'une "dictature".[/cite]
Pour l'IDE, oui, vu qu'il n'y a effectivement pas de mainteneur Delphi.
Au passage: FreePascal + Lazarus, ça ne suffit pas ? FreePascal 2.0 n'avait fait aucune histoire quand j'avais essayé de compiler mon programme CLI qui convertit un fichier texte de ROM_CALLs dans un certain format en fichier pour la FlashApp de développement / debug faite par Greg Dietsche (j'ai oublié le nom de la FlashApp).
Pour le reste... on en parle ailleurs (et il n'y a même pas de posts lockés là-bas, d'ailleurs, ça fait longtemps que je n'en avais pas vu ^^)

[cite=Kevin]L'intérêt de TIGCC IDE / KTIGCC est que justement on n'a pas besoin de la ligne de commande.[/cite]
Déjà, il faut distinguer l'utilisation des IDE et l'utilisation des fichiers projet (TPR). Ca clarifiera certainement la discussion.
Ensuite, pour les deux exemples de programmes de TICT qui me viennent à l'esprit, c'est _possible_ de ne pas utiliser la ligne de commande.

(Dans la suite, je me place dans le cas où ni l'IDE, ni tprbuilder ne sont utilisés pour la construction. Cela pour rester dans la plus droite ligne de la citation que je reprends.)

TI-Chess est nettement antérieur à l'IDE, et il nécessite la compilation avec des options de compilation différentes, typiquement -Os pour tout saut le moteur de calcul et -O2 pour le moteur de calcul (avec GCC 4.0+, au-delà de -O2, c'est une augmentation importante de taille pour un gain assez faible - quoique jamais quantifié - de vitesse) de plusieurs fichiers source qui seront plus tard linkés ensemble. Chose conseillée dans le tutorial S1P9 (il me semble que c'est JimRandomH qui l'avait contribuée), que ne permettent pas les TIGCC Projects.
* solution IDE: pour chaque langue (il y en a quatre), maintenir trois projets (un pour faire une archive statique avec les fichiers -Os, un pour faire une archive statique avec les fichiers -O2, et un pour linker le tout ensemble). Chaque triplet de projets est quasi-identique, seuls quelques caractères définissant la langue changent. Pour compiler une langue, ouvrir chacun des projets (puisque l'IDE n'a pas de notion de projets multiples, et par conséquent pas celle de groupe de projets).
* solution TICT: scripter la compilation individuelle de chaque fichier (comprenant la définition de la langue), puis le link.

TICT-Explorer utilise -Os partout, et comme TI-Chess, se compilait sans l'IDE (puisqu'il lui était antérieur), jusqu'à ce que je fasse des TIGCC Projects. Et ça, c'était une connerie de ma part, une grosse, vu qu'il faut un TIGCC Project par langue quand même, pour chacun des programmes de TICT-Explorer (tictex, tictexpl, tictexpv). Mais je ne m'en suis rendu compte qu'après avoir fait un certain nombre de modifications sur le source, quand il s'est agi de tester en plus d'une langue et de packager tout ce bazar.
* solution IDE: pour chacun des programmes de TICT-Explorer, et chacune des langues, faire un TIGCC Project. 3 groupes de 6 projets. Bonjour la maintenance dès qu'on veut changer une option de compilation dans l'un des groupes de projets. Et même si on fait ça, packager tictexpl nécessite quelques appels à des outils en ligne de commande de la TIGCC Tools Suite, et je ne suis vraiment pas sûr qu'on puisse s'en sortir totalement avec des commandes post-build.
* solution TICT: étendre tprbuilder pour accepter des options "-D..." identiques à celles que GCC accepte - ce qui permet de définir la langue, réduisant de façon très simple le nombre de TIGCC Projects à 3 - et contribuer la modification à Kevin (qui l'a reconnue comme utile). Tant que les modifications ne sont pas intégrées à mainline, c'est à dire dans les jours qui suivent le besoin et le codage de la solution simple pour résoudre le problème stupide que je me suis créé tout seul, utiliser la version locale de tprbuilder.

En résumé: ne pas utiliser la ligne de commande, c'est parfaitement irréaliste. La scriptabilité de la CLI est _parfois_ un énorme avantage.

Y a un effort sur les cite, mais ce n'est toujours pas ça

d'ailleurs, c'est vrai que cite=machin, ça serait cool

Lionel Debroux (./52) :
Au passage: FreePascal + Lazarus, ça ne suffit pas ?

Non. Déjà essayé. Il y a beaucoup trop de code spécifique à Delphi, et même du Win32. Et de toute façon ça ne sert pas à grand chose de passer notre temps là-dessus maintenant qu'il y a KTIGCC 2 qui est presque prêt.

la FlashApp de développement / debug faite par Greg Dietsche (j'ai oublié le nom de la FlashApp).

Command Post?

TI-Chess est nettement antérieur à l'IDE, et il nécessite la compilation avec des options de compilation différentes,

Il ne nécessite rien du tout, ça compile parfaitement avec -Os partout.

Quant aux langues, il y a une solution simple, ne faire le logiciel qu'en anglais. Je trouve que le NLS ne sert pas à grand chose en général.

Et sinon, tu peux traduire en temps d'exécution aussi, ce serait plus flexible de toute façon (comme pour la compatibilité binaire entre les différents modèles de calculatrice), et c'est comme ça qu'il est prévu (dans la conception de TIGCC IDE) que les projets fonctionnent: on compile une fois pour tout le monde.

Kevin Kofler (./54) :

TI-Chess est nettement antérieur à l'IDE, et il nécessite la compilation avec des options de compilation différentes,

Il ne nécessite rien du tout, ça compile parfaitement avec -Os partout.

Tu sais, tu devrais envoyer un patch a tes amis de RedHat pour fair virer -Ox et -march -mtune -mcpu de gcc, je pens que ça leur plairaient D'ailleurs je me demande pourquoi eux qui sont si fort n'y on pas encore pensé..

Kevin Kofler (./54) :
Quant aux langues, il y a une solution simple, ne faire le logiciel qu'en anglais.    Je trouve que le NLS ne sert pas à grand chose en général.

Dixit celui qui est aller jusqu'a traduire des application en TI-Basic...
ok

Godzil (./55) :
Dixit celui qui est aller jusqu'a traduire des application en TI-Basic...

Certains de mes logiciels TI-BASIC sont traduits effectivement (ORGANIZR et dépendances, en gros), mais je ne le ferais plus maintenant.

Quant à la compatibilité avec les versions traduites de AMS, c'est avant tout un problème de compatibilité, pas de NLS (même si à la base le NLS de AMS sux, je suis bien d'accord).


Sinon, il a été discuté sur la fedora-devel-list à un moment de changer les optimisations par défaut (RPM_OPT_FLAGS) de -O2 en -Os, je devrais peut-être resoulever la discussion. Les raisons ne sont pas tout à fait les mêmes que sur TI (temps de chargement moins élevé, meilleure utilisation du cache d'instructions, moins de consommation de RAM), mais il se peut bien que ça vaille le coup.

Sur TI, les raisons sont simples: plus on optimise en taille, moins on consomme de mémoire archive et donc plus on peut mettre de logiciels dans la mémoire limitée des calculatrices.

Ouuuuuuuuiiiiiiiiinn ! J'ai pas fait de preview car je suis allé manger directement (couché ce matin à 02h45, et demain, lever à 05h45 pour le premier jour de mon premier emploi... donc faut aller se coucher un peu tôt ce soir ^^), mais mes cite ne ressemblent en effet à rien du tout
Je pensais que les cite=auteur existaient ici, vu que yAronet a quand même plus de features que les forums PHPBB des hébergeurs gratuits (Forumpro, etc.), où j'utilise parfois ce type de quote

la FlashApp de développement / debug faite par Greg Dietsche (j'ai oublié le nom de la FlashApp).

Command Post?

Oui, merci.

TI-Chess est nettement antérieur à l'IDE, et il nécessite la compilation avec des options de compilation différentes,

Il ne nécessite rien du tout, ça compile parfaitement avec -Os partout.

Ouais, évidemment. A part pour des raisons de ne pas frustrer l'utilisateur d'avantage parce que la machine est déjà assez lente à calculer, et qu'il est intéressant d'optimiser un peu vitesse le coeur de calcul, effectivement, ce n'est pas _nécessaire_

Quant aux langues, il y a une solution simple, ne faire le logiciel qu'en anglais.

C'est pas une solution valide, ça

Je trouve que le NLS ne sert pas à grand chose en général.

J'imaginais que ça sert à rendre les softs plus accessibles aux gens - et ils sont et resteront nombreux encore pour des décennies, sauf changement radical - qui ne maîtrisent pas l'anglais. Mais je vois bien que c'est une idée saugrenue, que personne ne suit, d'ailleurs, dans le logiciel libre. C'est bien Windows, et pas (GNU/)Linux, qui existe pour des langages avec des systèmes d'écriture spécifiques à une langue parlée par quelques centaines de milliers de personnes seulement.

Et sinon, tu peux traduire en temps d'exécution aussi, ce serait plus flexible de toute façon (comme pour la compatibilité binaire entre les différents modèles de calculatrice),

Tu es pour, je suis contre la compatibilité binaire entre les différents modèles de calculatrice. Chacun de nous a des arguments valides à mettre en face de ça (par exemple, le fait qu'un même binaire fonctionne sur tous les modèles, même si certains sont plus fréquents que d'autres; de l'autre côté, des graphismes et toutes les combinaisons de touches en double qui rendent Ice Hockey 68k plus de 3 KB plus gros - juste en enlevant le code de compatibilité - et rendraient la taille décompressée, celle qui importe à l'exécution du programme gourmand en mémoire, de TI-Chess +/-10 KB plus élevée...). On en a déjà discuté un nombre certain de fois, ne compte pas sur moi pour y revenir en longueur.

et c'est comme ça qu'il est prévu (dans la conception de TIGCC IDE)

Pour continuer dans ta veine troll: il est mal conçu

que les projets fonctionnent: on compile une fois pour tout le monde.

Avec les avantages et les défauts que cela a...

Sur TI, les raisons sont simples: plus on optimise en taille, moins on consomme de mémoire archive et donc plus on peut mettre de logiciels dans la mémoire limitée des calculatrices.

... en particulier des lanceurs spécifiques pour chaque programme compressé, ou des programmes compatibles on-calc entre les différents modèles, en effet.