Forum TI-Planet.org

parisse a écrit:C'est quand meme assez different entre tiplanet et Numworks, n'importe qui peut archiver des programmes d'autres calculatrices ailleurs que chez tiplanet (sur son propre PC par exemple mais sur un autre serveur web).
C'est tres bien de pouvoir echanger des programmes de sa calculatrice vers un serveur de Numworks et qu'on puisse les partager, ce qui me gene c'est qu'on ne puisse apparamment le faire *que* vers la (je ne comprends pas ce qui peut empecher de sauvegarder *aussi* en local).
D'ailleurs si tous les constructeurs faisaient de meme, tiplanet risquerait de disparaitre, l'echange d'information suivant les donnees sur des serveurs des constructeurs.
Pour le moment Numworks est un outsider dans le monde des calculatrices, mais imaginez qu'il remplace un jour le duopole Casio-Texas, serait-il souhaitable de laisser une seule societe controler le contenu des calculatrices dans une situation de monopole?

On parle quand même de scripts Python, qui contrairement aux langages TI/Casio n'utilisent pas de caractères bien exotiques.

Donc il est toujours possible de copier/coller le code du script, pour sauvegarder ou restaurer à partir d'un fichier local à l'ordinateur.
C'est juste une étape supplémentaire avant ou après le transfert.

critor a écrit:

parisse a écrit:Je ne suis pas sur d'avoir bien compris : les scripts Python sont stockes ou? Sur le PC, sur le site de numworks, sur les 2?

Les scripts échangés avec la calculatrice sont stockés chez NumWorks.

Pour le reste, je regarde dès que possible.

De ce que j'ai compris, NumWorks a décidé d'utiliser le protocole DFU. Il y a un mini-stub DFU qui est activé quand la calculette est en mode transmission et le nouveau buffer de stockage est mis à jour en RAM, puis le stub rend la main au firmware principal quand le câble est déconnecté ou la touche Back appuyé.

