π
<-
Chat plein-écran
[^]

TILP: beta-test...

Discussions diverses, débats, sondages, parler de tout et de rien... mais en restant plutôt sérieux.

Re: TILP: beta-test...

Unread postby Adriweb » 01 Mar 2018, 18:08

Ca, Lionel en fait de temps en temps :)

(Mais plus sérieusement, pour Linux, il trollait juste, on parle depuis peu de faire renaître les builds OBS un jour (ce qu'utilisent Firebird et CEmu) pour TiLP. C'est pas tres compliqué, mais faut prendre le temps de le faire et de s'assurer que ça fonctionne comme prévu - mais après, c'est sacrément plus simple pour tout le monde).

Cf. ce qu'avait fait Vogtinator il y a 2 ans : https://build.opensuse.org/project/show ... nator:TILP
User avatar
AdriwebAdmin.
Niveau 16: CC2 (Commandeur des Calculatrices)
Niveau 16: CC2 (Commandeur des Calculatrices)
Level up: 51.5%
 
Posts: 12616
Images: 1081
Joined: 01 Jun 2007, 00:00
Location: France
Gender: Male
Calculator(s):
Class: (ingénieur)
Twitter: adriweb
GitHub: adriweb

Re: TILP: beta-test...

Unread postby Ti64CLi++ » 01 Mar 2018, 18:14

Ah, excuse-moi de ne as avoir compris :?
Image
User avatar
Ti64CLi++Modo
Niveau 15: CC (Chevalier des Calculatrices)
Niveau 15: CC (Chevalier des Calculatrices)
Level up: 70.4%
 
Posts: 3148
Images: 61
Joined: 04 Jul 2014, 14:40
Location: Clermont-Ferrand 63
Gender: Male
Calculator(s):
Class: Maths Sup
GitHub: Ti64CLi

Re: TILP: beta-test...

Unread postby Lionel Debroux » 05 Jun 2019, 07:37

Ca fait plus d'un an que je n'ai pas posté dans les topics de beta-test TILP des divers forums... Pendant ce temps-là, il s'est passé des choses, même si comme d'habitude, peu sont vraiment visibles :)
Il faudra que je produise un build Windows quand la gestion des CX II sera utilisable.

Parmi les changements:
  • Adriweb a ajouté la possibilité de compiler les libti* avec CMake, je l'ai mergée, et la même chose pour TILP, que je n'ai pas mergée parce que je me concentre plutôt sur libti* ^^;
  • le ROM dumper TI-eZ80 a été amélioré, puis corrigé, par jacobly;
  • j'ai beaucoup travaillé sur le ROM dumper TI-68k:
    • correction de gros bugs dans la gestion des 92 / 92 II: non seulement j'avais cassé le dirlist lors d'un refactor, mais le ROM dumper 92 / 92 II a corrompu les données dumpées depuis 2005 au moins (le code était déjà faux au moment du passage libticalcs 1 -> 2) en effaçant 8 KB de données pour obtenir des dumps cohérents sur le bloc certificate memory... ben oui mais il n'existe pas sur ces modèles :( ;
    • plusieurs passes d'optimisation en C, avant de basculer en pur ASM pour optimiser davantage, bien sûr, mais surtout pouvoir se débarrasser de la dépendance à un compilo C ciblant le m68k. En effet, le vieux GCC m68k-coff lourdement patché de GCC4TI qui ne fonctionne plus correctement si on le compile avec des compilos plus modernes n'est pas du tout une solution d'avenir, et le m68k-elf standard compilé par Debian s'avère beaucoup trop buggé pour être utilisable... Un résultat final de ces opérations sera de rendre le ROM dumper TI-68k compilable de façon inconditionnelle par Debian, puisque Debian package tous les outils nécessaires. Pour ça, il a fallu être créatif pour la production d'un binaire au format Fargo II, assez spécial.
  • j'ai implémenté un système d'événements dans libticables et libticalcs, ce qui, avec les dissecteurs de paquets que j'ai réécrits ou que je dois finir pour libticalcs, permettra d'avoir une bien meilleure fonctionnalité de dissection des paquets - mais aussi de nouvelles fonctionnalités;
  • pour pouvoir benéficier d'un meilleur typage et à terme d'une meilleure librairie de fonctions standard, j'ai passé le code de libti* en C++, même si bien entendu, l'API externe reste en C;
  • j'ai corrigé encore pas mal de problèmes reportés par l'analyseur statique Coverity, j'avais déjà fait des passes précédemment;
  • j'ai ajouté la première partie de la gestion de deux modèles supplémentaires:
    • Nspire Lab Cradle / Datatracker Cradle: non testé, mais on sait que ces deux-là se comportent largement comme les Nspire;
    • Nspire CX II: elles sont détectées au niveau USB, mais pour l'instant, traitées comme des Nspire, ce qui est très faux. Le protocole qu'elles utilisent est très différent de celui des autres Nspire (il y a un wrapper sur une version modifiée de NavNet), mais apparemment, le même que celui du NWB, autrement dit des équipements utilisés en classe pour gérer plusieurs machines à distance. Ce protocole n'avait jamais été reverse-engineered.
  • les TI-eZ80 disposant de la capacité "Python On Board" sont maintenant reportées par libticalcs - autrement dit, les 83PCE EP. Merci Adriweb pour les infos :)

