TiLP/TiEmu: arrêt du développement - Page 6

YN : c'est pas compliqué
- K² a voulu supprimer le support VTI au profit de TIEMU en virant le support du premier, un fork a été créé pour maintenir le support de VTI => GCC4TI
- Roms arrête le dev de TILP et TIEMU parce que ses priorités ont changées
- K² tente de s'approprier le projet en s'autoproclamant nouveau mainteneur officiel en ./3
- Pour que ses années de travail ne soient pas perdues advitameternaem, Roms révoque les droits de K²
- K² décide de forker TILP et TIEMU pour pouvoir gérer ces projets à sa façon


Moralité, une scission (GCC4TI) a été créée pour contourner une manoeuvre sensée promouvoir un soft que l'équipe d'origine ne promeut plus (vu qu'il est maintenant question des forks de K²) mais à part ça il parait qu'il n'y a pas de raison apparente au désintérêt constaté pour la communauté TI68k (sachant que c'est pas le dev homebrew sur Nspire qui a pu les débaucher )

(sachant que c'est pas le dev homebrew sur Nspire qui a pu les débaucher )

Sisi... Il parait qu'il y a un DOOM en préparation sur Nspire ...



...
Ouais bon c'est un peu gros...

Kevin Kofler (./150) :
À peu près. Ils comptent aussi accepter d'autres patches qui dégradent la qualité du code. La divergence augmentera de plus en plus.

non, qui répondent aux demandes des utilisateurs.

Kevin Kofler (./150) :
il faut que je refasse une release.

lol

Kevin Kofler (./150) :
Je trouve que la documentation est claire, si tu as des améliorations à proposer, j'attends tes patches.

tu attends qu'un utilisateur qui tente de comprendre la doc t'envoie des patches pour améliorer la dite doc?

Yoshi Noir (./151) :
Emu-TIGCC ? C'est quoi ça encore ?
Je ne comprends plus rien avec tes forks... Avant c'était simple, on avait une IDE, et un ému, là j'ai l'impression que maintenant on a plusieurs versions et plusieurs noms pour des programmes identiques

bon, vince l'a expliqué. Quand on a un mec borné qui veut rien comprendre, l'open source permet de continuer quand même en se passant du mec borné.

contra: passera pas

* Si j'ai bien compris, GCC4TI est un fork de TIGCC qui remet le support de VTI ?

qui, entre autres, remet le support de VTI, en effet.
Cet élément de la todo list de GCC4TI n'est ni le déclencheur du fork (il s'est passé plus de 21 mois entre la suppression du support VTI et la création du fork), ni un des éléments principaux de la todo list ( http://trac.godzil.net/gcc4ti/report/1 ) - même si c'est un des plus visibles pour l'utilisateur.

* Quelle est la dernière version de TIGCC et quelles en sont les dernières features ?

La version 0.96 Beta 8, qui date du 31 octobre 2006...
GCC4TI 0.96 Beta 9 comprend tous les bugfixes de TIGCC CVS à la date du 3 janvier 2009, et plus de choses.

bon, vince l'a expliqué. Quand on a un mec borné qui veut rien comprendre, l'open source permet de continuer quand même en se passant du mec borné.

C'est en effet pour pouvoir implémenter des choses en lesquelles on est plusieurs à croire (avec des arguments techniques, en général), mais que Kevin trouve mauvaises (avec d'autres arguments techniques, en général), que GCC4TI a été créé.
Dans l'autre sens, Emu-TIGCC (fork de TIEmu) et CalcForgeLP (fork de TILP) ont été créé par un mec borné qui ne veut rien comprendre (cf. ./3) pour pouvoir continuer à faire le borné.


contra: bien essayé

Moi je dit Duke3D en 256 Couleur en préparation pour la nSpire, je peut meme dire qui c'est qui le fait

comprendra qui pourra

Il y a le port de GTools à terminer avant tout

