Coder rapidement des programmes interactifs - Page 5

Bon courage alors ! Si tu galères trop, tu peux patcher ta machine avec ça.

J'ai déjà FlashAppy mais je l'ai pas encore installé, j'veux un GTC signé :s

T'as lu là doc ? Si c'est celui auquel je pense, il décrit dans la doc où installer les différents composants, et quelle est la syntaxe.

Bien sûr que j'ai lu la doc de GTC ...

Ah, je suis HS, j'ai cru que tu parlais des softs pour signer ta flash apps.

C'moi qui avait pas compris.

Bon en fait j'ai demandé à GoldenCrystal ^^

Voilà une vidéo montrant le programme d'exemple fourni avec likeonpc.





On constate que :

- la façon de passer les arguments n'a pas d'importance : on peut les séparer soit par des espaces (façon PC), soit par des virgules (façon AMS).

- dans le code source, toutes les manips pour mettre au propre et remettre au propre l'écran, la police et le buffer clavier sont inutiles, comme sur PC.

- les fonctions standards d'entrées clavier sont enfin utilisables. Avec TIGCC, il était impossible de modifier sa saisie si on avait mal tapé quelque chose.

- le programme retourne un code d'erreur (0 en l'occurrence)



Source :

Splendide !

Les débutants seront contents d'apprendre que ce programme anodin aurait nécessité 200 lignes de C avec TIGCClib seule.

Super ! Pour apprendre le C, genre en TD si t'as pas de PC, c'est le pied.

Oh ! Merci Vince pour la surprise sur ti-fr.com ! C'est super sympa !

De rien, c'est le "minimum syndical"

argv[0] donne bien le nom de l'executable ?

argv[0] donne bien le nom de l'exécutable ?

Rha

!slap yAronet
• Godzil slaps yAronet around a bit with a large trout !

J'apprécie également l'évolution positive

très pas mal du tout!

Ça va se poursuivre. Prochaine version majeure : support des flux stdin/stdout et des redirections de ces flux, et version propre pour TIGCC/GCC4TI. Entre temps, il va y avoir une amélioration dans l'éditeur de saisie clavier pour prendre en compte le scroll ecran.


Godzil : Non, c'est une chaîne vide pour l'instant. J'ai cherché un petit moment mais j'ai pas trouvé comment faire. D'ailleurs ce n'est pas vraiment le nom de l'executable qu'il faut donner dans argv[0] mais ce qui a été tapé avant le premier argument. Quand le programme ne se trouve pas dans le dossier courant, on y trouverait typiquement /chemin/exécutable.
C'est toi le meneur de GCC4TI ? J'ai toujours cru que c'était Lionel mais j'ai un doute.

Ton argv[ 0 ], c'est les 8 premiers octets de kernel::Hd2Sym(kernel::Ptr2Hd(pc)) ...

Thibaut (./137) :
Ça va se poursuivre. Prochaine version majeure : support des flux stdin/stdout et des redirections de ces flux, et version propre pour TIGCC/GCC4TI. Entre temps, il va y avoir une amélioration dans l'éditeur de saisie clavier pour prendre en compte le scroll ecran.


Godzil : Non, c'est une chaîne vide pour l'instant. J'ai cherché un petit moment mais j'ai pas trouvé comment faire. D'ailleurs ce n'est pas vraiment le nom de l'executable qu'il faut donner dans argv[0] mais ce qui a été tapé avant le premier argument. Quand le programme ne se trouve pas dans le dossier courant, on y trouverait typiquement /chemin/exécutable.
C'est toi le meneur de GCC4TI ? J'ai toujours cru que c'était Lionel mais j'ai un doute.

Le contenu exact depend de l'OS, mais sous un UNIX c'est normalement la commande qui a été tapé sur la ligne de commande, donc si tu as tapé /usr/bin/blabla, tu auras /usr/bin/blabla cf :

