nojhan a écrit 600 commentaires

[^] # Re: graphisme

Posté par nojhan (page perso) le 15/06/13 à 21:12. En réponse à la dépêche Rejoignez LinuxFr.org ! LinuxFr.org c'est vous !. Évalué à 2.

Ça devait être aux alentours de 2005, sur une ML quelconque, je ne retrouve même plus l'image dans mes sauvegardes :-(

J'ai plus qu'à m'y remettre :-)

Répondre
[^] # Re: graphisme

Posté par nojhan (page perso) le 15/06/13 à 00:01. En réponse à la dépêche Rejoignez LinuxFr.org ! LinuxFr.org c'est vous !. Évalué à 2.

Moi aussi, même si je suis techniquement déjà utilisé. Ceci étant dit, j'ai déjà proposé un logo, mais je n'ai eu aucun retour…

Et d'ailleurs, il n'y pas de mailing-list graphisme d'indiquée dans la dépêche ? :-)

Répondre
[^] # Re: integration

Posté par nojhan (page perso) le 27/05/13 à 14:37. En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 1.
Une fonction ou un alias, par exemple j'utilise ça pour colorer une sortie de build cmake/g++ :
```
function cm()
{
    $@ 2>&1 | colout -t cmake | colout -t g++
}
```
Ça s'utilise simplement :
```
cm ./build_script
```
Répondre
[^] # Re: Colorer du texte sur la sortie standard en python

Posté par nojhan (page perso) le 16/04/13 à 08:27. En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 1.

Il y a peut-être moyen de refactoriser un peu colout pour qu'il puisse servir de module pour faire ce genre de truc aussi…

Répondre
[^] # Re: grep

Posté par nojhan (page perso) le 05/04/13 à 13:36. En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 7.

L'exemple le plus frappant est la lecture d'une sortie très verbeuse, comme par exemple la sortie de gcc.

Tu ne veux pas filtrer avec grep parce que tu peux avoir besoin de tout lire. Par contre il est pratique de pouvoir repérer très rapidement les passages qui t'intéressent (les erreurs, par exemple). Les couleurs sont un moyen très efficace de faire ça.

C'est pour ça que j'ai commencé à faire colout, mais je me suis assez vite rendu compte que le problème se posait aussi pour plein d'autres choses (diff, logs) et même dans des cas où j'utilisais grep habituellement (grep de code source, par exemple).

On peut se dépatouiller avec grep ou d'autres commandes dédiées (git coloré, colordiff, ccze, etc.) dans la plupart de ces cas mais je me suis vite rendu compte qu'il était très pratique d'avoir une seule commande bien pensée pour remplacer plein de façon disparates de faire moins bien.

Répondre
[^] # Re: Option

Posté par nojhan (page perso) le 05/04/13 à 13:27. En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 2.
C'est ce que fait l'option -t avec les fichiers de thème.
Un thème est une fonction qui renvoie une liste de la forme :
```
[
    ["regexp1", "couleur1,couleur1", "style"],
    ["regexp2"] # couleur et style par défaut
]
```
Voir les fichiers colout_*.py pour des exemples.
Répondre
# Inverse

Posté par nojhan (page perso) le 23/03/13 à 09:11. En réponse à la dépêche DChars, pour lire/écrire et modifier des caractères unicodes complexes. Évalué à 10.

Je ne suis pas sûr d'avoir bien compris à quoi ça servait, même si ça à l'air cool…

Est-ce que ça pourrait m'aider à faire une translitération "inverse" : d'une représentation multi-caractères latins vers de l'unicode ? (notamment vers du cunéiforme ?)

Répondre
[^] # Re: Shell graphique

Posté par nojhan (page perso) le 12/03/13 à 19:33. En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 2.

Dernier commit voilà 4 mois… pour moi ça n'est pas assez long pour déclarer une mort clinique…

Répondre
[^] # Re: Support Git

Posté par nojhan (page perso) le 12/03/13 à 17:52. En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 1.

