Les directives d'assemblage de A68k - Page 3

Thibaut (./58) :
Désolé, mais les programmes qui étaient codés, compilés avant la sortie des nouveaux modèles, se trouvent définitivement incompatibles.

Il faut recompiler. On a toujours dit qu'il faut recompiler dans le cas d'incompatibilités causées par TI, si les programmeurs ne nous écoutent pas, ce n'est pas notre problème. On fait tout pour que les sources compilent sans changement et fonctionnent sur les nouveaux AMS (sauf évidemment si le code du programme contient un hack non-portable, c'est bien pour ça qu'il faut utiliser les macros/fonctions comme SetIntVec qui ont pu être corrigés).

Allez on arrête de t'embêter Kevin

Deux expressions opposées ? Ah bon, je croyais que ca avait un autre nom
Alors comme l'a si bien dit Thibaut dans ./62 : j'arrete de t'embeter
(Mais c'était plutôt dans l'optique d'apporter une précision à ton français - connaissant tes origines linguistiques - )

Edit> Pour répondre a ./64 > Oui ca me semble plus approprié ici, mais on s'écarte un peu du sujet, alors je mets ca en Edit plutôt

Je peux l'appeler contradiction aussi si tu veux, c'est le terme plus général.

Tu as vraiment une vision tordue des choses.
Je ne vois aucune attitude monopoliste dans ce qu'on fait, on fait de notre mieux pour faire que nos programmes soient compatibles avec les matériels et AMS futurs, mais TI a cassé les programmes avec des changements qui n'étaient pas prévisibles, on ne peut pas prévoir le futur. Nous avons toujours conseillé de n'utiliser que les méthodes qui fonctionnent avec les AMS et matériels futurs (ROM_CALLs au lieu de hacks des variables globales etc.), mais par exemple le coup de l'espace fantôme était imprévisible. Tout ce qu'on pouvait donc faire dans ces cas-là, c'est corriger le problème (entièrement dans la librairie, aucune modification des sources des logiciels n'était nécessaire (sauf s'il y avait des incompatibilités dans les sources elles-mêmes)!), avant la sortie officielle de la calculatrice concernée (!), et dire aux programmeurs de recompiler, c'est ce qu'on a fait.
Et comparer recompiler à acheter un nouvel ordinateur, c'est un peu "apples and oranges", ça n'a vraiment rien à voir. Mettre à jour TIGCC et recompiler est gratuit et fait en quelques minutes.

Kevin Kofler (./66) :
Mettre à jour TIGCC et recompiler est gratuit et fait en quelques minutes.

Ca m'a quand même pas l'air si facile que ça (il y a une ligne de commande qui reconstruit un tigcc.zip à partir des sources ?), surtout que tous les fichiers ne sont pas dispos dans les sources : par exemple les includes ne sont dispos qu'après avoir lancé le setup ^^ (d'ailleurs, toi qui es pointilleux sur les licences, je ne suis pas sûr que ça soit autorisé par la GPL de faire ça le setup est une oeuvre dérivée des includes, donc il faut aussi distribuer leur code source)

Pollux (./67) :
Ca m'a quand même pas l'air si facile que ça (il y a une ligne de commande qui reconstruit un tigcc.zip à partir des sources ?)

Je parle de recompiler les applications avec le TIGCC plus récent que je propose, pas de recompiler TIGCC lui-même.
Pour construire tigcc.zip, j'utilise ces scripts (qui se trouvent aussi dans tigccsrc.zip):
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/setup/
(en particulier makeall.sh) mais les binaires là-dedans sont compilés à la main.

surtout que tous les fichiers ne sont pas dispos dans les sources : par exemple les includes ne sont dispos qu'après avoir lancé le setup ^^ (d'ailleurs, toi qui es pointilleux sur les licences, je ne suis pas sûr que ça soit autorisé par la GPL de faire ça le setup est une oeuvre dérivée des includes, donc il faut aussi distribuer leur code source)

