Bug ou pas bug? - Page 2

paxal> heu ?

Faut dire que ma routine était utile car sur TI-92 y a pas beaucoup de ROM_CALL.

Kevin : tu sais que sprintf est plus lente. Si tu voulais être objectif, tu dirais "si tu n'as pas besoin de vitesse, utilise sprintf car elle n'est pas boguée et ne prend pas de place dans ton prog"

C'était la leçon numéro 1 du Manuel du Petit Kevin Sympa

Certes mais penses auissi a consulter le manuel du Gentil petit Thibault de temps en temps aussi alors.

lol

le fait est que uther n'a pas tord, ma foi...

C'est bizarre que quand thibaut ce pointe, le topic deviennent hors sujet.

Uther Lightbringer : j'y veillerais. Mais là, j'ai eu du mal à laisser passer cet acte de propagande de plus

bah on peut pas considérer ca comme un acte de propagande puise que Kevin(jusqu'a preuve du contraire) n'a pas programmé les romcalls.

Je ne te suis pas là. Pas besoin d'être auteur pour faire de la propagande sur un concept !?

Il a parlé de sprintf comme si elle était préférable de tous les points de vue. Tu n'as pas l'air au courant que Kevin a l'habitude de faire passer l'optimisation mémoire pour la meilleur optimisation. Il oublie que c'est vrai pour lui, pour ses programmes qui n'ont pas besoin de vitesse, mais que d'autres gens programment des choses devant être très rapides, et que conseiller ses propres solutions à ces gens en sachant qu'il a tort, c'est de la propagande pour ses petites idées.

Enfin, je le vois comme ça. D'où ma réaction à son post.

Uther > je vois pas le rapport, il peut bien faire toute la propagande qu'il veut meme si c pas pour son truc..

Si c'est un sprintf simple, du style sprintf(string,"%hu",number), number étant un unsigned short, des routines beaucoup plus rapides vont être ajoutées à TIGCCLIB. Quand je dis "beaucoup plus rapides", c'est plus de 10 fois que sprintf pour certaines.
Il faut d'ailleurs que je modifie les routines en base 10, parce que j'ai fait une énormité, au niveau taille comme vitesse.

Et évidemment, les routines décrites ci-dessus ne vont pas pour sprintf(string,"%hu ",number) (pas un itoa simple, quoi)...

Thibaut a écrit :
Kevin : tu sais que sprintf est plus lente. Si tu voulais être objectif, tu dirais "si tu n'as pas besoin de vitesse, utilise sprintf car elle n'est pas boguée et ne prend pas de place dans ton prog"

N'importe quoi! Je ne vais quand-même pas lui conseiller de garder une routine boguée alors qu'il y en a une dans AMS qui fait la même chose sans les bogues (vitesse ou pas vitesse, peu importe)!

geogeo a écrit :
Faut dire que ma routine était utile car sur TI-92 y a pas beaucoup de ROM_CALL.

Extrait du tios.h de Fargo:

;----------------------------------------------------------------------------
; int sprintf(char *buffer, char *format[, argument, ...])
;
; Function: Uses {format} as a template to output a string to {buffer},
;           substituting arguments when '%' is found in {format}.
;
; Return: D0.W = number of bytes output
;
; For an explanation of format specifiers, please see a reference on the
; C programming language.
;----------------------------------------------------------------------------
tios::sprintf			equ	tios@000F

Pour les améliorations des routines, je n'ai pas le temps de m'y mettre franchement avant fin juin...

> vitesse ou pas vitesse, peu importe
comrpendra-t-il un jour que la vitesse n'a jamais d'importance que pour lui

non.

enfin faut optimiser pour la vitesse juste dans les routines critiques, sinon c une perte de temps

enfin rmq y'a pas que lui qiu pense ça : dans le black book, M. Abrash s'etonne que dans un sondage (ac des reponses libres je crois), la vitesse d'execution n'apparait [pour ainsi dire ? (ma memoire me fait defaut)] pas.

> non. #crayon#
Gardons espoir.

> enfin faut optimiser pour la vitesse juste dans les routines critiques, sinon c une perte de temps
Ouai Quand je n'ai pas besoin d'optimiser pour la vitesse, j'essaie d'optimiser en taille généralement.

Sinon, attention, Monsieur A. s'intéressait aux PC. La situation sur TI n'a rien à voir !

justement : sur ti la place est encore plus critique que sur PC. sur PC ca fait longtemps que les développeurs ne ce soucient gère de l'espace disque.

C'est ce que j'ai dit

Thibaut a écrit :
> non. #crayon#
Gardons espoir.

lol

> enfin faut optimiser pour la vitesse juste dans les routines critiques, sinon c une perte de temps
Ouai Quand je n'ai pas besoin d'optimiser pour la vitesse, j'essaie d'optimiser en taille généralement.

Sinon, attention, Monsieur A. s'intéressait aux PC. La situation sur TI n'a rien à voir !

ben si un peu qd meme, vu les pc de l'epoque.
et de toutes façons, le principe de pas perdre son temps à optimiser en vitesse n'importe quoi reste universel.

Thibaut a écrit :
C'est ce que j'ai dit

ben oué :]

Quelle probleme peut etre a l'origine d'une erreur de compilation de ce type:

INCLUDE file cannot be opened

Alors que le fichier existe, n'est pas buggé...
Le fichier en question contient des/un sous-programme(s) uniquement. Tout se compile bien lorsque ces sous-programmes sont inclus dans le ficher principal.

Depuis toujours je mets plein de fichiers include pour alleger le fichier principal et normalement il n'y a aucun probleme.

PS: Ca m'est deja arrivé jadis parce que le fichier include terminait par des données (du type info dc.b 0) et le total de la taille prise par ces données etait impaire.

Tu assembles tes sources comment? Avec TIGCC IDE? Avec tigcc.exe? Ou directement avec a68k.exe?

Directement avec a68k.exe

Apparement, c'est la faute du fichier included car le meme probleme intervient quand j'essaye de l'inclure a un programme qui fonctionne parfaitement.

Le fichier existe, mais est-il placé dans le bon répertoire (c'est-à-dire le même que le fichier .asm ou un des répertoires donnés en -i)?

Mauvaise nouvelle:
Le bug ne depend pas du contenu du fichier a inclure: que le fichier contienne du code ou des conneries, le compilateur dit exactement la meme chose.
Ca m'etonnerait que le nom des sous-programmes ou du fichier soit la cause du bug.

Donc, je n'ai STRICTEMENT AUCUNE idée pour resoudre le probleme.

Post croisé:
Oui le repertoire existe, ca fait longtemps que j'inclus de nombreux fichier donc le probleme ne vient pas de la.