oxman Le 29/07/2001 à 16:50 bon je viens polluer ici
pck yAro ma injustement banni mon pseudo avec mes fleches
roms Le 29/07/2001 à 16:50 Kevin: je t'ai rajouté ton option. Dorénavant, tu pourra faire './configure --enable-exit-homedir' et c tout bon.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
roms Le 29/07/2001 à 16:50 FlashZ: le pb des accents & console DOS est réglé.
FlashZ: la ligne de cmd ne marche pas effectivement.
OxMan: les pollueurs, dehors !
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
Tu as corrige le bug des group files ??
jibax Le 29/07/2001 à 16:50 ouais moi aussi j'ai ce bug: quand j'envois un group file il m'efface parfois toute la mem (meme archive) cependant il ne fait pas de reset .Mais peut etre que ce bug a ete resolu cardepuis que j'ai eu 2-3 fois ce bugue j'utilise wintransx.
Sinon je n'arrive pas a avoir le programme en francais car quand je selectionne le francais ca fait rien (version .24)
roms Le 29/07/2001 à 16:50 FlashZ:
- j'ai corrigé la ligne de commande. Ca marche maintenant.
- pour les group files, j'arrive pas à reproduire ce bug donc je ne l'ai pas encore corrigé.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
Le bug est ultra simple a reproduire :
Tu selectionne un group file que tu envoies a ta 89, maintenant que tu en as une, et tu verras bien !
C'est exactement ce que dit jibax.
roms Le 29/07/2001 à 16:50 Question: le group file, est-ce qu'il a aucune, une ou plusierus variables archivées ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
Un group file ne concerve jamais les attributs Archive a ma connaissance... il peut y avoir des fichiers lockes dedans c tout.
Et pis moa ca me fait ca avec TOUS les group files.
>roms:
>>Kevin: je t'ai rajouté ton option. Dorénavant, tu pourra faire './configure --enable-exit-homedir' et c tout bon.
Merci.
>roms:
>concernant GTK+, les développeurs GTK ont finalement décidé d'interdire aux apps GTK de tourner en setuid root à partir de gtk >= 1.2.9.
>Ils conseillent la mise en place d'un wrapper pour les applis qui ne peuvent pas faire autrement.
>Pour ma part, je trouve ca débile étant donné que sur une machine sécurisée, on déconseille déjà d'installer X.
>De plus, cela oblige les utilisateurs Linux de TiLP/GtkTiEMu ayant un BlackLink ou un cable 'maison' à installer un 'kernel module', chose pas tjs aisée pour certains meme si l'installation est maintenant grandement automatisée.
Ou à toujours tourner en root, ou à utiliser su. (Le check ne vérifie que suid, il n'empêche pas de tourner en root, je viens de vérifier cela dans les sources.)
On peut toujours distribuer un patch pour GTK+ (ça ne prend même pas 5 minutes d'enlever cette protection), mais ce n'est pas très propre comme méthode et ça oblige quand-même à recompiler GTK+.
>roms: Question: le group file, est-ce qu'il a aucune, une ou plusierus variables archivées ?
Un group file peut maintenir l'attribut archive si fait avec Get Backup.... Le logiciel TI-GraphLink ne le respecte que si on fait Send Backup..., pas si on fait Send....
Il me semble donc que TiLP pourrait très bien utiliser cet attribut dans tous les cas.
roms Le 29/07/2001 à 16:50 Ca fait longtemps que je laisse la possibilité (option active par défaut) de conserver ou non l'attribut archive lors de l'émission/réception d'un backup.
De toute façon, je vais creuser et valider çà ce WE.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
>FlashZ:
>Un GROUP FILE (.xxg) et un BACKUP (.xxb) sont deux choses differentes Kevin !
Pas sur les TI-89/92+! Le logiciel TI-GraphLink utilise des .89g ou .9xg pour les 2, et on peut utiliser Send pour envoyer des backups (mais l'attribut archive n'est pas maintenu), ou Send Backup... pour envoyer des groupes (mais ça écrase tous les autres fichiers déjà présents sur la calculatrice).
Dans le cas où tu aies un doute, essaye de: installer un TSR (un des miens, ou alors un kernel), recevoir un backup, réinitialiser la calculatrice et renvoyer le backup. Le TSR sera effacé. Pourquoi? Tout simplement parce que la TI-89/92+ n'utilise pas de vrais memory backups, mais de simples fichiers groupes pour les backups (probablement pour supporter correctement l'archive).
Pour d'autres modèles, comme par exemple les TI-85, effectivement, c'est différent: il y a des memory backups qui ne sont pas des fichiers groupes. Mais je vois mal pourquoi on parlerait d'attribut archive sur une TI-85, ou même une TI-92, donc j'ai donné des informations spécifiques TI-89/92+.
>A l'evidence, tu l'envoie comme tu envoies un BACKUP, or un backup efface ou ecrase tous les fichiers !
>Voila, je suis sur a 99% que c'est ca...
Oui, c'est tout à fait possible (et même probable) qu'il y ait des protocoles de transmission différents.
[edit]Edité par Kevin Kofler le 29-06-2001 à 17:47:47[/edit]
roms Le 29/07/2001 à 16:50 gandalf: j'ai rajouté le message pour prévenir.
TiLP conserve l'attribut (locked/archived) si tu utilises la fonction 'Backup' et non '<->'.
Pour expliquer le fonctionnement (identique à celui du TIGL soit dit en passant):
- 'Backup': effectue une sauvegarde de la caltos sous forme d'un groupe file avec conservation des attributs
- 'Restore': restaure la sauvegarde mais efface tout ce qui avait avant (comme une restauration, quoi). Les var qui étaient archivées seront ré-archivées.
- '<->': permet d'envoyer ou de recevoir un group file. Les attributs ne sont pas conservés. De plus, si la variable existe déjà sur la calc et est verrouillée/archivée, la transmission sera interrompue (le fameux 'send bit timeout').
Voilà, j'espère que c clair maintenant.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
Une idée pour les attributs: Si le protocole ne te permet pas de les restaurer directement sans utiliser Send Backup, peut-être que tu pourrais envoyer Archive mainvar1 en ligne de commande.
roms Le 29/07/2001 à 16:50 FlashZ: je peux mais ca oblige à faire un dirlist systématique avant un envoi de variable ce qui peut etre très chiant si il y a bcp de var dans la caltos.
Francois: j'ai pas encore fini le projet indus, ma soutenance est Vendredi...
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
Bah par exemple, tu ne fais que le dirlist si on ne l'envoie pas depuis l'explorer, mais seulement avec <-> ?
Ca irait comme ca... pasque qd on envoie des tas de fichiers, on le fait depuis l'explorateur.
roms Le 29/07/2001 à 16:50 Bon, j'ai fait des améliorations hier.
Explications:
- si la variable est envoyée depuis l'explorateur, pas de dirlist. Si la variable existait déjà sur la calc, elle sera écrasée sauf si elle est verouillée/archivée, elle sera sauté (rejected).
- si la variable est envoyée avec '<->', un dirlist est fait (qui peut etre désactivé optionnellement) avant. Ensuite, si il y a un doublon, TiLP affichera une boite de dialogue du type 'Sauter/Renommer/Ecraser'.
Voila, ca fait mieux et je pense que ca correspond à vos attentes.
La version sera prete pour cet AM. Ceux que ca intéressent me maille comme d'hab.
FlashZ: alors, ca donne quoi les test ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
C normal que je sois limité à 0.9 ko/s avec le graphlink gris et une ti89 ? Le TI Graphlink semble faire mieux (je tourne sous win98)
roms Le 29/07/2001 à 16:50 Oui, c normal. Le Grey TIGL fonctionne à 9600 bit/s soit 0.96Ko/s. C la vitesse max.
Pour monter plus haut, il faut utiliser un cable maison ou le fastAVRlink qui est compatible Grey TIGL mais jusqu'à 5 fois plus rapide.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
Non, je croyais qu'il etait compatible avec le Black Link justement...
Bon pour les tests je resume :
- je peux acceder aux repertoires accentues
- je ne peux tjrs pas envoyer depuis l'explorateur
- mon taux de transfert reste a 1.5Ko-2Ko/seconde
- la libcable envoyee dans le rep "flashz_undef" (92ko) ne fonctionne pas... je n'ai pas essaye avec le soft de ti en marche... tu veux que je fasse le test ?
roms Le 29/07/2001 à 16:50 Non, le BlackLink, c'est comme un cable sériel maison. Ca s'utilise à bas-niveau alors que le Grey TIGL utilise la norme RS232. Ils sont totalement incompatibles.
Si tu pouvais faire le test, ca serait cool.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
roms Le 29/07/2001 à 16:50 T'as tout compris, c un pb d'init du port COM.
En fait, entre les 2 DLLs que je t'ai envoyé, l'une est préinitialisée comme si j'ouvrais le port COM, l'autre pas.
Maintenant, 2 questions subsistent:
- pwkoi l'init fait chuter le taux
- pkwoi t'avais le taux max à un moment donné.
Conclusion: y'a peut etre une solution intérmédiaire.
Qu'est ce qui se passe si entre tps tu ferme le TIGL après l'avoir ouvert (l'idée: est-ce que l'init est furtive...) ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"
J'ai un timeout...
Bon, est-ce que tu fais la meme initialisation du COM que le TIGL ?
Pasque si c ton initialisation qui fait ralentir le transfert, c que tu ne fais pas comme le TIGL, etant donne que qd le TIGL est lance, ca marche a merveille...
Une question se pose : tu es sur que ton initialisation tu ne la poursuis pas pensant le transfert ?
