Mettre des fichiers tiers sur HP-Prime, mission impossible?

→ **MyCalcs** profile · de **Adriweb** » 21 Oct 2013, 12:02

Petite note :

Je *pense* qu'il y a un problème d'encodage (oublié de mettre en UTF-8 ?), au vu de l'accent sur "Liévain" qui n'est pas passé dans les nouveaux fichiers.

Question à 2 francs :
Puisque l'architecture ressemble tant à celle sur laquelle Tilp se base - serait-ce alors compliqué de littéralement utiliser (copy/paste) tous les codes de GUI de tilp pour faire un hplp ?

→ **MyCalcs** profile · de **Lionel Debroux** » 21 Oct 2013, 12:34

J'ai utilisé mon éditeur préféré, qui utilise ISO-8859-1(5), en effet. Le "é" de Liévin est le seul accent possible dans ces fichiers, cependant, puisqu'ils sont en anglais

Puisque l'architecture ressemble tant à celle sur laquelle Tilp se base - serait-ce alors compliqué de littéralement utiliser (copy/paste) tous les codes de GUI de tilp pour faire un hplp ?

En fait, il n'est pas souhaitable de faire ainsi, donc je ne me pose même pas la question

Quand l'interface graphique de TILP II a été faite, Qt n'était pas envisageable, car à l'époque, Qt 3 ne fonctionnait pas sous Windows. GTK+ était alors un des principaux toolkits permettant de cibler à la fois Windows, MacOS X et Linux avec une seule base de code contenant peu de code dépendant plate-forme, et à l'époque, c'était probablement le meilleur choix. wxWidgets, autre possibilité à l'époque, utilise de toute façon GTK+ sous Linux.
Par ailleurs, libti* utilise Glib pour l'abstraction plate-forme et les ADTs de plus haut niveau que ce que le C fournit (listes, arbres, etc.). Les fonctions de Glib apparaissent explicitement dans certaines APIs libti*, et apparaissent de toute façon implicitement. Je pense que c'est en partie pour ça qu'aucun front-end Qt à libti* n'a été fait: de toute façon, la dépendance à Glib reste présente.

De nos jours, longtemps plus tard, Qt est un bien meilleur choix que GTK+: meilleure portabilité, évolution plus rapide, bonnes performances. wxWidgets n'évolue plus beaucoup, et il reste verrouillé sur GTK+ sous Linux.
Pas plus tard que cette semaine, Wireshark s'est ajouté à la liste des projets qui passent de GTK+ à Qt. L'explication citée par https://lwn.net/Articles/570694/ est claire, et je suis bien d'accord (j'ai ajouté le gras):

Beginning with Wireshark 1.11.0 the project has switched its user interface library from GTK+ to Qt. "Both libraries make it easy for developers write applications that will run on different platforms without having to rewrite a lot of code. GTK+ has had a huge impact on the way Wireshark looks and feels and on its popularity but it doesn’t cover our supported platforms as effectively as it should and the situation is getting worse as time goes on." (Thanks to Matthias Berndt)

J'imagine que je vais renommer le repo hpcomm en hplp.

→ **MyCalcs** profile · de **romsor** » 21 Oct 2013, 18:55

Au début, le design me semblait complexe, mais j'ai fini par l'apprécier, car il fournit des structures de données et une couche d'abstraction raisonnables pour gérer plusieurs familles de modèles assez différents avec une API quasi-unifiée. Ca ne veut pas dire que le modèle de données de libti* est parfait, mais il n'est pas si mal, en fin de compte...yu

C'est juste que je suis parti de la TI92 en 1999 et que le code a grossi au fur et à mesure...

Puisque l'architecture ressemble tant à celle sur laquelle Tilp se base - serait-ce alors compliqué de littéralement utiliser (copy/paste) tous les codes de GUI de tilp pour faire un hplp ?

Je m'étais aussi posé cette question à un moment où l'on m'a proposé d'intégrer les HP et même conclusion que Lionel: il vaut mieux faire 2 programme indépendants sinon la correction de bugs devient exponentielle avec le nombre de machines.

