TIGCC :: Lib kernel? - Page 3

l'equipe originel de TIGCC etait prokernel. mais bon

Pour se qui est du kernel et des prog qu'on a maintenant sur les TI si les fraancais avec leur langue de *** etait pas la, je croit que la "communauté tigcc" serait pas se qu'elle est.

D'ailleur ayont chacun une minute de non post en mémore du fabuleux forum de robi (pour l'epoque)

Kevin > Ce n'est pas un hors-sujet. Je lui ai demandé pourquoi il veut absolument faire une librairie dynamique, ce qui est tout à fait dans le cadre du sujet.
C'est du même niveau que moi quand j'avais posté un lien vers GraphX et Xlib quand un débutant avait demandé de l'aide sur le double-buffering sur votre forum. Je lui proposais comme alternative des libs qui évitent d'avoir à s'en occuper. Comme toi qui proposes une alternative aux libs dynamiques.

Kevin, sois tu arrêtes ta propagande et tes hors-sujets, soit tu arrêtes de censurer les hors-sujets sur le forum de la TICT.
Et je suis d'accord avec ce que dit sBibi : tu contribues rarement à donner une bonne image de la communauté TICT/TIGCC, par ton manque total d'objectivité.

XDanger : des attaques paersonnelles, oui, il y en a eu, j'en suis conscient. Mais que faire d'autre face à un Kevin décidément très insupportable en ce moment ?
Compte le nombre de gens qui geulent sur Kevin à la page précédente, il y a comme un ras-le-bol général.
Quant à ce que tu dis (dans le post sur un topic kernel/nostub sur votre forum), je suis surpris par ta pensée

Merci sBibi Tout n'est pas perdu sur ce forum

> l'equipe originel de TIGCC etait prokernel. mais bon
Ah tiens, je ne savais pas que Zeljko Juric était pro-kernel... Pourquoi alors a-t-il défriché ROM_CALLs, qui n'avaient aucun intérêt puisque le kernel en remplaçait la plupart (c'est à dire bouffait de la place pour doubler les fonctions du système, en utilisant des méthodes pas toujours propres, stables et compatibles avec des versions futures de hardware et/ou de software en utilisant notamment des valeurs câblées en dur, alors que de futures versions de hardware et de software n'étaient pas extrêmement improbables) ?

> Quant à ce que tu dis (dans le post sur un topic kernel/nostub sur votre forum), je suis surpris par ta pensée
Il y a des fois où je m'énerve quand les autres postent des conneries... Le mal est déjà fait, donc je ne vais pas présenter d'excuses. Je me comporte parfois comme ceux que je critique, OK. Comme quoi, la colère est mauvaise conseillère...
Je tiens à féliciter certains, notamment Thibaut, d'être resté modérés après ce que j'ai posté. En revanche, je vois qu'il n'y a plus moyen de s'entendre avec Vertyos, qui va augmenter la liste de ceux avec qui j'ai/j'ai eu des problèmes...

En revanche, je me souviendrai des arguments de Vertyos "Si tu viens sur un forum tu dois en accepter les règles" et autres...
Accepter les règles ne veut pas dire ne pas dire ce qui, à mon avis, ne va pas.
Je dis et je répète: les admins ne foutent rien pour assurer la paix sur ce forum ! Je vois certains qui sur le FlashChat, en réponse à "!seen xxx", répondent "xxx n'a pas été vu depuis [un certain temps]" ou "xxx est quelque part sur le site". Pour moi, être admin, ça n'est pas ça...

Je dis et je répète qu'il est possible que je ne sois jamais venu ici, s'il y avait eu des admins ici...

heu c un bot qui réponds xxx n'a pas ete vu depuis xxx temps... c pas un admin qui passe la journée derrière le pc

LOL XDanger je savais pas que t'étais aussi

Au temps pour moi. Ca me paraissait évidemment bizarre qu'un admin soit là aussi souvent et aussi longtemps, mais les trucs étant postés par un pseudo qui existe...

XDanger a écrit :
En revanche, je vois qu'il n'y a plus moyen de s'entendre avec Vertyos, qui va augmenter la liste de ceux avec qui j'ai/j'ai eu des problèmes...

