Les jours de PC-Tools, TicTex et Einstein sont compter... - Page 1

Bon, ben voilà, j'annonce officiellement l'existence de mon propre shell en basic
Un petit screen pour vous mettre dans le bain :



Bon, c pas sur que je le termine (motivation PoWa), mais bon, on c jamais (ça dépend aussi de Pollux)

Yeah !!!!!!!!! Il rulezzzzzzzzzz ce shell !

Je précise quand même qu'il est poweréder par :
-Vertel (Bob64)
-FLib (FL)
-GTSR (Ced)
-GKRNL (Azerty83)
-Monolog (re-Bob64
-PC1 (re-FL)

Mais vous en faite pas, le reste est en basic

Yeah !!!!!!!!! Il rulezzzzzzzzzz ce shell !

(© Vark)

(nan mais c vrai en plus !)

Les jours de PC-Tools, TicTex et Einstein sont compter...

Vive la modestie...

Et je ne veux pas te vexer, mais j'ai déjà des critiques à faire (j'essaye d'être le plus constructif possible):
* Si le shell est aussi lent en réalité que le screenshot, c'est beaucoup trop lent (et ça ne m'étonnerait pas vu qu'il est en BASIC). Ce qui m'a l'air vraiment trop lent est surtout l'affichage de la liste des fichiers (on les voit apparaître un par un), et le démarrage (on voit les composants apparaître un par un).
* Ton shell surcharge vraiment l'écran. Tous les chiffres qui sont en haut à droite et qui remplissent 4/5 de la barre de menus, TICTEX ne les affiche que quand on appuie sur F5, donc ça ne bourre pas l'écran de choses inutiles quand on n'en a pas besoin.
* Tu le trouves peut-être utile, mais personnellement, je trouve que la liste de TSRs installés n'a vraiment rien à faire dans un shell, surtout pas en plein milieu de la zone dédiée à la liste des répertoires. (La raison: On installe les TSRs après un reset, et après on ne s'en occupe plus. On connaît la liste de TSRs qu'on a, pas la peine de l'afficher.)
* 6 librairies pour un shell?! On voit clairement que le langage de programmation choisi n'est pas adapté vu qu'il faut un total de 6 librairies écrites en d'autres langages...
* Mets "BUSY" à la place de "ENGAGED", c'est plus correct.

Bref, je garde TICTEX, moi.

Attention, je ne dis pas que ton travail est nul (tu as certainement investi beaucoup de temps là-dedans, et le résultat m'a l'air plus ou moins utilisable d'après la capture d'écran), mais juste que:
* La surcharge de fonctionnalités n'est pas forcément une bonne chose.
* Tu devrais vraiment programmer en C ou en assembleur au lieu de perdre ton temps avec du BASIC lent avec un paquet de librairies externes en C ou assembleur. Ça donnerait certainement un résultat meilleur.

C'était l'instant pub de KK

Plus sérieusement, ca a l'air bien mais KK a raison en disant que les chiffres en haut font un peu tas et que tu ferais mieux de la faire en C.

Bah pour le titre, si j'avais mis "et un shell de plus", ça l'aurait pas trop fait.

Nan, il est pas aussi lent
Et puis je compte aussi sur Pollux et son GT-Basic, qui devrait booster le shell de ce coté. L'affichage des fichier un par un serat corriger quand Bob sortiras une version fonctionnelle de Vertel qui intègreras la fonction var_type.

Pour l'affichage des données, j'aime bien voir en permanence ou j'en suis au niveau de la RAM et la Flash, donc pour moi, ça charge pas (de toute façons, y a bien assez de place en dessous pour afficher les fichiers.

Cette partis permet de décharger l'arborescence. Tu met tes Kernel et t'es TSR dans un dossier et tu l'enlèves de l'arborescence. Ca fait une 10-aines de fichiers qui peuvent disparatre chez moi (bien que je les laisse pour les besoins du screen). Et puis ça permet d'avoir un accées direct à l'installation/suppression des TSR/kernel, sans avoir besoin de quitter le shell. Il serat aussi possible de définir quel kernel/TSR doit être installer/désinstaller avant le lancement d'un programme, par soucis de compatibiliter (par exmple si on veut jouer à Chrono Fantasy et SOR3) et libérer de la RAM pour les gros consommateur.

Ouais, bon ça tu te plein à TI, c pas e ma faute s'il nous file pas tous les outils dont on a besoins
Et puis, encors une fois, je garde un espoir envers GT-Basic

Je c, mais aprés, g des pixels qui servent à rien, et j'aime pas ça. C par caprice. Et je crois que je v mettre occuper, plutot, pour garder l'ensemble en français et éviter de mettre un mot anglais par-ci, glisser une expression française par là...

Tu risque de le garder encors longtemps, TicTex

Oui, mais j'aimes bien avoir plein d'infos afficher en même temps. Je c exactement ou j'en suis.

T'inquiètes pas que si je pouvait, je le fairait sans hésiter. A termes, il pourrait même être totalement en C (enfin, je c pas, cette années on apprend le C++, donc j'aviserais).

Au fait, sur le screen, les chiffres sont faux, c à cause de VTI, qui à pas le même getconfg() que sur vrais TI.
Et un autre petit détails, il serat pas adapter sur 89, l'écran étant beaucoup trop petit.

