TILP2 beta-test... - Page 1

J'ai uploadé à http://lpg.ticalc.org/prj_tilp/download/setup.exe une pré-version (pour Windows, évidemment ) de TILP II 1.14, pour beta-test
(pour *nix, essayez http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh en commençant par regarder à l'intérieur)
Même si j'essaie de me donner les moyens de remplir correctement la tâche de (co-)mainteneur (achat d'une 89T, d'une 83+SE et d'un SilverLink), des tests plus larges et plus approfondis que ceux que j'ai effectués sur mes VM Vista x86 et Seven x64 sont absolument nécessaires
En particulier, je vois des soucis de drivers sur Seven x64 (qui se plaint des drivers non signés) mais pas sous Vista x86. Je vois aussi qu'à moins de désactiver totalement l'UAC (c'est maaaaal !), Seven interdit à TILP d'enregistrer tilp.ini => il va falloir améliorer ça (en changeant d'endroit, probablement).

Depuis TILP II 1.13, les nouveautés visibles sont des bugfixes pour TI-68k (en particulier pour PedroM) et des bugfixes plus importants pour TI-Z80 (donnant une bien meilleure interopérabilité avec TI-Connect). Evidemment, TILP continue à supporter de façon transparente les groupes non conformes créés par les versions précédentes. Il me semble également avoir corrigé un problème de build/packaging qui fait que TILP II 1.13 ne marche pas pour nombre d'utilisateurs.

La compilation de cette version de test a été réalisée avec MSVC 2008 et GTK+ 2.12.9 (conformément à un sondage d'il y a un an, dans un autre topic de cette section: le support 9x/ME/NT4 n'est plus garanti).
Il faut donc installer le VC++ 2008 Redistributable Package ( http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf ) si vous ne l'avez pas encore. J'espère pouvoir trouver un MSVC 6 en état de fonctionnement, pour enlever cette dépendance.
Note: GTK+ 2.12.9 est la dernière version dispo à http://gladewin32.sourceforge.net/ - cette version de GTK+ n'est manifestement plus maintenue, ça va poser problème à moyen-long terme...

Avant d'essayer avec grand succès MSVC, j'ai commencé par essayer MinGW+MSYS, que j'avais déjà dû l'installer dans ma VM pour autre chose... vu que cette bouse met trois à cinq secondes par ligne de "configure" (!!) et n'a pas voulu produire de DLL convenables (en revanche, aucun problème pour la production de pages et de pages de messages d'erreur...), j'ai abandonné

Une petite limitation dans cette version de test: elle ne s'exprime pas en français.


Merci d'avance

Lionel Debroux (./1) :
Avant d'essayer avec grand succès MSVC, j'ai commencé par essayer MinGW+MSYS, que j'avais déjà dû l'installer dans ma VM pour autre chose... vu que cette bouse met trois à cinq secondes par ligne de "configure" (!!) et n'a pas voulu produire de DLL convenables (en revanche, aucun problème pour la production de pages et de pages de messages d'erreur...), j'ai abandonné

Si tu montrais tes messages d'erreur, quelqu'un pourrait peut-être t'aider.

Sinon, il y a aussi la cross-compilation (cross-MinGW). Ça devrait fonctionner a priori. (Je ne sais plus quand j'ai testé la dernière fois, c'était probablement avant le schisme du projet, mais ça marchait très bien.)

pour ce que ça m'a servi, cross mingw était plus efficace que msys.

c'était pour générer cegcc, donc c'était pas du trivial.

Ah, les Canadian Crosses, toujours fun.

clair ^^

j'ai appris a mes dépends au passage qu'il fallait une version linux du compilateur que tu veux compiler pour windows, parce que c'est tout de même linux qui compile les libs de la cible, même si plus tard t'utiliseras windows

ça m'a bloqué un moment ça

Avec TIGCC, je n'ai pas ce problème parce que je peux compiler tigcc.a à part. (Mais en pratique, je le compile avec TIGCC/*nix évidemment, et je pense que tôt ou tard je vais modifier mes scripts pour compiler tigcc.a pendant la compilation de TIGCC, du moins celle de TIGCC/*nix, celle de TIGCC/W32 étant de toute façon un processus manuel assez lourd.)