De nos jours, longtemps plus tard, Qt est un bien meilleur choix que GTK+: meilleure portabilité, évolution plus rapide, bonnes performances. wxWidgets n'évolue plus beaucoup, et il reste verrouillé sur GTK+ sous Linux.

Au départ, je pensais coder TiLP avec QT et j'ai choisi GTK pour sa license/gratuité. A un moment, j'avais envisagé basculé sous Qt mais l'empreinte de code GTK était devenu trop importante. Mais, je penche pour Qt et je ne vois plus aucun intérêt à choisir GTK aujourd'hui.

→ **MyCalcs** profile · de **Lionel Debroux** » 21 Oct 2013, 19:37

Salut Romain

Ah oui, j'avais oublié qu'en plus, la licence de Qt était différente à l'époque...

EDIT: renommé le repository en "hplp": https://github.com/debrouxl/hplp .

→ **MyCalcs** profile · de **Lionel Debroux** » 22 Oct 2013, 20:59

J'ai introduit un système de build, qui est capable de construire une lib dynamique, comme libti*... mais je n'ai pas committé, car je n'ai pas encore eu le temps de refactoriser le client de test, donc l'arbre des sources local est (encore) moins utile que l'arbre des sources publié...

→ **MyCalcs** profile · de **Lionel Debroux** » 24 Oct 2013, 21:32

Le système de build fonctionne (sous Linux, tant pour la compilation native que pour la cross-compilation), il y a un vrai client de test interactif... mais il n'y a pas encore assez de tests, je n'ai pas encore assez confiance dans le code pour committer quelque chose.
J'ai des backups, ne vous inquiétez pas

→ **MyCalcs** profile · de **Lionel Debroux** » 25 Oct 2013, 11:01

Moyennant, pour l'instant, un petit trafiquage pour enlever des octets non filtrés (pour l'instant) au début du fichier, voici en pièce jointe ce que la fonction screenshot de libhpcalcs produit (merci critor pour les nombreux dumps et tests)

Je sais, l'heure est cassée, et pour l'instant, le code de libhpcalcs n'est pas capable d'envoyer ou de recevoir des fichiers vers/depuis la calculatrice, ce qui le rend peu utile en pratique pour l'instant...

→ **MyCalcs** profile · de **Adriweb** » 25 Oct 2013, 14:06

pas mal, c'est déjà bien - on (tu

) en apprend de plus en plus sur le protocole

→ **MyCalcs** profile · de **critor** » 25 Oct 2013, 15:13

Belle avancée!

Les couleurs sur l'image récupérée sont mauvaises, particulièrement pour la barre de titres.

Cela ressemble à ce qui se passe si on lit en RGB un code couleur écrit en BGR (échange des teintes rouges/bleues).

→ **MyCalcs** profile · de **Lionel Debroux** » 28 Oct 2013, 07:53

Le code a pas mal avancé depuis vendredi, il est maintenant capable de segmenter correctement un backup de la calculatrice, pour peu qu'il n'y ait pas de pertes de paquets pendant le transfert. Mais le transfert de gros volumes de données semble assez fiable... du moins, à partir du moment où on ne sort plus de texte de log dans l'énormissime saloperie qu'est le terminal Windows.
Cette connerie de terminal Windows est tellement lent (à un tel niveau que la seule explication rationnelle est que c'est fait exprès) que l'exécution du programme est terriblement ralentie par le simple fait d'écrire sur la sortie standard... C'est exactement pour ça que sous Windows, les logs de TILP sont redirigés vers un fichier. Cependant, alors que la lenteur du terminal Windows semblait pardonner avec les devices USB de TI, en classe vendor-specific et utilisant des transferts bulk, ça ne pardonne pas avec la Prime, device USB HID utilisant donc le mode interrupt (plus sensible au timing): un des essais de critor a montré que l'ordinateur ratait plus de trois paquets sur quatre en moyenne (!) dans un screenshot d'une vingtaine de KB...
Bref, la console Windows, c'est extrêmement mal fait.

Il reste quand même à implémenter l'envoi et la réception de fichiers individuels... et après, ce sera publiable, même si toujours difficile à utiliser