GTC : un TIGCC sur votre calculatrice ? - Page 79

Godzil :
On ne se plaint pas derriere son dos !!
Tu es le seul représentant de la tigccteam sur ce forum tu as donc comme obligation de reporter ce genre de plainte

Non, c'est toi qui as l'obligation de te plaindre directement chez le responsable. Il y a un formulaire de bug report, nous n'avons aucune obligation de corriger quoi que ce soit qui n'a pas été reporté à travers le formulaire.


Et encore une fois: C'est Sebastian qui a fait ce choix, pas moi, et il a donné les raisons sur notre forum (section TIGCC Programming du forum de la TICT), il suffit d'aller le lire. Je vous ai déjà donné mon avis personnel (je trouve que c'est un excellent feature), je ne vois pas ce que vous attendez de plus de moi.

vince
: d'abord en faisant passer lesdits bugs pour des changements volontaires, des "features"

Parce que ce sont des changements volontaires! C'est vous qui ne les aimez pas, mais ce ne sont pas des bogues pour autant!

puis ensuite en rportant la responsabilité sur d'autres membres de la team, bien entendu en leur absence, ils pouraient se défendre...

Parce que je n'ai strictement rien décidé à ce sujet. Sebastian a inventé le système de répertoires virtuels. Moi, je n'ai qu'admiré le résultat et dit "excellent", parce que je le trouve vraiment (donc ce n'est pas sur moi qu'il faudra compter pour que ce soit changé). Mais c'est Sebastian qui a fait tout le design. J'ai marre de voir toutes les plaintes au sujet de TIGCC adressés à moi personnellement sur un forum et pas à toute l'équipe à travers le formulaire prévu pour.

Kevin Kofler
: Non, c'est toi qui as l'obligation de te plaindre directement chez le responsable.

genre...

Parce que ce sont des changements volontaires! C'est vous qui ne les aimez pas, mais ce ne sont pas des bogues pour autant!

le fait de parfois zapper des labels locaux, c'est aussi une feature ??? la meilleure preuve que c'est un bug, c'est que tu ne peux pas prouver que tigcc marche bien, maintenant

Flanker
:

Parce que ce sont des changements volontaires! C'est vous qui ne les aimez pas, mais ce ne sont pas des bogues pour autant!

le fait de parfois zapper des labels locaux, c'est aussi une feature ???

"parfois zapper des labels locaux"? Tu veux dire quoi?

tu le sais très bien, je te l'ai signalé comme bug, mais tu m'as dit que c'était une "user error"

Et ben, sache que ce problème (je refuse toujours de l'appeler "bogue" parce que c'est toi qui n'avais pas lu la documentation) est maintenant corrigé: le switch nécessaire est maintenant passé automatiquement pour que les crétins qui n'ont pas lu la documentation arrêtent de nous reporter un "bogue" qui n'en est pas un.

Donc arrête de te plaindre d'un "bogue" qui n'est plus!

Et on a bien appris notre leçon: toujours tout faire automatiquement, parce que les utilisateurs sont des ânes. Après, il ne faudra pas vous plaindre que vous avez du code de démarrage (SET_FILE_IN_USE_BIT et consortes) rajouté automatiquement...

la meilleure preuve que c'est un bug, c'est que tu ne peux pas prouver que tigcc marche bien, maintenant

quand je parle de prouver, c'est une vraie preuve, avec Coq ou un truc du même genre

Parce que ce sont des changements volontaires! C'est vous qui ne les aimez pas, mais ce ne sont pas des bogues pour autant!

changements volontaires qui ne font pas partie de l'offre de version, c'est bien ça ?... on t'adore Kevin ^^

Flanker
:

la meilleure preuve que c'est un bug, c'est que tu ne peux pas prouver que tigcc marche bien, maintenant

quand je parle de prouver, c'est une vraie preuve, avec Coq ou un truc du même genre

Coq? COCORICO!

Plus sérieusement, les labels locaux sont maintenant émis par l'assembleur (on met automatiquement le switch qui active ça), et donc le linker sait qu'il n'a pas le droit de faire n'importe quoi. Ça a été dit et redit, mais évidemment tu préfères ne pas écouter parce que tu es parti dans une croisade anti-TIGCC. Il vous donne quoi en échange, Pollux?

vince
:

Parce que ce sont des changements volontaires! C'est vous qui ne les aimez pas, mais ce ne sont pas des bogues pour autant!

changements volontaires qui ne font pas partie de l'offre de version, c'est bien ça ?... on t'adore Kevin ^^

"L'offre de version"?

bah oui, celle qui précède le bordereau de livraison (qui aboutit au final au "changes.txt")...

Kevin Kofler
:

Godzil :
On ne se plaint pas derriere son dos !!
Tu es le seul représentant de la tigccteam sur ce forum tu as donc comme obligation de reporter ce genre de plainte

Non, c'est toi qui as l'obligation de te plaindre directement chez le responsable. Il y a un formulaire de bug report, nous n'avons aucune obligation de corriger quoi que ce soit qui n'a pas été reporté à travers le formulaire.

Et encore une fois: C'est Sebastian qui a fait ce choix, pas moi, et il a donné les raisons sur notre forum (section TIGCC Programming du forum de la TICT), il suffit d'aller le lire. Je vous ai déjà donné mon avis personnel (je trouve que c'est un excellent feature), je ne vois pas ce que vous attendez de plus de moi.

Donc tu (vous) faites partit des gens qui disent "ON fait qq chose, tant pis si les autres aiment pas on s'en branle ça nous plait a nous"

Ok noté.

Je te le ressortirait a l'occasion si tu fait qq chose qui te plait pas


non mais n'importe quoi..

Kevin Kofler :
Il vous donne quoi en échange, Pollux?

Il est beaucoup moins antipathique que toi, c'est déjà pas mal.

Je préciseriat meme qu'il nous donne strictement rien, mais LUI il ecoute les avis des gens et il fait les choses si c'est realisable, bref, il est a l'attente de son publique

Godzil
:

Kevin Kofler
:

Godzil :
On ne se plaint pas derriere son dos !!
Tu es le seul représentant de la tigccteam sur ce forum tu as donc comme obligation de reporter ce genre de plainte

Non, c'est toi qui as l'obligation de te plaindre directement chez le responsable. Il y a un formulaire de bug report, nous n'avons aucune obligation de corriger quoi que ce soit qui n'a pas été reporté à travers le formulaire.

Et encore une fois: C'est Sebastian qui a fait ce choix, pas moi, et il a donné les raisons sur notre forum (section TIGCC Programming du forum de la TICT), il suffit d'aller le lire. Je vous ai déjà donné mon avis personnel (je trouve que c'est un excellent feature), je ne vois pas ce que vous attendez de plus de moi.

Donc tu (vous) faites partit des gens qui disent "ON fait qq chose, tant pis si les autres aiment pas on s'en branle ça nous plait a nous"

Ok noté.

Je te le ressortirait a l'occasion si tu fait qq chose qui te plait pas


non mais n'importe quoi..

quand c'est les autres qui codent, ils doivent se torturer pour faire ce que l'utilisateur veut (et pas coder en tant que simple hobby, c'est utopique) quand c'est tigccteam qui code, le process est on ne peut plus flou, cette lacune est masquée par un volume important (trop ?) de livraisons de versions, indépendament des doléances des tigcc-users...

Bref, la tigccteam marche exactement comme les startups a la mauvaise epoque..

On fait qq chose, super génial, mais ya aucun marché pour ça..

Faut etre a l'écoute du marché !!

Un programme qui n'est pas buggué peut être prouvé, non ? J'ai dit Coq, mais j'aurai pu également dire Simplify (je sais pas trop comment ça s'écrit) et je sais qu'il y en a encore d'autres

je suis d'ailleurs surpris qu'avec sa rigueur (qui est tout à son honneur) Kevin n'ait pas appliqué de process ISO9001 (allégé) aux livraisons de tigcc...

huhu flanker ^^


edit (pasque crosse avec vince) : huhu vince

je viens d'avoir un séminaire d'un chercheur qui est en train de prouver son compilateur ^^
il a dit entre autres que le compilateur pouvait générer différents binaires suivant les switchs, mais que les binaires devaient toujours donner le même résultat avec les mêmes entrées (aux fonctions random près, pour les coupeurs de cheveux en 4)

#2358²

Flanker :
je viens d'avoir un séminaire d'un chercheur qui est en train de prouver son compilateur ^^ il a dit entre autres que le compilateur pouvait générer différents binaires suivant les switchs, mais que les binaires devaient toujours donner le même résultat avec les mêmes entrées (aux fonctions random près, pour les coupeurs de cheveux en 4)

(cf un article de MSDN sur la MFC qui traitait des méthodes de compilation et des résultats...)

vince
: bah oui, celle qui précède le bordereau de livraison (qui aboutit au final au "changes.txt")...

http://tigcc.ticalc.org/doc/ide.html#history
* Added support for virtual folders used when compiling programs.

a été dit et redit, mais évidemment tu préfères ne pas écouter parce que tu es parti dans une croisade anti-TIGCC. Il vous donne quoi en échange, Pollux?

tu n'arrives toujours pas à raisonner autrement qu'en termes de conflits ? Si on te reproche un bug, ça y est, c'est la guerre.... Si j'étais tant anti-tigcc, j'utiliserais GTC. Je ne suis pas du genre à critiquer Microsoft tout en continuant à utiliser leurs produits

Godzil
: On fait qq chose, super génial, mais ya aucun marché pour ça..

Si, le feature a été bien accueilli sur notre forum. Il n'y a que vous qui râlez sans arrêt!

Flanker :
je viens d'avoir un séminaire d'un chercheur qui est en train de prouver son compilateur ^^ il a dit entre autres que le compilateur pouvait générer différents binaires suivant les switchs, mais que les binaires devaient toujours donner le même résultat avec les mêmes entrées (aux fonctions random près, pour les coupeurs de cheveux en 4)

C'est absurde... Si un programme bogué dépend de trucs comme la valeur des variables non-initialisées, n'importe quel switch peut changer son comportement!

C'est absurde... Si un programme bogué dépend de trucs comme la valeur des variables non-initialisées, n'importe quel switch peut changer son comportement!

aux fonctions random près

mais heureusement que M Kevin Kofler est là pour corriger les chercheurs français

Écoute, ce n'est pas que moi qui dis que l'idée d'optimiser sans changer le sens de n'importe quel programme est absurde, mais aussi à peu près tous les mainteneurs de GCC. Ça a été souvent discuté, regarde les archives. Un programme bogué qui est cassé par une optimisation n'est pas une "fonction random".

Et un programme non buggué ?

et là encore ça dépends de la définition de "buggé" parcque bon c'est pas universel...

et comme tout ce qui viens de saint www.fsf.org, saint www.gnu.org, saint www.slashdot.org et saint www.rms.org est bénie des dieux et sans equivoque particuliere, kevin a tout a fait raison...