Ne t'inquiète pas, je comptais essayer la cross-compilation (et InnoSetup sous Wine) avant de poster les messages d'erreur (s'ils se produisaient également en cross-compilation, bien sûr)
Vérifier que les programmes se compilent bien avec un MSVC récent était de toute façon utile.

J'ai fait une pré-release pour beta-test (et non pas une release, je veux dire), parce que seulement deux minutes de tests sous Seven me montrent qu'il y a des problèmes. Problèmes qui existaient déjà dans TILP II 1.13 (et libs correspondantes), et qui existent par conséquent dans la branche dérivée n'apportant aucun changement significatif (surtout pas pour Windows).
Appeler "release" des builds issus de l'état actuel (d'un côté comme de l'autre) ne serait pas sérieux.


(off-topic, merci d'avance Kevin de ne pas dériver)

celle de TIGCC/W32 étant de toute façon un processus manuel assez lourd

Dans GCC4TI, nous avons ajouté le support de la cross-compilation (et dans une moindre mesure la gestion des erreurs) aux scripts de build. Ca facilite grandement la tâche.

Lionel Debroux (./7) :
Vérifier que les programmes se compilent bien avec un MSVC récent était de toute façon utile.

Pas vraiment, le support Visual C++ ne sert à rien et devrait être supprimé (c'est déjà fait côté CalcForge).

Problèmes qui existaient déjà dans TILP II 1.13 (et libs correspondantes).

=> pas une régression => pas un blocker

Comme annoncé depuis longtemps, je ferai une release dès que j'aurai fini les renommages, rien que pour les renommages, même s'il n'y a aucun autre changement (mais de toute façon il y a déjà des corrections de bogues et je vois mal pourquoi je ferais attendre tous mes utilisateurs existants pour ces correctifs seulement parce qu'il reste des problèmes sous 7 qui ont toujours été là).

Et puis, j'attends tes correctifs pour 7. Mais ce n'est pas ça qui bloquera mes releases.

Pas vraiment, le support Visual C++ ne sert à rien et devrait être supprimé (c'est déjà fait côté CalcForge).

C'est un avis, ton avis, et rien de plus. Cette position est loin d'être universellement partagée. Tu le sais, même si tu t'en fous.

je ferai une release dès que j'aurai fini les renommages, rien que pour les renommages, même s'il n'y a aucun autre changement

Bah, libre à toi de commettre la faute que nous avons évité de commettre dans GCC4TI
Nous ne sommes pas stupides, les utilisateurs n'auraient eu aucun intérêt à utiliser la nouvelle branche si sa première release n'avait rien apporté par rapport à l'autre.

mais de toute façon il y a déjà des corrections de bogues

Tu ne peux pas utiliser ça dans ta PR: dans upstream aussi, il y a des bugfixes, puisque la plupart des bugfixes visibles de l'utilisateur viennent d'upstream

=> pas une régression => pas un blocker

J'aime beaucoup cette façon de classifier un problème important d'utilisabilité décrit dans ./1
Libre à toi de présenter comme une release, un build fait à la va-vite d'un logiciel qui n'apporte rien par rapport à upstream (tu l'écris toi-même en ./7 !) et dont tu connais au moins un problème significatif... comme tu nous l'as déjà écrit, tu fais ce que tu veux parce que tu es le mainteneur.

Lionel Debroux (./9) :
Tu ne peux pas utiliser ça dans ta PR: dans upstream aussi, il y a des bugfixes, puisque la plupart des bugfixes visibles de l'utilisateur viennent d'upstream

Pourtant tu utilises sans arrêt mes bugfixes de TIGCC dans ta PR pour GCC4TI.

J'aime beaucoup cette façon de classifier un problème important d'utilisabilité décrit dans ./1

Lequel?
Pilotes non signés? Problème connu, insoluble pour nous, il faut contourner le mécanisme de signature du côté utilisateur ou utiliser une version 32 bits de l'OS.
Problèmes liés à l'UAC? Certainement pas des blockers, étant donné que ça se désactive en 1 minute.

Pourtant tu utilises sans arrêt mes bugfixes de TIGCC dans ta PR pour GCC4TI.

Manifestement, ça ne t'a pas effleuré que je parlais des bugfixes dans libti*/tilp depuis que tu as forké ?
Du côté de TIGCC, des bugfixes depuis que nous avons forké, c'est vachement simple, il n'y en a pas (difficile de considérer deux ou trois corrections de typos comme bugfixes)... donc on ne craint pas de les utiliser dans notre PR
En revanche, on peut parfaitement utiliser le fait que même des bugs des outils corrigés dans GCC4TI, reportés sur #tigcc, ne sont toujours pas corrigés, des mois après.
Bref, tu postes donc une nouvelle fois des conneries off-topic.

Problèmes liés à l'UAC? Certainement pas des blockers, étant donné que ça se désactive en 1 minute.

Désactiver l'UAC est la solution évidente pour se laver les mains et reporter le problème sur les utilisateurs. On peut aussi essayer de s'adapter aux changements et faciliter la vie des utilisateurs, c'est à mon avis une meilleure solution.


Si on vise l'inefficacité, l'obsolescence et l'insatisfaction, il faut bien s'en donner les moyens et les excuses

Je ne dis pas que ce n'est pas à corriger, je dis que ce n'est pas un blocker pour la release.

je pensais que vous deviez pas dériver...

Bonjour,

J'ai installé TILPII 1.14 sur le mini HP de ma copine.
Il s'agit d'un Windows Seven "Starter" (la version minimaliste de seven : on ne peut même pas modifier le fond d'écran ! ça pousse au piratage... enfin bon passons)

J'ai installé GTK+ et VC2008 avec tes liens.
Je n'ai pas désactivé l'UAC donc j'ai droit au message d'erreur pour le Tilp.ini comme prévu.
Mis à part ça, tout semble fonctionner correctement mais je n'ai malheureusement pas testé de transfert.

Evidemment ce test est un peu limité mais au moins c'est un rapport de succés concernant l'install de tilp II 1.14.



Beau travail et bon courage.

Thibault
(tilp.png)

(tilp0.png)

Merci du feedback