Par ailleurs, j'ai repris et modifié un peu les précédents travaux sus-mentionnés de packaging de versions de développement de libti*/gfm/tilp sur OBS par Fabian "Vogtinator" Vogt, le résultat (absolument pas testé !) est disponible à partir de https://build.opensuse.org/project/show ... rouxl:TILP .

A venir:
  • une vraie gestion des CX II, en utilisant leur "nouveau" protocole. J'avais commencé les travaux de RE, mais je n'avais pas trouvé exactement l'algo de calcul du checksum - ce que Fabian, qui dispose maintenant d'une CX II, a fait cette semaine, en utilisant
    d'autres méthodes
    . On va pouvoir avancer.
  • quelques modifications de commits existants (par exemple, le dissecteur DBUS, qui est assez tôt dans la pile de commits sur la branche experimental2, n'est pas rempli), et quelques tests supplémentaires;
  • plus tard: une gestion initiale du CBL2, au moins détection et reflashage d'OS. UPECS vient d'en acheter un, il est arrivé à la maison hier;
  • la release TILP II 1.19 + libs associées, entre deux et trois ans après TILP II 1.18 - il y a bien de quoi, avec toutes ces nouveautés;
  • un packaging Debian/Ubuntu non officiel sur OBS: pour l'instant, il n'y a qu'openSUSE et Fedora.
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: TILP: beta-test...

Unread postby romsor » 13 Jun 2019, 17:49

Salut Lionel,

Je suis content de voir que tu continue de faire vivre le logiciel...

Sinon, çà gaze ?

Romain.
User avatar
romsorProg.
Niveau 0: MI (Membre Inactif)
Niveau 0: MI (Membre Inactif)
Level up: 0%
 
Posts: 8
Joined: 08 Jun 2012, 15:45
Gender: Male
Calculator(s):

Re: TILP: beta-test...

Unread postby Lionel Debroux » 13 Jun 2019, 19:24

Salut Romain :)

Je suis content de voir que tu continue de faire vivre le logiciel...

Merci :)
Ca fait déjà dix ans que je suis devenu mainteneur, puisque c'est à peu près à cette période de l'année 2009 que tu as annoncé que tu cédais la maintenance. Ce n'est qu'à partir de novembre 2009 que je me suis vraiment mis à travailler sur la base de code.
J'ai toujours beaucoup moins travaillé sur GFM et TILP que sur les libs. L'architecture en couches m'a posé quelques problèmes au début, mais elle est bonne, les couches sont nécessaires et bien faites. La seule exception notable que je voie, dont je me suis rendu compte assez récemment, est le logging + dissection automatique des paquets... et ça ne sera bientôt plus un problème parce que vu qu'il y a un nouveau protocole, plutôt que d'intégrer sa gestion à l'infrastructure existante, il est préférable que je fasse le refactor avant.

