TIGCC: demandes de fonctionnalités (feature requests)... - Page 7

vive les programmes compressés et le pstarter ttstart/SuperStarter standard!

Fixed, cf. ./158

Pourquoi pas laisser le binaire où il est? Un seul dossier pour le projet complet.

La plupart des programmes de TICT ne sont pas faits comme ça.

Kevin Kofler (./179) :
Pas possible tant qu'il n'y a pas les groupes de projets. Il change si souvent que ça, le loader? Et puis pour le loader perso, vive les programmes compressés et le pstarter standard!

Le loader change pas souvent effectivement, mais j'aime bien l'avoir sous la main. Surtout que plusieurs projets dans le même répertoire, j'aime pas. Quant à pstarter, il est standard chez toi mais pas chez moi. PreOS est standard pour moi, donc j'utilise son format.

Kevin Kofler (./179) :
Pour la date, tu peux utiliser __DATE__ dans un .c (cf. grayversion.c dans les sources de TIGCCLIB pour un exemple). Pour le reste, c'est plus propre de mettre ça directement dans le .h en question.

Sauf que centraliser mail + version + auteur dans un seul fichier permet de faciliter la maintenance, et de pas avoir deux noms d'auteurs, ou deux casses différentes ou que sais-je encore.
Quant à la version, c'est demandé par le standard des pack archives, donc je respecte.

Kevin Kofler (./179) :
Il y a sans doute une meilleure solution pour ça. Par exemple, tu pourrais traîter include "author" et include "version" spécialement dans ton assembleur, ça éviterait de devoir autogénérer ces fichiers à chaque fois.

Version change, c'est chiant de devoir parcourir le source pour savoir où il est. Dans un fichier ) part, c'est mille fois plus simple. Pourquoi pas me laisse faire simple ?

Kevin Kofler (./179) :
Beurk le format de packs archive. (Non supporté par TIGCC.) Et puis il change si souvent que ça, le commentaire?

Le commentaire a également son format spécifique dans le pack archive, et je le respecte. Encore une fois, j'ai besoin que ce soit une string ajoutée au pack, et ça TIGCC sait pas faire. Je suis donc, vu l'insuffisance de TIGCC, obligé de le faire à la main.

Kevin Kofler (./179) :
C'est possible avec le post-processing de l'EDI. Mais pour ton système de pack archive, surtout le fait que asmain n'est pas compressé et gaspille donc de l'archive.

Et gagne plusieurs ko de RAM pour beaucoup moins d'archive perdue. Et rien n'empêche à l'utilisateure de compresser, ça marchera pareil hein, suffit de virer un point d'exclamation et c'est parti.

Kevin Kofler (./179) :
Pourquoi pas laisser le binaire où il est? Un seul dossier pour le projet complet.

Parce que j'ai plus de 35 fichiers source pour le moment et c'est pas fini. J'aime bien la structure de projets que je vois souvent (pour les projets simple comme celui-ci :
- 3 répertoires /doc/, /bin/, /src/ dont les contenus sont évidents vu les noms
- 3 fichiers exécutables
- une license et un readme
- éventuellement des trucs exotiquesn genre le png des GNU à distribuer avec tes softs sous GPL ou que sais-je encore