J'aime bien l'idée, même si ça doit ramer à mort… tu nous fais une demande de fonctionnalité ?
https://github.com/nojhan/liquidprompt/issues/new :-)

Répondre
[^] # Re: Shell graphique

Posté par nojhan (page perso) le 12/03/13 à 17:51. En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 3.

TermKit : http://acko.net/blog/on-termkit/

Répondre
[^] # Re: Mieux !

Posté par nojhan (page perso) le 12/03/13 à 17:49. En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 2.

Ça n'est clairement pas fait pour un RPi… ceci étant dit, un prompt de base n'est pas non plus fait pour une bête de course :-)

Tu peux réduire de beaucoup le temps d'exécution en jouant avec les variables LP_ENABLE_* ou en virant des fonctionnalités dans ton propre LP_PS1 (cf. la doc).

Répondre
[^] # Re: Mieux !

Posté par nojhan (page perso) le 12/03/13 à 17:47. En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 1.

un prompt sur deux lignes…
comme ça je peux avoir le chemin en entier sur la première ligne.
Est-ce possible comme évolution/option ?

Pas pour le thème par défaut.

Mais tu peux tout à fait configurer le liquid prompt différemment, sans toucher au code.
Le plus simple est sans doute d'utiliser "]\n" pour LP_MARK_BRACKET_CLOSE, mais tu peux régler le prompt encore plus finement en utilisant ton propre LP_PS1. La doc explique tout ça avec des exemples, voir aussi les fichiers liquid.ps1 et liquid.theme.

Répondre
[^] # Re: PROMPT_COMMAND

Posté par nojhan (page perso) le 17/01/13 à 21:45. En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 2.

Corrigé, merci.

Répondre
[^] # Re: Question bête ...

Posté par nojhan (page perso) le 17/01/13 à 21:18. En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 1.

Il faut passer par le réseau pour voir l'écart avec un dépôt distant… je ne suis pas sûr que ça soit très rapide… et se reposer sur un fetch de l'utilisateur n'est pas très ergonomique. Le module git_ps1 est rapide, parce qu'il n'est pas en bash, je suppose ? Peut-être qu'on pourrait parser sa sortie au lieu de passer par des appels systèmes ?

Répondre
[^] # Re: Lazy ?

Posté par nojhan (page perso) le 17/01/13 à 19:33. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 2.

WTFOO : What The Fuck Object Oriented. C'est une vanne sur la lourdeur syntaxique du C++.

Pour des exemples d'opérateur $, voir le langage fonctionnel Haskell.

Je me garderais bien de donner un avis tranché sur l'élégance, quant à moi :-)

Répondre
[^] # Re: Licence

Posté par nojhan (page perso) le 17/01/13 à 13:45. En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 4.

On peut utiliser un prompt en se connectant sur un serveur, sans avoir à le télécharger. D’où l'AGPL.

Répondre
[^] # Re: Question bête ...

Posté par nojhan (page perso) le 17/01/13 à 13:44. En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 1.

Le prompt affiche le nombres de lignes en plus/moins des modifications non commitées en rouge, le nombre de commits non pushés en jaune.
Récupérer à chaque affichage le retard sur pull serait bien trop lent pour le prompt. Mais on peut peut-être envisager un job en arrière plan et un cache…

Répondre
[^] # Re: À coupler avec pysh ?

Posté par nojhan (page perso) le 17/01/13 à 11:38. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 1.
Avec Plumbum, je ne sais pas trop, mais avec chut ou pyxshell, c'est trivial, il suffit d'utiliser map avec une fonction (lambda, par exemple).

Ça devrait être un truc du genre :
```
ls("-l") | map( lambda x : rm(x) )
```
Répondre
[^] # Re: Conflit propagé

Posté par nojhan (page perso) le 17/01/13 à 11:31. En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 1.

Corrigé, merci.

Répondre
[^] # Re: Complémentarité avec byobu

Posté par nojhan (page perso) le 17/01/13 à 11:02. En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 1.

