Kernel vs Nostub? - Page 22

XDanger a écrit :
>Oui mais une de vos revendications (relis les 21 pages) étaient qu'il ne faut pas faire envoyer trop de fichiers à l'utilisateur (tu penses, ça risque de le fatiguer le pauvre de faire trois clics supplémentaires) . Donc si vous voulez vraiment simplifier la vie de l'utilisateur tu viens de contredire. Si le programmeur veut faire la même chose que le kernel, il le met dans son programme; mais (sauf cas éventuels de dépassement des 64 KO ou trucs du genre), ça ne fait pas de fichiers supplémentaires...

Tu oublies les problèmes de mises à jour de libs statiques par exemple
Enfin bon...

squale92: OK (ce genre d'utilisation n'est pas très répandu). Mais il n'y a pas besoin d'un RAM_CALL pour ça...

je n'utilise pas un ram_call, vu que je suis en nostub

FYI => merci pr l'info

godzil
a écrit : Hummm un truc a propos de TIGCC, il y a bcp (voire la totalité) des fonction "unknown" de TIGCC lib qui sont ECRIT et DECRIT NOIR SUR BLANC dans le pdf de TI pour son SDK...

ben vaut mieux vérifier avant c'est pas impossible qu'il y ait des erreurs avec le SDK ... non ?

Si ya des erreur dans la doc du sdk, TI a du tord a se faire :/

Oui, il faut les vérifier avant de recopier bêtement ce qui est dit dans la doc.
D'ailleurs si tu es volontaire pour le faire, c'est très bien

arf, la connexion a planté et g perdu ce que j'avais écrit
bon, pr résumer :
il y a des trucs dans le sdk qui sont dit tourner sur ttes les rom... et dans tigcc, ils sont dit ne tourner que sur 2;xx...
je pense que ceux qui ont fait la dic de tigcc ont vérifié, non ?

Oui.
Il y a plein d'erreurs dans la documentation du SDK. On ne peut utiliser rien de cette documentation sans vérifier.

>Mais on s'en fout, du boot code !
>Aucune des fonctions d'AMS qui dessine des caractères n'utilise le boot code !
>Une fois de plus, le kernel ne respecte pas le comportement des fonctions d'AMS.
Que veux-tu que je te repondes ? Le kernel impose ses normes, pas celles d'AMS.
Si cela ne te va pas, tant pis, c'est comme cela.

>Ca, c'est vraiment une remarque très positive...
Que veux-tu ? Cela fait si longtemps.

>La communauté franco-française kernel qui se passe du site de référence, tout simplement...
Arg !! Absolument pas d'accord ! Ce n'est plus le site de reference ! Et ce depuis la disparition de Brian Rabeler, grand maitre des archives de ticalc !
Il ne reste plus que des vieux trucs sur ce site.

>Quelle preuve d'ouverture d'esprit, d'intelligence, de finesse...
J'ai essaye la voie diplomatique pendant 2 ans, mais rien n'a changé.
Maintenant c'est fini.

>Tant que vous y êtes, vous devriez vous passer de calc.org et de ti-news.com,
>les staffs et ceux qui y vont ne sont probablement pas plus favorables à un mode dépassé.
La n'est pas la question. Ils font leur boulot (du moins ti-news), et je n'en demande pas plus.

>Ah bon ? Tiens, je voudrais savoir pourquoi ?
Ouvre le debogguer de VTI, va chercher un jsr _ROM_CALL_XXX et tu comprendras pourquoi.

>Utiliser le meilleur format de décompression disponible on-calc pour essayer
>de maintenir à flot un truc dépassé depuis longtemps ? Quel intérêt ?
Au moins je peux repondre aux arguments pseudo-tecniques de Kevin. Mais les tiens me laissent sans voix. Je suis désolé.

>FYI, "ttpacklib" n'est pas un nom AMS valide
Et alors ? "packlib" ne convient pas ?

>Et avec FL_getHardwareParmBlock (tous AMS)
Marche pas correctement sous AMS 1.00.

>et AB_getGateArrayRevision (AMS 2.xx)
Ne marche que sur AMS 2.0x

>Quel intérêt ?
Tu veux que je te dises l'interet de la moitie des romcalls exportes d'AMS ?

>De telles choses n'existent pas dans AMS _nostub (seul et unique standard car natif). On ne compare pas la même chose, là.
L'importation de code partagé, qui puisse reimporte ton code, n'est-il pas tres interressant ?

