>* problème de compatibilité avec des émulateurs
C'est plutot un probleme de manque de bout de code de ROM.
Et c'est corrige.
>* problème potentiel de compatibilité avec les versions futures du boot code
Possible. Mais on pourra toujours adapte le kernel.
>* algorithme de recherche extrêmement stupide (on cherche un certain long dans la ROM entière)
Tres peu couteux en memoire
Et il fonctionne sur tous les boot code.
>* utilise des fontes potentiellement différentes de celles utilisées par AMS
Et ?
>La deuxième solution. Le format kernel a été spécifié de manière autoritaire.
Tu n'avais qu'a etre parmi les debats qu'ont echange Xavier et Rusty a l'epoque.
Je te rappelle qu'il n'existait pas de forum aussi.
>S'il y a qqch. qui te dérange dans TIGCC IDE, donne-nous des critiques concrètes. Parce que là, il n'y a rien de concret.
Lourd.
>Sauf que le "DOS Extender" apporte de vraies fonctionnalités (mode 32 bit).
Pas le kernel. Bien sûr. Arrete d'être de mauvaise fois.
>Et le raisonnement derrière? Le _nostub convient pour tous types de programmes!
pas aux gros programmes : ils sont + difficiles a faire en _nostub qu'en kernel (Les progs arrivant pres de la limite des 64K).
>Et quand on ajoutera le débogage à TIGCC, ça sera très probablement avec TIGCC IDE uniquement.
Ah bon ? ce n'est toujours pas abandonne ?
>Pourquoi? Il y a beaucoup moins de calculs à faire.
Il faut restaurer l'ecran du background efface par les autres sprites.
Donc il faut aussi sauvegarder cet ecran lors de l'affichage du sprite.
Et on ne peut pas faire du parallax.
>Bon, d'accord, mais ses graphismes sont affreux (personnages composés surtout de lignes et de cercles). Et en plus, c'est en grande partie du blanc&noir.
Et alors ? Tu n'as parle en niveau de gris. Moi je le trouve mignon mon perso
>S'ils ne l'ont pas posté, c'est qu'ils ne l'ont pas trouvé digne de news. Réessayez à la prochaine release. Michael Vincent semble être disposé à annoncer des bêtas et même des alphas, donc peut-être que ça marchera.
Nous ne reessairons plus. ticalc a ete raye de notre liste.
>Mais je ne vois vraiment pas l'intérêt de faire 5 versions alors qu'une seule (_nostub PPG) suffit pour couvrir toutes les TI-89/92+/V200.
Pour satisfaire des utilisateurs capricieux.
>On les supporte déjà parfaitement. Tout ce qui est possible en _nostub avec TIGCCLIB (à part EXECUTE_IN_GHOST_SPACE et ENABLE_ERROR_RETURN, mais c'est au kernel de s'occuper de tout ça) est aussi possible en mode kernel.
Il voulait dire pourquoi des trucs possibles en kernels ne sont pas proposes dans tigcc
>Mais si on ne veut pas avoir des erreurs "missing lib" dès qu'on essaye un nouveau programme/jeu qui utilise des librairies dynamiques, on n'a pas d'autre choix que de mettre stdlib en entier. Alors que les librairies statiques résolvent ce problème une fois pour toutes, et sans la solution barbare, gaspillante et imparfaite (cf. api92, smqlib et autres libs "exotiques") qu'est stdlib.
Tu sais. La plupart des programmes qui utilisent des libs exotiques les distribuent en meme temps que le programme. Tu peux te contenter de graphlib/userlib/filelib/ziplib et leur synon
>Pas sûr. Les tables de relogement se compressent bien. Et puis, CC n'est pas le genre de programme qui se retrouve sur beaucoup de calculatrices, vu qu'il n'est utile qu'aux développeurs qui développent on-calc et acceptent les limitations de CC.
Ca fait des utilisateurs.
>Je ne suis pas d'accord.
Tant mieux. Vive les debats.
>Et pourquoi?
Cf ce que j'ai dit plus haut.
>Le premier shell avec ce format à être sorti était DoorsOS. Aucun dossier de ticalc.org ne porte le nom de 2 shells/kernels ou plus.
Et tu es fier de pousser les gens a utiliser doorsos pour que ca leur plante dans les doight afin qu'ils preferent le _nostub ?
>Ça plante parfois, donc c'est instable.
Ca ne se lance pas. Nuance.
>Un jeu qui remplit la mémoire archive entière a intérêt à valoir ce qu'il prend en mémoire. S'ils jugent que ce n'est pas le cas, c'est une raison de ne pas faire de news.
Un peu limite comme argument.
Je crois plutot que combinaison frenchy+kernel, mauvaise pour ticalc.
Les a-priori ont la vie dure.
>C'est exactement cette attitude qui m'énerve. Tu essayes de contraindre les programmeurs à faire tout ce que tu veux. Et après, il y en a (n'est-ce pas Thibaut ) qui nous accusent de faire ce genre d'actions. On n'a jamais mis des messages d'"erreur", voire des désinstallations automatiques, intentionnellement pour forcer les programmeurs à se mettre à jour.
Je fais ce que je peux pour faire avancer les choses et c'est pas facile.
Je n'ai jamais impose des choses aux programmeurs... Je les conseilles.
>Et je n'ai toujours pas compris pourquoi il est un problème si grand que ça d'avoir une librairie qui a son numéro de version à 0.
Parce que certaines libs vieilles et tres bugguee ont des nums de version a 0.
C'est pour les differencier des nouvelles.
>Non, au moins par 3. Les packs archive sont compressés avec un algorithme totalement différent que les PPG, donc il n'y aura pas de séquences en commun entre les 2. Et d'ailleurs, les séquences _nostub et kernel sont également assez différentes.
Tu n'a toujours pas compris qu'on peut compresser une PackArchive avec le meme algo que celui des PPG ?
>Et tu fais quoi de tous les shells pour kernel qui utilisent NG_execute pour lancer des programmes en assembleur ou des programmes en BASIC qui font appel à des programmes en assembleur?
La reponse me semble evidente, non ? Itercepter t.......
>D'ordre de grandeur totalement négligeable. Les essais de Zeljko et de Patrick Davidson le montrent.
Urgent: rappel cc...
>Et voilà l'erreur. Tu présupposes que tout le monde aura forcément tous ces projets sur sa calculatrice en même temps.
Et ton erreur est de supposer qu'ils n'en ont qu'un a la fois. C'est lassant comme pb.
>Non, puisque c'est ce que c'est techniquement
Alors ne vous etonnez pas que certains l'utilisent comme des dll.
>Ce n'est pas pratique.
Mon kernel est en built-in, donc je prefere cela
>Pas pour ce pour quoi les DLLs _nostub sont prévues.
Si car on peut faire des appels croises entres les parties ce qui est impossible en DLL a moins de le faire a la main. Et c'est lourd.
>Alors là pas du tout. En quoi jsr doorsos::toto est-il plus simple que ROM_CALL toto???
C'est + intuitif sous un deboggueur.
>Non, ce n'est pas ton niveau d'anglais le problème. Tes documentations en français ne sont pas mieux.
J'en fais encore ?
Je ne savais pas.
>Mais j'ai malheureusement l'impression d'être en minorité sur ce forum. Alors que partout ailleurs, la réaction au mot "kernel" est presque toujours "that outdated piece of crap".
C'est bien pour cela qu'on a besoin de toi sur ce forum
>Mais l'ajout minimal à la portabilité vaut-il le coup si ça double la taille? Je ne suis pas de cet avis-là.
Oui.
>Non. Je ne connais aucun autre éditeur qui a des règlages spécialisés (séparés) pour A68k et pour GNU as.
C'est pourtant simple.
>Sans parler du Quill Adventure Writer de Zeljko Juric, pour lequel je ne connais que TIGCC IDE qui fait la coloration syntaxique.
Tres, tres utilise.
>Sur VTI, ça marche même avec PedroM. Pour la vraie calculatrice, si ça ne marche pas, c'est que ton gestionnaire du link bogue.
Ca ne marchait pas. Depuis j'ai mis le systeme de link, et le lancement avec les '()' a la fin. Depuis ca marche.
>Il y a quoi qui est lourd? Moi, je ne vois rien de lourd.
Je programme sur un P200 moi.
>Pourquoi? TIGCC IDE est très simple à utiliser!
j'aime pas les couleurs.
>Si, utiliser un autre éditeur que celui prévu est un bidouillage.
... Enlever la ligne de commande tant qu'a y etre.
>Ils n'ont aucun intérêt. Il y a des ROM_CALLs qui font la même chose proprement.
HW_VERSION ? EMULATOR ? kernel::Idle ? kernel::Exec ? kernel::Ptr2Hd ? kernel::Hd2Sym ? kernel::LibsBegin ? kernel::LibsEnd ? kernel::LibsPtr ?kernel::LibsCall ? kernel::LibsExec ? kernel::HdKeep ? kernel::ExtractFromPack ? kernel::ExtractFile ? kernel::ExtractFileFromPack ? sont donc disponibles en romcalls ?
>Je parle de vraie compression, pas de ziplib
ziplib compresse. Que tu le veuilles ou non.
>Pas vraiment. ExePack est plus flexible parce qu'il:
>* marche aussi sans kernel
Huhu.
>* permet le lancement par plein de manières différentes: lanceur personnalisé, ttstart, AutoStart, TICT Explorer, explorateurs d'auteurs tiers, ...
Les PackArchive permettent la meme chose sans AUCUN code de la part de ces programmes.
>Tu veux vraiment faire ch**r Thomas de cette manière?
Et je n'ai toujours pas compris pourquoi tu n'as pas intégré ttunpack_decompress à PreOs. Ça aurait rendu le système de packs archive beaucoup plus transparent et amélioré la qualité de la compression.
Parce que c'est impose un format. Si je n'ai pas fait de lib ttpacklib, c'est pour ne pas embeter Thomas. C'est quand meme son boulot. Le systeme de pack archive est totalement transparent a l'heure actuelle ! L'inclusion de shrnklib directement dans stdlib rend ce systeme 100% transparent. Et on peut faire evoluer le format de la compression SANS changer le format d'une Pack Archive !
>Pas d'une manière qui justifie le gaspillage de place.
Ca prend pas beaucoup quand meme.
>Non. ziplib est très loin d'offrir le taux de compression offert par ttpack.
C'est du huffman de base. Ca compresse deja pas mal, en etant relativement simple.
Et ca fonctionne on-calc.
>Un jeu d'échecs ne peut-il pas être un bon jeu pour toi??? Pour moi, TI-Chess est un excellent jeu.
Tu me parlais de jeu d'action, puis tu parles de jeu d'echec.
Ok, c'est un bon jeu ! Mais non, ce n'est pas un jeu d'action.
>D'ailleurs, je veux te voir coder un jeu d'échecs, toi... Et: non, changer 3 lignes dans TI-Chess ne compte pas. Ton jeu doit être indépendant de TI-Chess pour qu'il soit intéressant.
Si je te le fais en asm, tu es content ?
>Ton texte en français est tout aussi illisible, donc le problème n'est pas la langue.
Il n'est + mis a jour.
>N'essaye pas de nier des problèmes qui sont réels et indéniables. Les librairies dynamiques portent à des conflits de version et gaspillent de la place pour les fonctions inutilisées (qui le sont vraiment, donc le mot "supposées" est mal placé).
Les conflits de version sont une chose du passé.
Les fonctions inutilisees peuvent tout aussi bien existe dans une librarie statique...
>Et il y a aussi d'autres inconvénients. À titre d'exemple, la nécessité de code spécial pour les reloger en temps d'exécution, alors que les librairies statiques sont relogées lors de l'édition des liens.
C'est un inconvenient horrible. Heureusement que l'utilisateur n'a pas a le reloger a la main.
>Un autre exemple d'inconvénient est le fait que l'utilisateur doit s'occuper d'"installer" (copier sur la calculatrice) les librairies dont le programme a besoin alors que pour les librairies statiques, c'est l'éditeur de liens qui fait ça automatiquement.
Tu oublies les fichiers externes des programmes.
Ca fait qqs fichiers externes en + et c'est tout.
En +, de nos jours, on peut les regrouper dans des Pack Archive. Donc ce probleme est un faux probleme.
>Alors pourquoi ce système de suppression automatique
Pour eviter de voir trainer dans la calc des vieux relicats. Mais je plenche sur une autre solution.
>Ce n'est pas un stub, c'est du code de démarrage!
Detail.
>Il est utile parce qu'il apporte l'anti-crash et d'autres fonctionnalités utiles, ou du moins que toi, tu juges utiles au point de les inclure à PreOs.
Alors repond a cette question :
"Pourquoi empeche-t-il l'installation d'un kernel alors qu'il n'apporte aucune fonctionnalite que doit offir au minimum un kernel ?"
>Tu fais une liste des fonctionnalités utilisables en chaque mode. L'anti-crash avec crashlib est utilisable en _nostub, donc tu devrais le mettre.
Non a moins que ca rentre dans un flag de compilation de tigcc.
>Ça porte le nom de ce que c'est techniquement.
D'ou des abus tolerables.
>>Oui la aussi ca me fait peur Il faudrait que cette option ne soit fonctionelle que pour les lib en double(on suprime la plus ancienne)
>Voilà une idée bien meilleure que la suppression barbare de toute librairie portant un numéro de version de 0.
Oui.
>Et puis, Universal OS intégrait moins de librairies que stdlib.
Tu peux mettre les libs que tu veux dans stdlib ! Compresse comme tu le veux !
>Sauf que c'est du gaspillage de place!
Si on installe un kernel c'est que l'on utilise un kernel, donc il y a des programmes kernels. La +part des kernels utilisent une bonne partie de ces libs. Quelques unes restent exotiques mais ne prennnent que peu de place (J'ai pas mis jplib dans le pack).
>Beurk! Autant dire que ce n'est pas possible.
... T'es lourd.
>Chez toi peut-être. Pas chez d'autres.
Forcement : c'est bien + gros. Vu la taile les problemes d'installation sont faibles relativement.
>Pourquoi? TIGCCLIB apporte exactement les mêmes fonctionnalités en les 2 modes!
Mais tigcclib n'offre pas tout.
>La différence est que les programmes _nostub marchent très bien sur les calculatrices avec kernel. Pourquoi faire un programme pour un ensemble A d'utilisateurs si on peut le faire pour l'union de l'ensemble A avec un autre ensemble B? C'est limiter stupidement la portée du programme!
Ces utilisateurs pourront toujours installer un kernel. Le kernel fonctionne sur toutes les roms, donc ca ne limite pas le nombre d'utilisateurs. Evidemment y'a les extremistes.
>C'est faux. L'appel d'une librairie statique est au moins aussi rapide que l'appel d'une librairie dynamique kernel.
Le kernel permet de faire des programmes + gros + facilement.
>Et on peut faire tout ce que fait le kernel même sans écrivant un kernel
Mais bien entendu ! C'est tout l'interet du kernel d'ailleurs de CENTRALISER les problemes pour ameliorer la portabilite.
>C'est faux. Par exemple, le C permet de garder la compatibilité source entre 2 versions d'une librairie beaucoup plus simplement.
Le rapport ? Si une lib n'est pas concue pour etre utiliser en asm, c'est son probleme.
>Donc vive le C!
L'asm plutot
Et puis je dirais que PedroM solutionne tout cela : kernel natif pour tous avec librairies standards offertes en bonus
ensuite, TiGCC ~ 5Mots etc. :
Je ne savais pas.
:
La communauté franco-française kernel qui se passe du site de référence, tout simplement... Quelle preuve d'ouverture d'esprit, d'intelligence, de finesse... 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é.
