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à.]