Sinon, çà gaze ?

Toujours chez le même employeur, dans les locaux où tu étais venu me rendre visite il y a plus de 5 ans. Plus vraiment sur le même projet, hélas, même s'il existe et évolue toujours. J'ai fait diverses autres choses sur des projets internes ou client. Ca fait deux ans que je fais davantage de sysadmin que de programmation.


Et de ton côté ? :)


A +,
Lionel.
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: TILP: beta-test...

Unread postby romsor » 14 Jun 2019, 14:26

L'architecture en couches m'a posé quelques problèmes au début, mais elle est bonne, les couches sont nécessaires et bien faites.


Ca fait plaisir...
C'est mon côté "systèmes embarqués": j'aime bien découper en couches indépendantes.

La seule exception notable que je voie, dont je me suis rendu compte assez récemment, est le logging + dissection automatique des paquets...


Je te rassure, j'ai toujours trouvé que ce truc était une verrue mais c'était tellement pratique pour débugger.

et ça ne sera bientôt plus un problème parce que vu qu'il y a un nouveau protocole


Ah bon ?

De mon côté, j'ai fait 1 an de thèse (biblio terminée + position paper en cours d'écriture) et il me reste encore 2 ans.
Perso, j'en bave un peu pour écrire, c'est pas mon truc. J'ai un peu l'impression "d'enculer les mouches" !
User avatar
romsorProg.
Niveau 0: MI (Membre Inactif)
Niveau 0: MI (Membre Inactif)
Level up: 0%
 
Posts: 8
Joined: 08 Jun 2012, 15:45
Gender: Male
Calculator(s):

Re: TILP: beta-test...

Unread postby Lionel Debroux » 14 Jun 2019, 15:30

L'architecture en couches m'a posé quelques problèmes au début, mais elle est bonne, les couches sont nécessaires et bien faites.
Ca fait plaisir...
C'est mon côté "systèmes embarqués": j'aime bien découper en couches indépendantes.

C'est un bon principe de génie logiciel.
Le nombre de couches présent semble rarement apprécié de ceux qui mettent le nez dans la base de code pour les premières fois, nous trouvons tous l'assemblage trop complexe. Et c'est tout à fait exact si on ne considère que le besoin restreint de communiquer avec une seule famille de machines. Plus de la moitié de la base de code est superflue si on ne s'intéresse qu'aux Nspire, j'avais fait un exercice assez rapide de trim à gros grain il y a longtemps: https://github.com/debrouxl/strip_tilp_nspire .
Mais si on cherche à gérer plusieurs familles de machines qui offrent toutes des opérations similaires, et qu'on veut le faire avec une seule base de code plutôt qu'avec plusieurs qui dupliquent du code, les couches existantes sont ce qu'il faut, à peu de choses près.

La seule exception notable que je voie, dont je me suis rendu compte assez récemment, est le logging + dissection automatique des paquets...
Je te rassure, j'ai toujours trouvé que ce truc était une verrue mais c'était tellement pratique pour débugger.

Jusqu'à un certain point, en effet... mais la façon dont l'implémentation est réalisée, en sérialisant tout vers un fichier puis en cherchant à reparser le dump hexa sérialisé, élimine l'info de direction des paquets. J'ai mal réinterprété les données, et ça m'a déjà fait perdre un temps certain quand j'ai voulu utiliser le dump DUSB libticables comme source d'info pour réimplémenter du code de communication sur 89T... du coup, je n'étais pas content :)