En revanche, je me souviendrai des arguments de Vertyos "Si tu viens sur un forum tu dois en accepter les règles" et autres... Accepter les règles ne veut pas dire ne pas dire ce qui, à mon avis, ne va pas.

Je vais augmenter la liste de ceux avec qui tu as des problèmes. Mais dis moi, j'imagine que dans ton esprit le problème vient à chaque fois de "l'autre" ? Autrement dit à chaque fois que tu t'étais engleulé avec quelqun c'était de sa faute, bien sûr ?
Tu ne t'es jamais remis en cause ?

Alors tu a encore beaucoup à gagner en lucidité. Ce forum est très bien, et avant que tu ne débarque personne ne se plaignait comme tu le fais. Si tu n'est pas capable de suivre un débat sans éprouver le besoin de censurer ceux qui se dressent contre toi, je le répete, casse toi et retourne sur le forum de la TICT, tu y étais beaucoup mieux.

On a pas les mêmes idées que toi ? Tant pis. N'espere pas répendre ton idéal ici, il ne convient à personne.

XDanger
a écrit : Au temps pour moi. Ca me paraissait évidemment bizarre qu'un admin soit là aussi souvent et aussi longtemps, mais les trucs étant postés par un pseudo qui existe...

Boo est un bot, aussi bien sur le FlashChat que dans la liste des connectés.

XDanger a écrit :
> l'equipe originel de TIGCC etait prokernel. mais bon Ah tiens, je ne savais pas que Zeljko Juric était pro-kernel... [...Strip...] ?

Il me semvle pas que Zeljko Juric fasse partit de la team originale de TIGCC, de se que j'en sache le projet a été lancé par Xavier Vassor, auteur de DoorsOs et quelque un de ses amis. Il on été rejoin APRES par Zeljko et les autres.

Je vois certains qui sur le FlashChat, en réponse à "!seen xxx", répondent "xxx n'a pas été vu depuis [un certain temps]" ou "xxx est quelque part sur le site". Pour moi, être admin, ça n'est pas ça...

