kdewin foutage de geule - Page 6

squalyl (./148) :
Faux, faux et refaux, on peut faire:
-des options par défaut attachées au compilateur-des projets template pour définir des options par défaut pour chaque nouveau projet créé

Alors fais-le, parce que sinon ton template est limite inutilisable.

tu attaques sans savoir, as tu au moins touché une fois CodeBlocks?

Oui, et c'était bogué à fond, on dirait que c'est un lieu commun des logiciels utilisant wxGTK...

parce qu'il est un peu obsolète et que tu ne veux entendre aucune plainte de tes utilisateurs? On va pas répéter hein...

Obsolète, tu rigoles? Je ne vois rien d'obsolète.
Et il n'est pas vrai que je ne veux entendre aucune plainte de mes utilisateurs, le problème est que vos suggestions demandent des modifications radicales à la structure des EDIs:
* que je n'ai pas le temps de faire maintenant, surtout que je dois d'abord finir KTIGCC 2 (version KDE 4) et ensuite faire la version 3 multiplateforme,
* que je ne peux pas rajouter avant KTIGCC 3 parce que sinon je devrais le coder 2 fois, dont une fois avec un outil de développement auquel je n'ai pas accès (Delphi). (Mais évidemment, si tu es volontaire pour maintenir l'EDI en Delphi jusqu'à ce que KTIGCC 3 soit prêt, on pourra en reparler.)

Qu'est ce que c'est que ce truc de filer une DLL comme binaire?

C'est l'interface utilisée par TIGCC IDE et le tigcc.exe en Delphi, je ne vais pas livrer un exécutable utilisé nulle part! Mais il est fort probable qu'il y aura un ld-tigcc.exe avec KTIGCC 3.

Tu veux pas mettre gcc en DLL tant que t'y es?

Impossible parce que GCC ne libère pas ses allocations, ça leakerait de la mémoire comme pas possible.

Et puis je pensais que tu pestais contre le DLL Hell, comment oses tu y participer?

Ce n'est pas une DLL partagée, ça n'a strictement rien à voir avec du DLL Hell. La seule raison pourquoi c'est une DLL est qu'on ne peut pas statiquement linker du C dans du Delphi.

C'est de plus une manipulation pour nous obliger à utiliser tigcc.exe

Je ne vois pas du tout pourquoi tu veux contourner tigcc.exe à part pour être lourd. tigcc.exe est l'interface documentée, qui continuera à fonctionner même si la chaîne d'outils utilisée en interne change (comme ça a été le cas plusieurs fois dans le passé, on a eu 3 générations de systèmes de linking avant ld-tigcc: link.exe tout seul, GNU ld + link.exe, GNU ld + obj2ti). Et tigcc.exe est dans le PATH système, les outils utilisés en interne ne le sont pas.

et en plus, pourquoi l'option tigcc -ar n'est pas documentée dans tigcc --help? J'ai du observer la sortie de tprbuilder pour deviner cette option!

Je vais voir ce que je peux faire pour tigcc --help dans la version -W32 (la version *nix documente -ar dans tigcc --help, vois-tu maintenant pourquoi je veux me débarasser de toute cette duplication de code?), mais l'option est documentée dans http://tigcc.ticalc.org/doc/comopts.html#SEC3.

Lionel Debroux (./150) :
Mais quand je change de demo (ce que j'ai fait très souvent, ces temps-ci, avec l'augmentation de la couverture de tests), je vais prendre le temps de créer 33 projets pour les demos, alors que ces projets ne contiennent chacun qu'un fichier, que toutes les demos sont compilé avec les mêmes options, etc. ? Ouais, bien sûr

Ben franchement, je ne vois pas pourquoi pas... Tous les 67 exemples de TIGCC ont un fichier .tpr correspondant, et ils sont tous composés d'un seul fichier .c chacun eux aussi.

Il faudrait tout simplement une gestion de groupes de projets.

C'est pas faux, mais ça ne ferait que contourner une grosse limitation de l'outil et ses projets brain-dead qui sont incapables de compiler certains fichiers avec des options différentes (ce dont est capable Code::Blocks). C'est pas une solution à la cause racine du problème

Ce n'est pas du tout le même problème! Compiler avec des options différentes ne va pas magiquement te permettre de compiler plusieurs targets en même temps (par exemple plusieurs démos dans un exécutable séparé chacune), seul un groupe de projets avec un projet pour chaque target peut faire ça.

Solution évidente: arrêter de compiler tout avec des options différentes, TI-Chess compile très bien avec -Os par tout.

Solution évidente... et fausse. Mais tu ne peux manifestement pas comprendre.

Tu ne veux pas faire le moindre sacrifice pour t'adapter aux outils, c'est ça le problème, et c'est bien dommage parce que tu perds tous les avantages de ces outils seulement parce que tu ne peux pas accepter une petite limitation qui n'a aucune importance en pratique.

Solution évidente: rendre les programmes compatibles on-calc.

Solution évidente... et fausse. Antinomique avec le but de solution précédente, aussi. Tes contradictions, comme d'habitude

Tu n'as toujours pas compris que c'est une considération qui n'a strictement rien à voir avec l'optimisation!

Optimisation = gagner en taille ou en temps sans changer les fonctionnalités du programme!

Là, il s'agit de rajouter une fonctionnalité, la possibilité d'exécuter le même programme sur des calculatrices différentes, et il est évident que ça prend de la place, comme n'importe quelle autre fonctionnalité! Avec le concept d'"optimisation" que tu défends là, il faudrait faire tous les jeux en blanc et noir parce que les sprites prennent 2 fois moins de place qu'en niveaux de gris, donc les niveaux de gris ne sont pas du tout "optimisés".

C'est fou qu'avec le nombre de fois que j'essaie te t'expliquer ça, ce ne soit toujours pas rentré!

Solution évidente: faire de la langue un choix en temps d'exécution, pas de compilation (cf. réponse précédente).

Solution évidente... et fausse. Antinomique avec l'optimisation taille. Voir réponse précédente.

"Antinomie" totalement imaginaire. Voir réponse précédente.

Je parle que je compile certains projets avec tprbuilder dans mon terminal, j'ai besoin de cette option -v, parce que sinon je n'ai pas les stats. Et si je veux compiler le même projet, sans me faire ch*** à le modifier à chaque fois, dans KTIGCC, je ne peux pas parce que ton truc d'arrête avant de linker parce qu'il croit que la compilation a généré tout plein d'erreurs.

C'est normal, rajouter -v aux options du compilateur est un hack que je n'avais pas du tout prévu, et c'est absolument la mauvaise solution, pourquoi n'appelles-tu pas tprbuilder avec l'option -v tout simplement?

Faut-il vraiment que je me mette à sortir des erreurs pour tout ce qui n'était pas prévu? Je n'ai vraiment pas envie de me mettre à valider les options de GCC définies dans le .tpr, mais si vous y mettez tout et n'importe quoi, vous allez m'y obliger.

Kevin Kofler (./151) :
t'adapter aux outils

C'est la réplique typique des templiers du libre... Ca explique bien pourquoi si peu de gens passent au libre vu qu'ils devront faire l'effort au lieu du contraire...

Cela dit c'est "possible" de s'y adapter, et après ça donne les fanas du libre qu'on connaît.
Le problème à mon sens, c'est que comme dans l'absolu il faut se dénuer (ou biaiser) du sens de l'ergonomie et de la cohérence pour "rentrer dans le moule", on en voit souvent qui prônent des trucs qu'ils sont seuls au monde à vouloir C'est un peu dommage et ça ne fait pas avancer les choses.

vince (./152) :

Kevin Kofler (./151) :
t'adapter aux outils

C'est la réplique typique des templiers du libre...

Non, c'est la réplique typique des réalistes. Les outils sont ce qu'ils sont, c'est à toi de t'adapter à ce qui est disponible.

Cela dit, le libre te laisse aussi une autre option que tu n'as pas avec le propriétaire: tu es libre d'adapter l'outil à tes besoins. C'est valable aussi pour Lionel: vu que de toute façon tu as tellement envie de forker TIGCC, pourquoi ne rajoutes-tu pas les fonctionnalités que tu veux à KTIGCC et/ou TIGCC IDE tout simplement?

