Qui connaît TIGCC ?

Ici, on fait dans le petit, le LCD qui déchire sa race, on y cause même calculatrices quand on est en manque !

Modérateur : Politburo

Avatar du membre
gege
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 7141
Enregistré le : 31 janv. 2008 14:24
Localisation : Banlieue Paârisienne
Contact :

Qui connaît TIGCC ?

Message par gege »

Bonjour,
Utilisant TIGCC depuis quelques jours, savez-vous si on peut debugger au niveau source (suivre le code C à l'exécution) ?
Ca semble peu probable vu que le programme tourne dans VTI qui ne semble pas avoir les infos symboliques (et pour cause)...
Bon je peux toujours débugger au printf !

Qui a utilisé ce truc ? C'est super !!
Merci !
G.E.
Avatar du membre
tyann
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 845
Enregistré le : 06 oct. 2012 14:37

Re: Qui connaît TIGCC ?

Message par tyann »

Bonjour

J'ai utiliser TIGCC il y a plusieurs années de cela, pour m'initier au C.
J'avais trouvé un tutoriel très détaillé en français, que je dois encore avoir si ça
t'intéresse.
J'ai même réussi à créer 2 programmes complets (jeux de cartes) pour la v200, puis j'ai laissé tomber.
Dernièrement j'ai téléchargé GTC qui est la version On-Calc de TIGCC si j'ai bien compris, mais pas encore
testé.
Ti(s) 60, 62 Galaxy, 66, 67 Galaxy, 68, 74 Basical 80, 81, 82, 83+, 83 CE, 84+SE, 85, 86, 89, 89 titanium, 92, 95 Procalc, v200, nSpire cx
Hp(s) 35s, 41CX, 28S, 48g, 50g, 39gII, Prime G1 et G2,
Casio(s) fx 602P, 702P, 4000P, 4500P, 6000G, 6900G, 7700G, 8500g, PB-700, CG-20, Graph 95 sd
Psion(s)II LZ64, siena, s3a, s3mx, s5mx.
Sharp(s) pc-1350, 1403, 1500A, E500, El 5120, 9200, 9600
Canon X-07
Avatar du membre
Miskatonic91
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 477
Enregistré le : 27 août 2016 17:28
Localisation : Valdemarnie

Re: Qui connaît TIGCC ?

Message par Miskatonic91 »

Du C sur calculatrice TI?
Ça a l'air intéressant, je vais suivre ce sujet de près... 8)
Un peu de tout, mais toujours de bon goût :wink:
Avatar du membre
gege
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 7141
Enregistré le : 31 janv. 2008 14:24
Localisation : Banlieue Paârisienne
Contact :

Re: Qui connaît TIGCC ?

Message par gege »

Bonjour,
Ca fonctionne très bien, télécharges TIGCC 2.5 et VTI + une ROM et voilà !
Mon programme tourne, c'est un Forth sur TI89/92/V200, encore quelques ajustement et ça fera un article pour la Gazette n°10 !
G.E.
Avatar du membre
Miskatonic91
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 477
Enregistré le : 27 août 2016 17:28
Localisation : Valdemarnie

Re: Qui connaît TIGCC ?

Message par Miskatonic91 »

Un Forth? Je suis preneur aussi! Vivement la prochaine gazette! :D
Un peu de tout, mais toujours de bon goût :wink:
Avatar du membre
Miskatonic91
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 477
Enregistré le : 27 août 2016 17:28
Localisation : Valdemarnie

Re: Qui connaît TIGCC ?

Message par Miskatonic91 »

Un peu de tout, mais toujours de bon goût :wink:
Avatar du membre
Miskatonic91
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 477
Enregistré le : 27 août 2016 17:28
Localisation : Valdemarnie

Re: Qui connaît TIGCC ?

Message par Miskatonic91 »

En train de tester TIGCC (émulé par Wine sous Linux), avec le tutoriel cité dans mon message précédent + TIEmu.
Ça marche du tonnerre! :D

Image
Un peu de tout, mais toujours de bon goût :wink:
Avatar du membre
gege
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 7141
Enregistré le : 31 janv. 2008 14:24
Localisation : Banlieue Paârisienne
Contact :

Re: Qui connaît TIGCC ?

Message par gege »

Bonjour,
ça y est ma TI89 est programmable en Forth !
Si vous avez des idées de programme ?
A bientôt....
G.E.
debrouxl
Fonctionne à 300 bauds
Fonctionne à 300 bauds
Messages : 125
Enregistré le : 03 mars 2013 09:01

Re: Qui connaît TIGCC ?

Message par debrouxl »

Alors, dans l'ordre:

* à peu de choses près, tous les programmeurs en C sur TI-68k ont utilisé TIGCC, ou de nos jours, son fork un peu moins obsolète GCC4TI;

* disons tout de suite que je ne suis pas neutre sur le sujet TIGCC / GCC4TI, étant un des co-créateurs en 2008 et le mainteneur de GCC4TI. Mais je vais baser mon argumentation sur des faits vérifiables que j'ai déjà utilisés à de nombreuses reprises par le passé, je ne crains absolument pas une éventuelle vérification si vous avez vraiment du temps à perdre.
Le fork a eu lieu pour des raisons à la fois techniques (refus nets d'intégration de features utiles pour des motifs discutables, non traitement des contributions, annonce par le mainteneur comme priorité d'un but considéré par tout un groupe d'utilisateurs comme non prioritaire et déraisonnable à l'époque, et d'ailleurs toujours déraisonnable 9 ans plus tard, etc.) et non techniques (le mainteneur de TIGCC est un empoisonneur au sens psychologique du terme, et reste une des personnalités les plus détestées de la communauté, même encore des années après qu'il ait cessé de participer, parce que les anciens se souviennent encore bien des dégâts; il s'est également fait remarquer en mal dans d'autres communautés libres beaucoup plus importantes et actives, donc ce n'est pas seulement nous qui posons problème);

* inutile de suivre TIGCC de près: il n'est plus maintenu. Aucune release de TIGCC n'a été produite depuis plus de 10 ans, plus de 2 ans avant la publication de la première version de GCC4TI début 2009;

* peu utile également de suivre GCC4TI de près: il ne s'y passe pas grand chose non plus. Non pas que ça ne m'aurait pas amusé davantage que la maintenance de libti*/gfm/tilp à une époque, mais soyons réalistes: ceux-là (seule vraie implémentation non TI du code de communication avec les calculatrices graphiques de TI, tous modèles confondus; modèle dont je me suis très lourdement inspiré pour faire libhpcalcs, ayant le même but pour la HP Prime, et dont tout le monde se fout notamment parce que pas grand monde ne s'intéresse à la Prime, malgré ses qualités matérielles) ont bien plus d'utilisateurs (pardon, "bien moins peu d'utilisateurs") qu'une toolchain lourdement obsolète ciblant une plate-forme dont la communauté était quasi-morte depuis plus d'un an et demi avant la création de GCC4TI.

* TIGCC et par suite GCC4TI gèrent en effet le debug symbolique, mais pas avec VTI;

* VTI est un vieil émulateur, présentant un certain nombre de bugs bien connus, et incapable d'émuler un tant soit peu fidèlement les TI-68k du 21ème siècle: la gestion des HW1 n'est déjà pas parfaite, et depuis environ 1999, il n'y a plus que des HW2 et ultérieures. Les V200 sont HW2, les 89T sont HW3/HW4, et les deux, qui apportent des changements significatifs, sont bien postérieures à VTI. Ca ne veut pas dire que VTI soit inutilisable en pratique, puisqu'on peut faire un certain nombre de choses en se limitant aux 89/92+ HW1; il faut juste être conscient de ses limitations.

* le seul émulateur qui gère le debugging symbolique est la version GDB de TIEmu. L'intégration de GDB a été responsable d'une complexification et d'une salissure massive de la base de code et du système de build, qui a largement contribué à rendre in-maintenable le projet. Sans parler à la fois du ralentissement de l'exécution et de la baisse de fiabilité. J'ai coutume de décrire TIEmu+GDB comme un mélange fou d'event loops et de forks patchés de versions lourdement obsolètes de divers logiciels libres, collé ensemble par un système de build fragile, qu'à ma connaissance, personne n'a testé depuis des années. Oui, c'est moi aussi qui suis censé être le mainteneur de ce b*, et pour le coup, je ne maintiens plus rien depuis des années, à cause de la complexité immense et du nombre d'utilisateurs ridiculement bas.
Bref... si tu arrives à faire fonctionner le build Windows obsolète de TIEmu+GDB 3.02, tant mieux pour toi, mais je conseille très fortement le build Windows de TIEmu-GDB 3.03, qui a moins de bugs et plus de features. Si tu arrives à builder le projet, même sans GDB, tant mieux pour toi aussi... même si je suppose que la situation n'est en réalité pas si horrible que ça, TIEmu étant toujours packagé par Debian et les distros dérivées. Heureusement que le créateur et précédent mainteneur de TIEmu a toujours insisté pour que la version sans GDB reste utilisable, même si faire ainsi a augmenté la complexité de la base de code: au moins, des années après, il reste une version utilisable.

* GTC n'est pas une version on-calc des énormes GCC+binutils, c'est un effort indépendant de développement par l'excellent Paul "Pollux" Froissart, qui fonctionne on-calc et on-computer (avec un peu plus de capacités pour cette dernière version, bien entendu). Le projet n'a jamais recontré le succès que le travail correspondant aurait mérité: c'est du boulot de faire un compilo C avec intégration ASM fournissant autant de features sur une plate-forme aussi limitée. Pourquoi, me direz-vous ? Largement à cause de gros bâtons non techniques lancés par le mainteneur de TIGCC dans les roues de Pollux... On a toujours pensé qu'il voyait tout concurrent de TIGCC comme une menace, et il n'a d'ailleurs pas essayé d'agir autrement avec GCC4TI.

* inutile d'utiliser des ROMs, les OS upgrades disponibles en téléchargement gratuit depuis le site de TI conviennent pour tous les usages autres que, en gros, désassembler et debugger le code de transfert de l'OS. Ce qu'environ 2 personnes de la communauté ont dû faire en plus de 20 ans (si on compte les TI-92).

* le Forth ou l'Ultra Pascal ont rencontré encore moins de succès que divers langages plus ou moins custom faits par des tiers pour les TI-68k: Newprog, GFA-Basic, et d'autres (certains ayant souffert des attaques du mainteneur de TIGCC). Des portages expérimentaux de Lua et Python-on-a-chip (p14p) avaient été réalisés, mais ils ont vraiment zéro utilisateurs :)


Vous pouvez tout à fait continuer à utiliser TIGCC... c'est juste que vous aurez moins de features et plus de bugs connus qu'avec GCC4TI qui a bénéficié de travaux de:
* portabilité, automatisation et fiabilité du système de build: l'original ne fonctionnait (presque) bien que sous Linux, ne s'arrêtait pas à la moindre erreur (donc produisait des builds incomplets, ce dont l'utilisateur peut ne se rendre compte que bien plus tard), ne gérait pas la cross-compilation, et autres problèmes majeurs. Et d'ailleurs, les sources de TIGCC dans CVS (...) sont tout simplement incomplets, ça va bien que le morceau manquant était dans un tarball de release...
* correction de bugs connus, certains (dans du code rarement utilisé) crashant les machines - ou même des choses aussi simples que les exemples de code fournis qui ne compilaient pas ou dont les noms on-calc entraient en collision;
* intégration de vieilles contributions pourtant utiles (enfin... moins 7-9 ans plus tard et après la mort de la communauté de programmeurs, forcément... d'ailleurs, elles n'ont pas toutes été intégrées) mais jamais processées. Largement mes propres contributions, parce qu'elles étaient parmi les plus abondantes; j'aurais aimé pouvoir ne pas être être juge et partie;
* optimisation de la librairie, par exemple -16 octets sur le morceau le plus fréquemment utilisé et donc le plus dupliqué du code de startup;
* ajout de quelques features mineures, dont des choses dans le linker pour faciliter la production de l'OS tiers libre PedroM, ou encore quelques fonctionnalités pour faciliter le portage de programmes ANSI C vers les TI-68k (quand j'ai repris les vieux travaux de portage de Lua 5.0.x et que j'ai essayé de porter p14p).

Avec TIGCC, vous n'aurez personne à qui reporter les bugs. En 2009, c'est déjà moi qui ai corrigé dans GCC4TI des bugs reportés à TIGCC, les fixes n'ont pas été reportés dans TIGCC...

Il n'y a certes pas eu de nouvelle release de GCC4TI depuis 2009, mais pour les non-Windows, le code compile directement depuis Git en enchaînant environ 3 commandes, et pour Windows, un ZIP overlay (à utiliser après installation de GCC4TI 0.96 Beta 10) a été publié notamment sur TI-Planet. Cause: manque de temps de ma part, et manque d'utilisateurs. Nous avions correctement identifié le système de build comme un gros point noir de TIGCC, qui emmerdait à la fois les utilisateurs et les mainteneurs... et si nous n'avons fait qu'une fraction des idées que nous avions, nous avons au moins préparé le projet pour la phase "mort lente" dans de meilleures conditions, contrairement à l'original non maintenu.


Bouh, quel vilain pavé. On va arrêter là pour ce soir :)
Avatar du membre
gege
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 7141
Enregistré le : 31 janv. 2008 14:24
Localisation : Banlieue Paârisienne
Contact :

Re: Qui connaît TIGCC ?

Message par gege »

Bonjour,
Merci pour ta visite.
Sachant que tu es un techos bien dur et qui FAIT des choses je résume : respect.

En lisant ton post je vois beaucoup de critiques, reproches et autre amertume.
Tu perds ton temps je pense, dommage.
Je crois que cela résume aussi pourquoi j'aime Silicium et pas d'autres coins du Web dont le nom commence par TI et finit par Planet (wow la plus **grande** communauté TI !), où j'ai croisé ego et arrogance en la personne de ce connard ignorant et belliqueux d'Haleia (Flash=RAM bwaaaahahahaa faut que je l'encadre).
J'attends toujours ses excuses. Mais là, JE perds mon temps ;-)

Pour revenir à la technique, mon usage de TIGCC est extrêmement basique et ça fonctionne, idem VTI.
Les bugs et le debugging me passent au-dessus de la tête, peut-être à tort.
Est-il nécessaire qu'un outil basé sur des trucs qui ne bougent pas depuis 15 ans, reçoive des mises à jour incessantes ? Si ça marche... ben ça marche. On peut toujours améliorer, mais pendant 15 ans ?
Disons simplement merci pour les updates.

Bref, ce qu'il nous faut ce serait de l'aide pour la mise en oeuvre, des exemples à un niveau faible qui est le mien, des conseils. Si tu pouvais expliquer simplement ce que sont les divers trucs dont tu parles, pourquoi ils sont intéressants, ce qu'ils font, comment les utiliser ?
Je trouve que TIGCC et certainement GCC4TI sont des outils fantastiques.
Zéro plantage, zéro surprise. Comme disait Pournelle : recommended.

Oui le Forth est certainement mort, disons qu'on peut s'amuser à en faire un.
Merci pour les infos.
G.E.
debrouxl
Fonctionne à 300 bauds
Fonctionne à 300 bauds
Messages : 125
Enregistré le : 03 mars 2013 09:01

Re: Qui connaît TIGCC ?

Message par debrouxl »

En lisant ton post je vois beaucoup de critiques, reproches et autre amertume.
Difficile d'expliquer un certain état de fait sans tomber dans le linge sale de la communauté. C'est valable pour presque toutes les communautés humaines de façon générale :)
Tu perds ton temps je pense, dommage.
C'est devenu exceptionnel que je parle de ce linge sale-là (auquel j'ai donc participé), en fait. Je pense que ça fait une bonne année que je ne l'avais pas fait :)
Et même avant, j'étais beaucoup moins systématique en attaques personnelles que l'autre, qui recourait de plus au mensonge, en particulier contre moi. Sans résultats durables (hormis le fait de décourager certaines personnes de participer à la communauté) puisque les faits sont les faits, et qu'à l'époque, les alternative facts étaient moins à la mode.
Les bugs et le debugging me passent au-dessus de la tête, peut-être à tort.
L'aspect néfaste des bugs et limitations des outils obsolètes est qu'ils peuvent te faire perdre du temps pour rien, ce qui est toujours dommage.
Avec VTI en particulier, certains cas d'utilisation comme le lancement dynamique d'autres morceaux de code exécutables (le nombre de ceux, en particulier débutants, qui ont essayé n'est pas négligeable) semblent beaucoup plus simples qu'ils ne sont en réalité. Les machines réelles (et TIEmu) disposent de protections non émulées par VTI, et des programmes qui semblent fonctionner avec VTI crashent tout simplement les vraies machines, avec pertes de données.
Un autre bug de TIGCC corrigé dans GCC4TI s'avère pénible à l'utilisation pour une proportion significative du peu d'utilisateurs, mais si tu étais dans les conditions d'utilisation qui le déclenchent (il suffit d'avoir une machine Windows Vista ou ultérieur avec l'UAC activé, et un nom d'utilisateur de plus que quelques caractères), tu t'en serais déjà rendu compte :)
Est-il nécessaire qu'un outil basé sur des trucs qui ne bougent pas depuis 15 ans, reçoive des mises à jour incessantes ?
Nécessaire, non. Mais s'il y a une communauté significative d'utilisateurs, à mon avis souhaitable, oui.
Par exemple, avoir une toolchain plus moderne que les forks assez lourdement patchés de GCC 4.1.2 + binutils 2.16.1 utilisés par GCC4TI et son ancêtre mort donnerait accès à des versions plus modernes du langage C, et habituellement un code généré un peu plus optimisé... bien que sur les plate-formes secondaires ou tertiaires, un upgrade de GCC ne soit pas toujours exclusivement bénéfique de ce point de vue. Le dernier gros upgrade de GCC, 3.4 -> 4.0/4.1, avait été plutôt bénéfique, une fois les gros bugs initiaux du portage corrigés et une passe d'ajustements réalisée.
Bref, ce qu'il nous faut ce serait de l'aide pour la mise en oeuvre, des exemples à un niveau faible qui est le mien, des conseils. Si tu pouvais expliquer simplement ce que sont les divers trucs dont tu parles, pourquoi ils sont intéressants, ce qu'ils font, comment les utiliser ?
Suivant ce que tu appelles "divers trucs", j'en ai peut-être mentionné pas mal dans mon message. Et il est parfaitement évident pour moi que tu attends beaucoup mieux que l'irrespectueux et contre-productif "tu n'as qu'à lire le manuel !", dans la mesure de mes connaissances bien sûr. Connaissances qui sont basses pour l'utilisation pratique de GTC, Newprog / GFA-Basic / presque tous les langages alternatifs.
Donc - sur quels aspects voudrais-tu que je me concentre plus particulièrement ? :)

Quelques notes en attendant... dis-moi si je tombe complètement à côté:
* pour la simplicité d'utilisation, l'IDE Delphi Windows et de son format natif de projets "TIGCC Projects" (TPR) qu'il utilise est la bonne façon de démarrer. C'est ainsi que les exemples fournis sont packagés, et c'est suffisant pour beaucoup de projets. Pour des utilisations plus avancées, j'ai vite rejoint l'avis d'utilisateurs à l'époque plus expérimentés, qui avaient posté qu'ils n'aimaient pas du tout, mais sans expliquer d'une manière que j'avais pu voir ou comprendre, donc j'avais passé certains programmes vers les TPRs avant de me prendre les limitations dans la figure.
* si tu préfères écrire des makefiles ou des scripts de build, le front-end est "tigcc". Appeler directement les gcc, as, etc. internes (leur nom est préfixé dans GCC4TI, comme dans toute cross-toolchain bien élevée, plutôt que de créer des conflits avec les exécutables du système) n'est pas vraiment prévu.
* pour optimiser ton code pour la plate-forme TI-68k, en jouant sur les flags passés à la toolchain: dans les options du projet, tu peux presque toujours utiliser toutes les optimisations du linker, jouer sur les types de tables de relocation, et pour le compilo C, -mregparm=5 -fomit-frame-pointer -ffunction-sections -fdata-sections -Wa,-l. Souvent, on peut également passer -mpcrel au compilo C. Pour plus de détails et de finesse à la fois sur les flags et sur certaines façons d'écrire du code plus petit et/ou plus rapide (par exemple, presque toujours, éviter les BSS inefficaces sur cette plate-forme), tu pourras jeter un coup d'oeil au tutorial "S1P9" téléchargeable depuis http://tict.ticalc.org/ .
* pour la communication avec les vraies machines, il y a deux solutions: TI-Connect 4.0 officiel (pas la version CE, qui ne gère plus les TI-68k; pour Windows + MacOS X) ou TILP II non officiel, pour Windows + MacOS X + Linux + certains BSDs.
Oui le Forth est certainement mort, disons qu'on peut s'amuser à en faire un.
Ah, mais tout à fait :)
Je voulais surtout signifier que les solutions existantes Ultra Pascal et Forth n'étaient à ma connaissance pas finies.
Avatar du membre
gege
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 7141
Enregistré le : 31 janv. 2008 14:24
Localisation : Banlieue Paârisienne
Contact :