(et j'en passe)
Tu croit vraiment que Boo est un admin qui reste collé 24h/24 devant yaronet ??
Hé bé

Nan, mais quand même, au fond XDanger a raison, je trouve.
Les insultes et les attaques personnelles sont à virer par les admins.

c aussi un peu aux usagers de prendre leur responsabilité on passe pas forcémment notre journée à lire le forum

>Ce forum est très bien, et avant que tu ne débarque personne ne se plaignait comme tu le fais.
>Mais dis moi, j'imagine que dans ton esprit le problème vient à chaque fois de "l'autre" ? Autrement dit à chaque fois que tu t'étais engleulé avec quelqun c'était de sa faute, bien sûr ? Tu ne t'es jamais remis en cause ?
>Si tu n'est pas capable de suivre un débat sans éprouver le besoin de censurer ceux qui se dressent contre toi, je le répete, casse toi et retourne sur le forum de la TICT, tu y étais beaucoup mieux.
Impressionnant. Je ne poursuivrai pas la discussion avec quelqu'un qui se méprend sur moi à ce point.

xdanger-> tu n'as jamais pointé le curseur sur Boo dans la liste des connectés

> Boo est un bot, aussi bien sur le FlashChat que dans la liste des connectés.
Merci de m'en informer. Boo a un @ rouge exactement comme yAro...

> c aussi un peu aux usagers de prendre leur responsabilité on passe pas forcémment notre journée à lire le forum
D'accord. Mais si les usagers en sont incapables ?

jackiechan a écrit :
Nan, mais quand même, au fond XDanger a raison, je trouve. Les insultes et les attaques personnelles sont à virer par les admins.

Si un post te plai pas, tu clique sur le de sa barre de status !

Boo a un @ bleu...

XDanger > je suis pas payé pour ça , je le fais volontairement et quand il y a trop de problème on intervient. On ne peut pas lêtre partout. C'est aussi à vous de nous prévenir quand un post part en couille

> Si un post te plai pas, tu clique sur le <http://yn1.free.fr/bleue2/horn.gif> de sa barre de status !
Et tu manques éventuellement une partie du sujet, parce qu'au milieu des insultes, ceux qui postent peuvent avoir quelque chose à dire... Ca n'est pas une très bonne solution à mon avis.

XDanger
a écrit : Impressionnant. Je ne poursuivrai pas la discussion avec quelqu'un qui se méprend sur moi à ce point.

Je te retourne l'image que tu donne sur ce forum, et je ne suis pas le seul à te voir comme ça, loin de là. Il ne tient qu'à toi de changer. Encore une fois, soi un peu plus critique envers toi même...

on peut aussi éditer les posts pour supprimer des parties.
le klaxon n'implique pas le lock direct

je sais sur un de mes forum g cliqué dessus sans faire expré g raté le 'ip'
ya boo qui ma envoyé un mini message

> Boo a un @ bleu...
Je n'ai pas bien regardé... On va arrêter avec "Boo"...

> C'est aussi à vous de nous prévenir quand un post part en couille
C'est vrai. Ca part souvent dans le décor...

> Je te retourne l'image que tu donne sur ce forum, et je ne suis pas le seul à te voir comme ça, loin de là. Il ne tient qu'à toi de changer. Encore une fois, soi un peu plus critique envers toi même...
Il ne tient qu'à vous de ne pas dire n'importe quoi, et il tient à moi de ne pas m'énerver, même quand vous dites n'importe quoi...
Etre un peu plus critique envers moi-même: je suis prêt à reconnaître mes torts, quand je suis calme.

He bien alors calme toi et relis ce topic de meilleure humeur...

Prog C / Libs kernels


>des grands noms de la programmation TI:
>Thomas Nussbaumer, Zeljko Juric, Kevin Kofler, Greg Dietsche, Scott Noveck, Samuel Stearley
Desole. Nous n'avons pas les meme references de 'Grandes Personnes'.


>Ceux qui ont des couilles, qu'ils viennent faire un débat kernel/_nostub et lib dynamique/lib statique sur le forum de TIGCC/TICT !
Ok, dans quels topics ? Off-topic ?
Mais je vais preparer soigneusement mes arguments en epluchant tous les debats de ce genre syr yaronet. Ca va saigner.

>Pour tous:
Arreter ces insultes personnelles, s'il-vous-plait. Oubliez votre sang chaud de latin.

>Kevin:
>Je parle des librairies sur TI-89/92+/V200 là.
Peut etre. Alors tu as fait une bourde technologique. Car meme si elles sont apparues apres, elles sont technologiquement inferieures aux libraries dynamiques.

>Sauf en cas de changement d'API ou d'ABI de la part de la librairie, auquel cas on a plusieurs versions de la librairie toutes incompatibles entre elles.
Bien sûr ! Mais c'est strictement interdit lorsqu'on fait une librairie dynamique.
De toute facon, je ne conseille pas de changer d'ABI pour une lib statique. Ca peut provoquer des bugs si on utilise de l'assembleur.
Bref, c'est une tres mauvaise idee de changer l'ABI.

>C'est un avantage. Ça permet de mettre à jour la librairie dans un programme sans toucher au fonctionnement des autres. La librairie peut donc changer son ABI sans que ça ne dérange qui que ce soit.

>Et les changements d'ABI permettent pas mal de changements sans toucher à la compatibilité source:
>* ajout de nouveaux champs à une structure
>* changements de fonctions en macros ou vice-versa
>* changements de convention d'appel
>Et la librairie peut même changer son API. Il suffira de changer quelques lignes de code avant de recompiler. Alors qu'avec une librairie dynamique, c'est le bazar.

Ce que tu sous-entends est que faire une librairie dynamque necessite bien plus de rigueur que pour ceux faisant une librarie statique. C'est tout a fait vrai ! Il faut etre rigoureux lorsqu'on fait une librarie dynamique et se tenir a l'ABI qu'on s'est fixe. Il faut donc avoir une certaine experience. Une fois cette experience acquise, l'ABI n'a vraiment plus aucune chance d'evoluer.
La seule possibilite d'evolution est de voir un tout nouveau concept dans l'approche des fonctionnalites de la librairie... qui entrainera irremediablement une nouvelle version. (version 2 par exemple).


>1. Il suffit normalement d'avoir les sources de la librairie et de patcher l'exécutable.
>2. Je ne vois pas en quoi c'est un problème. Ça prend 5 minutes pour l'auteur de recompiler son programme.
Faux:
1. il doit se tenir au courant des evolutions des libraries, donc REGULIEREMENT frequenter les sites internets officiels de ces libraries.
2. Telecharger la nouvelle version de la librarie.
3. Verifier qu'il n'y ait pas d'incompatibilite avec la version precedente.
4. Corriger les erreurs suceptibles de survenir a cause d'incompatibilite.
5. Compiler le programme.
6. Donner son programme a ces testeurs, car on ne peut se permettre de distribuer un programme buggue : meme si l'erreur provient de la librarie, l'utilisateur ne pourra jamais accuse que le programme.
7. Distribuer son programme sur son site.
8. Avertir les utilisateurs d'une mise a jour.
Bref, au minimum 4 bonnes heures si on veut faire les choses proprement.

Du cote de l'utilisateur, a la mise a jour d'une lib statique, il doit :
1. Telecharger TOUTES les nouvelles versions des differents programmes mises a jour (Cher paye si ce n'est juste qu'une bugue corrige dans la librarie).
2. Reinstaller le tout.

>Comment ça, ça se complexifie?
la phase de debuggage se complexifie.

>Je ne vois pas pourquoi il faut tolérer les attaques personnelles. Si quelqu'un dit "godzil est un fils de p**e", tu le trouves correct??? Et ce genre d'insultes n'apporte rien au débat.
Je suis d'accord.

>Ce qui explique aussi pourquoi vous programmez encore en mode kernel: en refusant d'apprendre l'anglais, vous vous isolez complètement du reste du monde, qui a déjà arrêté la programmation pour kernel depuis longtemps.
Tu savais que Fransesco a fait une version personnelle d'EBook Reader en kernel
Il m'avait demande conseil pour un bug de compilation
J'ai l'impression que le monde pour toi c'est :
"Thomas Nussbaumer, Zeljko Juric, Greg Dietsche, Scott Noveck, Samuel Stearley"
(Reattaque personnelle, vas-y frappe moi, tu as raison).

>On n'est pas en justice ici.
Un debat se doit d'avoir des arbitres impartiaux.

>Parfois, pas toujours. Et ce n'est pas un bon argument.
C'est un argument. Qu'il soit bon ou mauvais est purement subjectif dans un tel debat.
Et franchement, c'est quand meme un bon argument.

>Non, je parle du concept de librairies statiques sur TI-89/92+/V200...
Ca n'a rien d'un concept novateur.
Ca fonctionnait tres bien sous Fargo...

>>Je n'ai jamais entendu dire PpHd, TiMad, nEUrOO ou Thibaut dire "UTILISE xxxLib, le reste c de la merde faut surtout pas utiliser le reste"
>Tu n'as pas bien regardé alors.
J'avour que j'ai du dire quelques fois 'utilise genlib'. Mais j'ai du argumenter (sauf si j'etais fatigue).

