Coder rapidement des programmes interactifs - Page 4

C’est possible de supporter nativement une telle fonctionnalité sans casser aucun programme existant (sauf peut-être ceux qui s’amusent déjà à redéfinir le main ?).

Godzil (./82) :
Je n'ai pas encore regardé les sources, et je ne sais pas si GTC supporte, mais défini au moins tes fonctions en static, ça evitera pour du multisources de tenter d'exporter les nom de fonctions, donc ça évitera des problèmes de links, par contre vive le code dupliqué au sein du meme projet ^^

Bah, ld-tigcc ne donne pas d'erreur pour les symboles en double, il prend juste un au hasard si on le référence.

Thibaut (./85) :
Vous ne pensez pas que TIGCC et sa lib devrait supporter nativement le standard ANSI, et ce depuis longtemps ?

Oui, mais faire ça proprement est très compliqué. Ta solution est une bidouille qui marche plus ou moins bien, mais est loin d'être au niveau nécessaire pour être accepté dans TIGCCLIB.

Sachant que tous les anciens programmes TIGCC resteront compilables puisque la couche de portabilité ne serait activée qu'en l'absence de _main.

Mais tu remplaces certaines fonctions de TIGCCLIB! Si tu veux faire ça seulement si _main n'est pas défini, c'est une fonctionnalité à rajouter au niveau de l'EDI par exemple, mais c'est plutôt pourri comme solution. (Ce n'est pas compatible avec le modèle de compilation séparée, parce que l'absence de _main est une propriété globale au programme, et changer le comportement des fonctions est une option globale, donc on doit compiler tout le programme en même temps pour gérer ça. Donc à mon avis, cette solution ne fonctionne pas.) Changer le comportement des fonctions et avoir un main ISO devraient être des options séparées (et seul le main ISO peut être automatique).

Alors, pour être précis, les programmes existants définissent tous _main, ldtigcc choisira le leur, donc ils ne seront pas concernés, pas cassés. Parmi eux, quelques uns font #include <stdio.h> au lieu du traditionel tigcclib.h. Ceux là seront peut-être cassés car les fonctions d'entrées au clavier se comporteront un peu différemment à l'exécution. On peut alors imaginer un flag, du genre #define LEGACY_TIGCCLIB ou CLASSIC_TIGCCLIB ou plus approprié, qui garderait les anciennes fonctions.

Voilà. Mais si TIGCC accepte plusieurs redéfinitions alors finalement le .h actuel permet la compilation séparée. C'est crado mais simple en attendant mieux. Je vais modifier les textes de présentation pour dire que la compil séparée n'est pas interdite.

Le comportement par défaut de stdio.h ne sera pas modifié. TIGCCLIB garantit une compatibilité antérieure à 100%.

Sinon, un problème pour le wrapper main, c'est qu'il devrait être configurable aussi. Par exemple, on pourrait ne vouloir que la gestion des arguments, sans l'effaçage de l'écran.

Sasume (./89) :
#include <peekpoke.h>

Merci, je sais pas encore trop m'servir de la Doc

Thibaut (./90) :
FireHunter, tu dois avoir merdé quelque chose dans l'installation Ils sont très bizarres tes messages d'erreur.

Nan mais j'ai réenvoyé un OS sur la ti (3.10, depuis le site offi), j'avais savegardé mes fichiers dans un .tig, et même GTC non-signé est passé sans problème Oo

pour le coup je comprends Kevin. GCC4TI sont pour le développement natif, une couche de compatibilité prend de la place et n'est pas forcément nécessaire dans une solution embarquée. Elle n'a d'utilisation que si elle sert à porter un programme PC sur une plate forme TI68k. Et quels programmes sont portables en changeant juste stdio?

ils nécessiteront d'autres chargement, et la bonne méthode de portage est dans ce cas une couche d'abstraction complète, mais spécifique au programme.