>Pas besoin d'une telle connerie puisque le _nostub/AMS ne libère pas automatiquement les handles alloués et non libérés (ce qui évite bien des problèmes...). La libération automatique des handles déresponsabilise le programmeur...
N'importe quoi. C'est bien la liberation automatique qui enleve des problemes et pas le contraire. Et je n'ai jamais vu de programmeurs kernels ne pas liberer ces handles alloues.

>Idem, ça n'existe pas sous le standard natif AMS _nostub.
Tu enfonces une porte ouverte. Donc justement ce n'est disponible que sur Preos.

>Tiens, je ne sais pas ce qu'est une lib statique, alors...
J'ai l'impression vu ta reponse...

>Ne pas utiliser toutes les fonctions d'ExtGraph (il y en aura plusieurs centaines) va
>faire perdre de la place on-calc ? Je te rappelle que là, on parle on-calc, pour la place
>perdue par les libs dynamiques, pas on-PC où la place est perdue par les deux types
>de libs.
J'ai dit 'peuvent' pas 'doivent'. Encore une fois, je rappelle que ca a rapport avec les fichiers objets, et pas les fonctions !

>> "Pourquoi empeche-t-il l'installation d'un kernel alors qu'il n'apporte aucune fonctionnalite que doit offir au minimum un kernel ?"
>Parce que ça n'est pas un kernel.
MORT DE RIRE !
Pourquoi empeche-t-il l'installation d'un kernel ?
Parce que ce n'est pas un kernel !
MORT DE RIRE !

>Il est détecté par la plupart des routines de détection de kernels,
>mais ça n'est pas un "vrai" kernel, puisque il ne fait pas ce que doit faire
>au minimum un "vrai" kernel. Quelqu'un avait dit ça, et il me semble que c'était toi.
Et tu n'as pas repondu a LA question.

>Ben non, ton header dans le pack de PreOS n'est pas officiel... Je parie que tu n'as pas demandé à ce qu'il soit officiel ?
Reponse: "On ne mettra pas des fonctionnalités seulement disponibles en mode kernel".
Fin de citation.

>Une telle demande ne serait pas forcément refusée. En effet, les membres de la TIGCC Team ne sont pas extrêmement anti-kernel, sinon ça ferait au moins deux ans que le peu de kerneleux devrait se débrouiller tout seul avec des outils dépassés (ben oui, s'ils étaient si bornés que ça, ça fait longtemps que le mode kernel ne serait plus supporté et qu'ils ne s'emmerderaient plus à mettre un truc pareil dans le linker, car ça n'est pas trivial) ?
S'ils le font je sortirais un tigcc parallèle qui ne supporte que le mode kernel. C'est tout.

>Une grande partie du monde est anti-kernel sans être extrémiste.
>Il y a juste un rejet d'un truc lourd, pas standard, buggé...
"Lourd" ? 4Ko lourd ? Quelle serait la taille a partir de laquelle ce ne serait plus lourd ?
Pas standard ? Mais oui, y'a eu PlusShell, DoorsOs, TeOS, UniOS, PreOS, Enhanced, LexOS, et comme chacun le sait tous les programmes codés pour un de ces kernels ne marchaient pas chez les autres. Arrete de dire des betises ! Il n'y a qu'un seul standard de kernel pour ti-92+/89/v200 !

>Et ne pas concevoir une lib pour être utilisée en ASM, est à mon avis une idiotie... Ca limite le nombre des utilisateurs....
Alors demande a la tigcc team d'arreter de faire des betises avec leur librairie

>"kernel natif": natif, forcément, dans PedroM; mais pas standard, le seul et unique standard restant AMS/_nostub.
Pourquoi je bavarde avec un extremiste informaticien ? Je devrais savoir que c'est voué à l'échec.

>"pour tous": non, pour ceux qui ne se servent pas de leur calculette pour autre chose que les jeux de la T3 qui sont tellement énormes qu'ils ne tiennent même pas dans les 640 KO, et qui sont prêts à mettre un système qui ne supporte pas quantité de fonctions. Autrement dit, certainement pas pour la majorité des gens...
J'ai eu pas mal de gens interréssé. Bien plus que ce que je ne croyais.

>"librairies standard offertes en bonus": non, pas standard, les librairies: pas dans le seul standard AMS/_nostub...
Pouquoi 'seul' ?

>C'est votre droit le plus strict. Je trouve ça stupide (ça ne va pas aider la communauté française...)
Mendier pour revenir te semblerait convenable ?

>Pour moi, si: c'est le seul site où il y ait des auteurs qui soient millionaires en téléchargements
Tu as entendu parler de la polémique des bots de téléchargement de ticalc ?

