Forum TI-Planet.org

Hayleia a écrit:Ça arrive "souvent" chez "les gens qui bidouillent" de coder un truc mais flûte alors, cette boucle est infinie, bon ben reset. Surtout s'il n'y a pas d'émulateur à disposition.

A moins de bidouiller avec le kernel (ce qui n'a plus rien à voir avec les apps, et qui nécessite une modification hardware en plus), tu peux pas être bloqué dans une boucle infini. L'implémentation de interrupts sur home et back pour le firmware est la même que pour les apps. Pour l'instant, les callback de ces interrupts sont juste de quitter l'app (ça peut être problématique, mais là n'est pas le sujet).

Hayleia a écrit:Et ça ça donne ni envie de développer des apps ni d'en installer.

Ca dépend des personnes alors.
Je ne crois pas du tout personnellement que c'est le défaut n°1 des apps (ni pour l'instant, ni dans le futur), et ça me dérangera pas tant que ça. Je suis sûr que pour d'autres personnes ça doit être le cas, mais pas pour moi en tout cas.

Hayleia a écrit:Il faudrait non seulement que la gestion des applis ne supprime pas les applis en cas de crash mais qu'en plus elle ne les supprime pas non plus en cas de reset pendant l'exécution d'une application.

Ca serait le mieux c'est sûr, mais il vaut mieux croire au père noël qu'à ça, il a plus de chances qu'il existe réellement . Je pense qu'à moins d'insister en très très grand nombre, ça ne changera pas malheureusement.

redgl0w a écrit:A moins de bidouiller avec le kernel (ce qui n'a plus rien à voir avec les apps, et qui nécessite une modification hardware en plus), tu peux pas être bloqué dans une boucle infini. L'implémentation de interrupts sur home et back pour le firmware est la même que pour les apps. Pour l'instant, les callback de ces interrupts sont juste de quitter l'app (ça peut être problématique, mais là n'est pas le sujet).

Ah du coup ça bute un "cas fréquent" alors effectivement. Et vaut mieux pour eux ne pas faire ce que je disais par rapport au fait de "ne pas supprimer les apps en cas d'appui sur reset pendant l'exécution d'une app".
Par contre une app mal codée peut toujours avoir des fuites mémoire et te donner envie d'appuyer sur reset à un moment dans la journée ?

Hayleia a écrit:Par contre une app mal codée peut toujours avoir des fuites mémoire et te donner envie d'appuyer sur reset à un moment dans la journée ?

Normalement, s'ils se débrouillent comme les apps externes de zardam, le heap de l'app est différent de celui du firmware / kernel (même s'ils n'utilisent surement pas de heap eux). Zardam utilisait le buffer de l'app en cours d'execution comme buffer pour _sbrk.
D'ailleurs tu parlais de gens qui debug leurs apps sur la calculatrice, et le reset soulant, mais l'argument est assez invalide : si ça crash, les gens générallement redémarre pas l'app en 2s, mais d'abbord fix le problème puis flash une nouvelle version.

Ça m'a d'ailleurs fait penser à un des autres problèmes avec les apps : l'impossibilité de les debug (à part sur simulateur). Comme il n'y a pas d'émulateurs pour le moments, et que pour debug sur hardware, il faudra une modification matérielle (et du travail à côté pour réussir à faire comprendre à gdb qu'il y a un elf venant de chez numworks, qui execute un autre bin) pour debug le matériel (du moins pour l'instant (soon)), ça ne sera pas pratique du tout...

Edit : pour debug une app lorsqu'on a un port SWD, la solution la plus simple doit sûrement de compiler bootloader, kernel, userland et apps en un seul elf, et de flash le tout. GDB arrivera alors très bien a se débrouiller je pense. Mais il doit être possible de faire mieux (soon).

redgl0w a écrit:Normalement, s'ils se débrouillent comme les apps externes de zardam

Je me souviens pas d'une fois où ils ont fait les choses correctement

redgl0w a écrit:D'ailleurs tu parlais de gens qui debug leurs apps sur la calculatrice, et le reset soulant, mais l'argument est assez invalide : si ça crash, les gens générallement redémarre pas l'app en 2s, mais d'abbord fix le problème puis flash une nouvelle version.

Euh j'ai pas compris de quoi tu parles et le rapport avec ce que j'ai pu dire.
Tout ce que je disais, c'est qu'en cas de problème dans l'app en cours de tests, les gens vont reset pour sortir de l'app et perdre cette app ET les autres apps qui n'avaient rien à voir avec le test, et c'est ultra chiant et ça donne pas envie de développer.
Argument toujours invalide par rapport au fait que tu disais plus haut que y'a les boutons back et home qui marchent donc pas besoin de reset, mais du coup je comprends pas ce que tu veux dire ici.

Hayleia a écrit:

redgl0w a écrit:D'ailleurs tu parlais de gens qui debug leurs apps sur la calculatrice, et le reset soulant, mais l'argument est assez invalide : si ça crash, les gens générallement redémarre pas l'app en 2s, mais d'abbord fix le problème puis flash une nouvelle version.

Euh j'ai pas compris de quoi tu parles et le rapport avec ce que j'ai pu dire.
Tout ce que je disais, c'est qu'en cas de problème dans l'app en cours de tests, les gens vont reset pour sortir de l'app et perdre cette app ET les autres apps qui n'avaient rien à voir avec le test, et c'est ultra chiant et ça donne pas envie de développer.
Argument toujours invalide par rapport au fait que tu disais plus haut que y'a les boutons back et home qui marchent donc pas besoin de reset, mais du coup je comprends pas ce que tu veux dire ici.

Et encore là, vous adoptez le point de vue développeurs d'applis, public privilégié qui est au courant et a normalement un ordi sous la main dans la situation que vous décrivez (test d'une appli en cours de développement).

Un plantage/freeze pour le simple utilisateur d'applis ne sera jamais à exclure. C'est bien là l'énorme problème. Mais visiblement, la bienveillance envers l'utilisateur n'est plus la priorité chez NumWorks.

Sans compter toutes les activations du mode examen qu'il y aura une année scolaire 'normale', parce que l'enseignant aura puisé pour son DS un sujet de la banque publique d'EC/E3C, et ne veut pas que les élèves recopient une correction mise dans la mémoire de la calculatrice.

redgl0w a écrit:(un workshop d'apps sur leur site, et des apps signés types non CAS seraient déjà très bien (en plus des autres défauts techniques corrigés)).

Je ne suis evidemment pas d'accord! Il faudrait plusieurs modes examens, dont un mode examen CAS avec KhiCAS signe : ce n'est pas de la science fiction, ca existe sur les TI Nspire et les HP Prime, et puis Numworks a deja realise un mode examen pour les Pays-Bas. Et bien sur persistance des apps en cas de reset ou de crash.
J'espere que la communaute de developpement Numworks peut presenter un front uni la-dessus. Il serait dommage de se faire avoir par la politique du diviser pour regner.

Il est clair que face à une entité apparemment déterminée, extrême, têtue et sourde, les divisions sont à éviter.

Tout comme je regrettais ci-dessus l'argument en gros du "non, ça ne dérange pas pour moi développeur".
Il faut penser aux autres et non juste à soi-même, 99% des utilisateurs NumWorks ne seront pas développeurs d'applications/firmwares.

Chacun doit être solidaire des arguments et besoins des autres. Sinon la suppression de l'alerte popup à chaque allumage restera la seule amélioration obtenue, hélas infime et négligeable par rapport à tout le reste.

Pour moi, les éléments techniques éprouvé depuis plus de 20 ans sur les TI-68k, que je connais bien, et les TI-Z80, que je connais moins mais qui utilisent les mêmes concepts, sont une excellente base. Décrivons-les en anglais:

Technically (not talking about how stupid exam makers ruin the fun and damage students' usefulness in the real world), there could be a near-1:1 adaptation of TI-Z80 / TI-68k concepts to NumWorks calculators with exam mode:

• the core firmware is signed by NumWorks, and validated by official boot code (itself dealt with by SoC manufacturer boot code) by chunks or after all blocks of said firmware have been written to Flash. TI calculators do the latter. Official apps are part of this firmware, and when exam mode is enabled, functionality is restricted however the exam regulators dictate;
• if NumWorks wants to make official addons not part of the main firmware, signed with an official key, stored in Flash memory, and possibly restricted / disabled with exam mode is enabled - so be it. TI made a number of those.
• select FlashApps signed by NumWorks could remain permanently present in Flash memory, even in exam mode, but be functionally entirely hidden when exam mode is enabled. There's precedent of hiding FlashApps on the TI-68k series, though it was made by third parties and for startup performance / memory consumption reasons: ExtendeD's FlapHide.
• unsigned stuff (~ TI-68k / TI-Z80 assembly programs) would obviously not be taken into account in exam mode either, so it doesn't even need to remain in RAM, it might as well be relegated to another area of the Flash memory (on the TI-Z80 and TI-68k series, "archive memory", which have real, if simple, reasonably general-purpose filesystems).

TI's certificate scheme supports key IDs: the "freeware" signing/validation key pairs were e.g. 0101 (92+), 0103 (89), 0108 (V200), 0109 (89T), 0104 (83+) and 010A (84+), though I'm not aware of FlashApps signed only for the V200 or 89T. As such, distinguishing official signed apps, community signed apps, and even user-specific FlashApps (after installation of a calculator-specific developer certificate - TI had that over two decades ago) is trivial: just write the key ID in the FlashApp's metadata, and upon reboot, parse said metadata, and act upon it.
On the TI-Z80 and TI-68k series, both official FlashApps and third-party FlashApps which are not user-specific use the "freeware" keys, but technically, that doesn't have to be the case.
The TI-eZ80 series, which is the closest competitor to the (current) NumWorks calculator series, does no longer have (normal) community FlashApps, but TI keeps using the signing infrastructure for the base OS and official FlashApps. Assembly programs were originally a fully supported feature, which TI removed later, but of course, the functionality can be restored by exploits for ACE (/ RCE, certainly) vulnerabilities.

Frankly, during exam mode, the difference between disabled content and erased content is tiny, but it would do wonders for usability by end users, and making a secure implementation of parsing code for simple app metadata shouldn't be too hard...
Of course, there's always the problem of stupid exam regulators and proctors not wanting to enable the stupid exam mode, and this can't be solved through technical means...

BTW: TI-68k FlashApps integrate with the base OS's cooperative multi-tasking which has support for startup phases. There may be some clues to take from this infrastructure as well.

Quelques mèmes par cent20 :

critor a écrit:Et encore là, vous adoptez le point de vue développeurs d'applis, public privilégié qui est au courant et a normalement un ordi sous la main dans la situation que vous décrivez (test d'une appli en cours de développement).

Je pense que pour n'importe quel utilisateur, il sera plus naturel en cas de freeze d'appuyer sur back / home que trouver un objet pointu pour appuyer sur le bouton reset. Le cas du crash n'est pas supporté pour l'instant, mais numworks a bien dit qu'ils n'étaient pas contre, donc comme j'ai dit, ça arrivera vite

critor a écrit:Sans compter toutes les activations du mode examen qu'il y aura une année scolaire 'normale', parce que l'enseignant aura puisé pour son DS un sujet de la banque publique d'EC/E3C, et ne veut pas que les élèves recopient une correction mise dans la mémoire de la calculatrice.

Justement je me pose la question du nombre de prof qui pour leur DS demandent d'activer le mode examen. De mes 2 profs de maths que j'ai eu, aucun ne l'a demandé.