ou alors, un OS from scratch intégrant une newlib dégraissée, mais dans ce cas on n'a plus du tout d'intéret à utiliser gcc4ti+lib.

ta "lib" , Thibaut, est vraiment intéressante techniquement, mais par contre il me parait pas intéressant de l'intégrer dans gcc4tilib. A la limite la seule "valeur ajoutée" que tu apportes c'est la gestion de argv, qui peut être isolée dans une fonction (par exemple, modulo mes erreurs de mémoire)

char **estack_to_argv(ESI ap, short max_argc);

Edit: supression du nom TIGCC à la suggesion de Kevin, je ne parle pas pour lui.
.

Je ne voulais pas être celui qui le formulerait, mais +1 ./96.

ta "lib" , Thibaut, est vraiment intéressante techniquement, mais par contre il me parait pas intéressant de l'intégrer dans tigcclib.

Tout à fait. C'est clair que la lib résout un problème réel, mais qui affecte a priori assez peu de monde.
Il n'est pas interdit à TIGCC/GCC4TI de mentionner que ça existe.

Quand est-ce que tu arrêteras de parler au nom de TIGCC?

À la limite, je pourrais mettre ça dans la liste des "Other downloads" sur le site de TIGCC, mais il faudra d'abord voir si la qualité est au rendez-vous. Je n'ai pas encore regardé le code, mais entre le code dans le header, la redéfinition (non optionnelle) d'options (SAVE_SCREEN) et de fonctions de TIGCCLIB, les tableaux de taille fixe et tout le reste qui a été discuté ici, ça craint.

A partir du moment où ça ne change pas le moindre octet dans les programmes classiques, je ne comprends pas votre raisonnement. Ca n'apporte un changement qu'aux programmes debutant par main au lieu de _main.

FireHunter : Mmmhhh... Réinstalle GTC a partir des fichiers dans le zip original. http://gtc.ti-fr.com

Kevin : ouai je m'en doutais Alors, un flag inverse, du genre de #define STANDARD_STDIO pour activer la compatibilité ? On perd un peu en portabilité mais si c'est le prix a payer pour simplifier à tout le monde la conception rapide de programmes, ca me parait raisonnable.

Pour la configuration, à voir... Mais franchement, tous les programmes commencent par effacer l'écran et finissent par le restaurer... Ceux qui ne font que du traitement d'information sans sortie écran donneront lieu à un flash blanc. Dans ce cas, on peut retirer definivement le clrscr du wrapper.

Ces modifs rendent-elles acceptable l'integation à tigcclib ?

Kevin : le .h qui contient du code, c'etait par necessité comme tu le sais et ça va être changé pour TIGCC. Le buffer limité à 256 caractères, je t'ai déjà répondu, c'est ni trop ni trop peu. Tu voudrais une taille dynamique en RAM plutôt que sur la pile ? Tu penses que creuser un gruyère dans le tas avant même l'exécution du programme serait une bonne idée ?

Carrément

Kevin Kofler (./98) :
Quand est-ce que tu arrêteras de parler au nom de TIGCC?

fixed

Joli travail Thibaut !

Merci. Si ca peut te servir un jour j'en suis heureux

Kevin : Ah et pour les redéfinitions de fonctions, tu as une autre méthode à proposer ? Si les fonctions sont plus puissantes que celles de base, il faut bien les redefinir ! Dans la version pour TIGCC, ca peut se traduire par des #ifdef LIKEONPC fonction utilisable #else fonction au comportement bizarre de TIGCC #endif. Pour la version GTC, n'hesite pas à expliquer comment régénérer la bibliothèque precompilée à partir des sources, là aussi on pourra avancer sur cette question de redéfinitions.

Tu sais, je fais ce truc pour GTC et si je me propose de faire une version propre pour TIGCC c'est uniquement pour ses utilisateurs. Donc te prive pas d'être plus respectueux, sinon je te laisse gerer, sachant que tu ne le feras pas vu que tu es un mainteneur qui parle beaucoup mais qui ne fait plus rien. Ce serait dommage pour les quelques programmeurs intéressés.