>mais la réciproque est fausse (TSRs kernel sans utiliser des trucs horriblement moches ?).
Et la fonctions kernel::InstallTSR tu connais ?

>il y a toujours des fanatiques pour s'accrocher aux trucs du passé.
Je ne te le fais pas dire.


>Si le programmeur veut faire la même chose que le kernel, il le met dans son programme; mais (sauf cas éventuels de dépassement des 64 KO ou trucs du genre), ça ne fait pas de fichiers supplémentaires...
Ca fait au minimum 2 trucs : le lanceur et le ppg

non mais de toute maniere dans la vie ya des causes perdue.. le nostub en est une

C'est sur que les fichiers de données compressées accompagnées d'un lanceur sont le grand paradoxe du nostub

Ximoon: problèmes de mise à jour des libs statiques ?

godzil: tes remarques sur le fait que des fonctions mises dans unknown.h dans TIGCC, mais documentées dans le SDK, sont malvenues pour un certain nombre de raisons... Ca n'est pas parce que les fonctions/variables n'ont pas encore été ajoutées à d'autres headers, qu'aucune documentation dans TIGCC n'est faite pour ces fonctions/variables. Il y a plusieurs centaines de fichiers en attente d'ajout à TIGCCLIB. La TIGCC Team doit tout vérifier/corriger.
D'autre part, TIGCC a beaucoup de trucs que TIFS n'a pas: un compilateur potable, TIGCCLIB est de loin la meilleure lib existante pour programmer sur TI (et ça va évidemment s'améliorer nettement avec les pending updates, des ajouts de fonctions à TIGCCLIB)... La doc du SDK est bourrée de fautes et doit être vérifiée/complétée/corrigée.

> arf, la connexion a planté et g perdu ce que j'avais écrit
Moi aussi... Je n'ai pas tout réécrit non plus.

Vu que PpHd dit absolument n'importe quoi sur un certain nombre de points, je n'ai pas envie de continuer la discussion. On va laisser les extrémistes du kernel et des trucs non standard, qui veulent se passer du monde entier, dire et faire toutes les conneries qu'ils veulent dans leur coin... Arrêter la "discussion" relancée par l'autre abruti (je parle bien évidemment de cet imbécile de TiMad qui rajoute encore des arguments "cacaniveau") va faire gagner du temps à tout le monde...

bien sûr les pro-nostub ne sont pas du tout extremiste, en décrétant que leur standart est celui de tout le monde

le mieux... c'est le paradox qu'a signaller Ximoon:

j'ai un fichier qui depasse les 24Ko de code pur, je fais quoi en nostub?

1. je prend une DLL, format de merde qui fait perdre de la place (enormément).
2. je le compresse en ppg, donc il me faut un lanceur.

Conclusion, dans les 2 cas, l'evolution (si on peut appleler ca une évolution) du format nostub converge vers le format kernel:
Dans un cas, il simule les lib kernel d'une maniere bien dégeulasse
dans un deuxieme ca, il a besoin d'un lanceur...

enfin bon le pire c'est les argument a la con:
"ca sert a rien une restauration automatique des kernels au niveau de la ram, ainsi que l'anticrash...).

tigcc ne permet pas de fair d'apps flash...
(et de toutes façon, elles seaient pas signées )
c le seul truc que je lui reproche par rapport au sdk de ti

XDanger a écrit :
Ximoon: problèmes de mise à jour des libs statiques ?

Oui. Relis ce que tu as raté dans les 21 pages précédentes.

Vu que PpHd dit absolument n'importe quoi sur un certain nombre de points, je n'ai pas envie de continuer la discussion. On va laisser les extrémistes du kernel et des trucs non standard, qui veulent se passer du monde entier, dire et faire toutes les conneries qu'ils veulent dans leur coin... Arrêter la "discussion" relancée par l'autre abruti (je parle bien évidemment de cet imbécile de TiMad qui rajoute encore des arguments "cacaniveau") va faire gagner du temps à tout le monde...

1- ton attitude est anti-cnstructive
2- d'aucun penseront que tu fuis le débat
3- on se demande qui est extrêmiste
4- les standarts ne sont pas seulement définis par ti et à quoi sert-il d'utiliser un standart contraignant et manquant visiblement de flexibilité?
5- insulter TiMad n'apporte rien au débat

Et j'adore aussi le délire a XDanger, je dit juste (et g testé pour les fonction qui m'interessait et tt marchait nickel du premier coup) que TOUTE les RomCall qui sont dans Unknows.h sont documenté dans le fichier PDF du SDK de ti.

