Le SDK de TI programmé en Java ? - Page 1

Pourtant l'IDE n'est pas lent

Oui, le SDK de TI est programmé (au moins en partie) en Java. (Vive TIGCC, écrit en Delphi, C et C++, pas un le langage lent appelé Java. )

Desolé Kévin mais je trouve l'IDE de TIGCC plus lent que celui du SDK de TI. Il a beaucou de défauts, mais il n'est pas lent!
Il ramme particulierement sur des enorme fichier avec plein de declacration de tableau comme des sprites....

Et qu'est ce que ce topic fait dans la partie Newbies

Et bien parceque je suis un newbie dans ce domaine. Je sais à peine ce qu'est le Java.
Tu l'aurais bien vu où ?

Oui, il utilise une machine virtuelle Kava ...
[extrait du readme.txt]

2.  System Requirements
-  Microsoft* Windows NT* 4.0, Windows* 95, Windows 98, or Windows ME
-  32 MB of RAM or greater (64 MB recommended)
-  Mouse or pointing device
-  35 MB of available hard disk space recommended
-  VGA monitor (800x600 resolution or better preferred)
-  Adobe Acrobat Reader* 4.0 or higher installed
-  Microsoft Virtual Machine.  Please download the latest 
   version (3319) from http://www.microsoft.com/java/
*All other brands and names are property of their respective owners.

> Thibaut
C'est quoi ce dossier Azur C dans la barre des taches ?

petit curieux

Gavé

Je suis sur qu'il a fait exprès pr qu'on lui pose la question

arf...
Une réponse simple serait que le compilateur AZUR est programmé en C...

Je trouve aussi que tigcc rame bien, quand on fait plein de tabulations. Par exemple, lorsque je déclare un tableau, j'aime bien avoir les colonne alignées les unes en dessous des autres, donc j'utilise la touche TAB pour les aligner.

>squale92: Une réponse simple serait que le compilateur AZUR est programmé en C...

En effet, c'est le cas. Thibaut utilise TIGCC pour programmer l'Azur. C'est en partie pour ça que je me suis fâché autant quand il a dit qu'il ne va pas contribuer tout son runtime au projet TIGCC tout de suite - il utilise TIGCC et il refuse d'y contribuer alors qu'il est totalement en mesure de le faire. Mais bon, je pense que tout le monde en a déjà marre de cette discussion, donc arrêtons d'en parler.
[edit]Edité par Kevin Kofler le 26-12-2001 à 02:51:26[/edit]

Il vaut mieux .

A propos du SDK de TI... je m'en suis servi un peu l'été dernier quand j'ai commencé AS, et c'est vraiment domage que personne ne l'utilise, car il contient quelques merveilles : le source-level debugger, qu'on n'est pas pret de voir dans TI-GCC, l'optimisation des rom-calls en "line emulator" (2 octets par rom calls), les nouvelles fonctions d'AMS 2 qui sont super pratiques (en particulier la gestion des fichiers)... de plus le compilateur Sierra est excellent, et permet de faire des choses qui ne sont pas possibles avec TI-GCC, et que JM a du rajouter à coups de patchs PalmOS et Amiga pour Win/LiteOS.
Mais voila, il y a un énorme probleme, il est vraiment tres tres buggé, alors quand je m'en suis aperçu j'ai envoyé des bug reports à TI, et j'ai utilisé TIGCC... le drame c'est que comme personne ne l'utilise, personne n'envoie de bug reports, et donc il n'y a pas de corrections, et c'est vraiment dommage

J'ai vu que Sebastian travaillais sur le debugger pour TIGCC, et qu'il avait l'intention de modifier VTI ? C'est vraiment pas la bonne méthode, c'est meme plutot stupide, il suffirait d'arranger un peu le stub GDB M68K pour utiliser le port i/o, et faire un tunnel TI-Graph Link - TCP/IP pour utiliser GDB (avec Insight, ou DDD, etc...) Et pour ceux qui voudraient rester dans TIGCC-IDE il suffirait de le modifier pour lire directement les données du graph link et se reperer dans les sources avec le .o coff produit en mode debug. Non seulement ça marcherait avec VTI, mais aussi avec n'importe quel autre émulateur et surtout avec la vraie calculatrice... Enfin bon c'est juste une idée

