PpHd a écrit :
Stop ! Je te parle du niveau technologique a utilise.
Evidemment qu'une secreatire est mieux qu'un traitement de texte.
On se demande comment tu comptes utiliser ta secrétaire en lisant cela.
Ca arrive !
Pas si on sait ce qu'on fait. Une règle à suivre:
ne jamais copier les headers dans
Include.
Toujours les inclure au projet avec les
.a (et les garder dans le même répertoire que le projet lui-même), comme ça, quand on met à jour la librairie, il suffit de copier tous les fichiers par dessus ceux d'avant.
Pas tant que ca.
Sur TI-89/92+/V200 oui.
que veux-tu que je dises a part que c'est mal concu ?
C'est mal conçu parce que c'est une librairie dynamique.
En linkant
libstdc++ statiquement, on n'a pas ce problème.
Et qu'en penses plus faire du C++ avec des libs dynamiques et pas une tres bonne idee (Car les definitions des classes changent sans arret => Bon plantage).
Faut etre rigoureux. Encore plus en C++
Les 2 facteurs contribuent au problème. Les librairies dynamiques autant que le C++. La combinaison est fatale. Vive le C linké statiquement!
a condition d'utiliser le bon compilo (Ex: tigcc v0.93 a v0.94).
On a tout fait pour garder la compatibilité antérieure des sources. D'ailleurs, on entend souvent: "plus rien ne compile sans changements après mise à jour de
TIGCC" sans aucun exemple concret. Il faudrait vous mettre dans votre tête que ce n'est pas du tout notre intention, et que si ça arrive, c'est un
bogue à reporter
immédiatement, avant que des programmes commencent à dépendre du nouveau comportement!
Pas par tous ceux que ca auraient pu interresser.
Mais si. Ceux qui sont vraiment intéressés par ce qui se passe lisent
tous les topics. Et puis, il y a toujours une solution: remonter le topic en postant n'importe quoi.
Même un simple message "up" suffit.
Oui. Mais y'a une chance neanmoins.
Comme avec une librairie dynamique. Et la différence est qu'avec la librairie dynamique, tu es
obligé de t'adapter à la mise à jour. Pas avec la librairie statique.
Ca serait tellement mieux.
Ah, parce que pour toi, c'est mieux si 32767 (chiffre au hasard) personnes doivent faire le même travail plutôt que si une seule personne doit faire ce travail? Alors là, je ne suis pas du tout d'accord. Dans le premier cas, le travail est multiplié par 32767 par rapport au deuxième cas. Donc 32767 fois plus de temps perdu globalement.
Pas tout a fait... Y'a des trucs qui disparaissent
Quoi par exemple? On a supprimé 2-3 trucs qui étaient définis par erreur dans
compat.h, qui ne marchaient qu'en mode kernel et qui n'étaient jamais documentés (donc qu'il n'aurait jamais fallu utiliser), et c'est tout.
...
Un code de corruption de certificat ne prend pas plus d'une centaine d'octets...
Bonjour la protection de chez ti 
C'est une des raisons qui me poussent a mettre PedroM.
Tu n'as qu'à reporter le problème à TI. S'il y a une chose qu'ils prennent sérieusement, c'est la protection Flash. Ils ont bien fait en sorte que
MaxMem et
HW2Patch arrêtent de fonctionner à chaque mise à jour.
Forcement je suis le seul a l'offrir cet technologie. Et tout le monde (sauf, a la rigueur, Pollux) a ete d'accord.
Ça fait déjà un de tes utilisateurs qui est contre, et tu lui forces le changement par dessus. Ce n'est pas ce que j'appelle garder une API compatible. Tu n'as pas à changer le comportement des fonctions existantes de cette manière.
Mais il a fallu la patcher.
Il a fallu la recompiler et c'est tout. Thomas Nussbaumer l'a fait. Donc l'utilisateur n'a rien eu à patcher.
Ca n'a rien a voir !
Si, ça a quelque chose à voir. Le rapport est que j'ai été obligé de choisir les .o dont j'ai eu besoin à la main, et je peux te dire que c'est lourd. C'est tellement plus simple quand on a un .a tout prêt.
Et tu aurais pu les prendre des sources de PedroM
1. Ah, parce que les fonctions de
TIGCCLIB sont dans les sources de
Pedrom maintenant?
Je te signale que je parle des fonctions de
TIGCCLIB là, pas de celles de AMS. C'est peut-être aussi pour ça que tu n'as pas compris le rapport.
2. Pour remplacer les 2 ou 3 fonctions de la ROM qui me manquaient, j'y ai pensé, mais vu l'interdépendance entre tes fonctions, j'aurais été obligé de prendre la moitié de ta ROM juste pour avoir
DrawClipRect... J'ai fini par l'implémenter en termes de
MoveTo,
DrawTo et de hacks avec
tios::globals pour implémenter
SetCurClip et
SetCurAttr.
Mais suffit de mettre des fonctions qui n'utilisent que la lib dynamique ou que du calcul simple.
Ben justement, si les fonctions utilisent la librairie dynamique, tu crées une dépendance entre la partie statique et la partie dynamique, donc un risque de conflit de versions.
Oui. Plus de flexibilite. Toi utilisateur est libre de les mettre a jour.
Pour moi, c'est un désavantage: l'utilisateur est obligé de mettre à jour tout séparément, donc un travail significatif de recherche des versions les plus récentes de chaque librairie. Dans les cas des librairies statiques, il a beaucoup moins de travail à fournir.
Mon header kernel est + petit...
Écoute: juste en comptant les champs obligatoires du header kernel (et pour éviter toute confusion possible: je parle du header des programmes, pas de
kernel.h, évidemment), je compte une cinquantaine d'octets (je peux refaire le calcul pour avoir le chiffre exact). Et cela n'est que pour un header complètement vide, sans aucun relogement!
PpHd a écrit :
Et bonjour la compatibilite PedroM !!!!
Et dire que je comptais mettre un max d'ebook !!
Merci !!
Pleins-toi chez XDanger, c'est lui qui compte changer ça, pas moi.
Et comme dit dans l'autre topic, tu n'as qu'à implémenter
OO_GetAttr. Même s'il n'y a pas de vrai ACB, il faut quand-même renvoyer les informations les plus demandées. Les fontes en font partie. On n'est plus en 1999. Il faut penser à implémenter les fonctions AMS 2.
)
En linkant libstdc++ statiquement, on n'a pas ce problème.
C'est une des raisons qui me poussent a mettre PedroM.