Re: Qui connaît TIGCC ?

Message par gege »

Bonjour,
Bon voici des questions précises qui pourraient faire avancer le schmilblick, à moi le pavé !!!!!

- "features utiles" c'était quoi ? On bave !

- "un but considéré comme déraisonnable" c'était quoi ??

- TILP : j'ai tenté mais un truc a bloqué (je ne sais plus quoi), il y a peut-être moyen de packager tout pour rendre l'installation facile ? Je réessaierai.

- "libhpcalcs... tout le monde se fout..." détrompes-toi ça m'intéresse, cependant comme l'outil HP officiel est gratuit (Casio, tu m'entends ???) et permet l'édition de programmes sur le GroPécé (TI tu m'entends ???), le public sera plus limité. Si tu as un bel éditeur avec coloration sytaxique, bibliothèques à copier-coller, ben j'achète !

- "TIGCC et par suite GCC4TI gèrent en effet le debug symbolique, mais pas avec VTI"
Oulà en lisant entre les lignes on a l'impression que c'est un gros bazar... j'abandonne.

- GCC4TI plus facile à builder que TIGCC : qui builde ses outils de nos jours ? Il faut aller sur Git ou Sourceforge, il faut une machine Linux, il y a sans cesse des dépendances qui sont obsolètes / incompatibles etc... Vive les librairies statiques ! Vive les mises à jour rares (genre tous les 10 ans) ! On s'épuise à faire tourner sa chaîne qui arrête de fonctionner abruptement sans demande de ta part.
Après si c'est plus facile, très bien, mais est-ce FACILE ?
Genre un zip à charger, quelques commandes à passer et go ?
"jouer sur les flags passés à la toolchain" ça fait un peu peur... on n'est pas à 10 Ko près souvent, par contre tourne/tourne pas ça compte. Je plaide pour le béotien (moi...). Pourquoi pas deux versions, une packagée sans choix possible qui marche dans 99.999% des cas et une autre avec les tripes à l'air, les version qui changent tout le temps etc etc...?

- GTC : très alléchant, je n'ai pas regardé. Apparemment il manque un moyen de faire connaître le projet, et avec les TI68K poussées dans le fossé obstinément par TI depuis 10 ans, ce n'est pas gagné. Quand est-ce qu'on est débarassé des Nspire-pas-vraiment ?

- "lancement dynamique d'autres morceaux de code exécutables" ok je vois, quels exemples d'utilisation (concrets) ?

Sinon dans le domaine émulateurs etc, que penses-tu de celui disponible en ligne sur Cemetech ?
Impossible de récupérer une version qui tourne de façon autonome sur un PC non connecté. En d'autres termes, tout ce que tu fais est en ligne visible par... on ne sait pas qui. Dommage, est-ce pour ne pas indisposer TI ? J'ai de la peine à le croire.
Pareil pour le truc qui permet de créer des PDF lisibles sur Nspire (ok ok mauvais choix, mais bon) disponible sur TI Planet.
Autant te dire que j'utiliserai ces trucs qui peuvent lire mes documents contre mon gré... ben... jamais ! :D
Bonne chance à ces gens pour diffuser leur truc, moi mon Forth sera libre et vous en ferez ce que vous voudrez.
Question de valeurs.
G.E.
debrouxl
Fonctionne à 300 bauds
Fonctionne à 300 bauds
Messages : 125
Enregistré le : 03 mars 2013 09:01

Re: Qui connaît TIGCC ?

Message par debrouxl »

- "features utiles" c'était quoi ? On bave !
Je me souviens de "Ptr2Hd" (retrouver l'éventuel HANDLE d'allocation à partir d'un pointeur même s'il ne pointe pas au début du bloc, feature fournie par les "kernels" depuis des années), des fread et fwrite plus rapides que celui de TIGCC (qui sont eux-mêmes beaucoup plus rapides que les terribles merdes moins puissantes embarquées par TI dans AMS 2.xx et 3.xx). Il devait y avoir quelques autres features non transcendantes mais elles aussi réclamées par plusieurs personnes au fil des années, et refusées abruptement ("ne sert à rien" était une phrase courante). GCC4TI a Ptr2Hd mais pas ce qui a été connu sous le nom de "fread/fwrite_fast".
Parmi les choses qui n'étaient pas explicitement refusées mais dont l'intégration n'a pas été faite pendant environ 7 ans, jusqu'à GCC4TI, il y avait par exemple les routines de sprite. Aucune justification valable pour l'absence d'intégration: côté non technique, ça n'aurait pas pris beaucoup de temps, et côté technique, la version améliorée était à la fois plus petite et plus rapide, tout en gérant un mode supplémentaire de dessin (RPLC) !
- "un but considéré comme déraisonnable" c'était quoi ??
Se débarrasser ASAP de l'IDE Delphi pour Windows et le remplacer, même sous Windows donc, par l'IDE basé sur l'énorme framework KDE 4, parce que "KDE 4 fonctionne sous Windows" et qu'il voulait se débarrasser d'un environnement propriétaire. Non seulement ça aurait fait télécharger des centaines de MBs de dépendances exotiques aux utilisateurs de TIGCC sous Windows, mais surtout, KDE 4 fonctionnait encore beaucoup plus mal sous Windows que sous Linux, ce qui n'était pas peu dire. KDE 4 n'a pas été utilisable avant 4.3 au plus tôt (donc une bonne année après 4.0), quoi que cet extrémiste de KDE ait pu en penser.
Presque 9 ans plus tard, KDE 5 - dont l'API est encore différente, elle changeait de toute façon même de 4.x à 4.(x+1) - fonctionne vraisemblablement moins mal sous Windows... mais pour autant, ça reste toujours vrai, comme nous le prévoyions (ça n'était pourtant pas difficile), que presque personne ne l'utilise sous Windows !
- TILP : j'ai tenté mais un truc a bloqué (je ne sais plus quoi), il y a peut-être moyen de packager tout pour rendre l'installation facile ? Je réessaierai.
TILP est packagé par Debian, Arch, Fedora, openSUSE et j'en passe.
Et pour avoir la version de développement qui a toujours plus de features et moins de bugs, le script d'installation https://ti-pla.net/tilpinst fournit les listes complètes de dépendances de build pour 6 familles de distro Linux. L'auto-détection de la distro et l'installation des dépendances de build en fonction de ce qui a été détecté est plus que chiante, donc la commande prête à l'emploi est déjà un excellent compromis ;)
- "libhpcalcs... tout le monde se fout..." détrompes-toi ça m'intéresse, cependant comme l'outil HP officiel est gratuit (Casio, tu m'entends ???) et permet l'édition de programmes sur le GroPécé (TI tu m'entends ???), le public sera plus limité. Si tu as un bel éditeur avec coloration sytaxique, bibliothèques à copier-coller, ben j'achète !
Non, libhpcalcs vise purement à gérer des fichiers et de la communication avec les HP Prime. C'est l'effort communautaire le moins mauvais existant pour ce faire, mais ça ne veut pas dire qu'il fonctionne super bien. Faute d'utilisateurs, je n'ai pas pris le virage des transferts compressés que permettent les OS modernes, pas plus que du code de transfert d'OS (aussi bien sur les vieilles machines que sur les nouvelles). Et puis il n'y a aucune interface graphique.
Il y a eu un beau logiciel de transfert tiers pour PC, en C# spécifique à Windows, avec éditeur fournissant la coloration syntaxique, doc des commandes HP PPL, et tout. Et il est vite tombé dans l'oubli parce que le mainteneur s'est concentré sur ces fonctionnalités visibles, même jolies, et a oublié le fondamental du fonctionnel d'un logiciel de communication (sans même parler, non-fonctionnellement, de l'architecture monolithique, de la complète non-portabilité et non-interopérabilité de son code, que je lui ai signalées): il n'a implémenté qu'une façon bizarre et moins puissante de communiquer avec la machine... façon presque tout de suite enlevée par HP. Je ne l'ai jamais implémentée par libhpcalcs parce que ce n'est pas ce que faisait le CK officiel de HP dans son mode normal, et bien m'en a pris.
- "TIGCC et par suite GCC4TI gèrent en effet le debug symbolique, mais pas avec VTI"
Oulà en lisant entre les lignes on a l'impression que c'est un gros bazar... j'abandonne.
En théorie, c'est très simple: il faut compiler avec les infos de debug (-g avec GCC), et faire charger à TIEmu+GDB un binaire qui a les infos de debug, ou importer plus tard les infos de debug, je ne sais même plus.
En pratique, il faut composer avec les limitations et bugs de TIEmu+GDB que j'ai détaillés précédemment.
- GCC4TI plus facile à builder que TIGCC : qui builde ses outils de nos jours ?
Les développeurs encore :)
Il faut aller sur Git ou Sourceforge,
Pas très compliqué ;)
il faut une machine Linux
C'est de moins en moins vrai, avec des choses comme Conan ou vcpkg pour Windows, et brew pour MacOS X. Mais c'est un fait que Linux est davantage fait pour les devs que Windows et MacOS X.
il y a sans cesse des dépendances qui sont obsolètes / incompatibles etc... Vive les librairies statiques !
Dépendances obsolètes et incompatibles, ça arrive à certains projets, oui. Moins à des toolchains comme GCC4TI qui, justement, ont peu de dépendances.
En revanche, clairement, aux chiottes les librairies statiques, en général. Sur ordinateur comme sur embarqué, comme les gens ne les mettent pas à jour, c'est une terrible source de failles de sécurité, donc c'est plus néfaste qu'autre chose :)
Après si c'est plus facile, très bien, mais est-ce FACILE ?
Genre un zip à charger, quelques commandes à passer et go ?
Ben... pour TIGCC, pas du tout, mais pour GCC4TI, oui, comme l'indique le README affiché sur ce qui est de fait une page officielle à https://github.com/debrouxl/gcc4ti/ : 4 commandes sans le clonage du repo, mais on peut se passer du clonage en utilisant la "feature" de Github permettant de télécharger un ZIP ;)
"jouer sur les flags passés à la toolchain" ça fait un peu peur... on n'est pas à 10 Ko près souvent,
Sur ordinateur, non, clairement. Mais sur la calculatrice, carrément. 10 KB, c'est plus de 5% de la RAM utilisable sur TI-68k !
par contre tourne/tourne pas ça compte.
Justement, je ne t'ai donné que les flags les plus sûrs pour la toolchain qui génère des programmes pour calculatrice (pas pour la (cross-)toolchain permettant de compiler la toolchain, bien sûr) ;)
Je plaide pour le béotien (moi...). Pourquoi pas deux versions, une packagée sans choix possible qui marche dans 99.999% des cas et une autre avec les tripes à l'air, les version qui changent tout le temps etc etc...?
Hmm... je ne comprends pas de quoi tu parles, là. De la toolchain ordinateur, peut-être ?
- GTC : très alléchant, je n'ai pas regardé.
Ce qui est le plus alléchant dans GTC, c'est la compilation on-calc. C'est à la fois plus puissant et moins instable que les vieux cc/as on-calc, même si ça n'est pas parfait (il faut laisser le maximum de RAM libre pour minimiser les problèmes). Sur PC, GTC est une toolchain plus datée que GCC4TI - en particulier, pas le linker spécial avec optimisation de TIGCC 0.95+ et GCC4TI, pour autant que je sache. GTC ne pourrait pas compiler tels quels un certain nombre de programmes de TICT, dans lesquels j'ai trafiqué le code avec des spécificités de GCC non toutes implémentées dans GTC, pour plus d'optimisations.
Apparemment il manque un moyen de faire connaître le projet, et avec les TI68K poussées dans le fossé obstinément par TI depuis 10 ans, ce n'est pas gagné.
Tu sembles encore raisonner comme s'il y avait quelque chose à faire pour la communauté TI-68k... Ca fait 10 ans qu'elle est morte, et plus de 8 ans que j'ai pris conscience qu'il n'y avait déjà plus rien à faire (quand la sortie de GCC4TI avec un modèle de développement plus ouvert n'a rien déclenché).
- "lancement dynamique d'autres morceaux de code exécutables" ok je vois, quels exemples d'utilisation (concrets) ?
Ben... tout simplement émuler une V200 ou une 89T, aussi :)
Trois des bugs et manques d'émulation de VTI (bits non existants dans le SR, GIGO sur l'instruction nbcd, absence d'émulation du micro-pipeline) sont utilisés pour empêcher l'exécution directe de HW3Patch sur VTI. Mais après ça, les protections anti-reverse-engineering de HW3Patch sont très faibles, un simple décodeur XOR (ou NOT, je ne sais plus, mais NOT est un XOR avec la pattern de 1). HW2Patch par JM était plus difficile à comprendre.
Sinon dans le domaine émulateurs etc, que penses-tu de celui disponible en ligne sur Cemetech ?
Du mal, comme toi.
Impossible de récupérer une version qui tourne de façon autonome sur un PC non connecté.
Ca va même plus loin que ça: le code est fait de telle sorte qu'on ne puisse pas l'utiliser sur un autre site, à la fois par la façon dont il fonctionne et par l'obscurcissement intentionnel du code, qui est un effet de bord pratique du minimiseur de JS. Et puis techniquement, il a été fait bien avant qu'asm.js existe (maintenant, WebAssembly), et il est donc un représentant de la mauvaise façon de développer du JS de nos jours: à la main (il n'y avait pas le choix à l'époque), plutôt qu'en utilisant Emscripten pour compiler du C/C++ en ciblant WebAssembly. Il faudrait le reprendre à zéro.
J'avais travaillé sur un émulateur de TI-68k en JS, non lié à un quelconque site, en modifiant lourdement le travail créé par Patrick Davidson. Mais j'ai abandonné à la fois par manque de temps et parce qu'écrire à la main n'était pas la bonne approche.
Il y a eu des protos de CEmu et Firebird, respectivement émulateurs de TI-eZ80 et Nspire, tous les deux écrits en C++, ciblant WebAssembly.
En d'autres termes, tout ce que tu fais est en ligne visible par... on ne sait pas qui. Dommage, est-ce pour ne pas indisposer TI ? J'ai de la peine à le croire.
Ne pas indisposer TI et avoir une grande gloire pour lui et Cemetech (quitte à tenter de salir gravement, à tort et heureusement sans succès, la réputation des autres auxquels il doit pourtant beaucoup) sont en effet manifestement des buts de l'admin principal de Cemetech et de certains de ses copains. La phrase précédente montre que ça aussi est un sujet sur lequel il y a du linge sale à déballer, mais je vais bien sûr m'en abstenir ;)
Pareil pour le truc qui permet de créer des PDF lisibles sur Nspire (ok ok mauvais choix, mais bon) disponible sur TI Planet.
Convertir du texte simple ou légèrement formatté (type syntaxe txtrider) en un format texte lisible par un lecteur on-calc, c'est facile, et faisable en JS côté client.
Convertir des images et des PDF, dans un format de stockage raisonnablement efficace côté calculatrice, et en particulier pour les Nspire, s'adapter au format de fichiers complètement tordu qu'elles utilisent... je peux te dire que c'est beaucoup moins simple qu'un convertisseur de texte simple ou légèrement formatté, et aussi qu'un émulateur en ligne :)
Je peux aussi te dire, parce que ça correspond à notre expérience, qu'installer un logiciel côté client dépasse la compétence de beaucoup d'utilisateurs du convertisseur en ligne, et qu'un tel convertisseur en ligne gagne du temps à tout le monde. C'est triste, mais c'est ainsi. Et oui, bien sûr, il pourrait y avoir un problème de confidentialité si ceux qui ont accès au serveur regardaient les documents... ce qui n'est évidemment pas le cas en pratique, pour plusieurs raisons, dont, d'ailleurs, le volume dû à la popularité de l'outil !

