Forum TI-Planet.org

Merci pour ces réponses détaillées. Je vois que c'est bien plus compliqué que ça en a l'air, surtout avec l'exemple de M4x1m3.

un OS qui me semble dans la meme philisophie que des toolkits GUI pour PC, un peu comme FLTK mais en plus complique. Pas du tout comme les syscalls de Casio

Cela dit les syscalls de Casio c'est pas un modèle de dessin raisonnable pour un vrai OS ? J'ai pour habitude de considérer les toolkits graphiques comme plus pertinents pour les applications type bureautique (les jeux sont une exception, comme d'hab). Surtout que normalement ils ne t'empêchent pas de créer un widget de ton choix que tu dessines à la Casio. Après tout dépend de l'API proposée >_>

type tutoriel "Comment créer son application" (..) pas d'équivalent à un SDK type Casio/TI

C'est moins orienté extensions tierces que je ne le croyais alors.

Bibliothèque C/C++: freestanding et extrêmement spartiate, ce qui rend le portage de code tiers vers epsilon compliqué

Dans quelle mesure est-ce que Epsilon contient du code fait main qui aurait (du point de vue du développeurs tiers) mieux fait d'être porté/standard ?

Développement internes de NumWorks: les ingénieurs NumWorks développent chaque nouvelle version dans leur coin, puis quand c'est suffisamment prêt pour une beta ils dumpent d'un coup des centaines de commits sur leur dépôt officiel, les développeurs tiers comme moi manquent de visibilité sur les PR

À quel point est-ce possible qu'une PR tierce soit intégrée dans le dépôt puis maintenue par Numworks ?

Je suis en train de faire de la revue et documentation de code dans les sources de Symbolibre et je voulais en profiter pour voir quelques écueils à éviter - on risquerait de tomber dans les mêmes pièges que Numworks.

Sur une calculatrice, je persiste a penser que le paradigme "int main()" est plus simple a mettre en oeuvre que le paradigme "bureautique" avec une hierarchie de classes, et tout autant pertinent. Maintenant, on est d'accord que le paradigme bureautique, s'il est bien documente et simple a utiliser, est accessible et a l'avantage de permettre des portages ailleurs.

C'est sûre que ça peut paraître bizarre point de vue nommage, mais bon, c'est comme ça que les vues sont implémentés dans epsilon : https://github.com/numworks/epsilon/blo ... view.h#L49

Le super-firmware communautaire serais une bonne solution, notamment face aux choix assez controversés de l'équipe de développement (retrait du calcul symbolique, etc.) juste pour s'adapter au marché, et non pour améliorer la vie de l'utilisateur...

Pour les maths, il y aura tout ce qu'il faut dans delta, qui sera bientot distribuable en enlevant tout lien avec les apps existantes. Khicas contient aussi les constantes physiques et la gestion des unites, par exemple
mksa(_c_), il faut juste les rajouter dans un menu. La table periodique des elements devrait aussi pouvoir etre ajoutee, sous reserve qu'il n'y ait pas d'incompatibilite de licence avec la GPL, avec la possibilite d'entrer les donnes selectionnees vers l'historique des calculs.

Sur une calculatrice, je persiste a penser que le paradigme "int main()" est plus simple a mettre en oeuvre que le paradigme "bureautique" avec une hierarchie de classes, et tout autant pertinent. Maintenant, on est d'accord que le paradigme bureautique, s'il est bien documente et simple a utiliser, est accessible et a l'avantage de permettre des portages ailleurs.

Oui, je suis d'accord que c'est pertinent également. Pour moi, une API graphique type widgets doit inclure de quoi dessiner plus simplement.

(En tous cas, pour Symbolibre il est tout autant possible de programmer en C avec la SDL qu'en C++ avec Qt. Ouf !)

Lephe a écrit:

Bibliothèque C/C++: freestanding et extrêmement spartiate, ce qui rend le portage de code tiers vers epsilon compliqué

Dans quelle mesure est-ce que Epsilon contient du code fait main qui aurait (du point de vue du développeurs tiers) mieux fait d'être porté/standard ?

Je pense qu'une libc custom ne se justifie plus dans une N0110. Pour ce qui est du code tiers, c'est surtout un manque d'infrastructure et d'outillage avec du développement tiers.

Lephe a écrit:

Développement internes de NumWorks: les ingénieurs NumWorks développent chaque nouvelle version dans leur coin, puis quand c'est suffisamment prêt pour une beta ils dumpent d'un coup des centaines de commits sur leur dépôt officiel, les développeurs tiers comme moi manquent de visibilité sur les PR

À quel point est-ce possible qu'une PR tierce soit intégrée dans le dépôt puis maintenue par Numworks ?

La dernière fois, c'était ma PR pour les grades (https://github.com/numworks/epsilon/pull/1029). Créée le 24 juin, mergée mi-septembre, pas de nouvelles entre temps.

Lephe a écrit:Je suis en train de faire de la revue et documentation de code dans les sources de Symbolibre et je voulais en profiter pour voir quelques écueils à éviter - on risquerait de tomber dans les mêmes pièges que Numworks.

Il suffit de se poser comme contributeur externe puis comme utilisateur lambda et d'essayer de porter puis d'installer un jeu vidéo et de documenter le processus. Si l'installation depuis un firmware original ne nécessite ni SDK ni magie noire, c'est bon.