vince (./151) :
Moralité, une scission (GCC4TI) a été créée pour contourner une manoeuvre sensée promouvoir un soft que l'équipe d'origine ne promeut plus (vu qu'il est maintenant question des forks de K²)

Emu-TIGCC fonctionnera avec TIGCC IDE sans modifications, et pour KTIGCC, il sera juste question de changer le nom de l'exécutable à lancer (TIGCC IDE regarde dans la registry, donc ce n'est pas nécessaire pour faire marcher TIGCC IDE), je vais faire ça dès la sortie de Emu-TIGCC (ou alternativement, je pourrais aussi mettre un symlink de /usr/bin/tiemu vers /usr/bin/emu-tigcc, c'est ce que Fedora fait pour cdrecord→wodim par exemple). Les interfaces IPC de Emu-TIGCC seront compatibles avec TiEmu (du moins au départ).

squalyl (./153) :
non, qui répondent aux demandes des utilisateurs.

Aux demandes naïves de certains utilisateurs qui n'ont pas compris pourquoi ces demandes sont de mauvaises idées. Ces modifications sont loin d'être demandées par la majorité des utilisateurs (juste par une petite minorité très vocale) et n'apportent aucun avantage réel en pratique (par exemple TiEmu, et Emu-TIGCC dans le futur, fait tout ce que VTI fait (sauf les bogues ) et plus).

Kevin Kofler (./150) :
il faut que je refasse une release.

lol

Bah, ce n'est pas drôle.

Kevin Kofler (./150) :
Je trouve que la documentation est claire, si tu as des améliorations à proposer, j'attends tes patches.

tu attends qu'un utilisateur qui tente de comprendre la doc t'envoie des patches pour améliorer la dite doc?

Il va bien finir par comprendre (en mettant qu'il ne soit pas totalement idiot ), et du coup il est le mieux placé pour améliorer la documentation parce qu'il saura exactement qu'est-ce qu'il aurait voulu comprendre dès le départ et n'a compris qu'après de longues recherches. Pour un développeur comme moi, tout est clair.

Quand on a un mec borné qui veut rien comprendre

Tu décris Lionel là?

l'open source permet de continuer quand même en se passant du mec borné.

… d'où la création de CalcForgeLP et Emu-TIGCC.

Combien d'utilisateurs t'ont demandé de retirer VTI ?

(quant à traiter Lionel de borné... au moins, il sait changer d'avis reconnaître publiquement quand il a tort, c'est loin d'être le cas de tout le monde, et surtout pas le tien)

Flanker (./158) :
Combien d'utilisateurs t'ont demandé de retirer VTI ?

Ce qui compte plutôt, c'est combien d'utilisateurs m'ont demandé de ne pas retirer VTI, et ils se comptent sur les doigts d'une main ou presque.

J'ai déjà expliqué plein de fois pourquoi le support pour VTI a été retiré et j'ai marre de le répéter, si tu souffre d'amnésies, je suis sûr qu'une recherche dans le forum pourra te rafraîchir la mémoire.

Si les développeurs ne faisaient que ce qui leur a été demandé par des utilisateurs, les projets n'iraient pas loin.

quant à traiter Lionel de borné...

Ce n'est pas moi qui ai commencé à insulter les gens ici (cf. ./153 et ./154).

au moins, il sait changer d'avis reconnaître publiquement quand il a tort

Ah bon? Quand? Il trouve toujours que ça a été bien pour la communauté de la couper en 2 en forkant TIGCC (avec Godzil).

Kevin Kofler (./159) :

Flanker (./158) :
Combien d'utilisateurs t'ont demandé de retirer VTI ?

Ce qui compte plutôt, c'est combien d'utilisateurs m'ont demandé de ne pas retirer VTI, et ils se comptent sur les doigts d'une main ou presque.

Soit à peu près autant que d'utilisateurs actifs de TIGCC

Kevin Kofler (./159) :
Si les développeurs ne faisaient que ce qui leur a été demandé par des utilisateurs, les projets n'iraient pas loin.

Alors la vie (la vraie, celle avec des vrais gens dedans) c'est pas que des 0 et des 1. En effet si les développeurs ne faisaient QUE ce qui leur est demandé par des utilisateurs, ça serait pas follichon, mais ça n'induit aucunnement qu'ils doivent faire absolument le contraire de ce qu'ils demandent. Et faire des évollutions que des utilisateurs n'ont pas demandés n'a Jamais impliqué de refuser celles que les utilisateurs demandent...

Tiens, le hasard veut que Jesse Keating vienne de poster le suivant sur la fedora-devel-list:

What users ask for is not always what they really want, often they just don't know of better alternatives. Instead of watching users gleefully bash a nail in using a round rock, you might instead teach them about a hammer and improve their life.

Comme quoi je ne suis pas le seul…

Nous sommes d'accord, ceux qui se contentent de ti-emu ne connaissent pas VTI... mais ceux qui connaissent VTI et qui préfèrent ?

(et ça te rassure de voir que tu n'es pas le seul intégriste, c'est ça ? )

Nous sommes d'accord, ceux qui se contentent de ti-emu ne connaissent pas VTI... mais ceux qui connaissent VTI et qui préfèrent ?

Voilà. Mais que veux-tu, il ne veut toujours pas comprendre ça, et continue à répandre des conneries à notre sujet... On ne le changera manifestement pas, malheureusement.

fedora-devel-list est le genre d'endroit que Kevin adore, puisqu'il est fréquenté par des gens qui pensent comme lui... mais en tant que ML d'une distro qui ne se soucie pas de la majorité des utilisateurs, ce n'est vraiment pas l'endroit où il faut aller chercher des opinions nuancées et pragmatiques sur le logiciel libre et la relation aux utilisateurs

Lionel Debroux (./164) :

Nous sommes d'accord, ceux qui se contentent de ti-emu ne connaissent pas VTI... mais ceux qui connaissent VTI et qui préfèrent ?

Voilà. Mais que veux-tu, il ne veut toujours pas comprendre ça, et continue à répandre des conneries à notre sujet...

Il n'y a rien à comprendre dans son troll, relis bien sa première phrase.

<SARCASM>C'est sûr que "se contenter" d'un logiciel beaucoup plus fonctionnel implique qu'on ne connaît pas l'autre… </SARCASM> N'importe quoi…

mais en tant que ML d'une distro qui ne se soucie pas de la majorité des utilisateurs

Hein?

Kevin Kofler (./165) :

mais en tant que ML d'une distro qui ne se soucie pas de la majorité des utilisateurs

Hein?

Tu vas bien finir par comprendre (en mettant que tu ne sois pas totalement idiot ), et du coup tu es le mieux placé pour améliorer l'explication parce que tu sauras exactement ce que qu'un développeur comme toi pour qui tout est clair n'avait pas compris. Pour le reste des gens, c'est clair que ton problème de chevilles ne s'est pas arrangé...

Kevin Kofler (./157) :
Aux demandes naïves de certains utilisateurs qui n'ont pas compris pourquoi ces demandes sont de mauvaises idées.

Ce n'est pas à toi d'en juger.

Kevin Kofler (./159) :
Si les développeurs ne faisaient que ce qui leur a été demandé par des utilisateurs, les projets n'iraient pas loin.

Rappelle toi qu'à la base un projet existe car il y a une demande d'utilisateurs, sans quoi le projet est inutile.
Ce qui gêne c'est de changer les buts du projet au milieu de son développement.
Quel est le but de tigcc?
faire ton propre soft pour toi tout seul dans ton coin, qui contient les features qui te plaisent et aucun autre?
ou faire une suite de développement pour ti68k accessible au plus grand nombre?
Je répondrai pas à ta place, je te laisse choisir et l'exprimer.
C'est la réponse à ces questions qui permet de prendre (oupa) une décision COMMUNE comme la suppression de vti.

Faire une suite de développement pour ti68k accessible au plus grand nombre, ce qui comporte entre autres un débogueur C, donc un émulateur sans débogueur C n'a aucun intérêt. Et tous les gens qui peuvent utiliser VTI peuvent aussi utiliser TiEmu (ou bientôt Emu-TIGCC, enfin presque: le dernier TiEmu nécessite un GTK+ à jour qui ne tourne plus sous 9x/Me/NT4, cette limitation sera héritée par Emu-TIGCC; mais de toute façon TIGCC lui-même va aussi laisser tomber ces OS obsolètes tôt ou tard, ils ne reçoivent plus de mises à jour même pour les trous de sécurité critiques et je ne vois pas pourquoi je devrais supporter des versions d'un OS que même l'entreprise qui le produit ne supporte plus), donc je ne vois pas en quoi ça réduit l'accessibilité de TIGCC de ne plus gérer VTI.

Mais tu n'arrives pas à comprendre qu'on ne VEUT pas utiliser TiEmu ????

Kevin Kofler (./169) :
donc un émulateur sans débogueur C n'a aucun intérêt.

pour toi

Kevin Kofler (./169) :
tous les gens qui peuvent utiliser VTI peuvent aussi utiliser TiEmu

sauf quand ils cherchent vti dans google, ou qu'un pote le leur passe.

Kevin Kofler (./169) :
pourquoi je devrais supporter des versions d'un OS que même l'entreprise qui le produit ne supporte plus

laisse tomber la ti68k alors, c'est encore supporté par TI ou pas?

Flanker (./169) :
Mais tu n'arrives pas à comprendre qu'on ne VEUT pas utiliser TiEmu ????

Non, c'est contraire à la raison. Sauf si tu veux dire que tu ne veux utiliser que Emu-TIGCC.

squalyl (./170) :

Kevin Kofler (./169) :
donc un émulateur sans débogueur C n'a aucun intérêt.

pour toi

Non, pour les utilisateurs pour lesquels TIGCC est conçu (développeurs C qui a priori ne connaissent pas l'assembleur, ou alors qui le connaissent, mais ont autre chose à faire que de débogueur du code C au niveau assembleur, ce qui, je t'assure, est absolument pénible, je l'ai fait quand TiEmu avec GDB n'était pas encore disponible).

Kevin Kofler (./169) :
tous les gens qui peuvent utiliser VTI peuvent aussi utiliser TiEmu

sauf quand ils cherchent vti dans google, ou qu'un pote le leur passe.

Les émulateurs ne s'excluent pas l'un l'autre, ils peuvent facilement installer TiEmu (ou bientôt Emu-TIGCC) en plus de VTI.

PS: TIFS nécessite aussi son propre émulateur avec débogueur C et ne gère pas VTI non plus, alors je ne vois pas pourquoi vous gueulez sur moi quand TIGCC fait pareil. Au moins TiEmu/Emu-TIGCC a toutes les fonctionnalités de VTI, ce qu'on ne peut pas dire de l'émulateur de TIFS!

Kevin Kofler (./171) :

Flanker (./169) :
Mais tu n'arrives pas à comprendre qu'on ne VEUT pas utiliser TiEmu ????

Non, c'est contraire à la raison.

Parce qu'utiliser un logiciel lourd (surtout vu les dépendances ) à la place d'un logiciel qui fait 2Mo qui ne m'apporte rien de plus (à part une interface que j'abhorre) n'est pas contraire à la raison ?

./165: c'est toi qui n'as compris ni ce que Flanker a écrit, ni ce que j'ai écrit (c'est une réponse à la deuxième partie de la citation de Flanker plus qu'à la première partie)

Ceux qui préfèrent VTI et connaissent ses bugs, ce qui est le cas de Flanker, devraient avoir le CHOIX de continuer à l'utiliser out of the box, comme ils ont pu le faire pendant des années. C'est ça qu'on essaie, depuis des années, de te faire comprendre.

Mais surtout que les bugs de VTI ne concernent pas ses utilisateurs dans 99,9999% des cas...

Kevin Kofler (./173) :
ont autre chose à faire que de débogueur du code C au niveau assembleur, ce qui, je t'assure, est absolument pénible, je l'ai fait quand TiEmu avec GDB n'était pas encore disponible

J'en ai rien a foutre de ton avis, on parle pas de toi kevin kofler centre de l'autriche mais bien de tous les autres.

Kevin Kofler (./173) :
Les émulateurs ne s'excluent pas l'un l'autre, ils peuvent facilement installer TiEmu (ou bientôt Emu-TIGCC) en plus de VTI.

1 tu te moques du monde car tu sais très bien que c'est TiEmu (ou bien TiEmu-fork aka Emu-tigcc (ça émule tigcc? ))
2 si tu oses dire "en plus de vti" pourquoi n'est il plus supporté?
tu es bourré d'incohérences.

Kevin Kofler (./174) :
alors je ne vois pas pourquoi vous gueulez sur moi quand TIGCC fait pareil.

parce qu'il pourrait etre moins con que TIFS. Tu t'alignes sur le pire pour te justifier? non mais quel troll je te jure

tu es bourré d'incohérences.

Tu t'alignes sur le pire pour te justifier? non mais quel troll je te jure

Business as usual with Kevin...


Bon... on arrête de discuter avec lui et on laisse ce topic comme témoignage - un de plus - de son égocentrisme, de son incapacité à coopérer, de son incapacité à admettre que d'autres gens peuvent penser autrement que lui, et autres comportements de sa part incompatibles avec une gestion sensée de projets ouverts ?

Flanker (./174) :
Parce qu'utiliser un logiciel lourd (surtout vu les dépendances ) à la place d'un logiciel qui fait 2Mo qui ne m'apporte rien de plus (à part une interface que j'abhorre) n'est pas contraire à la raison ?

Ça fait longtemps qu'il y a une interface "une seule grosse fenêtre" style VTI pour le débogueur. (Enfin, il y a aussi la Source Window de Insight, mais les autres fenêtres d'Insight sont cachées par défaut.)