D'ailleur sachant que le PDF a TI est la doc officielle, sa serait plus que largement etrange qu'il connaisent meme pas leur format et qu'il y commentent des erreur !

Toutes les RomCall que g testé avant le fonctionnement demandé, et prenait les parametres prévus.

D'autre pars, je n'ai jamais dit que le SDK de TI etait supérieur a TIGCC !
Se que j'adore dans les reaction a KK et XD dans se topic, c qu'il ne disent avec aucun lien (TIGCC Team et TICT) mais l'un n'arrete pas de défendre le groupe de l'autre !
A se demander si Xdanger serait pas plutot dans la TIGCC Team et KK dans la TICT :/

Ensuite tes argument XDanger sont eux aussi sans bcp de valeur, et insulter les autre n'apporte rien et ne ferra rien avancer :/

Bon, réponse au dernier message. Je sais que je devrais répondre à plein d'autres avant, mais je n'ai pas pu résister.

godzil
a écrit : Et j'adore aussi le délire a XDanger, je dit juste (et g testé pour les fonction qui m'interessait et tt marchait nickel du premier coup) que TOUTE les RomCall qui sont dans Unknows.h sont documenté dans le fichier PDF du SDK de ti.

Tu n'as pas bien cherché alors. Il y en a aussi qui sont tirés de Exec.inc. Et il y a pas mal de fonctions dans les headers autres que unknown.h (donc vraiment documentés chez nous) qui ne sont pas documentés dans le SDK!

D'ailleur sachant que le PDF a TI est la doc officielle, sa serait plus que largement etrange qu'il connaisent meme pas leur format et qu'il y commentent des erreur !

Désillusionne-toi!!! Tu ne sais pas du tout de quoi tu parles!

Toutes les RomCall que g testé avant le fonctionnement demandé, et prenait les parametres prévus.

Comme déjà dit, tu n'as pas cherché assez longtemps. Et surtout, tu n'as probablement pas vérifié que la version minimum de AMS indiquée par TI était correcte, et tu n'as certainement pas essayé toutes les combinaisons de paramètres possibles.

D'autre pars, je n'ai jamais dit que le SDK de TI etait supérieur a TIGCC !

Bien heureusement!

Se que j'adore dans les reaction a KK et XD dans se topic, c qu'il ne disent avec aucun lien (TIGCC Team et TICT) mais l'un n'arrete pas de défendre le groupe de l'autre ! A se demander si Xdanger serait pas plutot dans la TIGCC Team et KK dans la TICT :/

ca me ferait pas rire moi !

Pour moi, si: c'est le seul site où il y ait des auteurs qui soient millionaires en téléchargements, et des dizaines qui aient dépassé la centaine de téléchargements. Aussi, si une news importante est postée sur ticalc.org, elle est en général recopiée par les autres sites tels que calc.org ou ti-news.org (pas trop ces derniers temps, d'accord, parce que ticalc.org n'était pas très actif; mais avec le "recrutement" de Michael Vincent et de file archivers, ça recommence: regardez le nombre de fichiers ajoutés aux archives ces quatre derniers jours).

C'est vrai que récemment le situation a changé. Quand il sera terminé, j'enverai TISH à TiCalc on verra bien s'ils sont un peu moins sectaires maitenant.

Ah non, ça n'est pas strictement impossible. Rien de ce qui est faisable en kernel n'est infaisable en _nostub; mais la réciproque est fausse (TSRs kernel sans utiliser des trucs horriblement moches ?).

Pour les TSR c'est vrai que le nostub est la seule solution valable. Mais si tu veux implémenter ce que fait le kernel en nostub, tu auras écris un nouveau kernel. Pourquoi réécrire ce qui existe déjà alors que ca métonnerai que se soit du niveau de PreOS.

Oui, parce que c'est tout fait. Je suis d'accord. Mais ça aussi, est faisable en _nostub (par exemple, ttunpack_decompress sur groupes de fichiers tels que les GRP de FLib).

C'est peut-être faisable mais ce n'est pas fait, alors que les pack archive regle le problème de manière totalement transparente pour l'utilisateur et en un seul fichier.

