Nouveau firmware Prime + logiciel ordinateur, révision 10077

[zoulou]

Bonsoir,
bon, sans vouloir jeter de l'hule sur le feu, je veux bien relativiser, mais, là on parle de problèmes récurrents, pas d'un truc qui vient d'apparaître avec la dernière version du firmware !
Si ça marchait pas mal avec l'ancienne version et qu'on était déçu par la nouvelle, oui, on pourrait patienter pour soit une nouvelle MàJ soit se résigner à remettre l'ancienne version ... mais là on parle d'un truc qui n'a jamais marché !
Franchement, est-ce normal de devoir redémarrer la calculatrice après le chargement de tout au plus 2 Mo, est-ce normal de perdre tous ses programmes, bêtement, après une cinquantaine de Mo chargés, est-ce normal de jongler avec la mémoire cache et l'écriture en Flash (suis pas un expert ...), est-ce normal de devoir charger un max de pages sur son navigateur pour avoir un taux de transfert décent (???), est-ce normal d'avoir autant de freeze en utilisant l'écran tactile ... ?
Ces problèmes ne datent pas de la version 20160414 !!!
Ce n'est peut-être pas "trivial", mais maintenant ça date de quelques années, non ?

Ah, doublon avec Lionel Debroux ...

[Lionel Debroux]

un max de pages sur son navigateur pour avoir un taux de transfert décent (???)

Ca, c'est le couplage scheduler pourri de Windows / utilisation du protocole standard USB HID (pour ne pas avoir à installer un driver spécial; le choix se tient) basé sur les transferts USB en mode interruptions. Nombre de versions de Chrome sont connues pour changer le tick global du système pour plus de réactivité.

Avec les calculatrices TI et le SilverLink, qui sont des devices USB en class vendor-specific, sous Windows, il faut des drivers spéciaux et signés (pour de prétendues raisons de sécurité... tu parles), ce qui fait ***** à la fois les utilisateurs et ceux qui maintiennent des applications basées sur de tels drivers. Les autres OS n'ont pas besoin de drivers niveau système pour des devices en classe vendor-specific, et c'est beaucoup mieux ainsi.

[critor]

A tire personnel, je ne suis pas énervé.
Je ne suis pas utilisateur régulier de la HP Prime - à cause justement de tous ces problèmes (à la différence d'autres utilisateurs, j'ai le choix).
Si je devais passer un examen/concours et mettre des documents dans la calculatrice, je préfèrerais largement une machine plus lente comme la TI-Nspire CX quitte à attendre 10 secondes si il le faut plutôt que d'avoir quelque chose d'instantané, machine qui à la différence est fiable et avec laquelle mes données seraient en sécurité.

Je suis juste désespéré d'avoir un jour une version du firmware stable - nous sommes en 2016 maintenant pour un modèle sorti pour la rentrée 2013. Les problèmes persistent ou empirent...

Et je suis un peu fatigué d'autre part qu'à chaque fois qu'un problème est signalé sur les forums HP anglophones, la réponse officieusement officielle est systématiquement de se dédouaner en rejetant la faute sur l'outil mViewer GX qui 'abuse' des capacités de la machine.
A force de taper toujours au même endroit, ça finit par faire mal.
Nous 'abusons' tout autant des capacités de machines bien moins puissantes, et aucune ne nous fait ce genre de chose.



Mais donc, les opinions et avis négatifs que je partage ne sont hélas pas amplifiés par une éventuelle colère.



Quand Texas Instruments avait avait fait une bêtise de cet ordre de gravité en avril 2011 en sortant l'OS TI-Nspire 3.0.1 qui corrompait la mémoire NAND, ils avaient certes procédé de façon un peu similaire au départ, en disant par l'intermédiaire de leurs formateurs T3 que c'était la faute de Ndless, que ça n'arrivait que sur les machines ainsi modifiées.
Mais nous avions rapidement démontré avec des retours d'utilisateurs néophytes que c'était faux, et ils avaient été réactifs en le retirant d'une part assez rapidement après confirmation du problème, en sortant rapidement également (sous deux semaines) la version 3.0.2 ne présentant plus le problème, et en nous invitant à leurs frais à un meeting quelques semaines plus tard pour clarifier comment pourrait se poursuivre une collaboration future.

Là potentiellement ce week-end, plein de candidats sont en train de perdre des données qu'ils ont mis peut-être des heures à charger sur leur HP Prime, et seront dans l'incapacité de les recharger correctement sans downgrader, tâche compliquée par le retrait hier des anciennes versions.

[passant]

Bonjour,
Je suis souvent de passage ici (ainsi que sur hpmuseum), j'ai pour une fois l'envie de prendre ma plume ici.

Laissons les sentiments, la rancœur et la déception de cotés et réfléchissons.

Voici ce que nous savons :
[1] : l'OS sur lequel tourne la prime ne supporte pas les exceptions. (lu a plusieurs reprise sur hpmuseum, par l'auteur du CAS qui sait donc de quoi il parle)
[2] : l'instruction ICON réserve de la mémoire (c'est du déclaratif), l'info vient de tim (ici, post 13)
[3] : le garbage collector se fait sur le off (le cycle ON-OFF nettoye les données libérés)
voilà pour les faits.