Ben c'est aussi au développeur de réfléchir à son public (et à l'utilisation qu'il aura de ses outils) je trouve.
Et puis c'est un bon exercice parce que la satisfaction des clients est importante aussi

Ouais mais le client est un con qui ne connaît rien à la poésie des options de compilation et/ou de gestion de projet. Il faut qu'il comprenne à travers l'utilisation du logiciel toute la complexité de la réalisation et la compétence du programmeur nécessaires pour qu'il puisse avoir le privilège d'utiliser cet outil mis gracieusement à sa disposition. Vous allez voir, le client va devenir humble et bénir le programmeur. Si par contre le programmeur devait quand à lui se limiter à l'outil, on en serait resté à l'interface de Turbo C...

Kochise

EDIT : typo

Solution évidente... et fausse. Antinomique avec le but de solution précédente, aussi. Tes contradictions, comme d'habitude

Tu n'as toujours pas compris que c'est une considération qui n'a strictement rien à voir avec l'optimisation!
Optimisation = gagner en taille ou en temps sans changer les fonctionnalités du programme!

Bon, OK. J'ai formulé rapidement ce que je signifiais, et c'était plus complexe que le premier degré auquel tu as répondu...
J'ai pourtant pris le soin de mentionner 'but' de l'utilisation de -Os, parce que l'optimisation est un MOYEN, pas un BUT. Les buts sont, comme tu l'écris, 'gagner en taille', 'gagner en temps', auxquels de nos jours, et en particulier dans l'embarqué, on ajoute traditionnellement 'gagner en puissance électrique consommée'. Ces trois vecteurs d'optimisation sont deux à deux plus ou moins colinéaires selon l'ISA, la plate-forme et d'autres critères, il est parfois possible de faire deux optimisations à la fois.

Tu nous répètes tout le temps qu'un de TES principaux buts (pas forcément celui des autres, qui peuvent avoir d'autres avis, même si c'est difficile à comprendre pour toi) est 'optimisation taille', et que 'optimisation vitesse' n'est pas ton but (tu écris souvent 'ne sert à rien'). Sur KDE (je me souviens que tu avais écrit que tu suggérerais de passer à -Os), et même sur nos TI-68k qui ne sont pas exactement des plate-formes surpuissantes et qu'on n'aurait pas pu faire aussi bien certains programmes sans mettre d'optimisation vitesse aux endroits qui vont bien (= pas partout: on peut faire des bouts optimisés vitesse et des bouts optimisés taille, cf. TI-Chess, ce que ne permettent pas facilement les TPR).
Et en même temps, TU considères comme 'fonctionnalités' (donc a priori plus importantes que le BUT d'optimisation taille, même si on se demande parfois...) des choses comme compatibilité on-calc, choix de la langue au runtime et lanceur spécialisé.
MAIS le fait de mettre ça dans le programme, pour des raisons dogmatiques qui ne traduisent pas forcément ce qui se passe chez les utilisateurs, a un coût en place. Ca, c'est un FAIT: des KB sur Ice Hockey 68k (j'avais fait l'essai de désactiver -DUSE_TI92P -DUSE_V200, je n'avais même pas changé le code pour supprimer certains graphismes), au moins 10 KB estimés sur TI-Chess (double interface graphique, double gestion des touches). Ca, c'est antinomique avec TON BUT de gagner de la taille, que tu nous rabâches tout le temps. C'est ce que je voulais dire.
Le plus stupide dans tes opinions, c'est peut-être l'utilisation de lanceurs spécifiques - alors que SuperStart et à la fois plus rapide à décompresser et plus facile à utiliser (intégration à la ligne de commande...) que les lanceurs spécifiques. Oui, il nécessite AMS 2.05+ - version sortie en 2000, et cette version ou une version ultérieure est présente sur la plupart des TI-68k vendues depuis 2001, c'est à dire une écrasante majorité des machines en circulation active de nos jours.

Par 'qui ne traduisent pas forcément ce qui se passe chez les utilisateurs', je veux dire:
* asymétrie 89/89T et 92+/V200 dans la population (= code de compatibilité on-calc qui coûte à tous pour une minorité - c'est un tradeoff qu'on peut accepter, ou qu'on peut ne pas accepter);
* présence de PC/Mac<->TI link cables pour beaucoup de machines, présence de connexions Internet pour au moins un membre d'une classe (= c'est pas un problème en pratique de ne pas supporter le modèle minoritaire avec le même exécutable que le modèle majoritaire);
* aucun problème pour les utilisateurs à upgrader leur machine, installer un 'kernel', etc... ou sur une autre plate-forme, cliquer partout, utiliser les mêmes applis que leurs copains/copines même si elles sont connues comme des passoires de sécurité, installer le dernier programme à la mode, en se foutant totalement des questions de sécurité, confidentialité, etc. Ces utilisateurs auraient un problème à installer des programmes incompatibles on-calc ? Allons donc.
* ça serait utile à beaucoup d'utilisateurs des cours de lycée et de fac, le fait de pouvoir changer entre 4 ou 6 langues au runtime ?

C'est fou qu'avec le nombre de fois que j'essaie te t'expliquer ça, ce ne soit toujours pas rentré!

Je te retourne la remarque

Cela dit, le libre te laisse aussi une autre option que tu n'as pas avec le propriétaire: tu es libre d'adapter l'outil à tes besoins.

C'est très clair. Mais certains programmeurs de propriétaire sont plus ouverts aux suggestions, prennent mieux et plus vite en compte les wish lists que certains programmeurs de libre, si tu vois ce que je veux dire

C'est valable aussi pour Lionel: vu que de toute façon tu as tellement envie de forker TIGCC, pourquoi ne rajoutes-tu pas les fonctionnalités que tu veux à KTIGCC et/ou TIGCC IDE tout simplement?

Je te retourne la remarque: pourquoi ne rajoutes-tu pas les fonctionnalités que tu veux (compatibilité on-calc ET choix au runtime entre les langues) à TI-Chess et/ou TICT-Explorer tout simplement ?
Ce faisant, tu ferais monter leur taille bien au-delà de ce qu'elle était avant que je m'occupe de les optimiser (tout en étendant leurs fonctionnalités, dans le cas de TICT-Explorer). Mais c'est vrai que ce que TU crois être important pour les utilisateurs est plus important que le fait de gagner de la taille (ce qui est probablement plus utile en pratique pour les utilisateurs).

Le fork de TIGCC existe déjà dans les faits, et ce n'est pas moi qui l'ai créé. Mais tu es responsable de sa création, c'est un fait, et je pense que tu te souviens du topic où ça s'est passé.

Pour répondre directement à ta question: je ne rajoute pas moi-même des choses aux IDE du TIGCC officiel pour plusieurs raisons:
[ul][li]d'une façon générale: ta gentillesse, ton ouverture d'esprit, ta bonne volonté, ta célérité pour traiter les contributions passées (pas nécessairement les miennes: je ne suis pas le seul contributeur dont les contributions attendent, je te rappelle, même si mes contributions en attente sont parmi les plus grosses...) m'ont assez bien vacciné;[/li]
[li]plus spécifiquement pour les IDE:
[ul][li]pour TIGCC IDE: j'ai un Delphi, mais une vieille version (qui ne va pas faire des programmes compatibles Vista) sur une vieille machine; et ça fait quelques années que je ne l'ai pas utilisé. De toute façon, Delphi n'est pas cross-platform, donc ce n'est pas une très bonne solution;[/li]
[li]pour KTIGCC: je n'ai jamais fait un programme avec KDE, et comme d'autres, je ne pense pas que ce soit la bonne solution, cf. plus haut; de plus, je n'ai pas d'expérience en programmation avec Qt, pas plus qu'avec GTK+ ou wxWidgets.[/li][/ul][/li][/ul]

Je préfère me concentrer sur des parties que je connais mieux: par exemple la librairie, le système de documentation (dont j'avais reporté deux gros défauts qui ne sont toujours pas corrigés, quatre ou cinq ans après... [EDIT: l'abus probable de __need_in_use_bit; n'est qu'une _conséquence_ de l'un des défauts - mais comme on a perdu le source de l'outil de Sebastian, on ne peut pas facilement refaire le callgraph]).
Ca paraît plus efficace de s'attaquer à ce qu'on connaît, n'est-ce pas ?