C'est dommage, en effet, surtout que la documentation est assez complète
Personnellement je l'utilise lorsque TIGCC ne suffit pas (APP-Flash ...).

Ce sont quoi les merveilles du compilateur Sierra ?
Tu crois que si on codait une librairie documentée avec pleins de fonction ANSI-C (comme TIGCClib) pour ce SDK, il serait beaucoup plus utilisé ?

Non.

Thibaut:
Je ne sais plus exactement, mais la documentation du compilateur/assembleur/linker est tres détaillée...

Et puis pour répondre à ta question, non je ne pense pas que beaucoup de monde utiliserait ce SDK, meme avec une libc, parce que TI-GCC est deja bien ancré dans les moeurs et de tte façon TI c'est toujours les méchants dans l'histoire

D'un côté c'est un avantage, mais je reproche à la TIGCCLIB de n'inclure que les fonctions implémentées sur TOUTES les versions (Harware comme Software).
Bon c'est vrai que les nouvelles fonctions de AMS 2.0x (pourcentages dans la barre de status ..) ne sont pas non plus très utiles

>> la documentation du compilateur/assembleur/linker est tres détaillée...

Où on peut l'avoir cette doc ??

ZdRUbAl> je suis d'accord avec toi en ce qui concerne le désir absolu de la TIGCC Team de rester compatible avec les antiquités... Certes il y a des fonctions d'AMS 2 qui ne sont pas indispensables, mais par contre il y en a d'autres... comme par exemple, pour tokeniser un nom de fichiers en vérifiant qu'il est bien valide, dans SIDE essaie d'ouvrir une variable systeme

Thibaut> sur le site de TI.

J'y cours !!!

En tant que membre de l'équipe de TIGCC, je me vois obligé de répondre:

>Nitro:

>il contient quelques merveilles : le source-level debugger, qu'on n'est pas pret de voir dans TI-GCC

C'est prévu dans TIGCC, mais il est vrai qu'il reste beaucoup de progrès à faire.

>l'optimisation des rom-calls en "line emulator" (2 octets par rom calls)

Compatible avec AMS 2.04/2.05 seulement (ou alors en émulation avec Line1111 de Paxal). On ne compte pas rajouter cela.

>les nouvelles fonctions d'AMS 2 qui sont super pratiques

Oui, mais AMS 2 uniquement.

>en particulier la gestion des fichiers

1. Je trouve que vat.h est la manière la plus simple de manipuler des fichiers.
2. Il y a des fonctions de gestion de fichier compatibles ANSI (pas seulement style ANSI comme celles de AMS 2) dans TIGCCLIB.

>de plus le compilateur Sierra est excellent, et permet de faire des choses qui ne sont pas possibles avec TI-GCC, et que JM a du rajouter à coups de patchs PalmOS et Amiga pour Win/LiteOS.

À part le passage de registres (Leur compilateur le supporte-t-il? Ça m'étonnerait!), je ne vois pas ce que tu veux dire. Et on veut bien le mettre si quelqu'un nous donne un patch pour GCC 3.0.2 ou encore mieux 3.0.3 (pas pour 2.9.5 comme dans GCC-LiteOS - il est hors de question de revenir en arriere comme ça) qui le fait.
Et puis:
- le compilateur Sierra optimise moins bien que GCC.
- le SDK de TI ne permet pas les variables globales dans les programmes en RAM (du moins selon la documentation). TIGCC n'a pas de problèmes avec ça.

>J'ai vu que Sebastian travaillais sur le debugger pour TIGCC, et qu'il avait l'intention de modifier VTI ? C'est vraiment pas la bonne méthode, c'est meme plutot stupide,

Moi, je trouve que c'est une très bonne manière d'avoir vite un bon débogueur pour TIGCC. Seul problème: ça sera Win32 uniquement. Mais c'est le cas pour TIGCC IDE en entier de toute façon. Et puis, il y aura les sources, donc quelqu'un pourra l'intégrer dans d'autres émulateurs (comme GtkTiEmu) une fois qu'on a fini avec VTI.

>il suffirait d'arranger un peu le stub GDB M68K pour utiliser le port i/o, et faire un tunnel TI-Graph Link - TCP/IP pour utiliser GDB (avec Insight, ou DDD, etc...)

Je sens que ça va être le bordel! Les sources des programmes GNU sont extrèmement compliquées. Et puis, il n'y a pas seulement le port I/O, il y a aussi les 4 types de câbles différents (gris, noir ou série maison, parallèle, USB) du côté du PC à supporter. Et du TCP/IP sur port I/O... c'est vraiment n'importe quoi. (Tu comptes utiliser TinyTCP version TI? Je te signale que c'est pour câble gris uniquement... Et que c'est pour terminal uniquement pour l'instant (pas pour des programmes comme GDB). Il reste donc beaucoup de travail à faire.) Adapter VTI est beaucoup plus réaliste comme projet. Si ton idée est tellement facile, tu n'as qu'à l'implémenter toi-même. On se revoit en l'an 2042...