Thibaut (./100) :
Tu voudrais une taille dynamique en RAM plutôt que sur la pile ?

Je te signale l'existance de alloca et des tableaux de taille variable C99.

Kevin : ton objectif c'est quoi ? dénigrer thibaut ou son travail ? parce que là franchement tu n'apportes pas grand chose de réellement constructif je trouve...

Je lui donne un conseil, c'est tout! À lui de le suivre ou pas.

Kevin Kofler (./107) :
Je lui donne un conseil, c'est tout! À lui de le suivre ou pas.

A supposer que ce soit le cas, un petit effort sur la formulation pourrait probablement limiter l'aspect agressif afin de mettre en avant le coté participatif...

Alors, au menu de la nouvelle version (utilisable avec TIGCC mais encore conçue pour GTC, pour l'instant) :


Modifications sans aucune importance pour l'utilisateur :

- Le parsing des arguments est déplacé dans une fonction dédiée (suggestion de squalyl, pour une lisibilité meilleure).

- Les fonctions et variables "privées" sont déclarées en static (merci squalyl et Godzil pour m'avoir remémoré cette fonctionnalité).

- Les fonctions utilisées une seule fois sont déclarées en inline, pour gagner un peu en vitesse et en taille.

- Appel d'une méthode fournie par le système d'exploitation dans _set_system_cursor_coordinates_. C'est plus sûr.

- Stockage des arguments parsés (argv) sur la pile, pour gagner un peu de RAM (suggestion de squalyl qui est pertinente, car on reste bien en dessous des 3,8 ko que bouffe TIGCC).


Modifications très importantes :

- Vérification du nombre de caractères parsés et interruption du programme s'il dépasse la limite (réaliste) de 256. Le cas échéant, le code POSIX 7 est retourné (E2BIG, Arg list too long).

- La vérification du nombre d'arguments n'était pas complète, que suis-je distrait... C'est corrigé.



Téléchargement ici !
La version adaptée et plus clean pour TIGCC arrivera ultérieurement.

Je réinstalle GTC et je regarde

Ce que tu fais est clairement du code résolvant un vrai problème, continue

Je sais pas si c'est spontané Tu sais, tout ce qu'il faut, à moi et à quiconque écrit des programmes, c'est du respect envers le travail fourni - même s'il n'est pas énorme. Ici on fait les choses gratuitement, pour rendre service. Ce n'est pas forcément assimilé par certains.

Superbe.

Ce que tu fais est clairement du code résolvant un vrai problème, continue (et plus vite que ça )

Sinon, dans l'éditeur d'entrées clavier, ceux qui ont eu le temps de jeter un oeil ont-ils trouvé des imperfections ?

C'est quoi ? ^^' *profite du topic pour apprendre des trucs*

_internal_getsn_ dans likeonpc.h, je pense.

Ouai voilà. C'est l'ensemble de fonctions supervisées par _internal_getsn_.

La première moitié du .h, c'est grosso modo ce qui gère l'initialisation et la sortie du programme (le fameux parsing des arguments en fait partie). La seconde moitié est à l'origine de l'amélioration du comportement des fonctions d'entrée clavier (gets, getsn, getch, getchar, scanf).

Déjà une version 1.1.

exit(int errno) posait problème à l'édition des liens.

FireHunter, si tu as transféré la version 1.0 dans ta machine (celle sortie dans l'après midi), il suffit que tu retransfères juste le fichier gtchdr.likeonpc.h. Le reste (autres headers et exemple) ne change pas.

J'ai encore rien envoyé, je voulais signer GTC, vu que j'ai un OS tout propre (HW3Patch pour checksum fail seulement), je veux pas le pourrir tout de suite. Par contre j'y pige rien à RabbitSign, et je dois tout faire depuis mon LiveCD d'Ubuntu --", n'étant pas sur mon PC adoré