Flanker (./176) :
Mais surtout que les bugs de VTI ne concernent pas ses utilisateurs dans 99,9999% des cas...

Euh si, je t'assure qu'ils concernent beaucoup plus que 0,0001% des utilisateurs. Peut-être pas toi, mais tu n'es pas le centre du monde.

squalyl (./177) :

Kevin Kofler (./173) :
ont autre chose à faire que de débogueur du code C au niveau assembleur, ce qui, je t'assure, est absolument pénible, je l'ai fait quand TiEmu avec GDB n'était pas encore disponible

J'en ai rien a foutre de ton avis, on parle pas de toi kevin kofler centre de l'autriche mais bien de tous les autres.

Ce n'est pas un avis personnel, c'est un fait appuyé entre autre par mon expérience personnelle (qui prouve que je ne parle pas sans savoir).

As-tu déjà essayé de déboguer un programme C avec le débogueur de VTI? Non? Alors comment veux-tu savoir à quel point c'est pénible?

Vas-tu sérieusement nous prétendre que:
1. envoyer le programme à la main (parce que si tu cliques sur Run dans l'IDE de GCC4TI ou une version obsolète de TIGCC IDE qui utilise VTI, il est lancé directement sans breakpoint et tu n'as souvent aucune chance de bloquer VTI avant que ça plante),
2. mettre un Program Entry Breakpoint à la main (en espérant que tu utilises un AMS <= 1.05 pour la version de Rusty ou <= 2.09 pour la version modifiée et boguée de JM, parce que sinon ça ne marche pas),
3. lancer le programme à la main,
4. sauter le code de démarrage à la main, en cherchant péniblement à trouver le saut vers _main, VTI ne te donnant aucune information de quel saut il s'agit (il y a d'autres bsr dans le code de démarrage, par exemple pour les relogements en des formats compressés),
5. faire du single step en, pour chaque instruction C:
5.1. regardant les commentaires dans le fichier .s produit par GCC qui donnent les lignes C correspondantes (commentaires qui d'ailleurs ne sont plus générés par les versions récentes de TIGCC, et GCC4TI ne les a pas réintroduits, donc tu n'as même plus cette information!)
5.2. sautant à la main les instructions assembleur correspondantes à l'instruction C
6. vérifier les valeurs des variables en essayant de comprendre à partir de la source assembleur dans quel registre ou emplacement mémoire elles se trouvent
est plus simple que:
1. cliquer sur Debug / Run et avoir le programme automatiquement lancé et arrêté au début du code de démarrage
2. rien (tout est automatique)
3. rien (tout est automatique)
4. cliquer sur Continue pour sauter le code de démarrage
5. faire du single step en utilisant les boutons Step et Next de Insight (ou les raccourcis s et n)
6. vérifier les valeurs des variables en les lisant directement dans Insight (par exemple en passant la souris au dessus de la variable dans la source)
??? Arrête de raconter n'importe quoi!