Je me suis moi-même longtemps reposé sur des widgets de notifications, mais ça n'était pas pratique en connexion distante. Puis sur des barres de titres dans le terminal, mais comme c'était toujours au même endroit, ça ne sautait rapidement plus aux yeux.

Finalement, ce qu'il me fallait c'est mettre l'info là ou je regardais tout le temps (le prompt, et pas tout en bas de l'écran) et uniquement quand c'est nécessaire (de manière à ne pas l'ignorer par habitude).

Le seul bémol du prompt étant qu'il n'est pas mis à jour en temps réel. Mais je tape suffisamment de commandes pour que ça ne soit qu'un problème mineur, et j'ai pris le réflexe d'appuyer sur entrée assez facilement pour mettre à jour.

Un avantage que je n'avais pas prévu, c'est aussi qu'un prompt bien fait permet de repérer facilement les différentes parties des affichages à l'écran.

Répondre
[^] # Re: Joli!

Posté par nojhan (page perso) le 17/01/13 à 10:51. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 3.

Et si on fusionnait les deux ? J'aimerais assez avoir le choix de l'origine des commandes utilisées (système ou python).

Par exemple, on aurait le choix d'utiliser from chut.sys import * (commandes dispo sur le système) ou from chut.cmd import * (réimplémentations pure python).

Répondre
[^] # Re: pypi

Posté par nojhan (page perso) le 17/01/13 à 10:47. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 2.

C'est encore la doc de calabash, je n'ai pas encore pris le temps de soumettre ça sur pypi.

C'est un fork plus ou moins compatible (calabash n'est pas en python3, mais sinon c'est juste une extension). Les explications sur le changement de nom sont dans mon premier commit.
En gros, calabash était déjà très googlé et pas très vendeur.

Répondre
[^] # Re: Lazy ?

Posté par nojhan (page perso) le 17/01/13 à 10:42. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 7.
Je ne sais pas si vous vous en rendez compte, mais c'est un vieux troll, qui a eu ses beaux jours à l'arrivée de la POO.

De fait, les différentes syntaxes sont équivalentes, mais il y en a d'autres, aussi… quelques exemples :
```
data | op1 | op2(arg) | op3 > var         # style shell infixé
var = Pipe(data).op1().op2(arg).op3()     # style POO
var << Pipe(data)->op1()->op2(arg)->op3() # style WTFOO
var := op3(op2(op1(data),arg))            # style fonctionnel préfixé
var <- op3 $ op2 $ arg op1 $ data         # style fonctionnel infixé
var = (data op1) arg op2 op3              # style fonctionnel postfixé
etc. ?
```
Personnellement, j'ai l'habitude de traiter les flux en shell, et j'aime bien que le traitement se lise de gauche à droite, sans fioritures. D'ailleurs, je me garderais bien de décréter que tel ou tel style est le plus pythonique dans ce cas précis. le fait est que l'infixé avec pipe me parait à la fois plus concis, plus intuitive et est plus simple à implémenter. CQFD.
Répondre
[^] # Re: Lazy ?

Posté par nojhan (page perso) le 16/01/13 à 17:48. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 1.

Du coup j'ai rajouté une commande sleep :-)

Répondre
[^] # Re: Lazy ?

Posté par nojhan (page perso) le 16/01/13 à 17:41. En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 2.
Les commandes sont implémentées comme des générateurs (cf. la doc sur yield), donc la chaîne complète forme une fonction, qui s'exécute en entier tant que l'itérable passé a qqchose à envoyer (et qu'il n'y a que des générateurs dans la séquence). Donc, sur des traitements long, tu verras les lignes s'afficher au fur et à mesure.

Dans l'exemple suivant, la fonction sleep ne fait qu'attendre avant de passer le prochain item, et les chiffres s'affichent bien au fur et à mesure :
```
>>> import time
>>> from pyxshell.common import *
>>> @pipe
def sleep(stdin,t):
    for i in stdin:
   ...:         time.sleep(t)
   ...:         yield i
   ...:         
>>> for i in ( range(3) | sleep(1) ):
    print(i)
   ....:     
0
1
2
```
Répondre