La GPL dit qu'il faut distribuer les sources, elle ne dit pas que ça doit être dans l'archive source, si les sources sont déjà dans les binaires, ça ne sert à rien d'en distribuer une deuxième copie avec les sources. Si on ne veut pas lancer l'installeur, le setup.exe NSIS peut être décompressé avec 7-Zip ou p7zip par exemple. Et sinon, les includes sont aussi dans les tarballs source et binaire *nix et dans le CVS. Cela dit, je veux bien les rajouter au tigccsrc.zip aussi si tu penses que ce soit utile.

Au fait, c'était quoi le problème avec les sources de la bibliothèque de GTC ?
C'était le fait qu'elles ne soient pas distribuées ?

Pollux, tu les as modifiées ? (mis à part les adaptations de syntaxe, puisque ça ne change rien à la sémantique)
Si tu ne les as pas modifiées en dehors de la syntaxe, je ne suis vraiment pas sûr que tu sois obligé de les distribuer, ni de distribuer leur licence. Il te suffit de dire "Les sources de la bibliothèques sont celles de TIGCC 0.94 que vous pouvez télécharger là : http://...". Il te reste juste à fournir la méthode et les outils de conversion et de production des .pch, afin que chacun puisse vérifier que les sources que tu donnes en référence sont bien à l'origine des .hdr fournis.

La GPL n'impose pas de distribuer les sources avec le programme qui les utilise. Elle impose de les rendre disponibles (quel que soit le moyen).

Thibaut (./69) :
Au fait, c'était quoi le problème avec les sources de la bibliothèque de GTC ?C'était le fait qu'elles ne soient pas distribuées ?

Oui.

Pollux, tu les as modifiées ? (mis à part les adaptations de syntaxe, puisque ça ne change rien à la sémantique)
Si tu ne les as pas modifiées en dehors de la syntaxe, je ne suis vraiment pas sûr que tu sois obligé de les distribuer, ni de distribuer leur licence. Il te suffit de dire "Les sources de la bibliothèques sont celles de TIGCC 0.94 que vous pouvez télécharger là : http://...".

Non.
http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary
http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

La GPL n'impose pas de distribuer les sources avec le programme qui les utilise. Elle impose de les rendre disponibles (quel que soit le moyen).

Non. Elle impose de distribuer les sources avec le programme (section 3a), ou de proposer une offre écrite (sur papier! Donc pas appliquable à la distribution en ligne) valable pour au moins 3 années pour avoir les sources (section 3b).
http://www.gnu.org/licenses/gpl-faq.html#AnonFTPAndSendSources

Je ne suis pas si sûr que toi. Je prends l'exemple du fournisseur d'accès Free, en France, à qui on a reproché de violer la GPL. Le service juridique de Free s'est défendu face à la FSF en expliquant que tous les éléments GPL contenus dans leur modem n'ont pas été modifiés et que leur source est disponible sur Internet.

D'ailleurs, j'ai déjà vu plusieurs programmes pour PC sans sources, avec cette inscription dans le readme : "si vous voulez les sources, écrivez-moi à xxx@xxx.xxx"

Thibaut (./71) :
Je ne suis pas si sûr que toi. Je prends l'exemple du fournisseur d'accès Free, en France, à qui on a reproché de violer la GPL. Le service juridique de Free s'est défendu face à la FSF en expliquant que tous les éléments GPL contenus dans leur modem n'ont pas été modifiés et que leur source est disponible sur Internet.

Et ça a été laissé passer?

En Allemagne, il y a eu des injonctions contre les entreprises qui ont fait ça, les juges ont partagé l'interprétation de la FSF (et de Harald Welte de http://www.gpl-violations.org qui a porté plainte), il faut distribuer les sources même si elles n'ont pas été modifiées.

D'ailleurs, j'ai déjà vu plusieurs programmes pour PC sans sources, avec cette inscription dans le readme : "si vous voulez les sources, écrivez-moi à xxx@xxx.xxx"