Un nouveau use case est apparu ces dernières années: la possibilité de communiquer avec les machines sans avoir à installer de logiciel supplémentaire au préalable, ce qui simplifie la vie des utilisateurs peu avancés / motivés de l'informatique, de plus en plus nombreux, et des utilisateurs qui n'ont pas de droits d'administration sur leurs machines, assez nombreux eux aussi. Une des technologies les plus pratiques serait WebUSB + une UI Web, s'exécutant dans le browser habituel, mais les APIs correspondantes sont asynchrones, alors que l'API libti* est synchrone... C'est non seulement plus simple, plus facile à comprendre et maintenir (le code asynchrone et/ou événementiel peut être moins lisible et plus difficile à modifier), mais naturel pour implémenter des protocoles synchrones requête(s)-réponse(s). J'aurais fait la même chose à l'époque de la création de libti* 2 en 2005, où je ne me serais peut-être même pas posé la question, et encore pendant plus de 10 ans après ça, puisqu'en 2015, WebUSB n'était pas dispo.
Mais refaire en asynchrone une bonne partie de la base de code serait un travail considérable, bien plus que ce qu'on peut se permettre de faire pour un logiciel maintenu sur notre temps libre, sans être payés pour ce faire. Et encore, toi (à la fin) comme moi n'avons déjà pas à acheter les machines sur notre argent, même si je l'ai fait avec 4 machines avant d'en récupérer 15 chez toi...
Pour simplifier légèrement la réécriture asynchrone, on pourrait envisager de laisser tomber tous les câbles non USB ou réseau (ces derniers n'étant pas réellement implémentés), et les plus vieux modèles de machines comme 80, 82, 83, 85, 86 et 92, mais le code de gestion de ceux-là ne représente qu'une petite partie du travail qu'il faudrait réaliser.

et ça ne sera bientôt plus un problème parce que vu qu'il y a un nouveau protocole

Ah bon ?

Ouais. Comme je l'ai rapidement écrit plus haut, le CX II utilise un protocole "nouveau" au sens où il n'a jamais été implémenté par libticalcs, mais il existe depuis un certain temps sur les équipements spéciaux pour l'enseignement, de type réseau (on voit des référence à "NWB", ce que j'interprète comme Network Bridge ou Network Wireless Bridge). Que je sache, dans la communauté, on l'ignorait tous.
Pour aller plus en détail: il y a des headers de 12 octets, un peu plus simples que ceux de NavNet, et pour un certain nombre de paquets, une variante de NavNet capable de gérer des paquets plus gros que 16 octets de header + 254 octets de données est wrappée dans ce protocole. L'endpoint USB fait 512 octets, et les libs de TI gèrent des paquets jusqu'à 0x5C0 (1472) octets de header + header wrappé + données wrappées - pas loin de MSS/MTU sur les segments réseau habituels.

De mon côté, j'ai fait 1 an de thèse (biblio terminée + position paper en cours d'écriture) et il me reste encore 2 ans.
Perso, j'en bave un peu pour écrire, c'est pas mon truc. J'ai un peu l'impression "d'enculer les mouches" !

Ah, tu as donc commencé la thèse que je me souviens t'avoir lu évoquer par le passé :)
Après l'agreg, c'est encore beaucoup de boulot... mais c'est ton travail principal, contrairement à ce qui se passait pour l'agreg, que je me souvienne.
L'écriture,
sous format académique
(problématique de recherche, diverses contraintes de forme), d'un aussi gros papier qu'une thèse, plus d'autres papiers au long de la thèse, est aussi un gros problème pour moi. Je m'étais rendu compte de ça lors du stage de Magistère M1, avec un rapport beaucoup plus petit qu'une thèse et pour lequel j'ai demandé trop de travail de relecture. Ecrire de la doc technique, oui, je le fais parfois au boulot, mais écrire des papiers académiques, non. C'est pour ça que j'ai bifurqué vers un M2P, alors qu'en M1, je n'étais pas sûr.