TI-Planet fournit aussi un Project Builder, avec fonctionnalité de compilo en ligne et IDE collaboratif temps réel, principalement pour TI-(e)Z80. Il a toujours été prévu d'ouvrir le code de celui-là, d'autant que l'architecture modulaire permettrait de l'étendre à d'autres plate-formes - mais faute de revue sécurité (ça, c'est partiellement de ma faute... il faut pouvoir y passer du temps), ça n'est toujours pas fait.
debrouxl
Fonctionne à 300 bauds
Fonctionne à 300 bauds
Messages : 125
Enregistré le : 03 mars 2013 09:01

Re: Qui connaît TIGCC ?

Message par debrouxl »

Disposant de quelques jours de congés, j'ai commencé à bouger mes fesses pour relire le code du Project Builder que je mentionnais ci-dessus. J'ai vu des choses et Adriweb fait des améliorations. On va continuer pour pouvoir, un jour, ouvrir l'intégralité du code (il l'est déjà partiellement sur Github) dans un état utilisable :)
Avatar du membre
gege
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 7141
Enregistré le : 31 janv. 2008 14:24
Localisation : Banlieue Paârisienne
Contact :

Re: Qui connaît TIGCC ?

Message par gege »

Bonjour,
ok tiens-nous informés en termes simples...
Bonnes "vacances" !
G.E.
Répondre

Retourner vers « Tous les Pockets »