Standard pour commentaires et autres données statiques exportées en _nostub - Page 5

sinon, je ne vois moi non plus aucun problème quand au numéro de version alphanumérique...
Et sinon, le standard, est-il défini pour les progs faits directement en A68k ou bien m'est-il inutile de le consulter tant que je ne programme pas en C

et vous avez penser à une compatibilité avec le basic ???

Kevin Kofler a écrit :
La différence est que le format _nostub est le format natif d'un système d'exploitation.

On se repete. Bon je veux bien conceder que le format kernel n'est pas natif AMS si tu arretes de me le rabacher. Mais ca ne fait rien avancer.

1. L'anti-crash n'est pas de la stabilité. Un plantage est un plantage, même s'il est récupéré par un anti-crash.

Si car le plantage n'entraine pas forcement une perte des donnees.

2. Tout TSR est un risque de stabilité. Et un gros TSR comme PreOs l'est bien plus qu'un petit TSR comme AutoClBr.

Tu veux dire qu'il y a encore des bogues ? Je le concede oui.

Donc on s'amuse à installer et désinstaller le kernel en pemanence? Je faisais ça au début (des temps de DoorsOS), mais ça m'a vite lassé.

Les programmes basics peuvent automatiser ca

Pourquoi consommer 5 KO d'archive si on peut ne pas les consommer?

Parce que 5Ko c'est le prix que l'on pairait en compilant les programmes au format _nostub.

[Hors-sujet]

PpHd
a écrit : Si car le plantage n'entraine pas forcement une perte des donnees.

Ce n'est pas une mesure de stabilité, ça.

Tu veux dire qu'il y a encore des bogues ? Je le concede oui.

Je veux dire qu'il y aura toujours un risque de bogues. Et que le risque est plus grand si le programme est un TSR parce qu'il tourne en permanence. (Et oui, je sais que $34 n'est jamais exécuté par AMS, mais tu installes aussi d'autres hooks un peu partout dans la table des vecteurs.) Et que le risque est plus grand plus le TSR est grand.

Parce que 5Ko c'est le prix que l'on pairait en compilant les programmes au format _nostub.

Justement, ce n'est pas le cas.

Retour au sujet:

Link a écrit :
sinon, je ne vois moi non plus aucun problème quand au numéro de version alphanumérique...
Et sinon, le standard, est-il défini pour les progs faits directement en A68k ou bien m'est-il inutile de le consulter tant que je ne programme pas en C

Oui:
* il y a un header A68k pour définir ces extensions dans tes programmes. C'est dans l'implémentation de référence, répertoire a68k.
* la librairie statique dataext.a pour lire les extensions est utilisable en assembleur. Son API et son ABI sont documentés (tous les arguments sont passés par des registres choisis explicitement), et ils ne changeront probablement pas. La librairie est d'ailleurs écrite entièrement en assembleur (GNU).

MacIntoc
a écrit : et vous avez penser à une compatibilité avec le basic ???

On ne peut pas lire les données en BASIC pur. On peut avec FLib ou Vertel, évidemment. Pour cela, consulte le standard. Je ne ferai pas d'implémentation de référence en BASIC + librairie parce que je n'ai pas l'habitude de travailler avec FLib ou Vertel, et parce que, quelle que soit la librairie choisie, il y en aura forcément pour me gueuler dessus parce que j'ai choisi la "mauvaise".

Ce qu'il voulait dire je pense, c'est y a-t-il moyen que les programmes basic puissent aussi donner leur nom d'auteur, n° de version etc... quelque part dans le programme, parce que la simple ligne d'AMS, c'est assez peu...

Tu risque pas de choisir la mauvaise, je pense pas que Vertyos laisse qui que ce soit approcher des sources de sa lib
Sinon, je demandait juste s'il était possible de lire directement les champs avec une simple lecture d'octet, ou s'il fallait faire des manipulations quelquonques. Donc à priorie, ça marche.

Moumou
a écrit : Ce qu'il voulait dire je pense, c'est y a-t-il moyen que les programmes basic puissent aussi donner leur nom d'auteur, n° de version etc... quelque part dans le programme, parce que la simple ligne d'AMS, c'est assez peu...

Là, c'est complètement en dehors de la portée de ma spécification. Il faut en faire une autre pour le BASIC.

MacIntoc a écrit :
Tu risque pas de choisir la mauvaise, je pense pas que Vertyos laisse qui que ce soit approcher des sources de sa lib

Pas besoin des sources. Je parlais d'une implémentation en BASIC qui utilise des lectures d'octet avec FLib ou Vertel.

Sinon, je demandait juste s'il était possible de lire directement les champs avec une simple lecture d'octet, ou s'il fallait faire des manipulations quelquonques. Donc à priorie, ça marche.

Il faut quand-même récupérer des offsets codés sur un word (2 octets). Mais à part ça, je ne vois pas de grosse difficulté. Mais ça va être carrément lourd par rapport à l'implémentation de référence en assembleur. Un appel à une librairie externe à chaque fois pour lire un octet... Le BASIC n'est pas du tout adapté pour coder un shell.