D'autre part, TIGCC a beaucoup de trucs que TIFS n'a pas: un compilateur potable, TIGCCLIB est de loin la meilleure lib existante pour programmer sur TI (et ça va évidemment s'améliorer nettement avec les pending updates, des ajouts de fonctions à TIGCCLIB)...

Tigcclib est très bien mais son défaut est de mélanger ROMCALLS avec fonction linkées statiquement. Les romcalls sont très bien fait et bien documentés. Le reste est plus ou moins utile mais fait augmenter sensiblement la taille du fichier et la pluspart des utilisateurs ne font pas la différence.
Et l'integration d'Extagraph ne va pas arranger cela.

j'ai un fichier qui depasse les 24Ko de code pur, je fais quoi en nostub?
1. je prend une DLL, format de merde qui fait perdre de la place (enormément). 2. je le compresse en ppg, donc il me faut un lanceur.

Enfin une remarque réflechie de Timad. Oui le truc c'est que comme je l'ai dit, si on veut les même fonctions que le kernel il faut programmer un kernel

ca me ferait pas rire moi !

Les 2 équipes ne sont pas liée mais disont étroitement associées et c'est pas nouveau. Elles font ce qu'elle veullent, ca ne me dérange pas tant qu'elle se prennent pas pour le centre du monde

>1- ton attitude est anti-cnstructive
Celle de TiMad l'est, sans doute (si l'on excepte son dernier post où, miracle, il y a un argument) ?

> 2- d'aucun penseront que tu fuis le débat
D'aucuns penseront que j'ai raison de fuire le débat avec des extrémistes. Je considère dorénavant PpHd comme un extrémiste (c'est réciproque), je vais le traiter comme tel. Je vais faire ce qu'il m'a demandé (laisser les vieilles versions des routines de dessin de font car son truc n'est pas compatible avec les nouvelles versions qui sont pourtant plus petites, plusieurs ordres de grandeur plus rapides au startup et qui ne nécessitent pas de mémoire additionnelle). Mais ça n'était pas ma priorité, ça va l'être encore moins...

> 3- on se demande qui est extrêmiste
> 4- les standarts ne sont pas seulement définis par ti et à quoi sert-il d'utiliser un standart contraignant et manquant visiblement de flexibilité?
_nostub: ceux qui suivent le standard de TI, et dont les programmes marchent sur toutes les calculettes.
kernel: ceux qui utilisent un truc non supporté par TI, et les programmes ne marchent donc pas sans ajout de programmes spéciaux (kernel).
Bien sûr que le kernel a des avantages (ça n'est pas la première fois que je le dis). Je l'ai dit sur le forum de TIGCC/TICT, aussi. Mais les programmes kernel-based ont aussi un immense défaut: ils ne marchent pas sans kernel.

> 5- insulter TiMad n'apporte rien au débat
Apporte-t-il quelque chose au débat (si on excepte son dernier post) ? Je te rappelle que c'est lui, l'imbécile qui a relancé le débat kernel/_nostub.

> Ensuite tes argument XDanger sont eux aussi sans bcp de valeur, et insulter les autre n'apporte rien et ne ferra rien avancer :/
J'en ai marre de ce débat à la con et de la mauvaise foi.
Je fais comme les autres: je n'apporte rien au débat, je ne fais rien avancer, j'insulte les autres (à une époque, certains, dont Thibaut qui s'est calmé depuis, étaient très forts et très lourds) et moi, je me fais enguirlander, alors que TiMad ne se fait jamais réprimander par qui que ce soit (je remarque qu'il a donné un argument dans son dernier post)...

XDanger a écrit :
>1- ton attitude est anti-cnstructive
Celle de TiMad l'est, sans doute (si l'on excepte son dernier post où, miracle, il y a un argument) ?

Et bien ce n'est pas en surrenchérissant que tu vas passer pour plus intelligent que lui!

