Ndless v1.7 - Page 2

(Je sais, mais j'y étais encore moins ces dernières années)

Pen^2 (./30) :
(en même temps, personne n'y est trop en ce moment )

Mmmmh, j'ai sous le coude de la vapeur qui refroidit suffisamment vite pour se concrétiser la semaine prochaine

(ok, à 1 on a jamais fait une communauté )

On attend ça avec impatience \o/

()

Afin d'élargir le cercle de développeurs et potentiellement trouver des successeurs à geogeo, la documentation développeur a été déplacée et enrichie sur Hackspire : http://hackspire.unsads.com/wiki/index.php/Main_Page#Development_resources

excellent, merci.

La liste des syscalls reste assez légère, bien que hwti, geogeo et Goplat aient pu déterminer un très grand nombre de symboles. Tant que cette liste reste limitée, leurs efforts sont gâchés et les possibilités de développement et de portage resteront très limitées.

Il faudrait commencer par déclarer dans Ndless les syscalls dont les adresses ont déjà été trouvées. Ceci revient pour chaque syscall à :
- Déclarer la ligne correspondante dans os.h et syscalls.h
- Idéalement ajouter un cas de test dans arm/tests
- Editer Hackspire pour pointer sur la documentation externe correspondante

Les correspondances actuelles symboles-adresses au format IDC d'IDA sont les suivantes (sachant que tout ajout ou correction dans ces fichiers est aussi intéressante) :
boot2_1.4.1571.idc
OS_1.1.9253_non-CAS.idc
OS_cas-1.7.idc
OS_ncas-1.7.idc

Toute contribution même mineure est bienvenue.

Parmi ceux qui ont nommé des routines, il y a également bsl [EDIT après lecture plus complète des topics d'UTI: et Levak]

Une conversion automatique pour la table d'adresses (os.h), c'est envisageable? Ça m'a l'air plutôt simple à coder. Ce sont les prototypes (syscalls.h) le problème, comme pour TIGCC (où unknown.h est toujours très rempli avec ou sans les fameuses contributions de Lionel, donc s'il vous plaît évitez ce hors sujet!). Je me demande s'il ne conviendrait pas de générer la table automatiquement et de rajouter les prototypes correspondants au fur et à mesure. Au pire, un prototype peut être rajouté dans le code utilisateur.

Pourquoi pas, c'est aux devs de Ndless de décider
Sans oublier quand même que l'approche TIGCC/GCC4TI, à savoir la génération de code (headers) à partir de fichiers externes, a des avantages et des inconvénients. Doxygen et Javadoc, entre bien d'autres, fonctionnent dans l'autre sens.

Le système des fichiers *.hs? est effectivement à revoir, ça n'a pas marché très bien (les contributeurs potentiels n'ont souvent pas accepté le fait qu'il fallait écrire un fichier par fonction à déclarer, j'ai toujours trouvé ça lourd moi aussi). Il faudra probablement utiliser un autre système pour Ndless.

Le problème, c'est que Doxygen ne crée pas une documentation de la même qualité (les liens entre les fonctions manquent souvent).

On est d'accord, ce sont bien les prototypes le plus long.
Les tables (syscalls-....c) sont générées automatiquement à partir des fichiers .idc par MakeSyscalls. syscalls.h ne fait que sélectionner certaines syscalls.

Une release officielle de Ndless 1.7 (dont la vocation était une compatibilité OS 1.7) apparaît comme très prochaine. Les derniers gros changements implémentés contournent la dizaine d'incidents qui avaient été identifiés.

Des snapshots binaires sont désormais régulièrement publiés : http://bytecode.fr/miscfiles/ti/nspire/ndless-1.7-beta

Si les feedbacks font rapidement apparaître cette beta comme de bonne qualité, la release tombera juste à temps pour les POTY ticalc.orig 2010.

L'étape prochaine est la compatibilité OS 2.x (et donc avec les modèles Touchpad) qui devrait être désormais grandement facilitée.

Très bien, comme d'habitude

et en plus, c'est le post ./43

Voilà, tout frais et stable : http://www.ticalc.org/archives/news/articles/14/146/146939.html

(Et dire qu'on t'a connu tout petit... ! )

C'est déjà noël !

Magnifique, quelle bête ce ExtendeD

Bravo

Je me demande s'il y a un poster "Wanted : ExtendeD" sur les murs des bureaux de TI ?