me@confucius ~/test $ gcc test.c -o toto
me@confucius ~/test $ ./toto 
Hello world './toto'
me@confucius ~/test $ export PATH=.:$PATH
me@confucius ~/test $ toto
Hello world 'toto'
me@confucius ~/test $ ~/test/toto
Hello world '/home/me/test/toto'
me@confucius ~/test $ ln -s toto tata
me@confucius ~/test $ tata
Hello world 'tata'
me@confucius ~/test $ cat test.c 
#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("Hello world '%s'\n", argv[0]);
  return 0;
}
me@confucius ~/test $ 

bref n'avoir que le nom de l'executable est tres bien

c'est exactement ce qu'il a dit, non ?

Zephyr (./140) :
c'est exactement ce qu'il a dit, non ?

Oui je m'en suis rendu compte après coup, j'avais mal lu et lu "contient le chemin complet vers l'executable", enfin bref osef, on est d'accord sur ce point

(il me semble, oui)

(cross)

Ok, j'avais l'impression d'avoir loupé une marche ^^

Je ne sais pas s'il a d'autres utilités, mais pour moi ce argv[0] sert principalement à appeler d'autres programmes en utilisant des chemins relatifs, et éventuellement à afficher le bon chemin dans un printf ("usage: %s <arg1> <arg2>\n", argv[0]). Dans le premier cas c'est très anecdotique sur Ti vu qu'on appelle rarement d'autres programmes (sauf dans le cas d'un shell, mais de toutes façons la notion de "chemins relatifs" sur Ti, c'est assez limité du fait de l'unique niveau de profondeur), dans le second c'est juste cosmétique, donc au final c'est pas une feature forcément indispensable.

Folco : mmmh... Il faudrait reproduire le code de ces fonctions en C et sans appel au kernel, et voir si le répertoire courant est celui du programme, si c'est faux, concaténer le répertoire du programme au nom. Ca prendrait sans doute pas mal de lignes de C. Pourquoi pas, mais est-ce ça vaut la peine de le faire, de dépenser de la mémoire, pour quel intérêt ? C'est la question posée par Zéphyr. Quelqu'un aura-t-il une réponse tranchée...

oui, moi. ca sert a rien.


sur pc l'utilisation principale de ce truc est pour faire des liens symboliques vers des programmes. Exemple, gzip, gunzip et gzcat qui sont le même programme, mais dont le comportement change selon le nom du lien qui appelle le prog. cf busybox aussi.

sur ti je crois qu'on s'en fiche sauf si c'est aussi simple que 3 lignes.

Thibaut (./145) :
Folco : mmmh... Il faudrait reproduire le code de ces fonctions en C et sans appel au kernel, et voir si le répertoire courant est celui du programme, si c'est faux, concaténer le répertoire du programme au nom. Ca prendrait sans doute pas mal de lignes de C. Pourquoi pas, mais est-ce ça vaut la peine de le faire, de dépenser de la mémoire, pour quel intérêt ?

Ca n'a aucun intérêt en soi, si ce n'est de forcer le passage au mode kernel, qui n'est à mon avis pas la bonne solution pour ton soft. (notez bien ce que j'ai dit, c'est historique ! )

squalyl (./146) :
oui, moi. ca sert a rien.


sur pc l'utilisation principale de ce truc est pour faire des liens symboliques vers des programmes. Exemple, gzip, gunzip et gzcat qui sont le même programme, mais dont le comportement change selon le nom du lien qui appelle le prog. cf busybox aussi.

sur ti je crois qu'on s'en fiche sauf si c'est aussi simple que 3 lignes.

printf("usage: %s [-h]\n", argv[0])

est une utilisation plutot courante

(PS: les liens sont possible sur TI )
(PS2: perso oublie le repertoire, le nom de l'executable suffirait largement)

Godzil > printf("usage: %s [-h]\n", *argv) a l'avantage de ne pas pourrir les messages