MacIntoc a écrit :
Tu risque pas de choisir la mauvaise, je pense pas que Vertyos laisse qui que ce soit approcher des sources de sa lib

Oh la mauvaise foi ! Les sources tu les as, et je les ait aussi passées à qq personnes qui me les ont demandé...

Pour la lecture des données avec Vertel, je m'en chargerais si personne ne le fait.

Disons que ca serait bien mieux si vertel integrai les fonctions pour les lire

Kevin, c pas bien compliquer à faire, donc c pas la peine de faire une "lib" basic pour ça.
La pluspart des données (ou toute peut-être) sont de taille fixe, donc c la lib qui s'occupe de récupérer toute les données en 1 seul appel. Avec FLib, il risque d'y avoir des erreurs, la fonction getbyte n'étant pas au point, mais en contre partis, elle pourras transformé directement toutes les icones en PIC (hein, Vertyos).

au fait, Vertyos, les sources tu me les as filé pour que j'implante une fonction que tu voulais pas implanter. Hors, je c pas programmer en C, je risquais pas de toucher aux sources. Et les quelques personnes autres les ont prise pour pomper un truc dedans, si je me souviens bien

Uther Lightbringer
a écrit : Disons que ca serait bien mieux si vertel integrai les fonctions pour les lire

Non... Une des regles que je me suis fixé c'est de ne pas implémenter de fonction qui puisse être remplacé facilement par l'utilisation (ou la combinaison) d'une ou plusieurs autres. On peut très bien lire ces données avec v_read, donc il n'y aura pas d'instruction "toute faite".

(de toute façon si je fais le programme basic qui lit les données, il n'y aura plus qu'à recopier)

D'ailleurs, faudrait que tu rajoute un argument à v_read et v_writ qui permettrait à l'utilisateur de définir le type de donner qu'il veut recevoir ou qu'il envois (décimal, hexa, caractère, binaire...).

Pourquoi pas... Pour caractère, non, puisque les caractères 0, 10, 13, etc... vont faire bugger la chaine (comme FLib).

suffit de mettre 00, 010, 013...
d'ailleurs, g pas compris en koi ça pouvait faire bugger, ce genre de chaine.

char(0) > Caractere NULL, utilisé pour terminer une chaine
char(10) > CR
char(13) > LF (ou ptet dans l'autre sens pour CR et LF je sais jamais)

CR = Cariage return (Retour chariot)
LF = Line feed

Il s'agit des deux caracteres de controle utilisé pour le controle d'affichage, et dans se ca pour le retour chariot.
Si tu veux en savoir plus ya qu'un truc a apprendre : LE CODE ASCII !!

00 est le caratère de fin de chaine 13 et 10 le retour chariot et le retour a la ligne(je sais jamais lequel) Ce sont donc des caractère considéré comme des caractères de fin de chaine par la TI

10 = LF, 13 = CR. Mais ces caractères ne posent pas de vrais problèmes. Le caractère 0, lui, en pose un. Mais il suffit de retourner une chaîne vide: ord("")=0.

mais c en C, ça, pas en basic ???

En C en basic, en pascal, dans tout les langage informatique ses caracteres sigifie la meme chose

pasque en basic, la manipulation de chaine avec ces caractères ne posent aucun de prbm.

Kevin>sauf quand on veut récupérer plusieur octets en un seul appel

Problème : Quand tu veux retourner {56,65,0,98} ou bien {56,65,98} en chaine, ça fait pareil, puisque 0 donne "".

Pour les chars 13 et 10, ça ne pose la plupart du temps pas de problème, mais quand on veut afficher ces chars dans l'écran HOME par exemple, ça passe assez mal.

Vertyos> tu peux remplacer le '\0' par ' ' et le prog qui a besoin de lire les commentaires fait le tri...

Vertyos a écrit :
Problème : Quand tu veux retourner {56,65,0,98} ou bien {56,65,98} en chaine, ça fait pareil, puisque 0 donne "".
Pour les chars 13 et 10, ça ne pose la plupart du temps pas de problème, mais quand on veut afficher ces chars dans l'écran HOME par exemple, ça passe assez mal.

Pour le 0, je suis d'accord, mais le char 13 ne passe pas que dans la ligne de commande ou il se transformer en :, et le char 10 ne pose pas de problème du tous

(après avoir essayé)

En effet, pas de pb avec les 13 et 10, mais tous les 0 sont omis...

Pollux
a écrit : Vertyos> tu peux remplacer le '\0' par ' ' et le prog qui a besoin de lire les commentaires fait le tri...

C'est barbare... Comment tu veux reconnaitre un ' ' qui est un 0 d'un 32 qui est un espace ?

P.S : Vaudrait mieux créer un autre topic, puisque même si celui ci n'est plus utilisé, c'est pas le sujet.

En effet, merci de tenir ces discussions hors-sujet en dehors de mon topic.

dernier post hors topic
Vertyos> ben si c juste pour lire un commentaire, tu lis la zone correspondantes et voilà. Ca permet d'éviter les décalages dûs à la suppression des 0. Ou sinon tu mets un caractère custom.