>Et pour ceux qui voudraient rester dans TIGCC-IDE il suffirait de le modifier pour lire directement les données du graph link et se reperer dans les sources avec le .o coff produit en mode debug.

Encore un travail de fous à rajouter à ton projet déjà surchargé...

>Non seulement ça marcherait avec VTI, mais aussi avec n'importe quel autre émulateur et surtout avec la vraie calculatrice... Enfin bon c'est juste une idée

Une idée très bête. On se demande ce que tu as fumé... Ou ...

>ZdRUbAl:

>C'est dommage, en effet, surtout que la documentation est assez complète

Tu as oublié le petit préfixe "in-" devant "complète". Franchement, selon Zeljko, et selon ce que j'ai pu constater moi-même, il manque plein de choses là-dedans. Par exemple, ils ne perdent même pas une ligne sur EV_hook. Et il y a beaucoup moins d'explications sur les fonctions de base que dans notre documentation.

>Personnellement je l'utilise lorsque TIGCC ne suffit pas (APP-Flash ...).

Et tu les signes comment, tes Apps Flash? On ne peut pas créer des applications Flash avec TI-FlashStudio à moins de réussir à convaincre TI de les signer (et personne n'a encore réussi à part 2 ou 3 entreprises commerciales).

>Thibaut: Tu crois que si on codait une librairie documentée avec pleins de fonction ANSI-C (comme TIGCClib) pour ce SDK, il serait beaucoup plus utilisé ?

Non. Il lui manque plein d'autres fonctions:
- variables globales (dans les programmes en RAM)
- extensions GCC
- appels de ROM_CALLs compatibles tous AMS
- compression automatique de programmes avec possibilité de programmes en RAM >24 KO
et on ne peut rien faire avec ça qu'on ne peut pas déjà faire avec TIGCC (parce qu'on ne peut pas signer les applications Flash).

>Nitro:

>Je ne sais plus exactement, mais la documentation du compilateur/assembleur/linker est tres détaillée...

La nôtre aussi. Et si ça ne suffit pas, il y en a des pages sur gnu.org.

>Et puis pour répondre à ta question, non je ne pense pas que beaucoup de monde utiliserait ce SDK, meme avec une libc, parce que TI-GCC est deja bien ancré dans les moeurs et de tte façon TI c'est toujours les méchants dans l'histoire

Il y a d'autres raisons pour lesquels ça ne remplacera jamais TIGCC (du moins pas sans plusieurs changements radicaux).

>ZdRUbAl:

>D'un côté c'est un avantage, mais je reproche à la TIGCCLIB de n'inclure que les fonctions implémentées sur TOUTES les versions (Harware comme Software).

Correction: toutes sauf TI-92+ AMS 1.00.
Et comme en dit en anglais: "It's not a bug, it's a feature."

>Bon c'est vrai que les nouvelles fonctions de AMS 2.0x (pourcentages dans la barre de status ..) ne sont pas non plus très utiles

En effet. Franchement, il y a certaines qui serviraient bien (version de AMS par exemple), mais on peut s'en passer.

>Nitro:

>je suis d'accord avec toi en ce qui concerne le désir absolu de la TIGCC Team de rester compatible avec les antiquités... Certes il y a des fonctions d'AMS 2 qui ne sont pas indispensables, mais par contre il y en a d'autres... comme par exemple, pour tokeniser un nom de fichiers en vérifiant qu'il est bien valide, dans SIDE essaie d'ouvrir une variable systeme

if (!strcmp(nom,"xScl") || !strcmp(nom,"yScl") || ... )
Il y a une liste de noms de variable système.
Ou alors passe par push_parse_text:
TRY
push_parse_text(nom);
handle=HS_popEStack();
if (*(unsigned char *)HToESI(handle)>VAR_Q_TAG) ST_helpMsg("variable système")
HeapFree(handle);
ONERR
ST_helpMsg("variable système")
ENDTRY

>Compatible avec AMS 2.04/2.05 seulement (ou alors en émulation avec Line1111 de Paxal). On ne compte pas rajouter cela.
>Oui, mais AMS 2 uniquement.

Ca tombe bien c'est ce que quasiment tout le monde a. Les autres s'ils peuvent se procurer des programmes sur Internet peuvent également upgrader leur AMS.

>Je trouve que vat.h est la manière la plus simple de manipuler des fichiers.

Tu es bien le seul.

>Il y a des fonctions de gestion de fichier compatibles ANSI (pas seulement style ANSI comme celles de AMS 2) dans TIGCCLIB

Et il y en a style ANSI dans la ROM, qui ne sont pas buggées comme celles de TIGCCLIB et qui prennent 0 octet en plus contrairement à celles de TIGCCLIB.

>le compilateur Sierra optimise moins bien que GCC
>le SDK de TI ne permet pas les variables globales dans les programmes en RAM

Pour le compilateur il me semblait avoir constaté le contraire... et pour les vars globales je crois que ça marche quand meme, et dans le cas contraire il suffit de le demander à TI.

>Moi, je trouve que c'est une très bonne manière d'avoir vite un bon débogueur pour TIGCC

Mais c'est contraignant d'etre obligé d'utiliser TIGCC-IDE et VTI... et le pire c'est qu'il est impossible de debugger le programme en situation réelle, c'est-a-dire sur la calculatrice.

>Et puis, il n'y a pas seulement le port I/O, il y a aussi les 4 types de câbles différents (gris, noir ou série maison, parallèle, USB) du côté du PC à supporter

Et pourquoi Sebastian perd du temps à écrire une lib de link alors que libticables de Romain Liévin marche tres bien et supporte tous les types de cables (meme le virtual link de VTI) et marche sous Windows et Linux ?

>Et du TCP/IP sur port I/O... c'est vraiment n'importe quoi

Tu n'as pas compris ce que j'ai dit... c'est un programme "serveur" sur PC qui fait la transition entre le cable et le réseau. Ensuite tu dis à GDB de se connecter à ce serveur pour communiquer avec son stub sur la calculatrice (ou VTI). Et avec le Gray TI-Graph link on n'en a pas besoin, GDB peut directement communiquer avec. Ca marche tres bien et je l'ai deja fait.. j'ai le programme serveur et j'ai modifié le stub standard 68k pour utiliser le link, le seul truc que j'avais pas réussi à faire c'est compiler GDB sous Cygwin. Alors l'an 2042 n'est pas si loin.

>Encore un travail de fous à rajouter à ton projet déjà surchargé...

Et que GDB fait deja tres bien.

>if (!strcmp(nom,"xScl") || !strcmp(nom,"yScl") || ... )
Il y a une liste de noms de variable système.
Ou alors passe par push_parse_text:
TRY
push_parse_text(nom);
handle=HS_popEStack();
if (*(unsigned char *)HToESI(handle)>VAR_Q_TAG) ST_helpMsg("variable système")
HeapFree(handle);
ONERR
ST_helpMsg("variable système")
ENDTRY


En effet, pourquoi faire compliqué (en risquant d'avoir des bugs et d'oublier de nombreux cas) alors qu'il y a deja un rom call qui fait tout d'un coup ?
Je trouve ça bizarre de la part de quelqu'un qui refuse le C++ pour les quelques octets en plus.
[edit]Edité par Nitro le 04-01-2002 à 01:12:28[/edit]