Kevin Kofler (./179) :
Inutile. (Et il te crée des *~, KTIGCC? Si c'est le cas, il faudra que je corrige ça...)

Non t'inquiète, j'utilise ça pour virer les fichiers temporaires de Kate/KWrite et Emacs

Folco (./182) :
Le loader change pas souvent effectivement, mais j'aime bien l'avoir sous la main. Surtout que plusieurs projets dans le même répertoire, j'aime pas.

Bah, tu "aimes pas" peut-être, mais c'est comme ça qu'il faut faire avec l'EDI.

Quant à la version, c'est demandé par le standard des pack archives, donc je respecte.
Le commentaire a également son format spécifique dans le pack archive, et je le respecte. Encore une fois, j'ai besoin que ce soit une string ajoutée au pack, et ça TIGCC sait pas faire. Je suis donc, vu l'insuffisance de TIGCC, obligé de le faire à la main.

Alors déjà, tous ces trucs sont optionnels, le pack archive fonctionne très bien sans.
Et ensuite, pour le commentaire, il ne changera pas souvent, donc tu peux générer ton 89s une seule fois, pas besoin de faire ça à chaque fois que tu compiles le projet.
Et enfin, TIGCC ne supporte pas officiellement les packs archive, il y a le format PPG qui est proposé et qui est meilleur (la compression pucrunch/ttpack est plus efficace que celle shnrklib - enfin, faut déjà qu'on l'utilise, cette compression ).

Version change, c'est chiant de devoir parcourir le source pour savoir où il est. Dans un fichier ) part, c'est mille fois plus simple. Pourquoi pas me laisse faire simple ?

Un .h déjà au bon format pour être inclus, c'est aussi un fichier à part.
Et je te signale aussi l'existence de la directive .incbin.

Et gagne plusieurs ko de RAM pour beaucoup moins d'archive perdue.

Alors déjà c'est le cas seulement pour PedroM. Et c'est une erreur de ne supporter que PedroM. Vive les logiciels portables!

Et ensuite, la RAM est en général libre de toute façon, parce qu'elle est utilisée par des jeux (et libérée quand le jeu ne tourne pas), alors autant l'utiliser! L'archive, elle, limite le nombre de programmes que tu peux mettre sur la calculatrice. Donc il vaut mieux économiser l'archive que la RAM.

Et rien n'empêche à l'utilisateure de compresser, ça marchera pareil hein, suffit de virer un point d'exclamation et c'est parti.

L'utilisateur ne va pas s'amuser à recompiler ton programme. Et puis la compression des packs archives est moins efficace que celle des PPGs.

Parce que j'ai plus de 35 fichiers source pour le moment et c'est pas fini.

Et puis? Moi, je distribue toujours mes binaires dans le même dossier que les sources, les utilisateurs avec un minimum de cerveau (ou qui ont lu le lisezmoi, qui pour mes programmes contient même les informations évidentes) s'en sortent très bien.

Non t'inquiète, j'utilise ça pour virer les fichiers temporaires de Kate/KWrite et Emacs

=> Ne sert plus si tu passes à l'EDI. (Et au moins pour Kate/KWrite, ça se désactive.)

Et c'est une erreur de ne supporter que PedroM. Vive les logiciels portables!

=> Ne sert plus si tu passes à l'EDI.

Rassure-nous, tu fais exprès de poster des choses bêtes et non constructives ?

Donc il vaut mieux économiser l'archive que la RAM.

C'est bien pour ça qu'il faut utiliser des pstarters plutôt que ttstart/SuperStart

Moi, je distribue toujours mes binaires dans le même dossier que les sources, les utilisateurs avec un minimum de cerveau (ou qui ont lu le lisezmoi, qui pour mes programmes contient même les informations évidentes) s'en sortent très bien.

Séparer les sources des binaires est pourtant une pratique très courante de génie logiciel...

Kevin Kofler (./183) :
Et c'est une erreur de ne supporter que PedroM. Vive les logiciels portables!

Heu.. C'est toi qui dit ça ?

Kevin Kofler (./183) :
Alors déjà, tous ces trucs sont optionnels, le pack archive fonctionne très bien sans.

Et donc ? Si un shell fouille le pack archive pour y trouver des informations standard, je dois pas lui permettre de le faire ?

Kevin Kofler (./183) :
Et ensuite, pour le commentaire, il ne changera pas souvent, donc tu peux générer ton 89s une seule fois, pas besoin de faire ça à chaque fois que tu compiles le projet.

Sauf que le commentaire, j'en ai besoin pour faire un fichier string, donc je le laisse dans un texte. Et c'est pas pour le temps pris par une passe de ttbin2str que ça dérange

Kevin Kofler (./183) :
Et enfin, TIGCC ne supporte pas officiellement les packs archive

Mais j'en ai rien à foutre, moi non plus je ne supporte pas TIGCC

Kevin Kofler (./183) :
la compression pucrunch/ttpack est plus efficace que celle shnrklib - enfin, faut déjà qu'on l'utilise, cette compression

Mais je m'en fous, je vais pas me taper un overhead en archive puis en RAM pour compresser un truc, alors que stdlib est built-in sous PedroM (ok, la version de TiEmu, je sais, mais j'utilise pas et je suis pas pour)

Kevin Kofler (./183) :
Un .h déjà au bon format pour être inclus, c'est aussi un fichier à part.

Mais j'ai besoin de la version dans le binaire au run-time, et dans un fichier passé à ttbin2str. Et c'est plus petit de l'include deux fois à la compilation que d'aller la chercher dans le pack archive au runtime. Et au moins avec ma méthode, ce n'est présent qu'une fois dans le source, je suis sûr de ne pas releaser avec deux numéros de version différents.

Kevin Kofler (./183) :
Et je te signale aussi l'existence de la directive .incbin.

Sans blague

Kevin Kofler (./183) :
Alors déjà c'est le cas seulement pour PedroM. Et c'est une erreur de ne supporter que PedroM. Vive les logiciels portables!

C'est interdit de pas vouloir pour l'OS non-libre quasi-monopoliste et bugué qu'est AMS ?

Kevin Kofler (./183) :
Et ensuite, la RAM est en général libre de toute façon, parce qu'elle est utilisée par des jeux (et libérée quand le jeu ne tourne pas), alors autant l'utiliser! L'archive, elle, limite le nombre de programmes que tu peux mettre sur la calculatrice. Donc il vaut mieux économiser l'archive que la RAM.

