Je répondais au commentaire du dessus qui m'expliquait que je pouvais aller au resto ou manger chez moi… Si je n'ai qu'une seule version je me prive du resto ou de ma cuisine.
Il faudrait arrêter de tenter de commenter l'ensemble des posts de Linuxfr et faire attention aux discussions.
Je ne comprends pas l'argument du poids. Un e-reader fait aujourd'hui dans les 200g (Koboglo 185g, Kobo mini 134g, Kindle 170g). Mes livres de poche sont aussi lourds voire plus, et le les lis d'une seule main, debout dans le métro sans souci.
Le seul problème d'un livre de poche à une main est qu'il a tendance à se refermer et qu'on doit contorsionner les doigts pour le maintenir ouvert. Problème inexistant avec un e-reader.
Je ne peux pas parler du Koboglo, mais la référence pour gérer ses ebooks et chercher dans toutes les bibliothèques (gratuites ou non) est Calibre. La recherche se fait sur l'ensemble des bibliothèques d'un coup, du coup je ne me pose pas la question de quel catalogue j'utilise.
N'ayant pas de ebook (c'est ma copine qui a un Kindle), je ne sais pas si ça peut gérer la synchronisation entre plusieurs support. Mais une fois que tu auras goûté à un écran e-ink je te vois mal retourner à ton écran minuscule et brillant de ton téléphone.
Pour info, les gros avantages qui ont fait que je lui ai conseillé un Kindle sont :
- Elle utilisait déjà Amazon pour acheter ses livres
- Le Kindle a une fonction très pratique: tu envoies un epub (ou autre j'ai pas essayé) à une adresse mail liée au compte Kindle et le livre est téléchargé automatiquement sur le Kindle, vraiment pratique pour ne pas à avoir à brancher de câble. Cette fonction est d'ailleurs disponible directement depuis Calibre. Je ne connais pas d'autre appareil qui ont une fonction similaire.
Les ebooks s'utilisent sans problème d'une seule main.
Pour ma part je ne jure toujours que par un bon livre de poche papier, que je peux glisser dans une poche ouverte sans avoir peur des voleurs, que je peux laisser sur la plage/sur un banc sans surveillance sans risque de détérioration ni de vol, que je peux prêter à un amis, que je peux annoter, dans lequel je peux rapidement revenir deux à trois page en arrière car j'ai mal compris un passage, etc…
Et pourtant je suis un assez gros lecteur (1 livre de poche par semaine environ).
Pour moi le plus compliqué, il me semble, est de réaliser un simulateur qui soit assez fidèle à la réalité afin de sélectionner les candidats à la reproduction.
KDE 4.8.4 (4.8.4)
Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
4 Gio
Fonctionnait à peu près avant la réécriture de Dolphin.
Fonctionne parfaitement avec Konqueror.
Tu n'as pas compris. Ta version de KDE n'a rien à voir avec la vieillesse de ton .kde.
Essaye de déplacer ton dossier de config .kde, puis relance ta session.
Je ferais certainement un Journal quand j'aurais quelque chose de fonctionnel (ne pas s'attendre à ce que se soit pour bientôt).
En attendant je vais essayer de documenter mes bidouillages et investigations sur ce github : https://github.com/Oripy/Rabbity-Pi
J'y inclurais également le code (certainement en python) dès que j'en écrirais.
Pour l'instant c'est vierge, le github ayant été créé il y a quelques minutes.
Ce n'est pas trop gros, le Raspberry-Pi rentre largement dans le lapin (pas vraiment testé, mais en les mettant côte à côte, c'est flagrant).
Le lapin est sur secteur, je ne vois pas pourquoi j'y mettrais des piles… surtout qu'il y aura aussi le port hdmi quelque part a déporter ainsi qu'un hub USB
Effectivement je n'avais pas vraiment fait attention au circuit imprimé auxquels ces 4 fils étaient connectés, il semble que ce n'est qu'un moyen de se relier simplement aux 4 bornes du moteur pas à pas. Je dois avouer que j'ai un peu trop espéré que ce soit du moteur classique plutôt que du pas à pas, car le moteur classique paraît plus simple à contrôler.
Du coup je ne comprends pas comment le lapin sait quelle est la position de ses oreilles (on peut les tourner à la main et il reviendra tout seul à la bonne position lors de l'animation suivante). De mémoire les moteurs pas à pas n'indexent pas leur position.
J'en saurais plus quand j'aurais éventré mon lapin.
Il semble en fait (si je ne me trompe pas) que les moteurs soient de simples moteurs avec réducteurs, et que la position des oreilles soit détectée par un autre moyen (que je ne vois pas sur l'image).
Je vais donc pouvoir contrôler les 2 oreilles avec seulement 1 pont-H. Par contrôle il va me falloir trouver comment lire la position.
Par contre j'ai peur de manquer de GPIO:
- 5 leds RGB = 5x3 = 15 GPIO
- 2 moteurs = 2x2 = 4 GPIO
- 2 indicateurs de position = 2x2? = 4? GPIO
- 1 interrupteur sur la tête = 1 GPIO
Ce qui me fait un total de 20 GPIO, et il me semble que le R-Pi n'en a que 17.
Je suppose que je pourrais trouver une solution pour mutualiser sur les leds, de toute façon je n'en suis pas encore là !
J'ai acquis il y a quelque temps un Nabaztag à un Linuxfrien. Il trône depuis sur mon bureau, s'agitant et clignotant régulièrement (mais sans son car ce qu'il dit n'est pas vraiment intelligible).
Le problème du Nabaztag est qu'il est assez limité en fonctionnalités et surtout qu'on ne peut pas contrôler ce qu'il fait. Le constructeur a coulé et le serveur qui l'anime actuellement est vraiment limité.
J'ai reçu hier un Raspberry pi et j'envisage de remplacer la carte logique de mon Nabaztag afin de le contrôler avec le Raspberry pi. Cela fera un petit ordinateur avec des oreilles qui bougent ça peut être marrant.
Problème numéro 1 : Je n'y connais rien en électronique (hormis une petite base au lycée).
Je pense qu'il n'y aura pas trop de problème pour contrôler des leds (quoi que j'envisage d'utiliser des leds multicolore comme sur l'original, donc il y a certainement plus à faire que de simplement connecter une led à une sortie et une résistance).
Le plus difficile est de contrôler les moteurs pas à pas et surtout de récupérer les infos de l'indexeur qui permet au lapin de savoir dans quelle position sont ses oreilles.
Peux-tu me conseiller sur des sites expliquant à un débutant en électronique les bases pour apprendre à faire cela ?
D'après ce que je comprends de tes divers messages à propos d'Ultracopier et de Supercopier, Ultracopier est supérieur en terme de fonctionnalités, de performances et en portabilité. Supercopier quand a lui a uniquement comme avantage sa notoriété et sa base d'utilisateurs.
Tu pourrais par exemple faire une version 4 de Supercopier qui serait en fait un Ultracopier "skinné" pour ressembler à Supercopier. Le tout en annonçant aux utilisateurs les gains de fonctionnalités et de performances + le support de nouvelles plateformes.
Avantages :
- Une seule base de code à maintenir (à part éventuellement l'interface)
- Tu conserves la base d'utilisateurs de Supercopier (qui a l'air importante)
- Les utilisateurs de Supercopier gagnent les avantages en terme de fonctionnalités et de performances
Inconvénients :
- Un peu de temps pour adapter l'interface ?
- Rien d'autre ?
Maintenant que tu as appris tout ce qu'il y avait à apprendre du code de Supercopier, où est l'intérêt de continuer à le maintenir ?
Si j'ai quelque chose de compliqué à faire j'ouvre mon éditeur et je l´écris, et je le relis. Cela ne prend pas plus de temps et je fais moins de faute parceque mon programme jetable est mieux présenté, colorié et tout. ET c'est plus facile d'insérer une fonction intermédiaire si je décide que mon programme en serait plus facile à écrire — chose que tu ne feras jamais en ligne de commande.
Ben justement ipython te permet de commencer à faire du script interactif en quelques lignes puis si ça commence à devenir trop gros, un simple %save mon_script 1-num_dernière_ligne et roule ma poule !
Si on a plein de lignes à taper, un petit %edit, ça ouvre ton éditeur favoris, tu tapes, c'est plein de jolies couleurs, tu fermes en sauvegardant, puis ça exécute !
Dans ipython tu peux aussi écrire en tout ce que tu aurais pu écrire sur ton shell, simplement précéder la commande de !
Bref, c'est une habitude à prendre, mais je sais que mon ipython me sert souvent !
En disant "souvent décrit comme les échecs asiatiques", je parlais surtout au niveau de la popularité : le go est autant connu en Asie que les échecs sont connu en occident (par les joueurs et les non joueurs). Mais aussi au niveau de la compétitivité : il n'y a (à ma connaissance) pas de grande compétition internationale de shogi, contrairement au go et aux échecs.
Ceci étant dit tu as tout à fait raison, les règles du shogi se rapproche plus des règles échecs que le go.
[^] # Re: Tu fais des erreurs, mon ami
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 2.
Je fait donc l'impossible tout les soirs !!
[^] # Re: Calibre
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 2. Dernière modification le 01 février 2013 à 17:29.
Je répondais au commentaire du dessus qui m'expliquait que je pouvais aller au resto ou manger chez moi… Si je n'ai qu'une seule version je me prive du resto ou de ma cuisine.
Il faudrait arrêter de tenter de commenter l'ensemble des posts de Linuxfr et faire attention aux discussions.
[^] # Re: Calibre
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 2.
Le jour où en achetant le livre papier on me fournira en même temps la version numérique, j'achèterais peut-être une liseuse.
D'ici là je n'ai pas envie de payer 2 fois pour le même contenu…
[^] # Re: Apprendre de ses erreurs
Posté par Strash . En réponse au journal KDE from scratch. Évalué à 7.
C'est aussi du à la nature du changement dans Qt. Le passage de Qt3 à Qt4 était beaucoup plus violent que ne l'est celui de Qt4 à Qt5.
[^] # Re: Kindle
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 2. Dernière modification le 31 janvier 2013 à 18:06.
Tu peux aussi envoyer ton epub par mail à ton Kindle, Calibre se charge de la conversion.
[^] # Re: Kindle
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 1.
Calibre converti très bien les epub en un format lisible par un Kindle. Mais effectivement ça peut être un frein.
[^] # Re: Tu fais des erreurs, mon ami
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 7.
Je ne comprends pas l'argument du poids. Un e-reader fait aujourd'hui dans les 200g (Koboglo 185g, Kobo mini 134g, Kindle 170g). Mes livres de poche sont aussi lourds voire plus, et le les lis d'une seule main, debout dans le métro sans souci.
Le seul problème d'un livre de poche à une main est qu'il a tendance à se refermer et qu'on doit contorsionner les doigts pour le maintenir ouvert. Problème inexistant avec un e-reader.
# Calibre
Posté par Strash . En réponse au journal L'ebook reader des moules ?. Évalué à 10.
Je ne peux pas parler du Koboglo, mais la référence pour gérer ses ebooks et chercher dans toutes les bibliothèques (gratuites ou non) est Calibre. La recherche se fait sur l'ensemble des bibliothèques d'un coup, du coup je ne me pose pas la question de quel catalogue j'utilise.
N'ayant pas de ebook (c'est ma copine qui a un Kindle), je ne sais pas si ça peut gérer la synchronisation entre plusieurs support. Mais une fois que tu auras goûté à un écran e-ink je te vois mal retourner à ton écran minuscule et brillant de ton téléphone.
Pour info, les gros avantages qui ont fait que je lui ai conseillé un Kindle sont :
- Elle utilisait déjà Amazon pour acheter ses livres
- Le Kindle a une fonction très pratique: tu envoies un epub (ou autre j'ai pas essayé) à une adresse mail liée au compte Kindle et le livre est téléchargé automatiquement sur le Kindle, vraiment pratique pour ne pas à avoir à brancher de câble. Cette fonction est d'ailleurs disponible directement depuis Calibre. Je ne connais pas d'autre appareil qui ont une fonction similaire.
Les ebooks s'utilisent sans problème d'une seule main.
Pour ma part je ne jure toujours que par un bon livre de poche papier, que je peux glisser dans une poche ouverte sans avoir peur des voleurs, que je peux laisser sur la plage/sur un banc sans surveillance sans risque de détérioration ni de vol, que je peux prêter à un amis, que je peux annoter, dans lequel je peux rapidement revenir deux à trois page en arrière car j'ai mal compris un passage, etc…
Et pourtant je suis un assez gros lecteur (1 livre de poche par semaine environ).
[^] # Re: probleme 1
Posté par Strash . En réponse au message Challenge Codingame n°3. Évalué à 3.
Modifier l'énoncé d'un problème n'est pas une solution au problème.
[^] # Re: Grindadráp
Posté par Strash . En réponse au journal KDE : A webdesigner's workflow . Évalué à 3.
Je ne comprends pas vraiment pourquoi tu fais tout ceci pour démontrer l'existence d'un bug qui a depuis été corrigé.
Personne ne nie l'existence de ce bug, vu que quelqu'un a pris le temps de le corriger.
# Interopérabilité
Posté par Strash . En réponse à la dépêche Weboob 0.e. Évalué à 0. Dernière modification le 30 janvier 2013 à 08:08.
Vu la "professionalisation" de Weboob, y a-t-il des avancées sur le support d'autres OS ? (Je pense notamment à MacOSX)
[^] # Re: algorithmes plus efficace pour la gestion des pattes
Posté par Strash . En réponse au journal Bleuette, un robot hexapode libre. Évalué à 4.
Pour moi le plus compliqué, il me semble, est de réaliser un simulateur qui soit assez fidèle à la réalité afin de sélectionner les candidats à la reproduction.
[^] # Re: Grindadráp
Posté par Strash . En réponse au journal KDE : A webdesigner's workflow . Évalué à 3.
Tu n'as pas compris. Ta version de KDE n'a rien à voir avec la vieillesse de ton .kde.
Essaye de déplacer ton dossier de config .kde, puis relance ta session.
[^] # Re: Conversion d'un Nabaztag
Posté par Strash . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 2.
Je ferais certainement un Journal quand j'aurais quelque chose de fonctionnel (ne pas s'attendre à ce que se soit pour bientôt).
En attendant je vais essayer de documenter mes bidouillages et investigations sur ce github : https://github.com/Oripy/Rabbity-Pi
J'y inclurais également le code (certainement en python) dès que j'en écrirais.
Pour l'instant c'est vierge, le github ayant été créé il y a quelques minutes.
[^] # Re: Conversion d'un Nabaztag
Posté par Strash . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 2.
Première étape bloquante : les vis du Nabaztag ont des tête avec des trous en forme de triangle… j'ai pas ça en rayon…
[^] # Re: Conversion d'un Nabaztag
Posté par Strash . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 2.
Donc je pense qu'utiliser le Raspberry-Pi n'est pas si idiot que ça…
[^] # Re: Conversion d'un Nabaztag
Posté par Strash . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 1.
Effectivement je n'avais pas vraiment fait attention au circuit imprimé auxquels ces 4 fils étaient connectés, il semble que ce n'est qu'un moyen de se relier simplement aux 4 bornes du moteur pas à pas. Je dois avouer que j'ai un peu trop espéré que ce soit du moteur classique plutôt que du pas à pas, car le moteur classique paraît plus simple à contrôler.
Du coup je ne comprends pas comment le lapin sait quelle est la position de ses oreilles (on peut les tourner à la main et il reviendra tout seul à la bonne position lors de l'animation suivante). De mémoire les moteurs pas à pas n'indexent pas leur position.
J'en saurais plus quand j'aurais éventré mon lapin.
[^] # Re: Conversion d'un Nabaztag
Posté par Strash . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 1.
Merci beaucoup pour ces infos.
Pour le LEDs, peut-on faire varier la tension en sortie d'un GPIO ou est-ce forcément du tout ou rien ?
En regardant un peu avant d'éventrer mon lapin, je suis tombé là dessus :
http://asia.cnet.com/cracking-open-the-nabaztag-wi-fi-rabbit-62036366.htm
Il semble en fait (si je ne me trompe pas) que les moteurs soient de simples moteurs avec réducteurs, et que la position des oreilles soit détectée par un autre moyen (que je ne vois pas sur l'image).
http://asia.cnet.com/cracking-open-the-nabaztag-wi-fi-rabbit-62036366.htm
Cette image montre 4 fils sortant de chaque "moteur", je suppose que 2 fils alimentent le moteur et 2 autres fils contrôlent la position.
Je vais donc pouvoir contrôler les 2 oreilles avec seulement 1 pont-H. Par contrôle il va me falloir trouver comment lire la position.
Par contre j'ai peur de manquer de GPIO:
- 5 leds RGB = 5x3 = 15 GPIO
- 2 moteurs = 2x2 = 4 GPIO
- 2 indicateurs de position = 2x2? = 4? GPIO
- 1 interrupteur sur la tête = 1 GPIO
Ce qui me fait un total de 20 GPIO, et il me semble que le R-Pi n'en a que 17.
Je suppose que je pourrais trouver une solution pour mutualiser sur les leds, de toute façon je n'en suis pas encore là !
# Conversion d'un Nabaztag
Posté par Strash . En réponse au journal Je me fais des amis (au sens littéral). Évalué à 1.
J'ai acquis il y a quelque temps un Nabaztag à un Linuxfrien. Il trône depuis sur mon bureau, s'agitant et clignotant régulièrement (mais sans son car ce qu'il dit n'est pas vraiment intelligible).
Le problème du Nabaztag est qu'il est assez limité en fonctionnalités et surtout qu'on ne peut pas contrôler ce qu'il fait. Le constructeur a coulé et le serveur qui l'anime actuellement est vraiment limité.
J'ai reçu hier un Raspberry pi et j'envisage de remplacer la carte logique de mon Nabaztag afin de le contrôler avec le Raspberry pi. Cela fera un petit ordinateur avec des oreilles qui bougent ça peut être marrant.
Problème numéro 1 : Je n'y connais rien en électronique (hormis une petite base au lycée).
Je pense qu'il n'y aura pas trop de problème pour contrôler des leds (quoi que j'envisage d'utiliser des leds multicolore comme sur l'original, donc il y a certainement plus à faire que de simplement connecter une led à une sortie et une résistance).
Le plus difficile est de contrôler les moteurs pas à pas et surtout de récupérer les infos de l'indexeur qui permet au lapin de savoir dans quelle position sont ses oreilles.
Peux-tu me conseiller sur des sites expliquant à un débutant en électronique les bases pour apprendre à faire cela ?
# Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par Strash . En réponse à la dépêche Supercopier 3. Évalué à 9.
D'après ce que je comprends de tes divers messages à propos d'Ultracopier et de Supercopier, Ultracopier est supérieur en terme de fonctionnalités, de performances et en portabilité. Supercopier quand a lui a uniquement comme avantage sa notoriété et sa base d'utilisateurs.
Tu pourrais par exemple faire une version 4 de Supercopier qui serait en fait un Ultracopier "skinné" pour ressembler à Supercopier. Le tout en annonçant aux utilisateurs les gains de fonctionnalités et de performances + le support de nouvelles plateformes.
Avantages :
- Une seule base de code à maintenir (à part éventuellement l'interface)
- Tu conserves la base d'utilisateurs de Supercopier (qui a l'air importante)
- Les utilisateurs de Supercopier gagnent les avantages en terme de fonctionnalités et de performances
Inconvénients :
- Un peu de temps pour adapter l'interface ?
- Rien d'autre ?
Maintenant que tu as appris tout ce qu'il y avait à apprendre du code de Supercopier, où est l'intérêt de continuer à le maintenir ?
[^] # Re: tablette ?
Posté par Strash . En réponse à la dépêche Sortie de MyPaint 1.1. Évalué à 2.
A confirmer, mais sous Linux il me semble que seul les talettes Wacom sont bien compatibles avec tout les logiciels de ce type (Gimp, Krita, …).
# Krita
Posté par Strash . En réponse à la dépêche Sortie de MyPaint 1.1. Évalué à 5.
Quel est le positionnement par rapport à Krita (Calligra) ? Y a-t-il des collaborations entre ces deux logiciels qui semblent avoir la même cible ?
[^] # Re: Switcher à python comme shell
Posté par Strash . En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 5.
Ben justement ipython te permet de commencer à faire du script interactif en quelques lignes puis si ça commence à devenir trop gros, un simple
%save mon_script 1-num_dernière_ligneet roule ma poule !Si on a plein de lignes à taper, un petit %edit, ça ouvre ton éditeur favoris, tu tapes, c'est plein de jolies couleurs, tu fermes en sauvegardant, puis ça exécute !
Dans ipython tu peux aussi écrire en tout ce que tu aurais pu écrire sur ton shell, simplement précéder la commande de !
Bref, c'est une habitude à prendre, mais je sais que mon ipython me sert souvent !
[^] # Re: Une possibilité
Posté par Strash . En réponse au journal Tournoi de go de Paris. Évalué à 1.
Je n'avais pas réalisé la distance ! Je vais quand même transmettre le contact, mais j'ai peur que la salle ne soit considérée comme trop éloignée.
En tout cas merci pour cette possibilité !
Si quelqu'un d'autre à une autre proposition plus près de Paris, je suis également intéressé !
[^] # Re: Petit commentaire :
Posté par Strash . En réponse au journal Tournoi de go de Paris. Évalué à 3.
En disant "souvent décrit comme les échecs asiatiques", je parlais surtout au niveau de la popularité : le go est autant connu en Asie que les échecs sont connu en occident (par les joueurs et les non joueurs). Mais aussi au niveau de la compétitivité : il n'y a (à ma connaissance) pas de grande compétition internationale de shogi, contrairement au go et aux échecs.
Ceci étant dit tu as tout à fait raison, les règles du shogi se rapproche plus des règles échecs que le go.