Je suis passé a l'AMS2.05, mais devant le nombre de programmes qui ne fonctionnait pas je suis revenu à mon MAS 2.03, il est super stable, je ne perd pas mes variables archivés, alors pour moi y'ap pas photo vive l'AMS2.03

> Kevin :
Pour les Applications-Flash, en effet c'est quasiment impossible de réussir à la faire signer, mais on peut quand même s'amuser à les tester sur l'émulateur (enfin c'est vraiment très limité ).
J'avais commencé à faire un programme d'étude de fonction en application Flash afin d'en avoir un intégré au TI-OS, mais j'ai vite dû abandonner ... (d'ailleurs j'ai perdu les sources, mais je les avais passées à quelqu'un il me semble )

Sinon, je trouve que l'aide PDF du SDK (pas celle du compilateur) est pas mal en ce qui concerne les formats de variables, l'architecture évènementielle du TI-OS ...
(Je parle des pages jusqu'à la 220, je les aies d'ailleurs imprimées ).

>Nitro:
>Et il y en a style ANSI dans la ROM, qui ne sont pas buggées comme celles de TIGCCLIB et qui prennent 0 octet en plus contrairement à celles de TIGCCLIB.

Le seul "bogue", c'est que les fonctions de TIGCCLIB allouent plus que nécessaire. Mais on va probablement remplacer ces fonctions par celles de Thibaut, qui n'ont pas ce problème et qui sinon sont 100% compatibles avec celles qui sont actuellement dans TIGCCLIB (sauf pour rename, pour lequel on va probablement garder l'ancien ou modifier celui de Thibaut).

>Pour le compilateur il me semblait avoir constaté le contraire...

Alors le compilateur du SDK doit optimiser beaucoup mieux que celui qu'ils ont utilisé pour compiler AMS, parce que ce dernier, c'est vraiment l'horreur! Et quand tu as fait la comparaison, c'était avec GCC 3.0.x? Parce qu'on utilise GCC 3.0.2 depuis un certain temps, alors qu'avant on utilisait GCC 2.95.x qui optimisait moins bien.

>Et pourquoi Sebastian perd du temps à écrire une lib de link alors que libticables de Romain Liévin marche tres bien et supporte tous les types de cables (meme le virtual link de VTI) et marche sous Windows et Linux ?

Parce qu'elle n'existait pas en DLL Win32 à ce moment, si je me rappelle bien.

>En effet, pourquoi faire compliqué (en risquant d'avoir des bugs et d'oublier de nombreux cas) alors qu'il y a deja un rom call qui fait tout d'un coup ?

Parce que ce ROM_CALL n'existe pas dans AMS 1. Mes propres programmes en assembleur marchent même sur TI-92+ AMS 1.00!

>Slubman:
>Je suis passé a l'AMS2.05, mais devant le nombre de programmes qui ne fonctionnait pas je suis revenu à mon MAS 2.03, il est super stable, je ne perd pas mes variables archivés, alors pour moi y'ap pas photo vive l'AMS2.03

Il est bon pour la poubelle AMS 2.03. AMS 1.05 marche encore mieux que ça (moins de bogues). Mais la meilleure version pour l'instant est AMS 2.05. Et pour les problèmes de compatibilité, à part DoorsOS et TeOS, je ne vois vraiment pas ce qui marcherait sur AMS 2.03 et pas sur AMS 2.05.

Et as-tu essayé ma fonction?
int isVarNameOK(char *varName)
{
volatile int result;
TRY
push_parse_text(varName);
handle=HS_popEStack();
result=(*(unsigned char *)HToESI(handle)<=VAR_Q_TAG);
HeapFree(handle);
ONERR
result=0;
ENDTRY
return result;
}
[edit]Edité par Kevin Kofler le 04-01-2002 à 18:39:05[/edit]

Moi je prefere TokenizeName(filename, sym_buf) qui me tokenize mon filename dans sym_buf et me renvoie FS_OK si il s'agit d'un nom de variable autorisé
Et jusqu'à present personne ne s'est plaint que ça ne marchait pas sur leur AMS, alors j'en conclue que tous ceux qui utilisent SIDE ont une version récente d'AMS...