Problème applis mViewer GX & firmware HP Prime 13333

[critor]

J'ouvre ce topic pour que l'on puisse échanger au sujet d'un grave problème afin, je l'espère, de le résoudre.

Prenons 3 documents mViewer GX convertis en applications HP Prime.
Au hasard :
archives_voir.php?id=1367194
archives_voir.php?id=1367193
archives_voir.php?id=1367190
Ils sont tous les trois petits, moins de 10 pages, rien d'extraordinaire.

Mettons-les dans une HP Prime en version 13333.
Lançons l'une de ces trois applications une fois, puis quittons-la.
Voilà, maintenant c'est foutu, quand on tente de relancer n'importe laquelle de ces trois applications, nous avons l'écran d'erreur suivant :

Il faut faire reset pour être à nouveau capable d'accéder au contenu d'un document. Et il faudra le refaire après chaque lecture.

C'est très embêtant pour les candidats qui ont des examens ou concours dans seulement quelques semaines.
Et le reset n'est pas une solution. Voir un candidat sans arrêt retourner sa calculatrice ne va sûrement pas paraître normal aux surveillants.

Cela ressemblerait à des ressources mémoire qui ne sont pas libérées.
On note bien une baisse de la mémoire disponible entre avant et après la 1ère lecture du document, mais rien de catastrophique devant rendre tout document illisible :


Le problème semble avoir été introduit avec la version 13333.
Sur ma calculatrice qui est restée avec la beta 13217 je n'ai aucun problème, et les infos mémoire sont similaires.
Donc ce serait HP qui a changé quelque chose... Faut-il encore trouver quoi.

Si nous n'arrivons pas à identifier et résoudre le problème, il va falloir rapidement communiquer, dans l'intérêt des candidats, afin qu'ils soient informés et puissent librement choisir entre le reset et le retour en 13217.
Découvrir ce problème juste le jour de son examen/concours pourrait en effet être dramatique...

Merci à ceux qui apporteront leur aide.
Un moyen de récupérer précisément l'erreur déclenchée par une application à la place de l'interface de parabole d'une autre application ?

[critor]

Le problème se produit aussi sur l'émulateur en version 13333.

[critor]

Mis des MSGBOX(), vu que je ne sais pas déboguer les applications HP Prime autrement.

La ligne interrompant l'exécution à partir de la 2ème tentative de consultation d'un document, c'est le dimgrob de G1 en 320x240 dans la fonction OpenFile :

Code: Select all

MSGBOX({sw,sh});
DIMGROB_P(G1,sw,sh); // offscreen grob
MSGBOX("Done");

J'obtiens la 1ère boîte avec {320,240} mais pas la 2ème.
Et vu que, sauf erreur, il reste plus de 13Mio de RAM libre, ce dimgrob n'a pourtant strictement aucune raison d'échouer.

[critor]

Si je teste la commande sur l'écran de calculs, c'est un peu plus clair. Mais je ne suis absolument pas d'accord avec le message d'erreur affiché :

[critor]

Oui, il y a clairement un changement de comportement entre les firmwares 13217 et 13333, qui pour moi ne se justifie pas et relève donc d'un bug.

Faisons reset, et testons avec un calque de 1x1 pixel :

Et ben si, la machine vide a le culot de prétendre qu'elle manque de mémoire à la 2ème utilisation de dimgrob sur le même objet.

Plus précisément, la fonction DIMGROB_P() renvoie à tort une erreur de mémoire, si on tente de spécifier des dimensions de calque qui sont déjà celles appliquées à l'objet. C'est nouveau...

[critor]

Donc question, comment contourner cela proprement ?
Y a-t-il une fonction pour récupérer les dimensions du calque G1 avant de faire appel à DIMGROB_P() ?

Je pourrais toujours faire par exemple, au pif :

Code: Select all

DIMGROB_P(G1,13,33);
DIMGROB_P(G1,320,240);

Mais rien ne garantit qu'une application utilisée juste avant n'aura pas dimensionné G1 en 13x33 pour des sprites de jeu par exemple, auquel cas l'application de lecture de document va encore planter.
Je pourrais augmenter nettement la valeur de 13x33 pour réduire les chances de tomber sur un truc existant, mais c'est alors la mémoire qui pourrait râler...

[Adriweb]

Maintenant que le problème a l’air cerné, ce serait une question à poser sur MOHPC pour que les développeurs comme TW puissent y répondre potentiellement rapidement ? Je ne suis pas sûr qu’ils visitent TI-Planet si souvent que ça, d’autant plus sur des topics en Français.

Par ailleurs, est-ce que ça serait lié au bpp plus élevé désormais ?

[critor]

Créé le fil :
http://www.hpmuseum.org/forum/thread-10215.html

Si j'ai bien compris, ça doit casser à peu près toutes les applications graphiques pour HP Prime. Je suis surpris que personne n'ait reporté le problème depuis toutes ces semaines.
Toutes celles qui dimensionnent des calques avec des valeurs fixes, qui ne peuvent plus être lancées deux fois de suite.
Et toutes celles qui utilisent par hasard des calques de mêmes dimensions et ne pourront plus être lancées à la suite. Certaines dimensions sont usuelles et donc très fréquentes : sprites en 8x8, 16x16 ou 32x32, offscreen ou fond d'écran en 320x240...

[critor]

En attendant une éventuelle correction, on nous propose comme workaround d'englober les DIMGROB_P dans un IFERR :

Code: Select all

IFERR
  DIMGROB_P(G1,320,240);
THEN
END;

Je n'ai pas le temps de toucher au code sur le serveur dans l'immédiat, mais si ça marche ce sera sûrement en place d'ici la fin de la semaine.
Par contre, ceux qui tiennent à rester avec le firmware 13333 devront reconvertir tous leurs documents pour profiter du nouveau code avec le workaround.

[critor]

Voilà, corrigé dans le firmware 13441 sorti à l'instant. Jamais vu une telle réactivité, même pas 8h !