C'est illégal (pour un logiciel sous GPL évidemment; et si tout le code est de l'auteur, il n'est pas obligé de respecter sa propre licence même si c'est con de mettre une licence et de ne pas la respecter soi-mêmes; mais s'il utilise du code d'autres personnes sous GPL, c'est illégal).

Où as-tu lu que l'indication de l'endroit où sont disponibles les sources ne peut être écrit que sur papier ?

C'est l'interprétation de la FSF du mot "written", et comme c'est eux qui ont fait la licence, je suppose qu'ils savent ce qu'ils font.

Et de toute façon, "si vous voulez les sources, écrivez-moi à xxx@xxx.xxx" est aussi illégal parce qu'il n'y a pas écrit "cette offre est valide jusqu'à xyz" où xyz est au moins 3 années après que cette version particulière soit diffusée pour la dernière fois. Et il faut être prêts à fournir les sources de n'importe quelle vieille version de moins de 3 ans, pas de la plus récente. Et à n'importe qui, aussi, parce que l'offre peut être faite passer à quelqu'un d'autre sous le paragraphe 3c.

mmh....

Oui, Free est le miroir de plein de trucs. Ils font aussi du streaming audio (gratos ? je sais pas) par exemple pour Fréquence 3.

C'est surtout que ce n'est pas çà leur défense. Leur défense est de dire que le modem fait parti du réseau free et n'est pas loué ni vendu au particulier, mais déposé chez lui.

Oui, aussi.

> D'ailleurs, le mot nostub ne veut plus rien dire, vu la taille du stub (certains diront "micro-kernel") qui est mis d'office dans chaque programme.
Comme dit en page 2, il faut dire "AMS native", comme je le fais depuis longtemps

A l'époque où le kernel dominant était le salement programmé DoorsOS, et que nombre de programmes précédemment écrits ne fonctionnaient que sur HW1 à cause par exemple de l'utilisation d'adresses absolues pour écrire dans les variables du système, carrément pas.

Je connais cette époque en tant qu'utilisateur, puisque ça correspond à la 1ère, où j'ai commencé à utiliser une 89 en classe. Mes camarades me passaient des jeux presque tous kernel-based. J'ai eu beaucoup de plantages (qui ne nécessitaient pas forcément un reset, mais des Address Error ou Illegal Instruction peuvent laisser AMS dans des états incorrects) sur ma 89 HW2.
En Terminale, j'ai propagé nombre d'updates (txtrider et UniOS compris) sur les calculatrices de mes camarades. Et c'est en me basant sur cette expérience d'administration des machines des camarades, que je suis contre la compatibilité on-calc: la compatibilité on-calc apporte des programmes toujours plus gros, jusqu'à des kilo-octets (essais sur Ice Hockey 68k et TICT-Explorer, projection sur TI-Chess par le simple doublement des graphismes et du keyboard handling, etc.), et marginalement plus lents, pour une faible minorité de calculatrices (de mémoire, 1:7 dans ma classe de Terminale, et l'autre classe comportait également une forte majorité de 89).