>Reviens quand tu as une excuse meilleure.
Sur ce forum, enormement de posts sont au second voire au troisieme degre.
Pense toujours au caractere de la personne lorsque tu lis un message. Ca evitera les contre-sens.

>C'est une solution bâtarde et stupide. Soit on choisit une solution, soit on choisit l'autre. Mais si on mélange les 2, ça crée plein de problèmes (problèmes de mise à jour par exemple - comment faire en sorte que la partie statique soit toujours la même version que la partie dynamique, et cela pour tous les programmes présents sur la calculatrice???).
On utilise mon programme de convertion de librairies statiques en librarie dynamique par exemple (Cf TimeToTeam\Preos\Tigcclib)

>comment faire en sorte que la partie statique soit toujours la même version que la partie dynamique, et cela pour tous les programmes présents sur la calculatrice???
C'est bien le probleme des libraries statiques.

>Les avantages du _nostub sont bien plus importants que ses désavantages. Les avantages touchent à des domaines importants comme la simplicité d'utilisation, les désavantages ne sont qu'à niveau interne, donc complètement invisibles pour l'utilisateur.
Pas pour un utilisateur initie.
Et le desavantage premier du kernel (devoir l'installer a chaque reset) est quand meme bien faible. Meme le plus idiot peut le faire.

>Il ne s'agit pas d'une émulation de processeur, mais d'une "émulation" de système d'exploitation. "Émulation" n'est peut-être pas le bon mot, mais il n'y a pas de mot simple et bien défini pour décrire ce qu'un kernel fait. Peut-être "compatibility layer"... Mais peut-on parler de compatibilité avec un système d'exploitation inexistant?
Il y a un mot : 'MidWare'.

>Il faut distinguer entre stub, entête et code de démarrage. Ce sont 3 concepts totalement différents. Un stub est un morceau de code qui appelle un TSR ou une DLL en dehors du programme, et c'est ce TSR ou cette DLL qui exécute réellement le programme "stubbé". Mon header (cf. standard de commentaires _nostub) n'a rien à voir avec un stub. De la même manière, le code de tipatch.lib est du startup code (code de démarrage), pas un stub.

Problemes de definition. Mais ca prend beaucoup de place.

XDanger a écrit :
> l'equipe originel de TIGCC etait prokernel. mais bon Ah tiens, je ne savais pas que Zeljko Juric était pro-kernel...

Les premiers membres de l'équipe de TIGCC étaient Xavier Vassor et Jean Canazzi (Blue_Z). Ils étaient pro-kernel. Xavier Vassor l'est encore, Blue_Z plus vraiment.
Ensuite, en janvier 2000, Zeljko a lancé sa TIGCCLIB, qui était toujours pro-nostub, et depuis février 2000, elle fait partie de TIGCC. Il a rejoint l'équipe en juin 2000 en même temps que Sebastian Reichelt, quand il a été décidé que TIGCC, TIGCCLIB et TIGCC IDE seront désormais maintenues en un seul projet. Les membres fondateurs n'étaient plus vraiment impliqués, et donc Zeljko et Sebastian ont pris la tête du projet. C'est depuis ce moment que la direction est plutôt anti-kernel. Même si je signale que le mode kernel a toujours été supporté est l'est toujours.
Enfin, pour le troisième membre actif: j'ai rejoint l'équipe de TIGCC en travaillant sur A68k. J'ai commencé en tant que mainteneur de A68k en juillet 2001. J'ai officiellement rejoint l'équipe en novembre 2001. Je suis maintenant mainteneur de A68k, GCC et GNU Binutils. Et j'ai écrit pas mal de code pour ld-tigcc, le nouveau linker qui accompagnera TIGCC 0.95, même si le mainteneur et l'auteur principal est toujours Sebastian. J'ai aussi écrit quelques trucs pour TIGCCLIB, mais pas beaucoup (en attendant que les niveaux de gris à 3 plans, les fonctions *scanf et les commentaires _nostub soient intégrés ).

Vertyos a écrit :
Je vais augmenter la liste de ceux avec qui tu as des problèmes. Mais dis moi, j'imagine que dans ton esprit le problème vient à chaque fois de "l'autre" ? Autrement dit à chaque fois que tu t'étais engleulé avec quelqun c'était de sa faute, bien sûr ? Tu ne t'es jamais remis en cause ?

Comme par hasard, ma liste ressemble beaucoup à la sienne. Donc je ne pense pas que ce soit exclusivement de sa faute...

Alors tu a encore beaucoup à gagner en lucidité. Ce forum est très bien, et avant que tu ne débarque personne ne se plaignait comme tu le fais.

Si, il y a moi. Je me rappelle encore les beaux temps où yAro faisait encore le "dictateur".

Kevin Kofler
a écrit : Comme par hasard, ma liste ressemble beaucoup à la sienne. Donc je ne pense pas que ce soit exclusivement de sa faute...

comme par hasard vous avez toujours les mêmes idées et le même avis ...

PpHd a écrit :
>des grands noms de la programmation TI:
>Thomas Nussbaumer, Zeljko Juric, Kevin Kofler, Greg Dietsche, Scott Noveck, Samuel Stearley Desole. Nous n'avons pas les meme references de 'Grandes Personnes'.

Ce sont qui, les "grands" encore présents dans la communauté alors? Parce que c'est ce qui compte pour un forum: que les "grands" parmi ceux qui sont encore actifs y soient. Évidemment qu'on ne va pas y trouver David Ellsworth...

>Ceux qui ont des couilles, qu'ils viennent faire un débat kernel/_nostub et lib dynamique/lib statique sur le forum de TIGCC/TICT ! Ok, dans quels topics ? Off-topic ?

Euh... À la limite, ça devrait être tolérable même dans TIGCC Programming, mais dans ce cas, la limite de ce qui est accepté dans le topic sera bien plus stricte.

>Kevin:
>Je parle des librairies sur TI-89/92+/V200 là. Peut etre. Alors tu as fait une bourde technologique. Car meme si elles sont apparues apres, elles sont technologiquement inferieures aux libraries dynamiques.

Non, c'est le contraire: même si les librairies dynamiques en général sont apparues après les librairies statiques, elles sont techniquement inférieures. J'ai déjà dit pourquoi:

Et comme elles sont plus pratiques que les librairies dynamiques (pas de fonctions inutilisées sur la calculatrice, l'utilisateur ne doit pas s'occuper d'installer les librairies parce que l'éditeur de liens (linkeur) le fait pour lui etc.), elles sont techniquement supérieures.

>Sauf en cas de changement d'API ou d'ABI de la part de la librairie, auquel cas on a plusieurs versions de la librairie toutes incompatibles entre elles. Bien sûr ! Mais c'est strictement interdit lorsqu'on fait une librairie dynamique.

Voilà une bonne raison pour laquelle les librairies statiques sont plus pratiques.

De toute facon, je ne conseille pas de changer d'ABI pour une lib statique. Ca peut provoquer des bugs si on utilise de l'assembleur. Bref, c'est une tres mauvaise idee de changer l'ABI.

Tant pis. Si on programme en assembleur, il faut être prêt à adapter légèrement son code si on utilise une nouvelle version de ses librairies. Ou alors on continue à utiliser l'ancienne version, ça ne dérangera personne.
Cela dit, l'auteur de la librairie est toujours libre de décider en faveur d'une ABI stable. Par exemple, je compte garder l'ABI de dataext.a (la librairie statique pour les commentaires _nostub) inchangée.

>C'est un avantage. Ça permet de mettre à jour la librairie dans un programme sans toucher au fonctionnement des autres. La librairie peut donc changer son ABI sans que ça ne dérange qui que ce soit.

>Et les changements d'ABI permettent pas mal de changements sans toucher à la compatibilité source:
>* ajout de nouveaux champs à une structure
>* changements de fonctions en macros ou vice-versa
>* changements de convention d'appel
>Et la librairie peut même changer son API. Il suffira de changer quelques lignes de code avant de recompiler. Alors qu'avec une librairie dynamique, c'est le bazar.
Ce que tu sous-entends est que faire une librairie dynamque necessite bien plus de rigueur que pour ceux faisant une librarie statique. C'est tout a fait vrai ! Il faut etre rigoureux lorsqu'on fait une librarie dynamique et se tenir a l'ABI qu'on s'est fixe. Il faut donc avoir une certaine experience. Une fois cette experience acquise, l'ABI n'a vraiment plus aucune chance d'evoluer.

Sûr? Tu as dit toi-même que dans genlib, certaines parties de l'ABI et même de l'API pourraient être améliorées.

La seule possibilite d'evolution est de voir un tout nouveau concept dans l'approche des fonctionnalites de la librairie... qui entrainera irremediablement une nouvelle version. (version 2 par exemple).

Version qui a de bonnes chances d'être incompatible avec la version 1 dans les 2 sens, vu qu'il y a "un tout nouveau concept dans l'approche des fonctionnalites de la librairie". Donc 2 copies (entières, pas seulement partielles comme pour les librairies statiques) de la librairie on-calc. N'est-ce pas exactement ce que la librairie dynamique est censée empêcher?

>1. Il suffit normalement d'avoir les sources de la librairie et de patcher l'exécutable.
>2. Je ne vois pas en quoi c'est un problème. Ça prend 5 minutes pour l'auteur de recompiler son programme.
Faux: 1. il doit se tenir au courant des evolutions des libraries, donc REGULIEREMENT frequenter les sites internets officiels de ces libraries.

"Régulièrement" dans le sens de "périodiquement". Mais pas extrêmement fréquemment. S'il va voir chaque mois, ça suffit. Et puis, personnellement, j'envoie souvent des mails aux utilisateurs de h220xtsr.a pour leur rappeler de mettre à jour h220xTSR. Tu as déjà pu le voir d'ailleurs. Ça résout plus ou moins ce problème-là.

2. Telecharger la nouvelle version de la librarie.

Ce n'est pas si long que ça.

3. Verifier qu'il n'y ait pas d'incompatibilite avec la version precedente.

* Même chose pour une librairie dynamique.
* Peu probable si la librairie est bien faite.

4. Corriger les erreurs suceptibles de survenir a cause d'incompatibilite.

* Même chose pour une librairie dynamique.
* Peu probable si la librairie est bien faite.

5. Compiler le programme.

1 minute.

6. Donner son programme a ces testeurs, car on ne peut se permettre de distribuer un programme buggue : meme si l'erreur provient de la librarie, l'utilisateur ne pourra jamais accuse que le programme.

Personnellement, je teste moi-même, et si ça marche, c'est bon. S'il y a un problème, qu'on me le reporte et je le corrigerai, souvent le même jour.

7. Distribuer son programme sur son site.

C'est souvent ce qui me prend le plus de temps parmi toutes ces étapes. Mais c'est parce que mon site est en 4 langues et en 100% HTML (pas de PHP).

8. Avertir les utilisateurs d'une mise a jour.

Un message ici et un sur le forum de la TICT. 5 minutes.

Bref, au minimum 4 bonnes heures si on veut faire les choses proprement.

Moi, ça me prend 1 heure au pire.

Et avec une librairie dynamique:
* c'est l'utilisateur qui se tape les étapes 1-3
* en cas de problèmes, le programmeur se tape les étapes 4-8 exactement comme pour une librairie statique. Et cela même si la nouvelle version de la librairie dynamique ne lui apporte rien! Alors que pour une librairie statique, il se tape les étapes 4-8 seulement si la mise à jour lui apporte quelque chose.

Du cote de l'utilisateur, a la mise a jour d'une lib statique, il doit :
1. Telecharger TOUTES les nouvelles versions des differents programmes mises a jour (Cher paye si ce n'est juste qu'une bugue corrige dans la librarie). 2. Reinstaller le tout.

En général, l'utilisateur ne met à jour que s'il y a un problème. Et dans le cas d'une librairie statique, il sait quoi mettre à jour: le programme qui pose problème. Dans le cas d'une librairie dynamique, il doit mettre à jour le programme et toutes les librairies que ce programme utilise (y compris le kernel) pour être sûr que le problème n'est pas dû à l'utilisation d'anciennes versions.

>Comment ça, ça se complexifie? la phase de debuggage se complexifie.

Seulement si la mise à jour entraîne un problème. Si les librairies sont bien faites, ça a peu de chances de se produire. Et encore une fois, c'est la même chose avec les librairies dynamiques: là aussi, il faut essayer toutes les combinaisons pour voir quelle librairie est à l'origine du problème.

>Ce qui explique aussi pourquoi vous programmez encore en mode kernel: en refusant d'apprendre l'anglais, vous vous isolez complètement du reste du monde, qui a déjà arrêté la programmation pour kernel depuis longtemps.
Tu savais que Fransesco a fait une version personnelle d'EBook Reader en kernel
Il m'avait demande conseil pour un bug de compilation

Mais pour son usage personnel seulement.

J'ai l'impression que le monde pour toi c'est :
"Thomas Nussbaumer, Zeljko Juric, Greg Dietsche, Scott Noveck, Samuel Stearley" (Reattaque personnelle, vas-y frappe moi, tu as raison).

Je parle des programmes publiés, pas de ceux faits pour l'usage personnel. S'il a toujours un kernel sur sa calculatrice, il peut programmer en mode kernel pour son usage personnel et ça ne dérangera personne. Ce sont les programmes sortis publiquement qui devraient être en _nostub. Même si personnellement, je programme toujours en _nostub.

>Parfois, pas toujours. Et ce n'est pas un bon argument.
C'est un argument. Qu'il soit bon ou mauvais est purement subjectif dans un tel debat. Et franchement, c'est quand meme un bon argument.

Ce n'est pas un bon argument parce que la différence de vitesse n'est pas telle qu'elle ait une vraie importance.

>Non, je parle du concept de librairies statiques sur TI-89/92+/V200...
Ca n'a rien d'un concept novateur. Ca fonctionnait tres bien sous Fargo...

Non. Il n'y avait pas de système de .a dont seulement les fichiers objets vraiment utilisés seront automatiquement linkés.

>>Je n'ai jamais entendu dire PpHd, TiMad, nEUrOO ou Thibaut dire "UTILISE xxxLib, le reste c de la merde faut surtout pas utiliser le reste"
>Tu n'as pas bien regardé alors. J'avour que j'ai du dire quelques fois 'utilise genlib'. Mais j'ai du argumenter (sauf si j'etais fatigue).

Tu étais souvent fatigué alors.

>Reviens quand tu as une excuse meilleure. Sur ce forum, enormement de posts sont au second voire au troisieme degre.

C'est bien ce que je critique: le manque de sérieux...

>C'est une solution bâtarde et stupide. Soit on choisit une solution, soit on choisit l'autre. Mais si on mélange les 2, ça crée plein de problèmes (problèmes de mise à jour par exemple - comment faire en sorte que la partie statique soit toujours la même version que la partie dynamique, et cela pour tous les programmes présents sur la calculatrice???). On utilise mon programme de convertion de librairies statiques en librarie dynamique par exemple (Cf TimeToTeam\Preos\Tigcclib)

Ça ne résout pas le problème. Tu passes à côté de l'idée-même. Une réponse valable à ma question devra faire ça:
* sans linker dynamiquement la partie statique et
* sans linker statiquement la partie dynamique.
Sinon, on n'est plus dans le cas de figure cité.

>comment faire en sorte que la partie statique soit toujours la même version que la partie dynamique, et cela pour tous les programmes présents sur la calculatrice??? C'est bien le probleme des libraries statiques.

Non, c'est le problème des librairies dynamiques.
Non franchement, ce n'est pas le problème d'une des 2 méthodes, mais du mélange de ces 2 méthodes. Il n'y a pas de problème avec les librairies statiques seules (chaque programme utilise sa version et il n'y a pas de conflits). Avec les librairies dynamiques seules, il peut y avoir des problèmes de compatibilité entre programmes et librairies dynamiques (contrairement aux librairies statiques, où chaque programme utilise la version de la librairie pour laquelle il est prévu), mais en mettant une partie de la librairie en statique, ces problèmes sont pratiquement garantis.

>Les avantages du _nostub sont bien plus importants que ses désavantages. Les avantages touchent à des domaines importants comme la simplicité d'utilisation, les désavantages ne sont qu'à niveau interne, donc complètement invisibles pour l'utilisateur.
Pas pour un utilisateur initie. Et le desavantage premier du kernel (devoir l'installer a chaque reset) est quand meme bien faible. Meme le plus idiot peut le faire.

Il y en a plusieurs:
* devoir installer le kernel à chaque reset
* devoir mettre à jour le kernel régulièrement
etc.

Et dans le cas d'utilisation de librairies dynamiques, il y a aussi les désavantages d'utilisabilité des librairies dynamiques.

>Il ne s'agit pas d'une émulation de processeur, mais d'une "émulation" de système d'exploitation. "Émulation" n'est peut-être pas le bon mot, mais il n'y a pas de mot simple et bien défini pour décrire ce qu'un kernel fait. Peut-être "compatibility layer"... Mais peut-on parler de compatibilité avec un système d'exploitation inexistant? Il y a un mot : 'MidWare'.

Encore un néologisme.

>Il faut distinguer entre stub, entête et code de démarrage. Ce sont 3 concepts totalement différents. Un stub est un morceau de code qui appelle un TSR ou une DLL en dehors du programme, et c'est ce TSR ou cette DLL qui exécute réellement le programme "stubbé". Mon header (cf. standard de commentaires _nostub) n'a rien à voir avec un stub. De la même manière, le code de tipatch.lib est du startup code (code de démarrage), pas un stub.
Problemes de definition. Mais ca prend beaucoup de place.

Qu'est-ce qui "prend beaucoup de place"? Le code de démarrage? Le header de commentaires et autres données?

Vark
a écrit : comme par hasard vous avez toujours les mêmes idées et le même avis ...

Pas toujours. Par exemple, la TICT (Thomas et Lionel) préfère la compilation séparée pour les différents modèles de calculatrices, alors que moi, je préfère la compatibilité on-calc.