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

Ah ? A68k m'envoyait chier dans ce cas il me semble...

Je reviens juste à ça, après vous pouvez continuer à vous étriper ^^

Brunni (./149) :
Bon alors sur ce point je ne suis pas d'accord. C'est précisément pour cette raison que je n'utilise pas Eclipse pour le dév amateur par exemple, impossible de créer un projet dans un dossier qui a déjà des fichiers (p. ex. téléchargé sur le net ou fait avec un autre IDE).

Je pensais ça aussi, mais ça n'est pas le cas. Tu peux très bien ouvrir des fichiers qui ne seront dans aucun projets et pas dans le workspace, travailler dessus comme avec n'importe quel éditeur et bénéficier des avantage d'Eclipse "hors projet". Tu peux aussi inclure à un projet des fichiers déjà créés.
Après, tu as toujours intérêt à utiliser la syntaxe de commentaires utilisée pour l'aide (phpDocumentor, javaDoc...), ça permet vraiment d'utiliser l'IDE à fond, mais ça n'est pas non plus obligatoire.
Il y a une seule chose qu'Eclipse se sait pas faire (et encore, faut que je vois, ça a dû être rajouté dans la v.2), c'est la sélection par blocs et pas par lignes (indispensable quand on bosse avec de gros tableaux ou qu'on doit faire des tests avec des extractions de données).

Bug report pour TIGCC et GCC4TI: si on active -Wstrict-prototypes, gcc se plaint de la ligne 407 du header default.h (inclus par virtuellement tous les autres headers):
[code]extern float __BC()__ATTR_LIB_ASM__;[/code]

-Wstrict-prototypes n'est pas supporté.

Le prototype de __BC() est comme ça exprès, c'est le fonctionnement de cette fonction interne qui le veut.

problème réglé pour tigcc

Le prototype de __BC() est comme ça exprès, c'est le fonctionnement de cette fonction interne qui le veut.

Ca, j'avais compris en lisant les deux lignes qui suivent celle dont le compilo se plaint.
[code]#define _tios_float_1(f,x,t) ({typedef float(*__temp__type__)(short,t)__ATTR_LIB_ASM__;((__temp__type__)__BC)(4*0x##f,x);})

#define _tios_float_2(f,x,y,t1,t2) ({typedef float(*__temp__type__)(short,t1,t2)__ATTR_LIB_ASM__;((__temp__type__)__BC)(4*0x##f,x,y);})[/code]
On y remarque que __BC() prend toujours au moins un short en paramètre.

problème réglé pour tigcc

En effet

Hmmm, il serait peut-être possible de le déclarer __BC(short,...) au lieu de __BC().

Bravo, tu viens d'arriver à la conclusion à laquelle j'étais arrivé il y a quelques heures
Oui, le compilo est content si on met "short,..." à l'intérieur des parenthèses. Et ca devrait fonctionner pareil que si on ne les met pas, vu le code assembleur produit pour l'appel des fonctions varargs de la famille printf.

Kevin, FYI, l'erreur DBUS (qui persiste et qui signe) se produit après que KTIGCC ait envoyé ses données à TiEmu : Fichier joint : (dbus.png)

Vive DBUS !

A mon avis, c'est plus KTIGCC ou TIEmu que D-Bus

J'ai corrigé (r1362) ce que j'ai reporté il y a un certain temps en ./213.
Vive la réécriture d'historique: j'ai fait hier soir en local un commit, pour sauvegarder un état que je pensais être stable, et aujourd'hui, après davantage de tests et de modifs, je l'ai découpé en deux pour plus de clarté.

C'est un bogue à l'intérieur de TiEmu, ce n'est pas un problème de communication (ça se produit de même avec OLE et DCOP, c'est juste le message d'erreur générique de TIGCC IDE / KTIGCC qui ne distingue pas).