Rajouter à TIGCC des fonctionnalités attendues par plusieurs personnes est en cours, ne t'en fais pas pour ça
Tu n'as manifestement ni la volonté ni le manpower pour bosser convenablement sur TIGCC.
Si tu as la volonté, pour une fois, d'accepter que d'autres personnes pensent autrement que toi, de t'ouvrir un peu à tes utilisateurs, tu n'es pas rejeté a priori. Tu ne te porterais que mieux, et les autres aussi, de ce changement.
Si tu continues à faire le personnage désagréable que tu nous fais depuis des années, voire que tu nous mets des bâtons dans les roues (tu en serais bien capable...), c'est sans toi.

Pollux (./149) :
Une manipulation ? Je vois pas le problème, tu fais "tigcc machin.o truc.o -o bidule" pour linker...

mais chuteuh!

(je réponds juste aux trucs pas faits exprès pour que tu coures)

Kevin Kofler (./151) :
Oui, et c'était bogué à fond, on dirait que c'est un lieu commun des logiciels utilisant wxGTK...

ça fait longtemps que t'as pas dû tester. Il y a une nouvelle release depuis la 1.0 RC2

Kevin Kofler (./151) :
Je vais voir ce que je peux faire pour tigcc --help dans la version -W32 (la version *nix documente -ar dans tigcc --help, vois-tu maintenant pourquoi je veux me débarasser de toute cette duplication de code?), mais l'option est documentée dans http://tigcc.ticalc.org/doc/comopts.html#SEC3 .

OK.

Kevin Kofler (./151) :
Tu ne veux pas faire le moindre sacrifice pour t'adapter aux outils, c'est ça le problème

mais lol, pourquoi le programmeur devrait il sacrifier son travail pour l'adapter à un outil incompétent? C'est comme faire rentrer des carrés dans des trous ronds!

Kochise (./156) :
Ouais mais le client est un con qui ne connaît rien à la poésie des options de compilation et/ou de gestion de projet. Il faut qu'il comprenne à travers l'utilisation du logiciel toute la complexité de la réalisation et la compétence du programmeur nécessaires pour qu'il puisse avoir le privilège d'utiliser cet outil mis gracieusement à sa disposition. Vous allez voir, le client va devenir humble et bénir le programmeur. Si par contre le programmeur devait quand à lui se limiter à l'outil, on en serait resté à l'interface de Turbo C...
Kochise

Lionel Debroux (./157) :
J'ai pourtant pris le soin de mentionner 'but' de l'utilisation de -Os, parce que l'optimisation est un MOYEN, pas un BUT.
[...]Tu nous répètes tout le temps qu'un de TES principaux buts (pas forcément celui des autres, qui peuvent avoir d'autres avis, même si c'est difficile à comprendre pour toi) est 'optimisation taille', et que 'optimisation vitesse' n'est pas ton but (tu écris souvent 'ne sert à rien').

Mais ce but est subordiné au but de compatibilité et portabilité.

Mes buts sont:
1. proposer les fonctionnalités nécessaires pour que le programme puisse satisfaire tous les utilisateurs: compatibilité on-calc etc.
2. minimiser la taille sans sacrifier ces fonctionnalités. C'est une minimisation sous contrainte, les fonctionnalités sont des contraintes inamovibles, je minimise la taille sous ces contraintes. Par conséquent, il faut sacrifier autre chose: la vitesse.

Et en même temps, TU considères comme 'fonctionnalités' (donc a priori plus importantes que le BUT d'optimisation taille, même si on se demande parfois...) des choses comme compatibilité on-calc, choix de la langue au runtime et lanceur spécialisé.

Oui, parce que ce sont des fonctionnalités qui simplifient l'utilisation du programme.

Et elles sont tout simplement un BUT plus important que le but d'optimisation taille, je ne vois pas du tout où est la contradiction.

MAIS le fait de mettre ça dans le programme, pour des raisons dogmatiques qui ne traduisent pas forcément ce qui se passe chez les utilisateurs, a un coût en place. Ca, c'est un FAIT

Oui, c'est une évidence, je n'ai jamais contesté ça! C'est tout à fait normal, il y a toujours un tradeoff, un but peut contredire un autre (c'est le cas aussi avec vitesse et taille, tes 2 buts!), et il faut donc faire un choix. Mon choix est que les fonctionnalités sont le but principal, après il s'agit d'optimiser le programme sans toucher à ces fonctionnalités, et c'est dans le contexte de cette optimisation seulement que je suis pour la "taille à tout prix" (lire: entre la taille et la vitesse (les 2 paramètres de l'optimisation), choisir toujours la taille; ça n'implique pas du tout une préférence de la taille sur n'importe quel autre paramètre, c'est là que tu vois une contradiction qui n'existe pas).

Et les fonctionnalités ne sont pas toujours en contradiction avec le but de gain de taille: la fonctionnalité "intégration optimale au look&feel de AMS par l'utilisation de ses fonctions de menus et dialogues" que je défends correspond aussi à un gain de taille important.

Ca, c'est antinomique avec TON BUT de gagner de la taille, que tu nous rabâches tout le temps. C'est ce que je voulais dire.

Ce n'est pas antinomique du tout. Tu n'as montré aucune contradiction, et tu ne pourras pas la montrer quelque soit l'insistance avec laquelle tu t'efforces, parce que la contradiction n'existe pas!

Le plus stupide dans tes opinions

Tout ce avec quoi tu n'est pas d'accord est "stupide"? <SARCASM>Quelle démonstration d'objectivité!</SARCASM>

c'est peut-être l'utilisation de lanceurs spécifiques - alors que SuperStart et à la fois plus rapide à décompresser

La version intégrant ttunpack_fast est-elle déjà sortie? Mais en tout cas, on parle là d'une différence entre 1 ou 2 secondes (= une différence de l'ordre d'une seconde) au lancement du programme, et aucune pendant qu'il tourne, je ne vois pas du tout ce que ça change en pratique.

et plus facile à utiliser (intégration à la ligne de commande...) que les lanceurs spécifiques

Hein? Le lanceur spécifique permet à l'utilisateur de lancer un programme sans savoir qu'il est compressé, le PPG se comporte comme un simple fichier de données, on ne peut pas faire plus facile à utiliser. Super Start, une fois installé, est aussi facile à utiliser (pas "plus facile"), mais au prix de devoir installer une sorte de kernel en FlashApp. Ça va complètement à l'encontre du but des programmes natifs AMS ("nostub") qui est de ne rien devoir installer, on envoie le programme et on le lance, et c'est tout!

Oui, il nécessite AMS 2.05+ - version sortie en 2000, et cette version ou une version ultérieure est présente sur la plupart des TI-68k vendues depuis 2001, c'est à dire une écrasante majorité des machines en circulation active de nos jours.

