TI-Nspire Dev Day - Page 3

Trouver qqn qui a 7 doit pas être un problème (je l'ai aussi d'ailleurs), surtout qu'il s'installe même sur des machines pas toutes récentes, par contre la calculette c'est un autre souci

J'ai un ordinateur sous Seven home premium 64 bits et une CAS...
Mais vraiiment pas envie de la foutre en l'air hein

Contra, personne3000 : Sam101 et Lionel Debroux se sont déjà proposés avec les mêmes configs, donc sauf si vous y teniez vraiment, ça me suffit, merci

Pour les curieux le trunk SVN d'Ndless est désormais accessible publiquement :

https://www.unsads.com/scm/svn/nsptools/Ndless/trunk/, guest/guest (le certificat peut être accepté)

(merci squalyl !)

( de rien )

le certificat est validé par une carte à puce

En tout cas, vous voyez bien ce qui se passe quand on dépend de composants propriétaires qu'on ne contrôle pas, vous êtes totalement à la merci de TI, à chaque mise à jour de Computer Link, ça va casser à nouveau.

Kevin, c'est pas toi qui nous as stressé la tête avec ton release often release early?

tu fais de la provoc, je le sais, mais bon j'ai l'impression qu'elle te retombe dessus à chaque fois.

Je ne fais pas de la provoc, je me plains de la décision d'avoir utilisé un composant propriétaire au lieu d'un composant libre parfaitement fonctionnel (bon OK, il manque 3 ou 4 fonctions, mais c'est facile de les rajouter en vue de tout ce qui est déjà là, le fait que le composant soit libre permet justement de rajouter facilement ce qui manque).

t'es quand même incroyable. Au lieu d'être content d'avoir le truc avec ses sources, tu te plains que sapu saypalibre.

tu ne connais rien aux nspire, tu n'en n'as même pas une, tu n'as pas participé à une seule ligne de code du projet, et tu te permets de juger.

Vas y, produis, code, émets de la connaissance, participe, le svn est accessible, tu peux envoyer des patchs, code les fonctions manquantes, teste le code avec la version libre, fais un essai d'installation réussi, envoie un patch, ensuite on en reparle.

j'ai l'impression que tu brasses beaucoup d'air pour rien. ou alors tu provoques, je confirme.

Kevin n'a pas de Nspire, il passe beaucoup de son temps à faire des activités de basse importance pratique et/ou contre-productives (et se plaint qu'il n'a pas de temps...), et rares sont ceux qui veulent encore l'aider (ça aussi, il s'en plaint, alors qu'il en est responsable...): Ndless, et d'une façon générale la communauté, ne peut pas compter sur lui.

Je propose qu'on arrête là le off-topic: on sait tous, depuis le temps, qu'on ne gagne pas au jeu de "qui se comporte de la façon la plus stupide" si Kevin est de la partie

Si vous ne voyez pas l'importance stratégique d'avoir nos propres outils de liaison plutôt que ceux de TI, surtout pour un outil comme Ndless, ni l'utilité pratique de la portabilité, je ne peux rien pour vous.

Et au fait, es-tu en mesure de réassembler ("recompiler") les outils de ROM dump pour les Z80 que tu livres avec la libticalcs2? Où sont les mystérieux outils check85 et unsquish83 référencés dans le Makefile? J'ai passé la moitié de ma journée d'hier à rendre ces ROM dumpers réassemblables avec spasm et wabbitsign (check85 n'est visiblement pas nécessaire avec wabbitsign, et j'ai remplacé unsquish83 par un script bash utilisant hexdump pour avoir une solution rapidement). Tu n'as pas l'air de comprendre que la maintenabilité (ce qui implique aussi de pouvoir regénérer les binaires qu'on livre) est essentielle.

Kevin > et toi tu n'as pas l'air de comprendre que tu es hors sujet.

Dernier avertissement.

Kevin Kofler (./19) :
En revanche, il faudra rajouter ça aux libs CalcForge pour faire marcher Injector:

Implémenté:
conApi.mkDir (API calcprotocols_calc_new_fld déjà présente, implémentée pour la Nspire / Nspire CAS)
conApi.delete (API calcprotocols_calc_del_var déjà présente, implémentée pour la Nspire / Nspire CAS)
http://svn.calcforge.org/viewvc/calcforgelp?view=revision&revision=4567

Corrigé: on peut maintenant envoyer des fichiers sans l'extension .tns (type NSP_OTHER). Ces fichiers peuvent être sans extension, ou alors on peut mettre une extension directement dans le nom du fichier.
http://svn.calcforge.org/viewvc/calcforgelp?view=revision&revision=4568
http://svn.calcforge.org/viewvc/calcforgelp?view=revision&revision=4569
(Ça devrait être utile pour les fichiers copysamples et initialized.)

Toujours manquants:

conApi.getFileAttributes (fonction bas niveau présente: cmd_r_dir_attributes) (On pourrait éventuellement s'en passer et utiliser un receive à la place.)conApi.copyFile (vraie copie locale, indispensable, une copie à travers le PC ne marchera pas, ExtendeD sait sans doute pourquoi)

Réimplémentation indépendante, plus d'une semaine plus tard, de boulot que j'ai déjà fait et rendu public. Bien joué, Kevin

J'avais fourni ce patch publiquement (mélangé avec un patch encore plus important, pour faciliter la vie des éventuels testeurs), mais je ne l'avais pas committé, parce que je savais que je l'avais insuffisamment testé.
J'ai fait davantage de tests hier soir... tests qui ont vite révélé que mon implémentation était fausse. Je n'ai pas encore fini de re-tester mes modifs ET tester (et éventuellement corriger) d'autres chemins de code potentiellement affectés du même problème.

Ce matin, que vois-je ? Kevin a fait et committé une réimplémentation indépendante du boulot que j'ai fait, tout aussi fausse que mon implémentation l'était.
Dans r4567:
* Kevin a committé du code non testé qui ne fonctionne pas (et qui comprend une erreur de compilation);
* il a committé (et non pas juste fourni un patch mélangé) deux changements dans le même patch, ce qu'il me reproche souvent de faire.


r4568 et r4569 sont manifestement des modifs intéressantes. Nous les scruterons comme nous scrutons ses patches depuis qu'il a suggéré, à propos d'éventuels forks de TIGCC (qui n'existaient pas encore à l'époque), qu'il pourrait commiter des choses fausses et corriger plus tard


Pour l'ajout de:
* suppression de répertoire;
* renommage d'un fichier;
* déclenchement côté ordinateur de la copie d'un fichier vers un autre ("copie locale");

il faut, puisque ces opérations ne sont pas supportées par les autres modèles (cette liste peut ne pas être exhaustive):
* ajouter les flags correspondants dans l'enum CalcFeatures (sachant qu'il y a moins pas assez de valeurs OP_* inférieures aux valeurs FTS_*);
* ajouter les fonctions de bas niveau dans nsp_cmd.c;
* ajouter les pointeurs de fonction dans la struct CalcFncts;
* stubber les fonctions dans tous les autres fichiers qui contrôlent les machines qui ne supportent pas ces opérations;
* ajouter des entrées dans le GUI, pas très difficile.

Pour l'obtention des attributs dans le GUI (ça aussi est une opération que les autres modèles ne supportent pas), il faudra créer par exemple un dialog.


Deux choses qui sont publiques (enfin, c'est _sûr_ pour la première), mais que je vais re-poster ici, puisque Kevin n'est manifestement pas au courant (et qu'il ne peut pas s'en rendre compte par lui-même puisqu'il n'a encore et toujours pas de Nspire):
* TILP fonctionnait extrêmement mal avec les Nspire, c'est maintenant contourné par r4292 dans upstream (c'est ça, le patch "encore plus important" mélangé avec l'autre que je mentionnais au début de ce post, public depuis une dizaine de jours), en attente d'une meilleure solution à moyen et long terme, qui viendra probablement de la correction du fait que:
* TILP ne fonctionne pas du tout avec ma Nspire si elle tourne l'OS 2.0. J'ai retransféré des OS 1.x pour vérifier, puis de nouveau l'OS 2.0: les mêmes binaires fonctionnent avec les OS 1.x, mais sont totalement incapables de communiquer avec l'OS 2.0.


Je pense que vous aurez tous bien compris à quel point il était plus facile pour ExtendeD et geogeo d'utiliser, comme solution temporaire (même si tout le monde savait que ça n'était pas optimal à moyen et long terme), les composants de TI
Cela a clairement permis une release de Ndless au plus tôt, comme Kevin la réclamait à cor et à cris.

En tout cas soyons honnêtes, je remercie Kevin pour être passé à l'action. Que ce soit correct ou non, il y a une réalisation. merci.

Je suis d'accord, mais il ne fait que faire, enfin, "put his time where his mouth is". C'est ce que tu lui as demandé hier en ./70, et tu n'es pas le premier

Je viens d'implémenter la copie de fichiers:
http://svn.calcforge.org/viewvc/calcforgelp?view=revision&revision=4576
http://svn.calcforge.org/viewvc/calcforgelp?view=revision&revision=4579

(Et je signale que la révision 4577 est une optimisation, la révision 4578 une correction de bogue, elles devraient être intéressantes aussi pour Lionel.)

Il ne manque plus que le test d'existance d'un répertoire.

Je signale au passage que ça ne m'a pris que quelques minutes d'implémenter ces fonctions, alors que ça fait 2 mois qu'on attend Ndless…

la révision 4578 une correction de bogue

: l'intersection de ce que j'ai commencé à bugfixer hier soir et de ton commit n'est pas vide

Je signale au passage que ça ne m'a pris que quelques minutes d'implémenter ces fonctions, alors que ça fait 2 mois qu'on attend Ndless…

Hier, sur #inspired, quelqu'un t'a écrit une ligne très bien à propos du fait qu'à toi, ça ne prend pas beaucoup de temps d'implémenter ces fonctions (qui ne sont qu'une petite partie du boulot, voir ce que j'ai écrit en ./75 - et la partie la plus importante du boulot, le test, tu ne peux pas la faire), mais que ça prend plus de temps à presque tous les autres

Nous sommes heureux qu'une fois de temps en temps, tu bouges tes fesses (même si tu aurais pu t'éviter une partie de ce boulot en étant un peu plus au courant de ce qui se passe dans la communauté...), mais ça ne te donne pas le droit d'en rajouter

Lionel Debroux (./79) :
Hier, sur #inspired, quelqu'un t'a écrit une ligne très bien à propos du fait qu'à toi, ça ne prend pas beaucoup de temps d'implémenter ces fonctions (qui ne sont qu'une petite partie du boulot, voir ce que j'ai écrit en ./75 - et la partie la plus importante du boulot, le test, tu ne peux pas la faire), mais que ça prend plus de temps à presque tous les autres

Il aurait suffi de me demander d'implémenter ces fonctions et je l'aurais fait (comme je le fais maintenant).

Lionel Debroux (./75) :
* TILP fonctionnait extrêmement mal avec les Nspire, c'est maintenant contourné par r4292 dans upstream (c'est ça, le patch "encore plus important" mélangé avec l'autre que je mentionnais au début de ce post, public depuis une dizaine de jours), en attente d'une meilleure solution à moyen et long terme

En attendant, j'ai mergé ton workaround: http://svn.calcforge.org/viewvc/calcforgelp?view=revision&revision=4580

Quant à l'OS 2.0, le protocole pourrait avoir changé pas mal, sinon comment s'expliquer la réécriture de pas mal de code dans le logiciel Computer Link de TI?

Il aurait suffi de me demander d'implémenter ces fonctions et je l'aurais fait (comme je le fais maintenant).

A ce moment-là, tu t'es mis tout seul sur la touche, en ne faisant que critiquer
Regarde: à cause de celà, il t'a fallu plus de deux mois, et bientôt deux semaines après la release de Ndless, pour (re...)faire quelque chose de productif (hier et aujourd'hui). Moi, j'ai beta-testé Nspire8x, Ndless et, sans me cacher, commencé à implémenter ce qu'il manquait (que tu as détaillé fin février en ./18).