Et la petite famille ?
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: TILP: beta-test...

Unread postby Lionel Debroux » 26 Jun 2019, 21:20

J'ai produit une nouvelle version de l'installeur Windows de TILP, https://tiplanet.org/beta/tilp2-setup.exe . Je ne l'ai pas testé sur un vrai Windows.
Les changements sus-mentionnés, et davantage, sont disponibles.
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: TILP: beta-test...

Unread postby Lionel Debroux » 14 Jul 2019, 08:12

I have produced another build, available from https://tiplanet.org/beta/tilp2-setup.exe as usual. The main change from the previous build is the initial support for CBL / CBR / CBR2 / CBL2 / LabPro (/ TI-Presenter, hopefully) probing; also, I have greatly expanded the functionality and scriptability of the test_ticalcs_2 CLI tool, which is helping me a lot making tests, and packaged it in the TILP installer.
Not that in itself, the lab equipment support will be useful to many people, especially in this state, but it would be great if other people could help check that the support for other models has not regressed :)

The implementation of even this reduced support for older lab equipment was much more complex and time-consuming than I originally imagined. The newest of those lab equipments implement the version DBUS command, so it's easy to detect them, but the CBL, CBR and CBR2 don't. For those, and for meaningfully communicating with the CBL2 and LabPro as well anyway, an equivalent of the Send and Get TI-Basic commands is required. On the wire, those use an area of the DBUS protocol which was basically undocumented in the linkguide (which I've read for the first time in years, and I don't maintain), and unimplemented in libticalcs, so I'm not sure it was reverse-engineered before. TIEmu and TilEm's support for communicating with real calculators through cables, thanks to the libti* stack, were invaluable in gathering traces of the emulated calc <-> lab equipment communication :)

The commit adding lab equipment communication and expanding test_ticalcs_2 currently makes the code base grow by over 3K raw lines of code + test scripts (see https://github.com/debrouxl/tilibs/tree ... runk/tests for those) + build definitions. Yet, I only implemented support for the computer faking a TI-68k calculator; depending on the calculator model, the TI-Z80 series probably uses at least two variants of another protocol, as I saw two different formats for floating-point numbers. Also, I only implemented support for exchanging lists, wheras scalar expressions, indexed access in lists and matrices, sometimes strings and even pictures are supported for Get in most or some conditions... and even the list parser is simplistic: no support for spaces around '{', ',' and '}', no support for '.' (effectively restricting lists to integer values).
The fact that there's no portable, thread-safe way to parse strings containing floating-point numbers with a decimal point hard-coded to '.' - that's what the lab equipment sends to TI-68k calculators - is very annoying. At work, for that same purpose, I used a non-portable and probably thread-safe solution based on creating a new instance of the C locale and using strtod_l(), because it's in a code base which only targets Linux... but I can't do that here. The function names are different on Windows, which can be worked around, but then there are all of the other *nix that libti* support...
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Previous

Return to Autres discussions

Who is online

Users browsing this forum: No registered users and 3 guests

-
Search
-
Featured topics
Concours TI-Planet-Casio de rentrée 2019. 3 défis pour plus d'une 15aine de calculatrices graphiques et nombre de goodies sortant de l'ordinaire ! :D
Comparaisons des meilleurs prix pour acheter sa calculatrice !
12
-
Donations / Premium
For more contests, prizes, reviews, helping us pay the server and domains...

Discover the the advantages of a donor account !
JoinRejoignez the donors and/or premium!les donateurs et/ou premium !


Partner and ad
Notre partenaire Jarrety 
-
Stats.
468 utilisateurs:
>451 invités
>11 membres
>6 robots
Record simultané (sur 6 mois):
6892 utilisateurs (le 07/06/2017)
-
Other interesting websites
Texas Instruments Education
Global | France
 (English / Français)
Banque de programmes TI
ticalc.org
 (English)
La communauté TI-82
tout82.free.fr
 (Français)