T'oublies que PedroM supporte nativement le multi-thread, et qu'on peut très bien faire une compilation en jouant à CF (et là, merci l'exécution en archive )

Kevin Kofler (./183) :
L'utilisateur ne va pas s'amuser à recompiler ton programme. Et puis la compression des packs archives est moins efficace que celle des PPGs.

Ah bon, toi fan de Linux, tu vas me dire que l'utilisateur peut pas exécuter un script, elle est bonne Et je m'en bats puisamment les couilles de la compression PPG, je te répète qu'elle me balancera un overhead permanent en flash et également au runtime. Pas sûr de gagner le moindre octet avec ça.

Kevin Kofler (./183) :
Et puis? Moi, je distribue toujours mes binaires dans le même dossier que les sources, les utilisateurs avec un minimum de cerveau (ou qui ont lu le lisezmoi, qui pour mes programmes contient même les informations évidentes) s'en sortent très bien.

Tu fais ce que tu veux, mais à ma connaissance, rien ne m'oblige à distribuer un programme bordélique et dégueulasse, j'ai le droit de faire dans le propre quand même, non ?

Kevin Kofler (./183) :
Et au moins pour Kate/KWrite, ça se désactive

Je sais Mais je préfère ce comportement d'une manière générale. 3 caractères de script dans ce projet-là parce que je n'en ai pas besoin, çc'est pas encore la mort

Kevin Kofler (./183) :
Et puis la compression des packs archives est moins efficace que celle des PPGs.

Je rappelle que techniquement parlant rien n'enpêche d'utiliser la compression PPG pour les Pack Archive (qui est un format d'archive = un tar). Ce n'est pas un format de compression.

Folco (./186) :
T'oublies que PedroM supporte nativement le multi-thread, et qu'on peut très bien faire une compilation en jouant à CF (et là, merci l'exécution en archive )

Pas vraiment du multi-thread, mais un "basculateur de taches". Ce n'est pas pareil.

Lionel Debroux (./184) :

Et c'est une erreur de ne supporter que PedroM. Vive les logiciels portables!

=> Ne sert plus si tu passes à l'EDI.

Rassure-nous, tu fais exprès de poster des choses bêtes et non constructives ?

Ce que tu viens de citer n'est si bête ni non constructif. Je ne comprends pas du tout ta remarque (et je ne plaisante pas).

C'est bien pour ça qu'il faut utiliser des pstarters plutôt que ttstart/SuperStart

Non, pour le confort d'utilisation.
SuperStart est une espèce de kernel qu'il faut installer d'abord, pas du tout pratique, et il n'y a pas les correctifs de bogues des versions récentes de ttstart ou pstarter à cause des histoires de signature.
Quant à ttstart, ça implique de taper ttstart et le nom du PPG à chaque fois, ça fait un nom de programme à taper en trop. C'est le genre de tâches pour lesquelles les programmes ont été inventés. Je peux te proposer une manière parfaite d'économiser ton archive: au lieu d'enregistrer ton jeu en archive, tu le tapes avec un Exec à chaque fois, 0 octet d'archive consommés.

Séparer les sources des binaires est pourtant une pratique très courante de génie logiciel...

Totalement inutile pour un projet individuel pour calculatrice.

Godzil (./185) :

Kevin Kofler (./183) :
Et c'est une erreur de ne supporter que PedroM. Vive les logiciels portables!

Heu.. C'est toi qui dit ça ?

* Mes programmes pour calculatrice marchent aussi sous PedroM quand ça a un sens. Les hooks d'évènements ne marchent pas parce que PedroM ne gère pas les évènements, Gosper89 ne marche pas parce qu'il n'y a pas de calcul formel dans les releases de PedroM (et celui qui va venir est totalement incompatible avec celui de AMS pour lequel Gosper89 a été écrit, le calcul formel de PedroM n'existait pas du tout à l'époque), ce n'est pas de ma faute!
* TIGCC, TiEmu, TiLP sont tous multiplateformes!
Donc je ne vois pas du tout pourquoi tu me reproches d'être contre la portabilité des logiciels.

Folco (./186) :
Et donc ? Si un shell fouille le pack archive pour y trouver des informations standard, je dois pas lui permettre de le faire ?

Pas tant que ce n'est pas intégré à la chaîne d'outils (chose pour laquelle tu n'as pas fait le moindre effort), contrairement aux commentaires _nostub. (Mais il faut dire que ce n'est pas évident de gérer ça proprement, étant donné que les fichiers sont externes et rajoutés seulement au moment de la création du pack archive. On pourrait copier les commentaires _nostub dans un fichier externe au moment de la création du pack archive s'il y en a dans le fichier, mais les commentaires _nostub ne sont pas compatibles avec le format kernel. Une solution serait d'utiliser les exports kernel avec le même ID que le commentaire _nostub correspondant, mais tu les utilises déjà pour autre chose, et tu ne dois pas être le seul. Il faudrait un format de commentaires kernel, mais PpHd n'est probablement pas intéressé parce que pour lui tout devrait être pack archive. Le format kernel actuel n'a que _comment, pas de _author etc. Mais un truc qui doit être possible facilement dans kpack est d'extraire _comment au moment de la création du pack archive, ça t'éviterait de créer le fichier externe au moins dans ce cas, et à la limite tu pourrais te passer des autres trucs.) Et puis je ne connais aucun shell qui lit ces informations.

Sauf que le commentaire, j'en ai besoin pour faire un fichier string, donc je le laisse dans un texte. Et c'est pas pour le temps pris par une passe de ttbin2str que ça dérange

... mais pour le fait que c'est une étape de compilation non standard qui n'est pas prévue par l'EDI, et qui ne sert à rien parce que tu peux lancer ttbin2str une fois et ne plus y toucher.

alors que stdlib est built-in sous PedroM (ok, la version de TiEmu, je sais, mais j'utilise pas et je suis pas pour)

Il y a des libs dans stdlib pour lesquelles je n'ai pas la permission de les redistribuer, c'est impossible de les inclure dans TiEmu. (Et même s'il y avait cette permission, nous n'incluerons pas les libs non-libres, genre genalib dont les sources ont été perdues.)

Mais j'ai besoin de la version dans le binaire au run-time, et dans un fichier passé à ttbin2str.

Non, tu n'as pas besoin du fichier ttbin2str, c'est optionnel.

Kevin Kofler (./183) :
Et je te signale aussi l'existence de la directive .incbin.

Sans blague

Bah, pourquoi générer un header avec un .ascii alors?

C'est interdit de pas vouloir pour l'OS non-libre quasi-monopoliste et bugué qu'est AMS ?

Cf. ma réponse à Godzil.

T'oublies que PedroM supporte nativement le multi-thread, et qu'on peut très bien faire une compilation en jouant à CF (et là, merci l'exécution en archive )

N'importe quoi...

Ah bon, toi fan de Linux

Mais pas de Gentoo.
Ici on a des paquetages compilés...

Et je m'en bats puisamment les couilles de la compression PPG, je te répète qu'elle me balancera un overhead permanent en flash et également au runtime. Pas sûr de gagner le moindre octet avec ça.

Bah, teste alors, si tu n'es pas sûr.

Tu fais ce que tu veux, mais à ma connaissance, rien ne m'oblige à distribuer un programme bordélique et dégueulasse, j'ai le droit de faire dans le propre quand même, non ?

Bah non, l'EDI que tu es censée utiliser ne le permet pas. Et je ne vois pas en quoi c'est "propre" de faire un bordel à plusieurs dossiers plutôt qu'un simple dossier de projet avec tout ce qu'il faut dedans.

Je sais Mais je préfère ce comportement d'une manière générale.

Je déteste les fichiers *~ qui traînent!

PpHd (./187) :

Kevin Kofler (./183) :
Et puis la compression des packs archives est moins efficace que celle des PPGs.

Je rappelle que techniquement parlant rien n'enpêche d'utiliser la compression PPG pour les Pack Archive (qui est un format d'archive = un tar). Ce n'est pas un format de compression.

Alors qu'attends-tu pour remplacer shrnklib par ttunpack-small comme compression par défaut? Ce n'est pas la licence (LGPL+exceptions), le problème, elle est même plus permissive que celle de shrnklib (LGPL sans exceptions). Tu pourrais toujours proposer shrnklib - compressée avec ttunpack-small évidemment.

ttunpack-small est plus petit, plus rapide et compresse mieux dans mes tests. J'avais essayé shrnklib pour le pstarter à une époque où la licence de pucrunch posait problème (le fichier pst-shrn.h existe toujours, même s'il n'est pas utilisé), donc je sais de quoi je parle.

Kevin Kofler (./189) :
genre genalib dont les sources ont été perdues.

Ce n'est pas perdu, et ses sources sont sous LGPL.

Kevin Kofler (./190) :
Alors qu'attends-tu pour remplacer shrnklib par ttunpack-small comme compression par défaut? Ce n'est pas la licence (LGPL+exceptions), le problème, elle est même plus permissive que celle de shrnklib (LGPL sans exceptions). Tu pourrais toujours proposer shrnklib - compressée avec ttunpack-small évidemment.

Normalement ppglib le supporte. Il suffit de modifier la tool chain pour (enfin je crois).

PpHd (./191) :

Kevin Kofler (./189) :
genre genalib dont les sources ont été perdues.

Ce n'est pas perdu, et ses sources sont sous LGPL.

Réécrites? Retrouvées?

Mais ça ne résout pas le problème des autres libs non-libres qui restent. Les tiennes et celles de David Kuehling ne sont plus un problème, mais pour certaines, comme les vieilles libs de DoorsOS, c'est le bordel.

SuperStart est une espèce de kernel qu'il faut installer d'abord,

Pas plus qu'un pstarter ou ttstart ! Il suffit d'un transfert vers la calculette.
Contrairement à un "kernel", sstart se réinstalle tout seul à chaque reset.

pas du tout pratique

Faux
Je t'ai déjà expliqué que pour lancer un ppg, il y a besoin de moins de keypresses qu'avec un pstarter (sur une machine qui n'a pas AutoClBr - c'est le cas de la mienne)...

il n'y a pas les correctifs de bogues des versions récentes de ttstart ou pstarter à cause des histoires de signature.

Que Greg n'ait pas sorti une version depuis 2004, c'est vrai. Que ce soit pour une histoire de signature, c'est devenu faux depuis que Flashappy existe (et Greg sait que Flashappy existe)
Quels bugfixes y a-t-il ?

Suffit de faire PreOS en FlashApp, donc ?

Kevin, que penses-tu du ticket #34 de GCC4TI, 'Support folder names in the "External data variable" name and the "Compress program" name fields' ?

Je pose la question parce que le plus gros morceau restant (outre les tests, même si j'en ai déjà fait ^^) est de faire le travail dans KTIGCC...
Evidemment, il y a des membres de GCC4TI ML qui connaissent déjà l'API Qt / KDE. Je pourrais aussi le faire moi-même en regardant la doc des classes et fonctions qui vont bien, comme je l'ai fait il y a quelques jours pour le parsing de la ligne de commande avec Glib dans TILP (même si j'ai pas fait grand chose, c'est quasi-exclusivement Romain qui a implémenté mes feature requests ).
Mais ça serait fait plus vite et mieux par quelqu'un qui connaît déjà l'API (voire qui, dans ton cas, est le créateur du programme).

Même si tu ne comptes pas ajouter le support des noms avec répertoire dans le champ "Compress program", il faut de toute façon corriger deux bugs de KTIGCC:
* limitation de la taille du champ à 8 caractères (déjà reporté);
* absence de vérification de la validité des noms. Contrairement à l'IDE Delphi, KTIGCC ne voit aucun inconvénient à une data variable nommée "a\a\a" (ou a\a\a).

Comme en l'absence de patches, ld-tigcc (le patch que j'ai posté sur le Trac est incomplet...), ainsi que le reste de la toolchain, n'y voient aucun inconvénient non plus, les noms foireux se retrouvent dans les exécutables... et le code de startup, sous AMS et PedroM, ne trouvant pas un tel path, arrête l'exécution du programme.


En fait, la vérification des paths est encore plus compliquée que ce qui est mentionné dans le ticket #34. En effet, ld-tigcc, grâce à main.c :: DecodeOnCalcName, supporte l'utilisation du charset natif de la machine.
Mais aucun des deux IDE ne le supporte vraiment: non seulement les champs d'edit sont trop courts (IDE Delphi et KTIGCC), mais '%' n'est pas un caractère autorisé par le vérificateur de l'IDE Delphi (N/A pour KTIGCC qui ne vérifie rien du tout, pour le moment). La taille max du champ d'édition dépend de son contenu...
(je n'ai pas essayé, mais je ne vois pas pourquoi l'utilisation du charset natif ne fonctionnerait pas avec tprbuilder et tigcc, en revanche)

[EDITs: suppression d'un smiley intempestif, quelques ajouts.]

Kevin Kofler (./189) :
Pas tant que ce n'est pas intégré à la chaîne d'outils (chose pour laquelle tu n'as pas fait le moindre effort)

Tu sais très bien que je connais pas le C Je suis pas informaticien, et j'ai une vie à côté de mon PC, donc j'ai pas que ça à foutre d'apprendre le C pour ta toulchayne personnelle

Kevin Kofler (./189) :
mais les commentaires _nostub ne sont pas compatibles avec le format kernel.

T'es pas standard !!! Les commentaires kernel étaient là avant !!!

Kevin Kofler (./189) :
... mais pour le fait que c'est une étape de compilation non standard qui n'est pas prévue par l'EDI,

Je m'en bats puissamment les kooyes avec une pelle à tarte, ton IDE n'est pas plus standard que mon script.

Kevin Kofler (./189) :
et qui ne sert à rien parce que tu peux lancer ttbin2str une fois et ne plus y toucher

Et si je modifie l'image ? Faut que je repasse un coup de ttbin2str. Là, j'y pense même pas.

Kevin Kofler (./189) :
Non, tu n'as pas besoin du fichier ttbin2str, c'est optionnel.

Et si j'ai envie de l'inclure ? Il me fatu une permission ? Je dois te filer des thunes ? Te faire une révérence ?

Kevin Kofler (./189) :
Bah, pourquoi générer un header avec un .ascii alors?

Et t'es plus movea.l %a0,%a1, ou lea.l (%a0),%a1 ? Non, mais dis-le moi, parce que perso, je suis plus include que incbin. Chacun son truc.

Kevin Kofler (./189) :
N'importe quoi...

Multi-thread non simultané, non-préemptif, bref t'as très bien compris le fond de ce que j'ai soulevé et qui invalide ton argument, mon programme n'est pas censé tourner seul sur la calc. (et je me souviens d'une de tes diatribes d'il y a peut-être 5 ans, ou tu tapais sur les programmes qui se permettaient de penser qu'isl avaient le droit d'avoir toute la ram de la calc... faudrait savoir, non ? )

Kevin Kofler (./189) :
Ici on a des paquetages compilés...

Je m'en bats puissamment les kooyes avec une pelle à tarte, c'est ton choix et pas le mien.

Kevin Kofler (./189) :
Bah, teste alors, si tu n'es pas sûr.

Je m'en bats puissamment les kooyes avec une pelle à tarte, j'ai fait mon choix entre ppgsuperstarteroverkill et les packaarchives. J'ai fait le choix en connaissance de cause, je ne me sens nulle obligation de faire ton test pour le justifier.

Kevin Kofler (./189) :
Bah non, l'EDI que tu es censée utiliser ne le permet pas.

Je m'en bats puissamment les kooyes avec une pelle à tarte, ton IDE n'est pas plus standard que mon script

Kevin Kofler (./189) :
Et je ne vois pas en quoi c'est "propre" de faire un bordel à plusieurs dossiers plutôt qu'un simple dossier de projet avec tout ce qu'il faut dedans.

t1 j'aimerais pas voir ton PC (un seul dossier avec la musique, les photos, les textes, l'administratif, les sources et binaires de programme, les films )

Kevin Kofler (./189) :
Je déteste les fichiers *~ qui traînent!

Je m'en bats puissamment les kooyes avec une pelle à tarte, mon PC n'est pas le tien.


Au fait, peut-être que j'écris des programmes libres d'un point de vu gplistique, mais je suis avant tout un programmeur libre !

Folco (./196) :

Kevin Kofler (./189) :
Pas tant que ce n'est pas intégré à la chaîne d'outils (chose pour laquelle tu n'as pas fait le moindre effort)

Tu sais très bien que je connais pas le C Je suis pas informaticien, et j'ai une vie à côté de mon PC, donc j'ai pas que ça à foutre d'apprendre le C pour ta toulchayne personnelle

Spa gentil de sous-entendre que KK n'a pas de vie en dehors de TIGCC et de Fedora !

T'es pas standard !!! Les commentaires kernel étaient là avant !!!

Bah, tu sais, Kevin et les standards, ça fait 2 ^^

Kevin Kofler (./189) :
... mais pour le fait que c'est une étape de compilation non standard qui n'est pas prévue par l'EDI,

Je m'en bats puissamment les kooyes avec une pelle à tarte, ton IDE n'est pas plus standard que mon script.

Si, parce que Kevin l'a décidé !




Ceci dit, j'espère que tu n'as pas envie d'avoir beaucoup d'autres gamins

Lionel Debroux (./193) :
Quels bugfixes y a-t-il ?

Sûrement un bon paquet depuis 2004, mais malheureusement je ne me rappelle pas de tout ce qui avait été reporté.

(Pour ton ./195, j'y répondrai par la suite.)

Folco (./196) :
T'es pas standard !!! Les commentaires kernel étaient là avant !!!

Ils ne gèrent que le champ _comment et pas author, version, icon etc. Et le champ _comment est très bien géré par TIGCC. (Si on utilise COMMENT_STRING pour un programme kernel, ça crée automatiquement un champ _comment.)

Je m'en bats puissamment les kooyes avec une pelle à tarte, ton IDE n'est pas plus standard que mon script.

La compilation en ligne de commande est dépréciée, ça n'existe que pour les vieux projets.

Et t'es plus movea.l %a0,%a1, ou lea.l (%a0),%a1 ? Non, mais dis-le moi, parce que perso, je suis plus include que incbin. Chacun son truc.

Je suis pour utiliser l'instruction adaptée à la tâche. Contrairement à tes movea et lea, les instructions .include et .incbin ne sont pas équivalentes. Ça ne sert strictement à rien de convertir un fichier binaire en un header, c'est exactement à ça que sert .incbin.

Multi-thread non simultané, non-préemptif, bref t'as très bien compris le fond de ce que j'ai soulevé et qui invalide ton argument

Ce n'est pas sur le terme de "multi-thread" que portait mon "N'importe quoi...", mais sur la simple idée d'utiliser CF et un assembleur on-calc en même temps.

mon programme n'est pas censé tourner seul sur la calc.

Si, c'est une calculatrice, pas un PC.

(et je me souviens d'une de tes diatribes d'il y a peut-être 5 ans, ou tu tapais sur les programmes qui se permettaient de penser qu'isl avaient le droit d'avoir toute la ram de la calc... faudrait savoir, non ? )

Il faut laisser la place pour des TSRs et des sections BSS de FlashApps, et à la limite quelques petites variables, c'est sur ça que portait ma remarque. Mais ça ne sert à rien de consommer moins d'environ 90 à 100 KO parce que de toute façon il faudra garder cette RAM libre pour d'autres logiciels (qui s'exécutent un à la fois - une fois de plus, la calculatrice n'est pas du tout conçue pour le multitâches, le task switcher de PedroM est un joli proof of concept, tout comme le mien, mais ça reste une bidouille expérimentale, pas quelque chose de vraiment utilisable).

Je m'en bats puissamment les kooyes avec une pelle à tarte, j'ai fait mon choix entre ppgsuperstarteroverkill et les packaarchives. J'ai fait le choix en connaissance de cause, je ne me sens nulle obligation de faire ton test pour le justifier.

Donc ton argument prétendant que le PPG sera plus gros si on compte le pstarter n'est pas valide.

Et sinon, tu pourrais aussi argumenter de manière moins grossière.

Lionel Debroux (./195) :
Kevin, que penses-tu du ticket #34 de GCC4TI, 'Support folder names in the "External data variable" name and the "Compress program" name fields' ?

On ne peut pas mettre un dossier pour le PPG, le pstarter n'a la place que pour 8 octets, rajouter un dossier grossirait le pstarter pour une fonctionnalité limite inutile. Le pstarter ne cherche que dans le dossier courant, qui normalement est censé être main, tout comme le dossier dans lequel les fichiers seront envoyés.

Pour les noms de variables de données externes, c'est probablement plus simple, mais du coup ce serait incohérent.

Donc je ne suis pas convaincu que ce soit une bonne idée.

Même si tu ne comptes pas ajouter le support des noms avec répertoire dans le champ "Compress program", il faut de toute façon corriger deux bugs de KTIGCC
:* limitation de la taille du champ à 8 caractères (déjà reporté);

Euh, ce n'est pas un bogue parce que justement les dossiers ne sont pas autorisés et donc la taille maximale permise est de 8 caractères.

* absence de vérification de la validité des noms. Contrairement à l'IDE Delphi, KTIGCC ne voit aucun inconvénient à une data variable nommée "a\a\a" (ou a\a\a).

Hmmm, je valide les noms on-calc à d'autres endroits, je dois l'avoir oublié ici, je peux rajouter ça (mais la priorité est basse étant donné que le workaround est simple - ne pas rentrer n'importe quoi comme nom). De toute façon, une validation complète est impossible parce qu'il y a aussi les mots-clé réservés, qui dépendent de la version de AMS et de la langue. Je ne peux que rejeter ce qui ne peut jamais être un nom valide.

En effet, ld-tigcc, grâce à main.c :: DecodeOnCalcName, supporte l'utilisation du charset natif de la machine.

C'est une fonctionnalité que j'ai rajoutée pour KTIGCC 2.
Ce que KTIGCC 1 fait, c'est qu'il passe directement le nom dans le charset natif dans la ligne de commande de ld-tigcc. (Et TIGCC IDE fait à peu près la même chose, mais une fois de plus le charset natif est approximé par le CP 1252.) Je ne peux pas faire ça dans KTIGCC 2 parce que le KProcess de KDE 4 utilise des QString pour les arguments, pas des QByteArray.

Mais aucun des deux IDE ne le supporte vraiment: non seulement les champs d'edit sont trop courts (IDE Delphi et KTIGCC), mais '%' n'est pas un caractère autorisé par le vérificateur de l'IDE Delphi (N/A pour KTIGCC qui ne vérifie rien du tout, pour le moment).

% ne sera jamais autorisé à être rentré par l'utilisateur dans l'EDI (en ligne de commande, c'est accepté), c'est un codage utilisé en interne par KTIGCC 2 pour passer le nom à ld-tigcc de manière portable et compatible Qt 4. (Passer des arguments en un charset non-natif est un hack qui passe sous *nix, mais pas ailleurs.) Ce que l'utilisateur est censé faire, c'est rentrer le nom normalement. Ce qui se passe ensuite dépend de l'EDI utilisé:[ul][li]TIGCC IDE utilise le CP 1252 et passe la chaîne telle quelle à ld-tigcc. On peut (si le validateur le permet) mettre des lettres grèques en utilisant le caractère correspondant du CP 1252. Si tu veux faire ça proprement, il faudra faire comme KTIGCC 1 ou KTIGCC 2 (cf. ci-dessous). Mon plan à moi, c'est que TIGCC IDE sera remplacé par un portage de KTIGCC et du coup le problème se règlera tout seul.[/li][li]Dans KTIGCC 1, la saisie se fait en Unicode, tu peux rentrer les lettres grèques Unicode (par exemple avec KCharSelect), le nom sera converti en le charset natif avec la libticonv et passé à ld-tigcc directement en ce charset à travers un QCString.[/li][li]Dans KTIGCC 2, la saisie se fait en Unicode, tu peux rentrer les lettres grèques Unicode (par exemple avec KCharSelect), le nom sera converti en le charset natif avec la libticonv, encodé avec les % pour tous les caractères non-ASCII et passé à ld-tigcc sous forme encodée.[/li][/ul]

J'espère que ça éclaircisse la situation.

Kevin Kofler (./199) :
Donc ton argument prétendant que le PPG sera plus gros si on compte le pstarter n'est pas valide.

T'as répondu à un peut-être par un autre peut-être. J'ai rien affirmé péremptoirement sur ce point, contrairement à toi. Par contre, il faut faire des choix, j'ai fait celui de la puissance du kernel contre celui de la (f)rigidité du nostub, c'est tout. (et surtout, qui serait assez con pour aller développer du nostub PedroM-only ? )

Quels bugfixes [à pstarter/ttstart] y a-t-il ?

Sûrement un bon paquet depuis 2004, mais malheureusement je ne me rappelle pas de tout ce qui avait été reporté.

Je ne me souviens pas qu'il y en ait eu tant que ça, mais il faudrait retrouver des versions de 2004 pour en être sûr...
Dans le repository CVS de TIGCC, on trouve:

Date: Tue Feb 28 23:36:59 2006 +0000
Import pstarter.
Date: Mon Mar 20 17:16:22 2006 +0000
Port ttunpack code to GNU as and drop hex array hack.
Date: Mon Mar 20 17:21:33 2006 +0000
Fix hexadecimal number syntax.
Date: Sun Sep 2 00:50:51 2007 +0000
Fix pst-ttuf.h build (complete the GNU as port: macro and local label syntax, pc->%pc, missing : after label, change invalid bset.w to b
Date: Sun Sep 2 01:06:46 2007 +0000
Update copyright year and history.
Date: Sun Sep 2 21:11:27 2007 +0000
Move handles in front of program name so the program name can be changed to a name with odd length.

Deux bugs sur six commits.

Je vois qu'il y a des différences entre mon pstarter local et celui de TIGCC/GCC4TI (ce dernier étant manifestement plus à jour), il va falloir que j'unifie tout ça.


A priori, le support des dossiers dans le nom de la data variable fonctionne sans modifications au linker. J'ai écrit à David Randall avant les congés de Noël pour lui demander ce qui ne fonctionnait pas pour lui, je n'ai pas eu de réponse...
Ce serait donc l'absence de support des dossiers dans le nom du programme compressé qui serait une incohérence.

Le support des dossiers dans le pstarter ne consomme que 9 octets, soit moins d'1% de la taille d'un pstarter. Moins que de faire un wrapper TI-BASIC qui change temporairement et restaure le répertoire courant, ce que les utilisateurs font souvent pour éviter d'avoir à changer à la main dans un sens et dans l'autre le répertoire courant.

pour une fonctionnalité limite inutile

Ce n'est ni l'avis de David Randall, ni celui de TICT (dont le programme le plus connu utilise un répertoire autre que "main").

De toute façon, une validation complète est impossible parce qu'il y a aussi les mots-clé réservés, qui dépendent de la version de AMS et de la langue.

En effet.

Je ne peux que rejeter ce qui ne peut jamais être un nom valide.

Ce que fait l'IDE Delphi, c'est pour ça que je dis que KTIGCC est buggé

% ne sera jamais autorisé à être rentré par l'utilisateur dans l'EDI (en ligne de commande, c'est accepté), c'est un codage utilisé en interne par KTIGCC 2 pour passer le nom à ld-tigcc de manière portable et compatible Qt 4

Vu.

Lionel Debroux (./202) :
Dans le repository CVS de TIGCC, on trouve:

Ce ne sont que les modifications depuis la réécriture du pstarter. Ça peut paraître long d'un point de vue purement temporel, mais si on considère la fréquence des modifications effectuées, ce n'est que le tout dernier moment de la longue Histoire du pstarter.

A priori, le support des dossiers dans le nom de la data variable fonctionne sans modifications au linker. J'ai écrit à David Randall avant les congés de Noël pour lui demander ce qui ne fonctionnait pas pour lui, je n'ai pas eu de réponse...Ce serait donc l'absence de support des dossiers dans le nom du programme compressé qui serait une incohérence.

Bah, je peux interdire les backslashes dans les noms des fichiers de données dans ld-tigcc si cette incohérence te dérange tant que ça. (C'est déjà pratiquement interdit dans les EDIs, cf. la longueur limitée à 8 caractères.)

Le support des dossiers dans le pstarter ne consomme que 9 octets, soit moins d'1% de la taille d'un pstarter. Moins que de faire un wrapper TI-BASIC qui change temporairement et restaure le répertoire courant, ce que les utilisateurs font souvent pour éviter d'avoir à changer à la main dans un sens et dans l'autre le répertoire courant.

Ils n'ont qu'à envoyer tout dans main comme prévu.

Ce n'est ni l'avis de David Randall, ni celui de TICT (dont le programme le plus connu utilise un répertoire autre que "main").

Chose dont je n'ai jamais compris j'intérêt, je veux bien que vous mettez les BDD d'ouvertures etc. dans tict, mais pourquoi le programme et son PPG ne peuvent-ils pas être dans main comme tous les autres?

Certains des bugfixes de ttstart/pstarter ne s'appliquent probablement pas à sstart.

Bah, je peux interdire les backslashes dans les noms des fichiers de données dans ld-tigcc si cette incohérence te dérange tant que ça

Ben, fais ce que tu veux dans ton projet
Mais à l'avis de David Randall et à celui de TICT (au moins), c'est le contraire qu'il faut faire: corriger KTIGCC pour qu'il supporte des noms de fichiers avec backslashes de taille maximale (17 caractères). Ce que sait faire l'IDE Delphi, voir ProjectOptionsUnit.pas et un des patches que j'ai attachés au ticket #34.
Et pour faire le boulot mieux que ce qu'il n'a été fait jusqu'à présent, ajouter un peu partout - y compris dans la TIGCC Tools Suite - une vérification de la vraisemblance des noms. "Vraisemblance" et pas "validité", puisqu'on ne vérifiera pas les noms réservés: c'est à peu près impossible, comme tu l'as fait remarquer. On sait à quoi doivent ressembler un nom de dossier, un nom de variable dans dossier et un nom de variable avec dossier, on n'a même pas besoin d'utiliser un lourd moteur de regex (pcre, trucs de Qt/KDE, etc.) pour faire la validation.


Ce n'est pas le premier problème de validation des entrées utilisateur que je trouve dans TIGCC: il y avait déjà le crash de ld-tigcc (c'est très user-friendly) quand on essaie de faire rentrer la valeur d'un symbole spécial dans un endroit qui est trop petit pour contenir la valeur, par exemple
.byte __ld_link_time_timestamp
Je suppose que ça ne se produit qu'avec les symboles spéciaux, puisque pour les labels normaux, le linker se plaint quand l'offset est trop grand pour faire rentrer le déplacement dans une reloc de taille 1 ou 2.

[EDIT: typo]

Sinon, si on commence à rentrer dans la longue liste des bugs de la toulechayne standard, on a pas fini. Niouaès se permet certains bugs que même le soi-disant buggué A68k ne se permet pas. Je cherche où est la maintenance d'un tel soft là-dedans...

Kevin Kofler (./203) :
Ils n'ont qu'à envoyer tout dans main comme prévu.

comme Moi, Kevin Kofler de la Koflerdière et d'autres lieux découverts à marée basse, J'ai prévu, pensé, statué et érigé au rang de standard et de dogme infaillible, pour que jusque dans la nuit des temps, soit honni celui qui ne pliera pas sa volonté à Mes moindres désirs.

C'est quoi encore ce standard à deux balles ?!?

As-tu déjà signalé tes bogues de GNU as?

Ben c'est ce que je dis, la maintenance des softs libre m'a si souvent foutu sur les rotules que j'y compte même pas... Il y a depuis longtemps le bug des strings dans les macros, et encore au moins un autre que j'avais en tête quand j'ai écrit tout à l'heure, mais qui m'échappe (problème de parsing il me semble). Ceci dit, c'est suffisamment bon pour que ça me serve de modèle pour mon parseur.

edit -> ça me revient, et c'est pas un bug de parsing. C'est le fait qu'il accepte de créer un adressage court (.s) alors qu'il adresse quelque chose à plus de 128 octets sans broncher. Du coup, tu te retrouves avec des sauts que tu as du mal à comprendre... Il devrait signaler ça... (à moins que ce ne soit au linker de le faire ?)

Kevin: si c'est pour que les bugs que Martial reporterait soient traités avec autant de célérité que http://sourceware.org/bugzilla/show_bug.cgi?id=1198 , je comprends qu'il n'ait pas envie de reporter...
Oui, ce fichier contient des flags qu'objdump ne peut pas comprendre. Mais crasher est inamical pour l'utilisateur, et montre qu'objdump (probablement BFD, en fait) n'est pas du code sûr. Ce qui a été montré également par Sam Hocevar, voir cinq occurrences de nm et une d'objdump à http://caca.zoy.org/wiki/zzuf/bugs .

Ah oui, quand tu vois la date du report ça fait peur

(et j'ai édité mon post précédent)

J'ai expliqué pourquoi l'absence d'avertissement pour ton .s n'est pas un bogue.
(Pour tout le monde: c'est le linker qui calcule l'adresse et il ne peut pas savoir si le relogement est signé ou non signé, donc il accepte tout entre -128 et 255 sans warning. Manque de chance, ici, c'est entre 128 et 255 et le relogement est signé.)