Même si l'un au moins de nous deux avait implémenté ces fonctions plus tôt, ça n'aurait pas résolu le problème que la première release publique de Ndless (à moins de souffrir d'un délai - mais ça, ça aurait été contradictoire avec ton desiderata lourdement rappelé de voir une release au plus tôt, avant même que cela soit sage de le faire) ne pouvait pas dépendre de TILP SVN, et encore moins de CalcForgeLP SVN (même si tu backportes tout ce qu'on fait, ton fork est plus loin d'un état releasable qu'upstream). [EDIT pour clarifier: parce que c'est mal d'embarquer des copies locales des DLL, surtout sous Windows - sur lequel il y avait de toute façon le soft de TI, dont l'utilisation était obligatoire en pratique puisque TILP ne fonctionnait pas bien avec les Nspire.]

Quant à l'OS 2.0, le protocole pourrait avoir changé pas mal

Pas tant que ça, vu que Nspire8x est (au moins, je n'ai pas tout testé) capable d'obtenir des infos de la Nspire connectée et de lister les répertoires sous la racine, j'ai testé.
Les deux erreurs dans le terminal sont à un niveau plus bas que libti*: libusb.

[EDIT le soir pour parler de Nspire8x.]

allez allez maintenant c'est implémenté, passons à la fonction suivante au lieu de regretter le passé. Soyons contents du futur. (désolé de devoir dire ça)

Dépendre des libs CalcForge SVN est tout à fait faisable, elles ne sont pas en conflit avec les libs LPG (tous les noms de fichier ont changé) et j'essaie de garder la compatibilité binaire (et si je ne peux pas la garder, je bumpe le soname comme il faut). De plus, je peux faire une release libs-only à tout moment, les libs sont prêtes à être releasées et il y a déjà eu une release en Novembre (le Developer Preview).

Chapeau à ExtendeD et geogeo
(Pourvu que cette nSpire ne soit pas la PSP de TI aka une faille == un fix...)

Quelle compétitivité dans ce secteur de l’informatique

Kevin: r4575 est faux. ""Mon"" code (copier-coller-adapter depuis d'autres fichiers) de ROM dumping fonctionne, le tien pas du tout
En effet: je mets ton code, ça merde (plusieurs essais ratés). Je remets l'ancien code, ça fonctionne de nouveau du premier coup. Je remets ton code, ça merde de nouveau (plusieurs essais ratés).
J'ai essayé plusieurs variantes de ton code: mettre des attentes plus ou moins longues avant et après l'ACK (dont l'utilisation de cmd_r_delay_ack au lieu de cmd_r_data_ack), ne pas mettre d'ACK du tout, mettre un code 0x05 au lieu de 0x00 à l'appel à cmd_s_execute. Rien n'y fait, ça ne fonctionne pas mieux que l'original. Et à chaque fois, remettre l'ancien code restaure la capacité de faire le ROM dump.
=> l'utilisation de la commande cmd_s_execute pour faire autre chose que des envois de touche est une idée potentiellement intéressante, mais la copie est totalement à revoir

Précision: j'ai copié-collé tes changements de r4575 dans libticalcs, donc le problème ne vient pas du fait que je ne saurais pas compiler tes forks


EDIT: et j'ai édité ./83 pour mentionner Nspire8x: le protocole ne peut pas avoir changé tant que ça.

Si ce code ne fonctionne pas du tout, est-ce que ticalcs_calc_execute/calcprotocols_calc_execute fonctionne sur la TI-84+? Parce que le code est exactement le même que là et je m'attendais à ce que le code qui est déjà là fonctionne.

Je vais inverser la révision 4575 en tout cas.

Kevin Kofler (./78) :
Je signale au passage que ça ne m'a pris que quelques minutes d'implémenter ces fonctions, alors que ça fait 2 mois qu'on attend Ndless…

Tu ne compares pas ce qui est comparable, et tu n'as pas la moindre idée de ce qui s'est passé durant ces 2 mois. Pourquoi se vanter ainsi ?