1 tu te moques du monde car tu sais très bien que c'est TiEmu (ou bien TiEmu-fork aka Emu-tigcc (ça émule tigcc? ))

Emu-TIGCC = émulateur de (faisant partie de) TIGCC ou émulateur pour (à utiliser avec) TIGCC. Pour moi, l'émulateur et son débogueur niveau sources intégré font partie intégrante de la chaîne d'outils, d'où ce nom.

2 si tu oses dire "en plus de vti" pourquoi n'est il plus supporté?

L'utilisateur peut garder VTI à côté si ça l'amuse, mais TIGCC utilisera TiEmu ou Emu-TIGCC. C'est une dépendance comme une autre. A priori, les fonctionnalités proposées à l'utilisateur, c'est la possibilité de tester et déboguer ses programmes sur son ordinateur, l'émulateur utilisé en interne pour proposer ces fonctionnalités est un choix d'implémentation qui ne regarde que le développeur. Et donc de ce point de vue-là, TiEmu/Emu-TIGCC permet de proposer beaucoup plus de fonctionnalités que VTI (débogueur C!) et aucune fonctionnalité en moins, donc quel intérêt de proposer les deux?

Pourquoi t'obstines-tu à ignorer les arguments solides pour laisser tomber le dinosaure qu'est VTI et à nous ressortir sans arrêt le même FUD? L'utilisateur ne perd aucune fonctionnalité en passant du couple (vieux TIGCC, VTI) au couple (nouveau TIGCC, TiEmu ou Emu-TIGCC).

parce qu'il pourrait etre moins con que TIFS.

Le choix de TIFS n'est pas con, il est logique: pour proposer un débogage convenable, il faut un émulateur conçu pour la chaîne d'outils, l'émulateur en fait donc partie intégrante. D'où l'émulateur livré avec TIFS et d'où Emu-TIGCC (avec "TIGCC" dans le nom). On ne peut pas gérer n'importe quel vieil émulateur que tu nous sors.

tu aurais tu plutot les nommer

KevinEmu
KevinLP
KevinGcc

Kevin Kofler (./179) :
L'utilisateur ne perd aucune fonctionnalité en passant du couple (vieux TIGCC, VTI) au couple (nouveau TIGCC, TiEmu ou Emu-TIGCC).

Si l'utilisateur Windows (aka au moins 90% des (ex) utilisateurs de tigcc) n'ont plus un soft utilisant une IHM NATIVE, Legere, et j'en passe