Maintenant, imaginons, que le process de chargement de programme soit suffisamment low-level. que ce process vérifie biensur que l'espace mémoire est suffisant pour copier les données dans le file-system. mais qu'une fois copié le process enchaine avec la compilation (ce qui pourrait être logique) et qu'alors les parties déclaratives (donc les ICON et autres EXPORT). Supposons qu'alors cela se fasse en consommant de la mémoire (fait [2] et peut être même plus que la taille de l'image elle même, par ex pour reconstruction de l'image) et qu'alors (car fait [3]) les quelques 18 Mo disponibles soient bouffé, mais que l'on est dans un tel process d'où il n'est pas structurellement évident de remonter la piles des appels pour signaler ce problème. (les choses se faisant en cascade, voir post de Tim en lien : transfert->"compilation"->traitement ICON, ça serait plus simple si il n'y avait pas le fait [1]).

Maintenant il existe un outil mViewer GX, qui utilise une fonctionnalité d'une manière intensive.
Si cette supposition s'avère être plus ou moins vrai, alors les dev sont confronté à une situation très complexe, qu'ils n'avaient pas prévue (d'où le 'abuse' même si votre utilisation est legit). Ce n'est pas aussi simple qu'un free() qui manque à un malloc().
Comme beaucoup ici, je suis dev (c'est mon métier), ce genre de situations arrivent. Ce n'est pas toujours possible de modifier structurellement le code pour prendre un cas qui n'aurait pas du être autorisé, mais qui à été pourtant spécifié.

Leur souci, c'est que mViewer GX est populaire, sur une grosse communauté prescriptrice. que ca hurle...

Critor, mViewer GX utilise ICON en suivant la documentation (qui ne donne pas de limitation). Mais de toute évidence ils n'avaient pas prévu d'avoir x Mo de traitement a réaliser ici, car cela met le process en défaut. Honnêtement, je ne sais pas comment ils vont s'en sortir, mais il faut garder à l'esprit qu'il est possible qu'ils ne puissent pas modifier ce process. (voir note)
Et c'est peut être pour cela que c'est toujours pas corrigé, d'ailleurs...

Ce n'est donc pas "la faute" de critor, mais la solution en attendant serait ne plus utiliser mViewer GX.
Oui, ce n'est pas satisfaisant, je sais, désolé... J'espère que ceux qui ont acheté la prime ne l'ont pas fait sur le critère de pouvoir utiliser mViewer GX (dans ce cas une TI aurait été mieux dés le départ).

Pour rappel, ce n'est qu'une supposition (ça se trouve j'ai complètement faux). je ne bosse pas pour eux, je n'ai pas accès à leur code, je n'ai pas eut d'info particulière. je partage juste mon expérience sur des cas où on ne peut plus changer un code critique.


note : Oui, j'ai déjà vu des changements de spec à posteriori pour "corriger" ce genre de problème. "defect by design".

[Adriweb]

De toute manière, ICON va être retiré dans une version future, si j'ai bien lu, donc mViewer aura besoin d'être adapté avec d'autres choses.

[critor]

Ah, je l'apprends - et j'aurais apprécié de l'apprendre d'une autre façon.
Absence donc totale de prise en compte de l'intérêt des utilisateurs - très incorrect donc encore une fois si c'est exact, surtout dans un contexte où l'on évite de répondre depuis un an lorsque l'on est interrogé sur les contraintes techniques des applications - retardant ainsi toute évolution.

[Adriweb]

Ben, c'est marqué dans le post (le #13 aussi) de Tim :

Additionally, it is highly likely we will get rid of ICON either in the next release or the one after because we'll probably be switching to 888 color vs the 565 in use now, and it is *not* a portable format.

2. You have full support for PNG and JPG files with direct save and load. Can't get much more standard then that. Or memory efficient.

3. Make an .hpappdir folder. Stick in all your jpg/png. Stick in an empty .hpapp file of any kind. Stick your app program in there. Should be pretty easy to script no matter what the system.

[critor]

Ce n'est pas à moi qu'il s'adressait, et mon intervention sur le topic est ultérieure.

Mais si tu es en train de me dire quoi faire, tu n'as pas dû lire ce que j'ai posté plusieurs fois sur HP-Museum et ici alors.
Ce qu'il dit ne tient tout simplement pas debout, et il évite de répondre depuis près d'un an sur la question de la clarification des contraintes des applications.

[Adriweb]

Non, je ne faisais que citer Tim par rapport à ton "Ah, je l'apprends - et j'aurais apprécié de l'apprendre d'une autre façon.".
En effet, j'étais un peu largué sur toute la situation et j'ai du lire tous le(s) topic(s) en entier, et donc j'ai vu ça, en pensant que tu l'aurais lu aussi.

[parisse]

Je pense que passant resume assez bien la situation. Ce n'est pas par manque d'egards envers critor ou d'autres que Cyrille et Tim ne s'attelent pas au probleme, c'est certainement parce qu'il n'y a pas de solution technique simple. S'enerver ou avoir un discours completement negatif n'avancera a rien.
La meilleure strategie pour que ca avance a mon avis serait que l'un des developpeurs du viewer devienne beta-testeur (je ne sais pas si l'un deux a repondu a la demande recente de nouveaux testeurs de Tim). Il pourrait alors faire remonter les bugs avant la sortie d'une release et s'assurer que les problemes non resolus conservent une visibilite suffisante.
En attendant, chacun fera son choix en fonction de son utilisation de la calculatrice. Je pense quand meme que pour une tres grande majorite d'utilisateurs qui utilisent leur calc d'abord pour calculer (et pas essentiellement pour consulter certains types de documents), le nouveau firmware apporte plus de stabilite, ainsi que des fonctionnalites nouvelles, ce serait dommage que sur un site comme tiplanet on resume ce nouveau firmware a un bug, meme si bien sur il faut avertir. Un peu comme si je resumais la toolchain ndless/firebird aux cauchemards techniques que j'ai du surmonter pour avoir une installation fonctionnelle.