> 2- d'aucun penseront que tu fuis le débat
D'aucuns penseront que j'ai raison de fuire le débat avec des extrémistes. Je considère dorénavant PpHd comme un extrémiste (c'est réciproque), je vais le traiter comme tel.

tu deviens bien trop agressif en ce moment, ça n'apporte rien. Si tu dois passer tes nerfs sur quelqu'un, je ne sais pas si ce forum est le meilleur endroit.

> 4- les standarts ne sont pas seulement définis par ti et à quoi sert-il d'utiliser un standart contraignant et manquant visiblement de flexibilité?
_nostub: ceux qui suivent le standard de TI, et dont les programmes marchent sur toutes les calculettes.
kernel: ceux qui utilisent un truc non supporté par TI, et les programmes ne marchent donc pas sans ajout de programmes spéciaux (kernel).
Bien sûr que le kernel a des avantages (ça n'est pas la première fois que je le dis). Je l'ai dit sur le forum de TIGCC/TICT, aussi. Mais les programmes kernel-based ont aussi un immense défaut: ils ne marchent pas sans kernel.

et un prog de plus de 64ko sans sa dll ne marchera pas seul
et un prog compressé sans son lanceur ne marchera pas seul

> 5- insulter TiMad n'apporte rien au débat
Apporte-t-il quelque chose au débat (si on excepte son dernier post) ? Je te rappelle que c'est lui, l'imbécile qui a relancé le débat kernel/_nostub.

> Ensuite tes argument XDanger sont eux aussi sans bcp de valeur, et insulter les autre n'apporte rien et ne ferra rien avancer :/
J'en ai marre de ce débat à la con et de la mauvaise foi.

bon alors arrete de poster on t'en voudra pas, tant pis

Je fais comme les autres: je n'apporte rien au débat, je ne fais rien avancer, j'insulte les autres

tout le monde ne s'insulte pas mutuellement ici, vous êtes une poignée.

(à une époque, certains, dont Thibaut qui s'est calmé depuis, étaient très forts et très lourds) et moi, je me fais enguirlander, alors que TiMad ne se fait jamais réprimander par qui que ce soit (je remarque qu'il a donné un argument dans son dernier post)...

La preuve que l'espoir existe...

Kevin Kofler a écrit :
Tu n'as pas bien cherché alors. Il y en a aussi qui sont tirés de Exec.inc. Et il y a pas mal de fonctions dans les headers autres que unknown.h (donc vraiment documentés chez nous) qui ne sont pas documentés dans le SDK!

Je n'ai pas reelement cherché plus loin que les fonctions de unknown.h, et toutes les ROMCALL que j'ai cerché se trouvé documenté dans le PDF fourni par TI

Désillusionne-toi!!! Tu ne sais pas du tout de quoi tu parles!

Ben justement, si TI a défini un format dans son PDF, et qu'il veulent que les utilisateurs l'utilise, si il se disent, "ZUT on a pas codé cette fonction comme il faut" il vont la modifier et c tigcc qui sera plus compatible, ensuite

Comme déjà dit, tu n'as pas cherché assez longtemps. Et surtout, tu n'as probablement pas vérifié que la version minimum de AMS indiquée par TI était correcte, et tu n'as certainement pas essayé toutes les combinaisons de paramètres possibles.

Se n'est pas mon boulot, et de toute facon j'ai abandonné d'essayer de documenter pour tigcc ses fonctions, elle me servent finalement pas (elle ne fonctionnent pas vraiment comme leur equivalents ANSI :/ (j'ai bien regardé le fonctionnement des fonction sur les fichiers))

> D'autre pars, je n'ai jamais dit que le SDK de TI etait supérieur a TIGCC !
Bien heureusement!

J'ai rajouté sa pasque XDanger a (encore) mal interprété se que j'ai dit !
Dans le post précédent a celui la, il c mis a "délirer" sur la différence entre TIFS et TIGCC, alors que je n'y ai fait aucun rapport sur les différences de qualitées :/



J'voudrait aussi quand meme faire partager le gentil minimessage que XDanger ma laisser :

XDanger: "Et j'adore aussi le délire a XDanger, je dit juste (et g testé pour les fonction qui m'interessait et tt marchait nickel du premier coup) que TOUTE les RomCall qui sont dans Unknows.h sont documenté dans le fichier PDF du SDK de ti.
D'ailleur sachant que le PDF a TI est la doc officielle, sa serait plus que largement etrange qu'il connaisent meme pas leur format et qu'il y commentent des erreur !
Toutes les RomCall que g testé avant le fonctionnement demandé, et prenait les parametres prévus."

Mon pauvre, tu n'y connais rien... Tu devrais te taire et écouter ce que disent d'autres qui sont plus compétents que toi (et pas que dans ce domaine là), qui ont tous deux participé à documenter des fonctions inconnues (ni dans le SDK ni dans aucune doc connue), corriger les erreurs du SDK, et d'autres choses pour TIGCCLIB.

Pq tu la pas posté directement ici ?

Bon ceci dit, les fonction de Fichier de la TI sont décrit correctement dans le PDF du SDK, et je comprendrait jamais ta reaction XDanger, tu te sens agréssé alors que PERSONNE ne t'aggresse, meme kevin a pris certain truc que j'ai pu dire a la rigolade, alors si tu peut pas

Pour finir, XDanger, tu dit ne pas vouloir "traiter avec les extremistes", mais je trouve que tu te comporte plus comme un extremiste sur bcp de point que kevin, qui pourtant lui a été longuemen décrié comme "extrémiste nostub"