> D'un autre côté, gagner la compatibilité on-calc pour 1 ko perdu, je reste preneur.
C'est souvent beaucoup plus que ça... ~3K en changeant les USE_* de Ice Hockey 68k, sans rien optimiser d'autre (les graphismes doublés, notamment). A peu près pareil sur TICT-Explorer, qui est plus petit. Plus de 10K (!) sur TI-Chess (2 * LCD_SIZE pour le background; plusieurs jeux de sprites; plusieurs KB pour les touches).
(Je parle des tailles de code non compressé, celles qui importent à l'exécution)
> Question de point de vue (attends, je vais te choper demain le binaire pour ta v200, parceque là, j'ai que le 89 ).
C'était un problème que j'ai effectivement rencontré à l'époque (je l'ai mentionné dans S1P9 mais pas ici), parce que les machines avaient été pour la plupart achetées avant que la livraison du câble avec soit standard. Ce n'est plus vrai depuis environ 2002, donc cet argument est moins valide depuis un certain temps

> Faire de la compatibilité on-calc demande aussi de coder en conséquence
Presque toujours, oui.

> et encore une fois, le kernel fait gagner beaucoup de ce point de vue-là.
?
Ca ne fait gagner ni sur la partie graphique (il faut coder deux interfaces graphiques quand même), ni sur les touches (overhead comparable à l'option de ld-tigcc qui permet d'optimiser les constantes au niveau du link, ce qui reste loin de l'optimisation en temps de compilation). Et c'est pareil d'écrire les pseudo-constantes de touches et les RAM_CALLs.

Ce n'est pas l'incompatibilité on-calc qui empêche les gens d'utiliser un programme

Martial Demolins (./81) :
De quelque manière qu'on l'appelle, le développement de la programmation en nostub éatit pour moi une erreur de concept.

"était" parce que ça ne l'est plus?

Et c'est le mode kernel l'erreur de concept, c'est au programme de s'adapter à la plateforme, pas l'inverse.

Martial Demolins (./83) :
Ce que je n'aime pas dans le nostub, c'et la non-compatibilité des binaires avec les nouveaux AMS/HW. Ca n'existe pas pour un programme kernel bien codé (surtout vu la stabilité énorme de PreOS et les ram calls qu'il procure).

Ça s'est vu avec AMS 1.05, puis 2.0x. Dans certains cas aussi 2.04, 2.07, 3.00 et 3.10. À chaque fois du cassage.

Et la seule raison pour laquelle il y a compatibilité apparente sur la Titanium est que PpHd s'amuse à patcher les programmes dans le kernel sans rien demander à l'utilisateur, ce que je trouve une très mauvaise idée (si le programme n'était pas archivé, il est modifié sans préavis et va planter s'il est envoyé à autre chose qu'une Titanium). Un outil comme GhostBuster est plus adapté (ne fait rien sans demander l'avis de l'utilisateur, on n'est pas obligés de patcher les programmes qui n'en ont pas besoin et risquer un faux positif qui casse le programme, patche aussi des problèmes que PreOs ne peut pas patcher, par exemple tout programme utilisant une ancienne version des niveaux de gris de TIGCCLIB ne fonctionnera pas avec l'autopatcheur de PreOs, permet aussi d'enregistrer la version patchée sous un autre nom pour garder une version qui peut être envoyée aux autres calculatrices).

Martial Demolins (./85) :
Faire de la compatibilité on-calc demande aussi de coder en conséquence, et encore une fois, le kernel fait gagner beaucoup de ce point de vue-là.

Comment? La seule fonctionnalité que le kernel propose pour ça, c'est l'EXTRA_RAM_TABLE que tu n'utilises même pas (parce que tu as bien reconnu qu'elle ne sert pas à grand chose).

Lionel Debroux (./86) :
Ce n'est pas l'incompatibilité on-calc qui empêche les gens d'utiliser un programme

Si "Wrong calculator model" n'est pas empêcher les gens d'utiliser un programme, c'est quoi? Si un programme est passé de calculatrice à calculatrice, il est censé fonctionner.

Kevin Kofler (./88) :
Et la seule raison pour laquelle il y a compatibilité apparente sur la Titanium est que PpHd s'amuse à patcher les programmes dans le kernel sans rien demander à l'utilisateur, ce que je trouve une très mauvaise idée (si le programme n'était pas archivé, il est modifié sans préavis et va planter s'il est envoyé à autre chose qu'une Titanium). Un outil comme GhostBuster est plus adapté (ne fait rien sans demander l'avis de l'utilisateur, on n'est pas obligés de patcher les programmes qui n'en ont pas besoin et risquer un faux positif qui casse le programme, patche aussi des problèmes que PreOs ne peut pas patcher, par exemple tout programme utilisant une ancienne version des niveaux de gris de TIGCCLIB ne fonctionnera pas avec l'autopatcheur de PreOs, permet aussi d'enregistrer la version patchée sous un autre nom pour garder une version qui peut être envoyée aux autres calculatrices).

Installe le alors avec preos("strict_calculator")
Il sera strict sur la variable CALCULATOR.