C'est un autre désavantage, mais ce n'est pas le problème principal, le problème est que c'est un truc à installer. Un autre problème est que c'est une FlashApp, donc soumis au système de signature (enfin, ça se contourne maintenant, mais au prix d'encore un truc à installer ), système qui a déjà plusieurs fois empêché de corriger des bogues pendant des mois alors que ces corrections de bogues peuvent être sortis rapidement pour les lanceurs non-FlashApp, et non compilable avec TIGCC (il faut un SDK propriétaire et monoplateforme, qui de plus nécessite une JVM obsolète et illégale (celle du producteur de l'OS, pour laquelle il a perdu un procès et été obligé d'arrêter le support)). Tout ça, et aussi le fait que c'est un lanceur central pour tous les programmes, réduit énormément la liberté de modification.

Quant à l'implication (que tu n'as pas explicitement formulée, mais qu'on lit facilement entre les lignes) que les lanceurs personnalisés seraient un gaspillage de place, c'est ridicule, le pstarter de TIGCC fait 1007 octets. 1 KO environ! Tu râles vraiment pour pas grand chose.

Par 'qui ne traduisent pas forcément ce qui se passe chez les utilisateurs', je veux dire:* asymétrie 89/89T et 92+/V200 dans la population (= code de compatibilité on-calc qui coûte à tous pour une minorité - c'est un tradeoff qu'on peut accepter, ou qu'on peut ne pas accepter);

Au moins tu reconnais qu'on peut l'accepter.
Et ça ne coûte pas "pour une minorité", le jour où un utilisateur de TI-89 recevra un programme d'une TI-92+ et il fonctionnera, il sera bien content lui aussi!

* présence de PC/Mac<->TI link cables pour beaucoup de machines, présence de connexions Internet pour au moins un membre d'une classe (= c'est pas un problème en pratique de ne pas supporter le modèle minoritaire avec le même exécutable que le modèle majoritaire);

Les transferts TI-TI restent fréquents, et si les transferts entre modèles sont rares, c'est à cause de vos incompatibilités absolument inutiles et casse-pieds, pas l'inverse!

* aucun problème pour les utilisateurs à upgrader leur machine

Regarde le nombre de machines non mises à jour! Je suis sûr qu'il y a toujours des AMS 1.00 qui traînent, et si leur nombre diminue, c'est plus parce que les nouvelles calculatrices ont un OS plus récent préinstallé qu'à cause des mises à jour.

installer un 'kernel'

Justement, installer un kernel est lourd, ça cause déjà pas mal de problèmes pour les utilisateurs (cf. forum Questions TI), c'est aussi pour ça que je suis contre Super Start, qui est essentiellement un kernel.

* ça serait utile à beaucoup d'utilisateurs des cours de lycée et de fac, le fait de pouvoir changer entre 4 ou 6 langues au runtime ?

À l'école que j'ai fréquentée, pouvoir choisir entre allemand et français sans changer de binaire aurait certainement été apprécié!

C'est fou qu'avec le nombre de fois que j'essaie te t'expliquer ça, ce ne soit toujours pas rentré!

Je te retourne la remarque

De manière complètement injustifiée. Tu insistes à vouloir me montrer une contradiction qui n'existe pas. Ce n'est pas parce que tu n'es pas d'accord avec ma prioritisation des buts que cette prioritisation est contradictoire! Le concept de contradiction est un concept logique bien défini que tu essaies de détourner dans le but de renforcer ton argumentation (mais en pratique tu la ridiculises parce que tu la tournes en mensonge par un tel abus de termes).

Mon but s'exprime mathématiquement sous la forme:

min taille(programme)
s.t. programme compatible on-calc

ce qui est un simple problème d'optimisation avec contraintes, ce n'est pas du tout contradictoire.

[suite au prochain épisode Je n'ai répondu qu'à la première moitié du ./157 là.]

Mais certains programmeurs de propriétaire sont plus ouverts aux suggestions, prennent mieux et plus vite en compte les wish lists que certains programmeurs de libre, si tu vois ce que je veux dire

Certains... Maintenant essaie avec une des grosses entreprises qui produisent une grande partie des logiciels propriétaires...

Je te retourne la remarque: pourquoi ne rajoutes-tu pas les fonctionnalités que tu veux (compatibilité on-calc ET choix au runtime entre les langues) à TI-Chess et/ou TICT-Explorer tout simplement ?

Parce que j'ai des choses plus importantes à faire.

Ce faisant, tu ferais monter leur taille bien au-delà de ce qu'elle était avant que je m'occupe de les optimiser (tout en étendant leurs fonctionnalités, dans le cas de TICT-Explorer). Mais c'est vrai que ce que TU crois être important pour les utilisateurs est plus important que le fait de gagner de la taille (ce qui est probablement plus utile en pratique pour les utilisateurs).

Mais ça t'éviterait de devoir compiler TI-Chess 8 fois (!)...

Le fork de TIGCC existe déjà dans les faits, et ce n'est pas moi qui l'ai créé.

C'est qui qui a mis en place un dépôt git dans le but de forker TIGCC? Je n'ai vu aucun autre effort de fork concret.

Mais tu es responsable de sa création, c'est un fait, et je pense que tu te souviens du topic où ça s'est passé.

* Des gens qui disent qu'ils veulent forker TIGCC, ce n'est pas un fork, surtout si ces gens n'ont rien fait depuis.
* Utiliser une vieille version de TIGCC IDE pour pouvoir utiliser un émulateur totalement obsolète (VTI) n'est pas un fork, c'est un dead-end qui ne reçoit aucun nouveau développement, et je souhaite à ces personnes qu'elles souffrent au maximum de tous les bogues que j'ai corrigés ou que je vais corriger dans le futur, et aussi des nombreux bogues et limitations de VTI.

d'une façon générale: ta gentillesse, ton ouverture d'esprit, ta bonne volonté, ta célérité pour traiter les contributions passées (pas nécessairement les miennes: je ne suis pas le seul contributeur dont les contributions attendent, je te rappelle, même si mes contributions en attente sont parmi les plus grosses...) m'ont assez bien vacciné;

Attaque personnelle qui ne mérite pas de réponse autre que celle-ci.

pour TIGCC IDE: j'ai un Delphi, mais une vieille version (qui ne va pas faire des programmes compatibles Vista) sur une vieille machine; et ça fait quelques années que je ne l'ai pas utilisé. De toute façon, Delphi n'est pas cross-platform, donc ce n'est pas une très bonne solution;

C'est bien pour ça qu'il s'agit de le remplacer par KTIGCC à long terme!

pour KTIGCC: je n'ai jamais fait un programme avec KDE, et comme d'autres, je ne pense pas que ce soit la bonne solution, cf. plus haut; de plus, je n'ai pas d'expérience en programmation avec Qt, pas plus qu'avec GTK+ ou wxWidgets.

Donc tu te permets de dire que tu "ne pense[s] pas que ce soit la bonne solution" alors que tu n'as aucune expérience avec cette solution ni avec les alternatives.

Si tu avais déjà programmé avec Qt/KDE et avec GTK+ (comme c'est mon cas), tu comprendrais vite pourquoi j'ai choisi KDE!

Je préfère me concentrer sur des parties que je connais mieux: par exemple la librairie, le système de documentation (dont j'avais reporté deux gros défauts qui ne sont toujours pas corrigés, quatre ou cinq ans après... [EDIT: l'abus probable de __need_in_use_bit; n'est qu'une _conséquence_ de l'un des défauts - mais comme on a perdu le source de l'outil de Sebastian, on ne peut pas facilement refaire le callgraph]).

Il faudrait refaire entièrement le système de documentation pour corriger ces défauts, c'est prévu, mais je n'ai pas eu le temps de me plonger là-dessus.

Quant au problème des callgraphs imparfaits, regénérer les callgraphs n'est pas possible, ils ont été corrigés manuellement à beaucoup d'endroits, le chemin vers des callgraphs impeccables est de continuer les corrections manuelles, pas de perfectionner l'extraction automatique, extraction qui ne peut pas fonctionner à 100% parce que le problème est indécidable (équivalent au halting problem).

Ca paraît plus efficace de s'attaquer à ce qu'on connaît, n'est-ce pas ?

"Faites ce que je dis, pas ce que je fais!" Cf. 2 réponses plus haut.

Rajouter à TIGCC des fonctionnalités attendues par plusieurs personnes est en cours, ne t'en fais pas pour ça

En cours où? Sur ton dépôt git?

Tu n'as manifestement ni la volonté ni le manpower pour bosser convenablement sur TIGCC.

J'ai tout à fait la volonté. Le manpower, ben, je demande de l'aide, mais les personnes ne sont pas disponibles pour corriger les vrais problèmes (genre l'absence totale d'un mainteneur pour le code Delphi, le fait que les outils de documentation sont en Delphi et qu'ils souffrent de limitations dont la correction nécessite des modifications importantes, ...), juste pour imposer leurs préférences personnelles (en les faisant passer pour la volonté de la communauté).

Si tu as la volonté, pour une fois, d'accepter que d'autres personnes pensent autrement que toi, de t'ouvrir un peu à tes utilisateurs, tu n'es pas rejeté a priori. Tu ne te porterais que mieux, et les autres aussi, de ce changement.

Je n'ai aucune intention de participer à un fork de TIGCC! Ça m'apporterait quoi de me subordonner à vous? Il serait totalement déraisonnable pour moi de soutenir un projet qui vise à me retirer le contrôle de mon (puisqu'il faut être honnête, c'est tout ce qui reste de l'équipe internationale qu'on avait - mais ce n'est pas pour les raisons que tu présentes, mais tout simplement parce que les coéquipiers sont partis poursuivre d'autres intérêts; je m'entendais très bien avec Sebastian et Zeljko, et les autres étaient déjà partis avant mon arrivée dans le projet!) projet.

En revanche, ce que je compte faire est merger vos modifications si elles sont intéressantes et implémentées correctement (en particulier, avec la documentation qu'il faut). La GPL vous oblige de sortir les sources, donc vous ne pouvez pas m'empêcher d'utiliser vos modifications. Elles seront considérées comme toute autre contribution (ce qui signifie en particulier que je ne mergerai que ce qui serait acceptable si c'était contribué directement à TIGCC). Mais j'attends déjà de les voir, ces modifications, parce que tout ce que j'ai vu jusqu'à présent, ce sont de grands mots dépourvus de faits.

Si tu continues à faire le personnage désagréable que tu nous fais depuis des années, voire que tu nous mets des bâtons dans les roues (tu en serais bien capable...), c'est sans toi.

Effectivement, j'en suis bien capable. Par exemple, je pourrais désactiver le CVS ou le déplacer sur une machine privée, fini tes synchros CVS->git...

Une nette impression de déjà lu pour TOUT le post ./159...
Je n'ai pas le droit de l'appeler 'contradiction' au sens mathématique, soit, mais j'ai le droit de questionner (et tourner en dérision, comme tu as le droit de tourner en dérision la mienne) ta position 'optimiser taille à fond, y compris faire un caca nerveux quand les autres déroulent une boucle dans le programme pour un coût total de 4 octets, sous contrainte d'avoir augmenté au préalable la taille de plusieurs KB - conséquence de la compatibilité on-calc et de la multi-localization sélectionnable au runtime'.
J'ai aussi le droit de faire remarquer (ce que je m'étais abstenu de faire dans ./157) ton comportement 'faites ce que je dis, ne faites pas ce que je fais', dont je suis moins adepte que toi en ce qui concerne la programmation on-calc. Cf. S1P9 qui est un produit (conséquence) de mes activités d'optimisation.

Quant à l'implication (que tu n'as pas explicitement formulée, mais qu'on lit facilement entre les lignes) que les lanceurs personnalisés seraient un gaspillage de place, c'est ridicule, le pstarter de TIGCC fait 1007 octets. 1 KO environ! Tu râles vraiment pour pas grand chose.

1 KB est assez faible en relatif par rapport à la mémoire d'une TI-68k, mais ce 1 KB est multiplié par le nombre de lanceurs spécifiques... et sur les V200 XPandées ou 89T, avec 2.6-2.7 MB de mémoire, on peut mettre pas mal de programmes. Quatre fois plus que les legacies que nous possédons tous les deux.

Mathématiquement, puisque tu aimes bien ça:
* pour n entier >1, 1007*n [n lanceurs spécifiques] > 1100 [exagération de maximum 10% de la taille de ttstart], mais ttstart n'a pas la même facilité d'utilisation;
* pour n entier >0, 1007*n [n lanceurs spécifiques] > 0 [dans beaucoup de calculettes, SuperStart est 'gratuit' car il occupe de l'espace qui, autrement, serait inutilisé, sans nécessiter un secteur supplémentaire pour les FlashApps].
SuperStart ne consomme presque rien en RAM, contrairement aux deux autres.

et plus facile à utiliser (intégration à la ligne de commande...) que les lanceurs spécifiques

Hein? Le lanceur spécifique permet à l'utilisateur de lancer un programme sans savoir qu'il est compressé, le PPG se comporte comme un simple fichier de données, on ne peut pas faire plus facile à utiliser. Super Start, une fois installé, est aussi facile à utiliser (pas "plus facile"), mais au prix de devoir installer une sorte de kernel en FlashApp. Ça va complètement à l'encontre du but des programmes natifs AMS ("nostub") qui est de ne rien devoir installer, on envoie le programme et on le lance, et c'est tout!

Si, on peut faire plus facile à utiliser que les pstarters, parce que SuperStart ne nécessite même pas de presser la parenthèse fermante pour lancer un PPG
(ou alors, l'utilisateur utilise AutoClBr - mais à ce moment-là, il a déjà dû le transférer, et le réinstaller à chaque reset - ça ne présente donc pas d'avantage d'installation et d'utilisation par rapport à SuperStart.)

Kevin Kofler (./161) :
Effectivement, j'en suis bien capable. Par exemple, je pourrais désactiver le CVS ou le déplacer sur une machine privée, fini tes synchros CVS->git...

et la gpl?

Le libre selon KK, c'est de tout faire pour garder le monopole, malgré la GPL

Kevin Kofler (./159) :
Mon but s'exprime mathématiquement sous la forme:

min taille(programme)
s.t. programme compatible on-calc

ce qui est un simple problème d'optimisation avec contraintes, ce n'est pas du tout contradictoire.

Ca veut dire que si je te propose un patch qui réduit de quelques octets la taille au prix d'un ralentissement significatif des programmes tu l'intégrerais systématiquement ?

à priori oui

Lionel Debroux (./161) :
1100 [exagération de maximum 10% de la taille de ttstart]

C'est la version compilée avec ttunpack_small ça, pas ta version par défaut qui utilise ttunpack_fast, n'est-ce pas? Ne viens pas faire un choix par défaut pour ton logiciel et ensuite utiliser la version que tu n'as pas choisie comme la version par défaut dans les argumentations quand ça t'arrange...

Si, on peut faire plus facile à utiliser que les pstarters, parce que SuperStart ne nécessite même pas de presser la parenthèse fermante pour lancer un PPG

Tu es vraiment parti pour couper les cheveux en 4 là...
Bon OK, de manière strictement mathématique, tu as raison, mais en pratique ça ne simplifie pas vraiment l'utilisation de devoir taper sur une touche en moins.

squalyl (./162) :
et la gpl?

Les tarballs source et/ou SRPMs sont tout à fait suffisants pour être conforme à la GPL. L'obligation porte sur la diffusion des sources correspondantes aux binaires qu'on publie, pas sur tous les développements intermédiaires.

Pollux (./164) :
Ca veut dire que si je te propose un patch qui réduit de quelques octets la taille au prix d'un ralentissement significatif des programmes tu l'intégrerais systématiquement ?

En principe oui (cf. mon patch à GCC pour faire les switches en chaîne de tests linéaire plutôt qu'en arbre binaire balancé en -Os), mais bien sûr il ne faut pas déconner, si tu nous fais des multiplications par N en additionnant N fois, ça va sortir du domaine de l'utilisable (contrainte qui devrait être rajoutée à la formulation du problème d'optimisation ).

Si tu formalises d'une façon suffisamment précise pour savoir à l'avance si un patch sera intégré ou si c'est pas la peine, j'essayerai de faire des "contributions"

Le fork de TIGCC existe déjà dans les faits, et ce n'est pas moi qui l'ai créé.

C'est qui qui a mis en place un dépôt git dans le but de forker TIGCC? Je n'ai vu aucun autre effort de fork concret.

Relis le message topics/108648-ld-tigcc-flash-os-bss-special/5#120
Non seulement le dépôt vers lequel je donne un lien est un _miroir_, c'est explicitement marqué, mais de plus, la création d'un repository Git a été motivée par le fait d'utiliser de vrais outils de SCM. Ca aussi, c'est explicitement marqué.

Mais tu es responsable de sa création, c'est un fait, et je pense que tu te souviens du topic où ça s'est passé.

* Des gens qui disent qu'ils veulent forker TIGCC, ce n'est pas un fork, surtout si ces gens n'ont rien fait depuis.

C'est du moins ce que tu crois

* Utiliser une vieille version de TIGCC IDE pour pouvoir utiliser un émulateur totalement obsolète (VTI) n'est pas un fork, c'est un dead-end qui ne reçoit aucun nouveau développement, et je souhaite à ces personnes qu'elles souffrent au maximum de tous les bogues que j'ai corrigés ou que je vais corriger dans le futur, et aussi des nombreux bogues et limitations de VTI.

C'est vraiment utile et constructif, la fin de ta phrase

pour TIGCC IDE: j'ai un Delphi, mais une vieille version (qui ne va pas faire des programmes compatibles Vista) sur une vieille machine; et ça fait quelques années que je ne l'ai pas utilisé. De toute façon, Delphi n'est pas cross-platform, donc ce n'est pas une très bonne solution;

C'est bien pour ça qu'il s'agit de le remplacer par KTIGCC à long terme!

Je suis tout à fait d'accord, au cas où ça ne serait pas clair.
[cite]

pour KTIGCC: je n'ai jamais fait un programme avec KDE, et comme d'autres, je ne pense pas que ce soit la bonne solution, cf. plus haut; de plus, je n'ai pas d'expérience en programmation avec Qt, pas plus qu'avec GTK+ ou wxWidgets.

Donc tu te permets de dire que tu "ne pense [ s ] pas que ce soit la bonne solution" alors que tu n'as aucune expérience avec cette solution ni avec les alternatives.[cite]
En tant que programmeur, non. En tant qu'utilisateur qui trouve ch*** de devoir installer GTK+ pour pouvoir utiliser TIEmu sous Windows, si (c'était déjà le cas du temps où j'utilisais encore exclusivement ou principalement Windows) . Je trouverais également ch*** de devoir installer KDE, beaucoup plus gros que GTK+, pour pouvoir tourner un pauvre IDE tout simple...

Je préfère me concentrer sur des parties que je connais mieux: par exemple la librairie, le système de documentation (dont j'avais reporté deux gros défauts qui ne sont toujours pas corrigés, quatre ou cinq ans après... [EDIT: l'abus probable de __need_in_use_bit; n'est qu'une _conséquence_ de l'un des défauts - mais comme on a perdu le source de l'outil de Sebastian, on ne peut pas facilement refaire le callgraph]).

Il faudrait refaire entièrement le système de documentation pour corriger ces défauts, c'est prévu, mais je n'ai pas eu le temps de me plonger là-dessus.

A part la présence quasi-exclusive de code Delphi, réécrire intégralement n'est pas forcément une nécessité, du moins à court et moyen termes. Deux défauts que je connais ne nécessitent aucun changement aux exécutables Delphi, l'un se corrige par un one-liner et j'ai commencé à m'attaquer à l'autre pas plus tard que tout à l'heure (parce qu'il y en a besoin pour le fork, de toute façon).

Quant au problème des callgraphs imparfaits, regénérer les callgraphs n'est pas possible, ils ont été corrigés manuellement à beaucoup d'endroits, le chemin vers des callgraphs impeccables est de continuer les corrections manuelles, pas de perfectionner l'extraction automatique, extraction qui ne peut pas fonctionner à 100% parce que le problème est indécidable (équivalent au halting problem).

Perdre les sources du programme était une faute de nous trois.
Ne pas garder une trace des modifs faites à la main était une faute aussi.
Je sais que l'extraction automatique ne peut pas être parfaite... mais je pense que Sebastian et toi êtes partis trop vite sur les corrections manuelles. L'extraction est suffisamment imparfaite pour ne pas prendre en compte les A-Line, ce qui a faussé le callgraph avec les OSV*. Le nombre de référence à l'event loop, y compris dans des fonctions qui n'y sont liées que de très loin (et encore, pas sûr), m'a toujours paru trop élevé pour être honnête.

Rajouter à TIGCC des fonctionnalités attendues par plusieurs personnes est en cours, ne t'en fais pas pour ça

En cours où? Sur ton dépôt git?

Non, comme tu peux d'ailleurs le voir toi-même. Ce dépot-là est un miroir. Je te renvoie une nouvelle fois à topics/108648-ld-tigcc-flash-os-bss-special/5#120

Tu n'as manifestement ni la volonté ni le manpower pour bosser convenablement sur TIGCC.

J'ai tout à fait la volonté.

'Convenablement', j'ai écrit. Ca n'est vraiment pas l'impression que tu donnes...

Le manpower, ben, je demande de l'aide, mais les personnes ne sont pas disponibles pour corriger les vrais problèmes (genre l'absence totale d'un mainteneur pour le code Delphi,

Pour le système de doc, tant que le code Delphi tourne sous Wine (c'est le cas) ET qu'on n'a pas besoin de le modifier, à la limite, on s'en fiche.
Pour l'IDE, c'est un peu plus un problème...

le fait que les outils de documentation sont en Delphi et qu'ils souffrent de limitations dont la correction nécessite des modifications importantes,

La sensibilité aux line endings (CR LF obligatoire), par exemple ? C'est une limitation importante, mais elle est facile à contourner.

...), juste pour imposer leurs préférences personnelles (en les faisant passer pour la volonté de la communauté).

, que veux-tu que je réponde d'autre ?

Si tu as la volonté, pour une fois, d'accepter que d'autres personnes pensent autrement que toi, de t'ouvrir un peu à tes utilisateurs, tu n'es pas rejeté a priori. Tu ne te porterais que mieux, et les autres aussi, de ce changement.

Je n'ai aucune intention de participer à un fork de TIGCC! Ça m'apporterait quoi de me subordonner à vous? Il serait totalement déraisonnable pour moi de soutenir un projet qui vise à me retirer le contrôle de mon (puisqu'il faut être honnête, c'est tout ce qui reste de l'équipe internationale qu'on avait - mais ce n'est pas pour les raisons que tu présentes, mais tout simplement parce que les coéquipiers sont partis poursuivre d'autres intérêts; je m'entendais très bien avec Sebastian et Zeljko, et les autres étaient déjà partis avant mon arrivée dans le projet!) projet.

Par exemple, un partage des tâches selon ce que chacun sait le mieux faire (toi: GCC, KTIGCC; d'autres: outillage et contenu documentation; d'autres: librairie; etc.) ?

En revanche, ce que je compte faire est merger vos modifications si elles sont intéressantes et implémentées correctement (en particulier, avec la documentation qu'il faut). La GPL vous oblige de sortir les sources, donc vous ne pouvez pas m'empêcher d'utiliser vos modifications.

Naturellement, mais on ne fait pas le fork pour t'empêcher d'utiliser nos modifs.

Elles seront considérées comme toute autre contribution (ce qui signifie en particulier que je ne mergerai que ce qui serait acceptable si c'était contribué directement à TIGCC).

On le sait parfaitement, et on sait qu'il y a un certain nombre de choses qui ne te plaisent pas beaucoup, pas du tout ou vraiment pas, que tu ne vas pas merger

Mais j'attends déjà de les voir, ces modifications, parce que tout ce que j'ai vu jusqu'à présent, ce sont de grands mots dépourvus de faits.

C'est pas parce que tu n'as pas vu les faits qu'il n'existent pas

Si tu continues à faire le personnage désagréable que tu nous fais depuis des années, voire que tu nous mets des bâtons dans les roues (tu en serais bien capable...), c'est sans toi.

Effectivement, j'en suis bien capable. Par exemple, je pourrais désactiver le CVS ou le déplacer sur une machine privée, fini tes synchros CVS->git...

Faudrait peut-être demander leur avis aux autres committeurs sur le projet TIGCC ?
Tu devrais aussi reporter l'utilisation de cvssuck à SourceForge et leur suggérer d'utiliser du filtrage, comme tu me l'avais suggéré une fois.

[EDIT: oups, gros problème de formattage dû à un [ s ] quoté ]

[ /s]

1100 [exagération de maximum 10% de la taille de ttstart]

C'est la version compilée avec ttunpack_small ça, pas ta version par défaut qui utilise ttunpack_fast, n'est-ce pas? Ne viens pas faire un choix par défaut pour ton logiciel et ensuite utiliser la version que tu n'as pas choisie comme la version par défaut dans les argumentations quand ça t'arrange...

'Choix par défaut' ? 'Choix préféré', oui, mais je compile à la fois les versions fast/large et les versions small/slow, moi, pour que l'utilisateur ait le choix

De toute façon, même si on met 1500 au lieu de 1100 (ce qui correspond à peu près à la différence entre les deux routines), ou 2000 au lieu de 1500,
* pour n entier >1, 1007*n [n lanceurs spécifiques] > 1100 [exagération de maximum 10% de la taille de ttstart], mais ttstart n'a pas la même facilité d'utilisation;
reste vrai

Pollux (./167) :
Si tu formalises d'une façon suffisamment précise pour savoir à l'avance si un patch sera intégré ou si c'est pas la peine, j'essayerai de faire des "contributions"

C'est bien pour ça que je ne formalise pas plus, je n'ai pas envie de te faire perdre ton temps à essayer de trouver des trous dans ma formalisation. Il est évident qu'il y a des limites pratiques (genre la multiplication à complexité exponentielle en la longueur en bits des entrées ou encore la recopie des plans dans la routine de gris qui est sous des contraintes de vitesse très étroites parce que sinon ça clignote, il doit y en avoir d'autres, de cas comme ça, tous regroupés dans le cadre de l'utilisabilité), et qu'un paquet de patches juste en dessous de cette limite va la faire dépasser à force. D'éventuelles optimisations en taille exploitant des bogues du matériel ou du logiciel seront aussi très mal vues (parce que ce n'est pas future-safe, rien ne garantit que TI ne va pas revenir aux 68k vu le flop qu'est la Nspire, aussi improbable que ce soit).

Le proc étant obsolète (d'un point de vue industriel, pas à ton sens, KK), je doute qu'ils reviennent aux 68k.

Lionel Debroux (./168) :
la création d'un repository Git a été motivée par le fait d'utiliser de vrais outils de SCM

Plutôt le fait de faire le développement en privé pour m'empêcher de voir ce que vous faites, n'est-ce pas?

Quand les seuls commits dans ton dépôt sont les miroirs de mes commits dans le CVS, forcément c'est soit ça, soit vous n'avez rien foutu en tout ce temps, au choix.

Faudra vraiment pas vous plaindre si je rends mon CVS privé en tout cas, vu que vous faites pareil.

C'est du moins ce que tu crois

Comme je l'ai toujours dit, pour moi, ce qui n'est pas public n'existe pas. Ça ne change rien en pratique qu'il y ait des améliorations privées auxquelles la communauté n'a pas accès.

A part la présence quasi-exclusive de code Delphi, réécrire intégralement n'est pas forcément une nécessité, du moins à court et moyen termes. Deux défauts que je connais ne nécessitent aucun changement aux exécutables Delphi, l'un se corrige par un one-liner et j'ai commencé à m'attaquer à l'autre pas plus tard que tout à l'heure (parce qu'il y en a besoin pour le fork, de toute façon).

Bon, OK, il y a 2 manières de corriger le problème: le bidouillage, rajoutant des outils supplémentaires pour essayer de contourner les limitations des outils existants, ou la refonte qui corrige réellement ces limitations, et qui rend aussi les outils maintenables (en l'absence d'un mainteneur pour du code Delphi). Je sais que tu as toujours défendu la première solution, mais c'est la mauvaise solution à long terme, tu ne peux pas éviter toutes les limitations comme ça, et tu risques d'introduire de nouveaux problèmes.

En cours où? Sur ton dépôt git?

Non, comme tu peux d'ailleurs le voir toi-même. Je te renvoie une nouvelle fois à topics/108648-ld-tigcc-flash-os-bss-special/5#120

Message qui ne contient aucun pointeur vers un dépôt autre que ton miroir git de mon CVS. Donc il ne répond pas à ma question.

'Convenablement', j'ai écrit. Ca n'est vraiment pas l'impression que tu donnes...

Si pour toi, "convenablement" = "en acceptant immédiatement et sans discussion tous les patches qu'on envoie, même s'ils ne documentent pas les ajouts, s'ils nécessitent des corrections manuelles pour être appliquables aux sources actuelles (genre pour les callgraphs dans tes patches de documentation), s'ils sont incomplets (cf. toujours les callgraphs), s'ils n'ont pas été testés, si les patches sont une mauvaise idée et/ou s'ils créent des problèmes non résolus", alors non, mais si tu utilises la vraie définition de ce mot, alors si. (Certains des problèmes, genre les corrections manuelles à apporter ou l'absence de tests effectués, vont retarder l'acceptance parce qu'il faut que je fasse votre boulot et que ça prend du temps, pour d'autres, comme un patch qui est fondamentalement défectueux, un rejet total s'impose malheureusement.)

Pour le système de doc, tant que le code Delphi tourne sous Wine (c'est le cas) ET qu'on n'a pas besoin de le modifier, à la limite, on s'en fiche.

Le problème, c'est qu'on a besoin de le modifier, et radicalement! Cf. plus haut.

La sensibilité aux line endings (CR LF obligatoire), par exemple ? C'est une limitation importante, mais elle est facile à contourner.

Oui, c'est facile de la contourner en bidouillant, il suffit de lancer unix2dos, c'est ce que je fais évidemment, mais c'est de la bidouille, pour une vraie solution, il faut corriger l'outil!

, que veux-tu que je réponde d'autre ?

Rien, ça aurait été mieux que ta réponse qui est une bêtise...

Quand il y a quelques nostalgiques qui veulent absolument utiliser VTI alors qu'il gère mal les HW2 (il émule essentiellement une HW1 qui se fait passer pour HW2, ce qui fait que la détection du matériel de TIGCCLIB est obligée d'avoir un cas particulier pour VTI ), qu'il ne gère pas du tout les V200 et les Titaniums (on peut faire tourner leurs ROMs avec des hacks, mais ça n'émule pas leur matériel de manière fiable, le matériel émulé reste celui d'une HW1), que certaines fonctionnalités (affichages des handles, program entry breakpoints) ne fonctionnent pas avec AMS 3 et ne fonctionnent avec AMS 2 que si on utilise une version modifiée plus boguée que l'originale et dont les sources ont été perdues, que VTI ne propose aucun débogueur C et qu'il n'a pas été mis à jour depuis 2001 et quand ils prétendent que "la communauté veut utiliser VTI", je ne vois vraiment pas comment je devrais l'appeler autrement qu'"imposer leurs préférences personnelles en les faisant passer pour la volonté de la communauté".

Par exemple, un partage des tâches selon ce que chacun sait le mieux faire (toi: GCC, KTIGCC; d'autres: outillage et contenu documentation; d'autres: librairie; etc.) ?

J'ai toujours proposé un tel partage des tâches, mais dans le contexte de l'infrastructure existante, votre intégration à l'équipe étant progressive, pas immédiate (donc tous les patches devront être revus par un membre de l'équipe au départ - et je suis désolé, mais à moins que vous ne réussissiez à faire revenir un de mes anciens coéquipiers, ce sera moi au départ, mais une fois un nouveau membre intégré, il pourra aussi s'occuper des revues des patches des autres membres aspirants), et pas dans le but de revenir sur des décisions déjà prises (donc hors de question de remettre les hacks pour envoyer des programmes à VTI ou de mettre les plans de gris consécutifs sur HW1, cette dernière décision a d'ailleurs été prise en concordance avec Thomas, Sebastian et Zeljko, ce n'est pas mon choix personnel!). De plus, en tant que membre actif le plus ancien, je resterais évidemment tête du projet. C'est toujours ce que je vous ai à offrir, je ne suis pas partant pour autre chose.

C'est le système de la méritocratie, celui ou ceux qui fait/font le travail décide(nt), pour l'instant c'est moi qui ai travaillé sur TIGCC pendant des années, vous ne pouvez pas sortir de nulle part et vous attendre de pouvoir tout bouleverser du jour au lendemain.

Naturellement, mais on ne fait pas le fork pour t'empêcher d'utiliser nos modifs.

Alors je réitère ma question: où sont-elles?

On le sait parfaitement, et on sait qu'il y a un certain nombre de choses qui ne te plaisent pas beaucoup, pas du tout ou vraiment pas, que tu ne vas pas merger

Et donc je ne peux prendre votre invitation à participer à votre fork que pour ce qu'elle est: une mauvaise plaisanterie.

C'est pas parce que tu n'as pas vu les faits qu'il n'existent pas

Contradiction! (Et là le mot est bel et bien correct!) Si vous ne me montrez pas vos modifications, comment voulez-vous que je les utilise? Donc vous m'empêchez bel et bien de les utiliser.

Si tu ne veux pas me donner cette impression, ben c'est simple: j'attends toujours la réponse à la question: où sont vos modifs?

Faudrait peut-être demander leur avis aux autres committeurs sur le projet TIGCC ?

Qui? Romain qui a fait un seul commit dans un répertoire debian récemment? Je ne pense pas que ça le dérangerait énormément, on peut facilement packager sans avoir le répertoire debian directement dans le dépôt des sources. Sinon il n'y a personne d'autre qui a fait un commit récemment (le plus récent était probablement Konrad qui a fait quelques petits nettoyages dans KTIGCC 2, mais ça commence aussi à faire quelques mois).

Ça serait différent si vous acceptiez de participer dans le cadre de l'infrastructure existante, mais j'ai comme l'impression que ça ne vous intéresse pas...

Tu devrais aussi reporter l'utilisation de cvssuck à SourceForge et leur suggérer d'utiliser du filtrage, comme tu me l'avais suggéré une fois.

Bah, si je désactive le CVS de SF ou si j'arrête de le mettre à jour, ce ne sera de toute façon pas nécessaire.

Ça serait différent si vous acceptiez de participer dans le cadre de l'infrastructure existante, mais j'ai comme l'impression que ça ne vous intéresse pas...

A moins que tu changes d'avis, l'infrastructure existante comprend CVS, n'est-ce pas ?
Utiliser le vieux CVS, avec ses problèmes de commit non atomique (rencontrés sur chacun des deux projets sur lequel je l'ai utilisé), la difficulté d'en créer un miroir local, etc. ne m'intéresse pas - et je ne suis pas le seul des forkeurs.
Tu ne vois peut-être pas l'intérêt de créer un miroir local, je vais donc te l'expliquer, à partir de mon expérience. Le miroir local (Git par-dessus SVN) m'a également tout simplement permis de bosser, plutôt que d'être payé 2 jours à ne rien pouvoir faire, à un moment où le serveur SVN était tout le temps down: pile à ce moment-là, pour faire ce que j'avais à faire, j'avais absolument besoin de merger des commits d'une version d'un outil dans une version expérimentale que je devais utiliser.
Sans le miroir + le travail déconnecté, comment obtenir les changesets qui affectaient cette partie de l'arborescence, en faire les diffs, et merger les révisions incrémentalement (une par commit local) ?

Passer à SVN te demanderait très peu d'effort, et serait une preuve importante de bonne volonté de ta part. Je veux dire par-là que tu te donnerais nettement plus les moyens d'atteindre ton but de partage des tâches (qui est aussi le nôtre, figure-toi... sauf qu'on est plus nombreux qu'une seule personne...) et d'avoir des contributions


Quant à l'adresse du repo: tu ne veux pas qu'on te fournisse des patches incomplets / pas forcément sous forme définitive (cf. le patch à ld-tigcc par PpHd, dont il a besoin pour pouvoir continuer PedroM, par exemple). Tu voudrais qu'on te donne _maintenant_ l'adresse du repo qui ne contient pour le moment que des patches incomplets / pas forcément définitifs dont tu ne pourras rien faire, pas plus que les utilisateurs, sinon tu menaces de fermer ton repository CVS ??
Du calme, Kevin. Sois un peu raisonnable

Lionel Debroux (./174) :
A moins que tu changes d'avis, l'infrastructure existante comprend CVS, n'est-ce pas ?

Quand vous serez suffisamment intégrés à l'équipe pour avoir accès en commit au dépôt, je suis prêt à discuter pour vous fournir les outils dont vous avez besoin. Pour développer un patch qui doit passer la revue, on n'a pas besoin de dépôt du tout, il suffit d'un tarball (on extrait, on copie le dossier extrait, on modifie, on fait un diff -Nur et on m'envoie le résultat). Évidemment, ça ne va pas être adapté pour les grosses modifications, mais il ne faut pas commencer par là, vous devrez d'abord montrer que vous êtes capables de faire de petits patches de manière complète (c'est-à-dire qu'il ne doit pas falloir que je les retouche et teste dans tous les sens), ensuite, avec la confiance gagnée, vous pourrez obtenir accès au dépôt et c'est à ce moment-là que j'accepterai vos suggestions sur le SCM à utiliser.

Utiliser le vieux CVS, avec ses problèmes de commit non atomique (rencontrés sur chacun des deux projets sur lequel je l'ai utilisé), la difficulté d'en créer un miroir local, etc. ne m'intéresse pas - et je ne suis pas le seul des forkeurs.

Au départ, tu n'utiliserais pas CVS, tu utiliserais ton client mail et l'outil diff.

Tu ne vois peut-être pas l'intérêt de créer un miroir local, je vais donc te l'expliquer, à partir de mon expérience. Le miroir local (Git par-dessus SVN) m'a également tout simplement permis de bosser, plutôt que d'être payé 2 jours à ne rien pouvoir faire, à un moment où le serveur SVN était tout le temps down

C'est un cas particulier, ça arrive très rarement que le serveur soit down. À l'époque où le CVS de SF avait des problèmes sans arrêt, j'aurais peut-être accepté cet argument (et encore, un serveur plus fiable m'a l'air d'être la solution la plus simple), mais pas maintenant.

Passer à SVN te demanderait très peu d'effort, et serait une preuve importante de bonne volonté de ta part. Je veux dire par-là que tu te donnerais nettement plus les moyens d'atteindre ton but de partage des tâches (qui est aussi le nôtre, figure-toi... sauf qu'on est plus nombreux qu'une seule personne...) et d'avoir des contributions

Je ne me fais pas avoir, passer à SVN dans la situation actuelle ne me donnerait pas de nouveaux committers au SVN, ça vous faciliterait juste votre tâche de forker et développer ailleurs. Crois-tu vraiment que je ne comprends pas ça?

Si vous étiez vraiment partants pour coopérer, on pourrait bien se mettre d'accord sur le SCM, mais là il me semble clair que c'est juste une excuse pour ne pas coopérer et/ou une demande visant à faciliter le forkage, pas la coopération.

Quant à l'adresse du repo: tu ne veux pas qu'on te fournisse des patches incomplets / pas forcément sous forme définitive (cf. le patch à ld-tigcc par PpHd, dont il a besoin pour pouvoir continuer PedroM, par exemple). Tu voudrais qu'on te donne _maintenant_ l'adresse du repo qui ne contient pour le moment que des patches incomplets / pas forcément définitifs dont tu ne pourras rien faire, pas plus que les utilisateurs

Une chose que je pourrais en faire, déjà, c'est de regarder ce qu'il y a, et donc vérifier si vous avez vraiment fait du boulot ou si ce sont juste de grands mots.

C'est ridicule que tu m'invites à coopérer à un projet sans donner la moindre preuve que ce projet est actif. (Cela dit, je n'accepterai de toute façon pas ton invitation. Si coopération il y aura, ce sera dans le cadre du projet existant, sous ma direction, et dans un SCM central. Sinon, allez faire votre coup d'état ailleurs et ne me demandez pas de rejoindre le projet-même qui vise à me contourner!)

sinon tu menaces de fermer ton repository CVS ??

Cette menace est en principe indépendante de la demande, mais il est clair que la réciprocité sera un des facteurs pris en considération pour cette décision. Si vous refusez de développer en public, je ne vois pas pourquoi je devrais le faire, moi.

"sous ma direction" ? Fait pas ton RMS non plus, tu es l'anti-thèse du libre que tu défends tant. Pourquoi vouloir tant garder la main-mise sur ce projet ? Tu gardes le contrôle de ton fork et puisque les autres n'ont que des 'grands mots' tu ne risques rien, hein ?

Kochise

Kochise (./176) :
Fait pas ton RMS non plus, tu es l'anti-thèse du libre que tu défends tant.

Cette phrase est totalement illogique, réfléchis un peu...

Pourquoi vouloir tant garder la main-mise sur ce projet ?

Parce que je travaille sur TIGCC depuis des années, pourquoi devrais-je confier le projet à des nouveaux venus qui n'ont aucune expérience dans le projet? C'est une demande totalement illogique et arrogante de la part des forkeurs.

Mais bien sûr....

Et toi qui n'as rien contribué à TIGCC, tu oses te mêler de nos affaires?

A titre de rappel le titre de ce topic n'est pas "Kévin foutage de gueule" mais "kdewin foutage de g(u)eule"

Par conséquent vu qu'on tolère le HS sur TIGCC il faudrait faire preuve d'un peu plus de respect envers les autres, merci.