Kevin passe bcp plus de temps que toi a aider les autres, meme si c'est du kernel, toi on te vois généralement plus en train de dire "Sa sert a rien" (cf AS) "c'est nul" ou posté des réponses ici

ensuite j'aimerait que tu argumente (pasque toi qui adore avoir des argument) cette phrase : "Tu devrais te taire et écouter ce que disent d'autres qui sont plus compétents que toi (et pas que dans ce domaine là)"

>>1- ton attitude est anti-cnstructive
>Celle de TiMad l'est, sans doute (si l'on excepte son dernier post où, miracle, il y a un argument) ?
Je le comprend. Moi aussi j'ai arreté de répondre a Kevin sur certaines des remarque auquelle je lui ai déja répondu et qu'il a ignoré, ou certain arguments de très mauvaise foi.

>_nostub: ceux qui suivent le standard de TI, et dont les programmes marchent sur toutes les calculettes.
>kernel: ceux qui utilisent un truc non supporté par TI, et les programmes ne marchent donc pas sans ajout de programmes spéciaux (kernel).
>Bien sûr que le kernel a des avantages (ça n'est pas la première fois que je le dis). Je l'ai dit sur le forum de TIGCC/TICT, aussi. Mais les programmes kernel-based ont aussi un immense défaut: ils ne marchent pas sans kernel.
Entièrement d'accord, la question est est-ce que ca en vaut la peine. Pour moi la réponse est oui.

>> 5- insulter TiMad n'apporte rien au débat
>Apporte-t-il quelque chose au débat (si on excepte son dernier post) ? Je te rappelle que c'est lui, l'imbécile qui a relancé le débat kernel/_nostub.
Il n'apporte pas grand chose au débat mais l'insulter ne fait que l'envenimer. Et puis le débat Kernel/Nostub est très intéressant, il est bon de savoir tout ce que permet l'un et l'autre de modes. J'y ai appris quelque trucs intéréssants et ca permet de ce forger une autre idée que celle de Kevin qui te matraque de "Kernel dépassé" et PpHd qui dit "Kernel rulezz".

>> Ensuite tes argument XDanger sont eux aussi sans bcp de valeur, et insulter les autre n'apporte rien et ne ferra rien avancer :/
>....
Dans ce genre de débat les argument de tout le monde ont de la valeur et même si je sais que je n'ai pas le même niveau que la pluspart de ceux qui postent ici je poste car ce débat concerne tous les programmeurs.

>> Ensuite tes argument XDanger sont eux aussi sans bcp de valeur, et insulter les autre n'apporte rien et ne ferra rien avancer :/
Si tu veux une explication sur cette phrase :
1-Elle ne dit pas que tu n'est pas bon, ni que tu est une merde en prog
2-Tu n'est pas le seul a avoir et a devoir donner son avis sur la question (c'est vrai quoi si on lit tout se qu'ecrit XD ou KK on dirait qu'il y a que eux qui on raison)
3-Tu t'emporte souvent et instule facilement :/
4-Tu manque parfois de bon argument, tout comme les personnes que tu 'combat'

Personnelement je suis de l'avis de la plus pars ici :
Le kernel, pour un usage courant c tres bien
Le _nostub, si on a envi de faire un truc genre TSR, c tres bien aussi

Tout les deux on des faiblesses au meme endroit et des point fort sur exactement la meme chose ! Pour certain auters point, le kernel remonte par rapport au nostub, et inversement, les deux format, au lieu d'etre concurent, sont COMPLEMENTAIRES !

Le support natif de l'asm existe oui ! mais il est "primitif" !il ne permet que de nous faire le relogement et nous donner le controle du 68000.
Le kernel permet sa aussi, mais en fait encore plus, (voir peut etre trop, puisqu'on peut pas faire de TSR kernel, faudrait pouvoir indiquer par drapeau si on veux desactiver certaines fonctionnalité du kernel a l'execution) il permet de mettre a jour dynamiquement les table de jump, permettant d'utiliser des fichier de fonctions externes, il permet au programme de pas faire des tonnes d'octets si on utilise des variables globales (allocation dynamique et utilisation des BSS) alors que le nostub demande que les var globales soit initialisé au moment de la compilation :/
Si on a un tableau de 10x10 par ex sa ne fait que 100octet, mais 100x100sa fait 1Ko etc !! (bon ok utiliser un ausi gros tableau en global et s'autent plus en static est débile, mais bon c qu'un exemple de se que le kernel permet)

En gros, personnelement et je sais ne pas etre le seul, le kernel c bien, le nostub c'est bien, mais chacun a ses utilisation et ses défauts