Moi aussi je fais du C++ cette année...

MacIntoc
a écrit : l'écran étant beaucoup trop petit.

"... le shell étant trop surchargé" serait plus approprié...

Mais nan, mais nan, il est pas trop surcharger. Il serait surcharger si l'écran de la 92+ était trop petit
G de l'espace inutiliser, donc je l'utilise, je c pas le laisser vacant pour garder une compatibiliter avec les 89 (z'avaient cas acheter une 92+)
C vrai que sur le screen, ça fait cafouilleux, mais sur TI, ça reste clair.

EvaSDK>BTS ??

ouais, ton shell est très bien niveau interface, mais il faut qu'il soit très rapide;...

d'ailleurs, si tu avales une noix de coco, c'est que tu as très confiance en ton anus

Ce qui m'a l'air vraiment trop lent est surtout l'affichage de la liste des fichiers (on les voit apparaître un par un)

Comme il l'a dit, ça va être corrigé... En fait il est obligé de tester les fichiers un par un (flib oblige ), plus tard ça se fera instantanément.

et le démarrage (on voit les composants apparaître un par un).

Bah... C'est peut-être "accelerable" mais le lancement d'un shell n'est pas primordial. Et puis il ne faut pas oublier que VTI fait toujours ramer les progs quand on le restictionne, et c'est le cas pour ce screen.

Enfin bon... C'est pas à moi d'argumenter

ce shell est vraiment ! mais 6 libs tu avais vraiment besoin de tout?
92+/V200 ruleeeeeeez

euh, si, dans tes posts, tu pouvais éviter les fôtes d'orrrtaugraphe et de gramèr, ce serait appréciable... Je ne te demande pas d'écrire comme KK, mais de t'en rapprocher... - s'il manque des n', ça fait rien, ou des abréviations, mais pour le reste, c'est presque du 1 faute par mot... -

Merci Mac, tu comprendras un jour...

Mac> c joli et ca aurait été interessant si ça n'avait pas été en BASIC ...
essaye de le faire en C ... ce sera plus rapide et econome en place

TheCodR a écrit :
-GTSR (Ced)
-GKRNL (Azerty83)
-Monolog (re-Bob64
-PC1 (re-FL)

kes que sa fait toute ces lib ?
et il est rapide ou pas ? parceque sur le screen, sa a l'air un peu lent

GTSR->récupère ou supprimes les TSR installer
GKRNL->récupère l'OS installer
Monolog->boite de dilogues plus évoluer que celles de TI-OS
PC1->cryptage
Pour la vitesse, ça serat jamais au niveau de C. Mais je pense que se serat parfaitement acceptable.

euh, si, dans tes posts, tu pouvais éviter les fôtes d'orrrtaugraphe et de gramèr, ce serait appréciable... Je ne te demande pas d'écrire comme KK, mais de t'en rapprocher... - s'il manque des n', ça fait rien, ou des abréviations, mais pour le reste, c'est presque du 1 faute par mot... -
Merci Mac, tu comprendras un jour...

bah pour les fautes, je c même pas ou j'en est mis (1 par mot, certes, mais c long un mot).
De rien, et j'espère bien comprendre un jours

Mac> c joli et ca aurait été interessant si ça n'avait pas été en BASIC ... essaye de le faire en C ... ce sera plus rapide et econome en place

Je pense pas que je le fairait 100% en C. La base resteras en basic, mais une grande partis du prog pourrait être en C (mais c pas du tous sur).


Je répètes, VTI ralentis beaucoup le prog. Si Bob améliore quelques petites choses sur sa lib, je pourrait accélerer encors le prog. De plus, il est absolument pas optimiser, je pense pouvoir multiplier sa vitesse globale par 2. Enfin, j'espère vraiment que GT-Basic accélèreras encors le prog.
Mais peut-être que le shell n'arriveras tous simplement pas à terme

Kevin Kofler >> La raison: On installe les TSRs après un reset, et après on ne s'en occupe plus. On connaît la liste de TSRs qu'on a, pas la peine de l'afficher.

MDR

je suis d'accord avec Kevin, ma fois...
j'installe deux TSR de hook, et je les garde en permanence

c vrai ke ce shell a l'air !!!


il prends combien d'octets (libs comprises) ???

euh... pour l'instant beaucoup

Plus qu'Einstein ?
hoooo comme c'est dommage pour toi

ba c pas grave il est mieux qu'einstein

Le pire c'est que c'est vrai

bah... on peut pas avoir 50 000 fonctions dans 1Ko, non plus

MacIntoc a écrit :
bah pour les fautes, je c même pas ou j'en est mis (1 par mot, certes, mais c long un mot).
De rien, et j'espère bien comprendre un jours

Juste la partie de ma réponse - on trouve des fautes dans la suite aussi... -
Mais tu t'améliores

Bob 64 a écrit :
En fait il est obligé de tester les fichiers un par un (flib oblige )

La pub comparative est interdite : tu cites pas mais on se
demande en effet de quoi tu parles
Vertel n'aurait pas ce problème ?

Je n'ai pas fait de pub comparative, j'ai juste souligné un fait :

"FLib oblige à tester les fichiers un par un, donc du coup c'est lent."

Je n'ai rien dit de plus

En attendant, si Vertel intégrait var_type, je serait plus obliger de tester les fichiers 1 par 1