Posté le 22/08/2016 12:13
Le projet est déprécié au profit de Cahute, qui réimplémente p7 et p7screen !
The project is deprecated in favour of Cahute, which reimplements p7 and p7screen!
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 110 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 22/08/2016 12:58 | #
Ce serait bien si ton configure pouvait détecter clang ou gcc et choisir celui qui est installé. Préciser aussi qu'il faut asciidoc pour avoir la doc (mon dieu ce qu'il est lent d'ailleurs).
Outre les nombreux warnings de clang (mais comment tu fais ?
a2x: WARNING: --destination-dir option is only applicable to HTML based outputs
Sinon, c'est bien : efficace et plus ergonomique, peut-être un poil plus rapide que CasioUsb, mais nettement plus lent que UsbConnector (dommage). L'interface est simple et les manpages pertinents. J'adopte !
Il manque un \n et un 'ed' à "Request file doesn't exist !".
Citer : Posté le 22/08/2016 13:05 | #
Les warnings de clang sont dûs à des utilitaires de logs qui sont inutilisés quand ceux-ci sont désactivés (ce qui est le cas par défaut). Faudra que je pense à les isoler, un de ces jours. Et yep, pour le compilo, j'utilise clang parce que je suis sous Debian (donc avec gcc 4.9, sans coloration des warnings) et que sur clang il y a de la coloration, mais faudra que j'ajoute une variable CC au configure script.
Pour le warning d'a2x, je suis au courant, mais l'option est utilisée malgré ce warning, donc c'est bizarre, mais ça marche bien comme ça. Et sa lenteur, j'ai dû m'habituer
Pour la lenteur du transfert, j'ai aussi remarqué lors de mes tests, faudra que je review les mécanismes internes de la libp7. Y a pas mal de mécanismes intermédiaires qui facilitent l'implémentation des protocoles, mais qui sont un peu lents (notamment côté data, mais je sais pas trop comment rendre ça plus rapide tout en gardant ça aussi simple).
Et pour le message, c'est corrigé, ça partira avec la v1.1 de l'utilitaire CLI
Mon blog ⋅ Mes autres projets
Citer : Posté le 22/08/2016 13:07 | #
Je crois pas ce soit du log qui cause « warning: initializing 'char *' with an expression of type 'const char [47]' discards qualifiers »
Mais sinon bon boulot, ça fonctionne bien comme il faut. C'est pratique de pouvoir transférer des petits fichiers quasiment instantanément !
Citer : Posté le 22/08/2016 14:42 | #
Bon du coup j'ai fait un peu de recherche et voici une règle udev un peu plus générale, pratique et sécure (que j'ai intitulé "60-casio-usb.rules"), la voici :
DRIVER=="usb", ATTRS{idVendor}=="07cf", ATTRS{idProduct}=="6101", MODE="0666"
Je l'incluerai dans la prochaine version de la lib (en mettant une option dans le configure script pour ne pas l'installer).
Ajouté le 22/08/2016 à 17:36 :
Et voilà, une update assez petite mais que je trouvais nécessaire des deux éléments : la lib est actuellement à la version 1.2 et l'exécutable à la version 1.1.
Grosses modifications :
- J'ai enfin défini une licence pour les deux projets, ils sont à présent sous GNU GPL v2 ;
- Désormais, installer la lib installe également la règle udev ;
- Il est à présent possible de supprimer un fichier distant (ce que j'appelle "la cerise").
Deux avertissements par rapport à la mise à jour :
- Premièrement, le script de configuration de la lib a changé et la configuration n'est pas rétrocompatible. Pensez à utiliser ./reconfigure ou à re-clôner le dépôt de la lib au lieu de pull !
- Deuxièmement, la lib installe maintenant la règle udev citée dans le message ci-dessus. Si vous avez encore la règle de l'époque UsbConnector, pensez à le virer ou à ajouter l'option --noinstall-udev-rule au script de (re-)configuration !
Voilà, avec ça, il devrait être facile de faire évoluer les deux projets, et l'ajout de la licence devrait permettre leur packaging sur des distributions comme Debian. À venir, d'autres sous-commandes et (peut-être) un travail sur la rapidité de transfert de la lib.
Ajouté le 23/08/2016 à 15:05 :
Et on remercie Breizh_craft pour avoir fait les deux paquets correspondant à la lib et à l'exécutable sur l'AUR ! Une mention concernant Arch/Manjaro a été ajoutée
Je travaille actuellement sur la prochaine version des deux. La différence de vitesse par rapport à UsbConnector me préoccupe, mais ne vous inquiétez pas, je suis dessus.
Mon blog ⋅ Mes autres projets
Citer : Posté le 23/08/2016 15:09 | #
Hmm, pourquoi t'as besoin de ranlib si t'as déjà ar ? Suffit d'ajouter -s.
Citer : Posté le 23/08/2016 15:11 | #
C'est vrai. Enfin, de toute façon, les deux sont dans binutils, donc bon... x)
Mon blog ⋅ Mes autres projets
Citer : Posté le 23/08/2016 20:46 | #
❤
Citer : Posté le 24/08/2016 13:08 | #
Wow, je viens de capter qu'il y avait un jeu de mot dans le titre. x)
Mais sinon c'est cool ! J'ai pas de machine pour tester, mais ça a l'air d'être assez pratique !
Je ferai peut être un paquet pour la Void Linux si j'ai un peu de temps, même si je doute que ça touche beaucoup de monde…
Citer : Posté le 28/08/2016 01:47 | #
[REDACTED]
Mon blog ⋅ Mes autres projets
Citer : Posté le 28/08/2016 02:05 | #
T'as marqué sur le chat que les paquets envoyés (et reçus, j'imagine) étaient les mêmes. Est ce que dans les logs tu vois une quelconque différence de temps pour des paquets spécifiques (par exemple, l'ACK est envoyé 50 ms plus tard avec p7 que usbconnector) ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 29/08/2016 00:48 | #
Bon, alors les expériences ont démontré que les paquets sur usb-connector mettaient 10 fois moins de temps à arriver. Donc j'ai cherché, et j'ai fini par enfin remarquer un truc : deux check packets sont envoyés par UC, et une seule réponse est lue, et il y a décalage entre l'envoi et la réponse. J'ai naturellement nommé ça du packet shifting.
J'ignore pourquoi, en situation de packet shifting, la calculatrice est plus rapide, mais c'est quelque chose à tenter d'exploiter. Je ne connais pas encore tout à fait les cas où on peut l'utiliser sans se faire gerter, et quand je les connaîtrai, il faudra que je gère les cas d'erreurs (avec un double buffer d'envoi, une globale pour savoir dans quelle situation on est et l'action de p7_recv vis-à-vis de cette globale) et que j'essaie de garder la même interface pour la libp7 (ce qui ne sera pas possible si le packet shifting ne marche qu'avec le paquet de shift initial...).
Donc pas mal de R&D à venir et un "serveur" qui a visiblement l'air codé avec les pieds. Mais je progresse, et ça, c'est cool.
Mon blog ⋅ Mes autres projets
Citer : Posté le 29/08/2016 08:04 | #
Btw, la plupart des envois que je fais avec p7-1.1 sont très rapides (1.5s) et quelques-uns plus lents (5-6s). Donc dans certains cas au moins, le phénomène se reproduit.
Citer : Posté le 04/09/2016 20:27 | #
Les versions 1.3 et 1.2 de respectivement la libp7 et de p7 sont là !
Si vous aviez installé manuellement une version précédente de la lib, n'utilisez pas la target "install" du Makefile, mais "reinstall", pour supprimer toute trace de l'ancienne lib statique.
Assez peu de nouveautés visibles au final. Pour la lib :
- la lib est devenue une lib dynamique ;
- fluidification des mécanismes internes ;
- introduction du packet shifting, technique encore non maîtrisée.
Et pour l'utilitaire :
- ajout d'une sous-commande info (pour dumper quelques informations utiles) ;
- accélération de l'envoi de fichiers - pour en profiter, l'option -f doit être présente.
Je retravaillerai l'I/O pour permettre la communication avec un port série, et plus généralement, avec des flux standards (ce qui permettra en prime d'implémenter des tests). Aussi, je chercherai à maîtriser davantage le packet shifting pour voir si on ne peut pas l'étendre à tous les packet flows interactifs - malheureusement, pour les packet flows faisant intervenir du role swapping (e.g., requête de fichiers), j'ai bien peur que ce soit impossible, sauf si je trouve une autre technique entre-temps.
Aussi, j'ai commencé à travailler sur une libg1m à côté pour manipuler les fichiers (issus) de la mémoire principale. Une fois faite, côté p7/libp7, travailler avec la mémoire principale ne devrait pas trop être hardcore.
Le paquet pour Manjaro/Arch Linux a été mis à jour par son mainteneur.
Ajouté le 05/09/2016 à 02:18 :
À peine plus de 6 heures après la release des versions précédentes, les versions 1.4 de la libp7 et 1.3 de p7 sont là !
Si vous aviez installé manuellement une version précédente (<= 1.2) de la lib, n'utilisez pas la target "install" du Makefile, mais "reinstall", pour supprimer toute trace de l'ancienne lib statique.
Le destin ne m'aimant pas beaucoup, il a décidé de provoquer le déclic vis-à-vis du packet shifting à peine une à deux heures après les dernières releases, sur lesquelles j'ai travaillé pendant beaucoup de temps. Maintenant, cette technique marche à peu près avec l'ensemble des manipulations réalisables avec l'utilitaire P7.
Pour vous donner un ordre d'idée, pour l'envoi comme pour la réception d'un fichier de 50Kio, j'obtiens une durée de l'ordre de la demi-seconde. Et ça, c'est beau. (mais on ne pourra pas vraiment avoir beaucoup moins)
Listage exhaustif des ajouts depuis la dernière version
Pour la lib :
- application du packet shifting sur les opérations d'envoi et de réception de fichier ;
- ajout de la fonction p7_copyfile et de la doc associée.
Pour l'utilitaire :
- gain de vitesse assez considérable sur les opérations d'envoi et de réception de fichier ;
- ajout de la sous-commande copy.
Petite note, la sous-commande copy ne demande pas de confirmation lorsque le fichier de destination existe déjà - c'est parce que le protocole n'en propose pas directement. En revanche, si je trouve et implémente une façon de vérifier si un fichier existe (sans le récupérer), je pourrai éventuellement créer une confirmation interactive et rendre à l'option -f ce qui est à l'option -f.
Le paquet pour Manjaro/Arch Linux a été mis à jour, et tout fonctionne nickel
Et en cas de bug, n'hésitez pas à m'en faire part ici. Il est 2 heures du matin, et je suis très moyennement éveillé (le moment idéal pour coder), donc j'ai pu laisser passer quelque chose de relativement énorme.
Ajouté le 06/09/2016 à 21:04 :
Bon, j'en fais la brève mention ici, mais j'ai fini une version fonctionnelle de P7SCREEN, un utilitaire d'affichage d'écran streamé (calculatrice en mode projecteur). Ça a les mêmes dépendances que P7, avec la SDL 1.2.15 en plus.
Dans les prochaines versions, ça serait sympa que je réussisse à faire une vraie interface GUI, ou, plus dans l'immédiat, une option qui sauvegarde les différentes frames dans des fichiers bitmap (utile pour les images d'illustration par exemple). M'enfin, déjà, on a du streaming qui fonctionne avec un zoom configurable (l'option -z).
Ça nécessite une version de la lib qui n'est pas released, j'y fais une brève mention ici pour les gens impatients (clônez la lib au commit ff95f9419a1ce9b83bc91cca0d1e25634f7d8794). Il faut encore que j'implémente d'autres trucs dans la lib pour passer à la version suivante (pour préparer le deuxième utilitaire p7-related sur lequel je travaille). Mais j'avance
Mon blog ⋅ Mes autres projets
Citer : Posté le 08/09/2016 21:50 | #
Tu pourrais peut-être implémenter un flux bitmap histoire qu'on puisse le récupérer dans un autre programme. Btw, je suis désolé mais personne ne pourra compiler p7screen avec une version de la SDL qui n'est plus disponible dans les dépôts. La version 2 est sortie depuis des lustres (2-3 ans), je crois qu'il serait bien que tu l'utilises
Bien joué pour le packet shifting, j'ai vu les convs' sur Casiopeia et ça a l'air d'être assez technique. C'est pas souvent qu'on apprend des choses à SimLo non plus.
Citer : Posté le 08/09/2016 21:53 | #
Pour le flux, je comptais effectivement implémenter un truc du genre (je pensais enregistrer dans des fichiers à la dvgrab, mais c'est vrai que prévoir la redirection du flux de sortie ça peut être pas mal aussi).
Pour la SDL, je sais que Debian (et ça m'étonnerait que les distros ne fassent pas pareil) gardent les deux versions de la SDL (1.2 et 2.x) dans leurs dépôts pour supporter les applications développées avec la SDL 1.2. Mint est une petite-fille de Debian, donc elle devrait avoir les deux aussi... Oo
Mon blog ⋅ Mes autres projets
Citer : Posté le 08/09/2016 21:55 | #
Manjaro a aussi la 1.2 et la 2.x dans ses dépôts…
Citer : Posté le 08/09/2016 22:16 | #
Au temps pour moi. Je devais pas être assez malin pour m'en rendre compte à l'époque. Bon, je te suggère quand même d'utiliser la dernière version hein, c'est un peu comme Python 2.7... x)
Je testerai ça quand j'aurai du temps libre (lol)
Citer : Posté le 08/09/2016 22:24 | #
Après, bon, tout ce qui n'est pas released, j'en fais mention pour donner l'eau à la bouche, mais mieux vaut attendre que ce soit released hein
Là, faut que je corrige deux-trois trucs dans la gestion d'erreur (des cas spécifiques et improbables, mais qui peuvent arriver) et que j'avance un peu p7os (un utilitaire à-la-fxRemote utilisant la libp7 (mais juste pour récupérer l'OS dans un premier temps, parce que je flippe à mort)) pour release le tout. J'en profiterai pour implémenter les streams d'images avec p7screen avant de release du coup. (un beau programme !)
Sinon, la SDL2 est chiante à manipuler pour tout ce qui est manipulation de pixels, alors qu'avec la SDL1.2 c'est easy, donc bon.
Ajouté le 12/09/2016 à 21:27 :
Bon, du coup, comme certains me l'ont demandé, je fais une nouvelle release de la libp7 et de P7, et publie P7SCREEN par la même occasion ! J'en ai profité pour réaliser un petit site qui sera la homepage du projet (j'en ferai une version anglaise un de ces jours). Aussi, le packaging Debian est déjà en place, il faut juste que je parvienne à faire mon repository.
Normalement, la lib devrait être plus stable (parce qu'elle tire davantage parti des filestreams et de leur bufferisation), il le fallait bien pour que P7SCREEN reste debout malgré les paquets parfois foireux envoyés par la calculatrice. Je vous laisse (re-?)découvrir toutes les instructions et l'aide sur le site (qui est une reprise du topic en plus joli et surtout plus pratique à maintenir derrière, loin du BBCode foireux de PC).
Si vous avez la poisse et que vous voulez savoir ce qu'il se passe si P7 ou P7SCREEN plante, n'hésitez pas à compiler/installer vous-même la libp7. Pensez à configurer avec l'option --loglevel=info :
À venir, une gestion plus précise de l'environnement (mode de la calculatrice) et un utilitaire de récupération de l'OS (l'utilitaire de remplacement d'OS ne viendra pas avant longtemps).
Mon blog ⋅ Mes autres projets
Citer : Posté le 12/09/2016 22:08 | #
Super
Breizh, tu nous avertis si tu met à jour le dépot sur l'AUR ?
Citer : Posté le 12/09/2016 22:14 | #
Je le ferais il y a une heure.
Approximativement.