Genre.. on va tout me remettre sur le dos.. j'apporte ce que je veux sur le debat.. pour ma part, tous les argument nostub n'apporte rien au debat, car le debat n'a pas lieu d'etre....

godzil: heureux de t'entendre dire des choses telles que "En gros, personnelement et je sais ne pas etre le seul, le kernel c bien, le nostub c'est bien, mais chacun a ses utilisation et ses défauts".

>ensuite j'aimerait que tu argumente (pasque toi qui adore avoir des argument) cette phrase : "Tu devrais te taire et écouter ce que disent d'autres qui sont plus compétents que toi (et pas que dans ce domaine là)"
J'aime bien les arguments et les faits, en effet.
Il y a un argument dans mon mini-message "Tu devrais te taire et écouter ce que disent d'autres qui sont plus compétents que toi (et pas que dans ce domaine là), qui ont tous deux participé à documenter des fonctions inconnues (ni dans le SDK ni dans aucune doc connue), corriger les erreurs du SDK, et d'autres choses pour TIGCCLIB.".
Kevin et moi avons une vue plus générale sur le contenu du système de fichiers d'aide utilisé pour constuire le .CHM que toi. On a participé à documenter des fonctions, et visiblement, pas toi (mais tu as visiblement voulu le faire, et on doit t'en remercier). Et il est heureux que tu aies abandonné de documenter pour TIGCC ces fonctions-là: tu aurais vraiment perdu ton temps car elles sont déjà documentées, mais pas encore ajoutées à TIGCCLIB (elles font partie des "pending updates" auxquels je fais souvent référence; beaucoup de fichiers sont dans le même cas, je n'ai pas le nombre exact).
Kevin, si tu passes par là, pourrais-tu donner un lien vers le fichier contenant les pending updates ? S'il n'est pas à jour, tant pis. Ca limitera au moins le boulot qui risque d'être refait... De mémoire, je peux citer: les fonctions telles que DynMenuAdd, et toutes les nouvelles fonctions de dialog/popup d'AMS 2.xx; les fonctions FOpen, FClose... Pour les updates que j'ai faits: divers dans divers headers, seuls les principaux sont cités (mais il y a au moins 5 autres headers où j'ai ajouté/modifié des trucs): estack.h (plusieurs dizaines de fichiers), flash.h (une dizaine de fichiers), system.h (plusieurs dizaines de fichiers), vat.h, wingraph.h.

> pour ma part, tous les argument nostub n'apporte rien au debat, car le debat n'a pas lieu d'etre...
Je ne te demande pas plus que ça... Arrêter "_nostub suxx" et " non mais de toute maniere dans la vie ya des causes perdue.. le nostub en est une", et dire des choses plus intelligentes "pour ma part, tous les argument nostub n'apporte rien au debat, car le debat n'a pas lieu d'etre...". Je ne suis pas d'accord avec toi, mais au moins, là, on ne va pas te reprocher de ne pas donner d'argument.



On en reste là ? J'ai dit plein de conneries, je présente mes excuses à tout le monde.

Une chose que je ne comprend pas...
La mentalité kernel n'empeche pas les programmeur nostub de continuer leur prog...
alors que les nostub eux.. borné ne supporte pas les prog kernel!!

C'est qui les plus bornés?

C'est le principe de "Qui peut le plus, peut le moins". Ceux qui ont un kernel peuvent profiter du _nostub s'ils le veulent, alors que les _nostubiens, coincés dans leur monde, sont jaloux et préfèrent spolier les kerneleux, pour ne pas se sentir inférieurs.

"L'égalite [Si on ne peut profiter des avantages du kernel, alors autant empêcher les kerneleux d'en profiter eux aussi] ou la justice [Chaque programmeur est libre de faire ce qu'il veut, que ce soit Preos, Pedrom, Tigcclib.9xz, (tiens, un nom revient à chaque fois, ça commence par Pp et finit par Hd, à croire qu'il est le seul à faire vivre la communauté kernel ) ou autres...]". c'est l'éternel combat Cimourdain vs Gauvain (dédicace spéciale à Neurone, Timad, and co )

Voila, sinon à-part ça, merci d'avoir lu ma digression totalement inutile, j'essayerai d'éviter de recommencer, mais considérez ça comme une pause (kit-kat), vous pouvez maintenant retourner parler de choses sérieuses

Arg nonnnnnnnnnnnnnnnnnnnnnnnnnnn! pas ce livre a la con!!!
je me susi tapé 4 au partiel de francais a cause de lui

Erf je suis 39ème sur 40 en français, à cause de lui, te plains pas