C'est... original. Et complètement inattendu. Les trois gros avantages que je vois sont que le firmware principal n'a pas à se soucier de l'USB, le stub peut à la fois servir pour la transmission de données et pour flasher un firmware avec la possibilité d'avoir une barre de progression (contrairement à l'écran noir du DFU intégré aux STM32F4) et que c'est pratiquement gratuit en terme de Flash et relativement facile à développer, l'intelligence n'étant pas du côté de la calculette.

Par contre, les inconvénients sont assez sévères. Le stockage est uniquement en RAM et de plus limité actuellement à seulement 4 KiB. Même si la méthode de transmission est techniquement indépendante du site de NumWorks et qu'on pourrait réaliser une implémentation tierce standalone, ça reste du protocole non-standard (je dirais même un abus caractérisé...). Le logiciel de transfert doit avoir une parfaite connaissance de la position, taille et layout du buffer en RAM.

Bref, une solution technique aussi astucieuse que limitée. Suffisante pour transférer quelques petits scripts Python dans un environnement scolaire ou pour faire sa propre boîte à outils avec comme "logiciel" un simple site web. Mais je vois mal NumWorks garder cette méthode à long (ou même moyen) terme, cela reste un détournement caractérisé de DFU qui n'est vraiment pas prévu ou pensé pour ce cas d'utilisation.

NumWorks utilisant un protocole standard (de manière certes détournée, comme l'indique Jean-Baptiste), il serait plus facile d'en refaire une implémentation tierce et de faire un gestionnaire tiers de scripts.
Le Project Builder de TI-Planet, qui est presque intégralement ouvert maintenant, fournit plusieurs briques de base pour la création d'un gestionnaire tiers de scripts pour machines NumWorks, si ça s'avérait nécessaire. Dans la phase de design, j'avais cassé les pieds à Adriweb pour qu'il aille plus loin dans la flexibilité des types de projets et de toolchains, même si ça compliquait un peu le code.

parisse a écrit:C'est quand meme assez different entre tiplanet et Numworks, n'importe qui peut archiver des programmes d'autres calculatrices ailleurs que chez tiplanet (sur son propre PC par exemple mais sur un autre serveur web).
C'est tres bien de pouvoir echanger des programmes de sa calculatrice vers un serveur de Numworks et qu'on puisse les partager, ce qui me gene c'est qu'on ne puisse apparamment le faire *que* vers la (je ne comprends pas ce qui peut empecher de sauvegarder *aussi* en local).
D'ailleurs si tous les constructeurs faisaient de meme, tiplanet risquerait de disparaitre, l'echange d'information suivant les donnees sur des serveurs des constructeurs.
Pour le moment Numworks est un outsider dans le monde des calculatrices, mais imaginez qu'il remplace un jour le duopole Casio-Texas, serait-il souhaitable de laisser une seule societe controler le contenu des calculatrices dans une situation de monopole?

Il n'y a pas de monopole sur les transferts de la part de NumWorks. Rien n'empêche quelqu'un de faire une implémentation en local du logiciel de transfert qui soit indépendant du site de NumWorks, ou TI-Planet de proposer le même service.

C'est même plus ouvert que la HP Prime. On a le code de l'implémentation de référence côté calculette avec assez de doc dans les commentaires pour s'en sortir très facilement. Je rappelle que j'ai abandonné mes efforts de dev third-party sur la HP Prime parce que le protocole d'upgrade du recovery est propriétaire, non documenté et qu'il est impossible de flasher sa HP Prime depuis Linux faute de support constructeur (et non, j'ai autre chose à faire que faire du reverse-engineering sur un protocole USB vraiment pas trivial). L'approche de NumWorks, même si limitée d'un point de vue technique, reste bien plus ouverte que n'importe quel autre constructeur sur le marché.

C'est vrai que c'est pas trop pratique d'avoir tout directement chez Numworks, même si je comprends les avantages que cela peut avoir.

critor a écrit:Donc il est toujours possible de copier/coller le code du script, pour sauvegarder ou restaurer à partir d'un fichier local à l'ordinateur.
C'est juste une étape supplémentaire avant ou après le transfert.

En lisant le fil de la discussion c'est aussi ce que me je me disais...
Mais : pour pouvoir éditer un script python, faut donc une connexion internet... Même si on est assez connecté (en tout cas pour moi ),faut pas être en manque d'internet le jour où on a besoin du python sur la calto Numworks...

EDIT :

jean-baptiste boric a écrit:Il n'y a pas de monopole sur les transferts de la part de NumWorks. Rien n'empêche quelqu'un de faire une implémentation en local du logiciel de transfert qui soit indépendant du site de NumWorks, ou TI-Planet de proposer le même service.

Très bonne idée !
Qui peut faire ça ?

Copier/coller un script reste quand meme assez artisanal comme methode de sauvegarde en particulier si on a un script un peu long, avec un risque non negligeable de fausse manipulation.
Evidemment, rien n'interdit de faire un autre systeme de sauvegarde, mais comme personne ne l'a fait jusqu'a maintenant (alors qu'il n'y avait pas de systeme), on ne voit pas trop pourquoi quelqu'un le ferait maintenant.
Enfin, meme si les autres constructeurs utilisent des protocoles fermes, ils permettent de sauvegarder les donnees chez soi, chacun disposant ensuite comme il l'entend de ses donnees, qui lui appartiennent. Qu'en est-il d'ailleurs des donnees stockees chez Numworks?

parisse a écrit:Evidemment, rien n'interdit de faire un autre systeme de sauvegarde, mais comme personne ne l'a fait jusqu'a maintenant (alors qu'il n'y avait pas de systeme), on ne voit pas trop pourquoi quelqu'un le ferait maintenant.

Parce qu'il était annoncé depuis un certain temps que NumWorks travaillait dessus. C'est bête, mais je ne vois pas pourquoi je m'embêterais à coder une stack USB OTG plus les surcouches logicielles pour faire du transfert de données alors que NumWorks travaillait dessus. Aussi, le fait que les sources du firmware soient sur GitHub ne veut pas dire qu'on fera tout le travail à leur place. Nous sommes contributeurs bénévoles à notre bon vouloir, pas corvéables à merci.

parisse a écrit:Enfin, meme si les autres constructeurs utilisent des protocoles fermes, ils permettent de sauvegarder les donnees chez soi, chacun disposant ensuite comme il l'entend de ses donnees, qui lui appartiennent. Qu'en est-il d'ailleurs des donnees stockees chez Numworks?

Et dire que je voulais passer un week-end à bronzer au soleil et siroter du jus de pomme... Dois-je vraiment en sacrifier une partie juste pour implémenter un PoC et prouver qu'on peut transférer des données en local sans avoir à passer par le Workshop de NumWorks?

??
Je n'ai jamais demande a quelqu'un de faire le travail a la place de Numworks, au contraire je dis que je vois encore moins quelqu'un faire le travail aujourd'hui qu'hier. Surtout avec la licence de Numworks qui n'a toujours pas evolue et leur permet de s'approprier le travail d'autrui sans contrepartie, c'est a mon avis une erreur de contribuer benevolement aujourd'hui (heureusement de mon point de vue, il y a tres peu de contributions benevoles dans ces conditions).
Je pointe juste les inconvenients du firmware 1.4 ou les sauvegardes ne peuvent pas etre faites en local et l'absence semble-t-il de document definissant le statut des donnees hebergees par Numworks.

jean-baptiste boric a écrit:Dois-je vraiment en sacrifier une partie juste pour implémenter un PoC et prouver qu'on peut transférer des données en local sans avoir à passer par le Workshop de NumWorks?

On sait (surement) que c'est possible, mais si tu pouvais quand même le faire ... ca serait cool ?

ok je sors ...

Vu que c'est du javascript uniquement (DFU via WebUSB), tout tourne en fait déjà en local sur l'ordi, c'est juste que les ressources diverses et variées sont chargées depuis le site de numworks.
Il ne serait probablement pas très compliqué de réunir tout ça dans un dossier local chez soi (je me demande même si une sauvegarde complète d'une page de transfert pourrait fonctionner...)

Je suis relativement d'accord sur le fait que ça serait pas mal qu'ils précisent leur politique de confidentialité, licence, et utilisation des données (même si à titre personnel ça m'importe peu, ce qu'ils feraient de scripts que j'uploaderais ).