nojhan a écrit 632 commentaires

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) )

Corrigé, merci.

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.

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).

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.

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.

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

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

Comme dit dans la dépêche, Plumbum fait la même chose que chut, mais par dessus le module sh, qui utilise un hack très élégant pour l'import des commandes shell sous la forme de fonction. L'API est uber-cool, tu peux appeler les commandes sans même voir que c'est de l'appel système :

>>> from plumbum.cmd import cat, head
>>> ((cat < "setup.py") | head["-n", 4])()

Tu devrais regarder leur code pour simplifier l'appel de tes commandes dans chut ;-)

Techniquement — dans ce cas précis — c'est à la fois un mélange des deux et un peu entre les deux.

Si j'avais voulu pinailler, j'aurais sans doute utilisé computational intelligence (difficilement traduisible en français ?).

Mais comme « intelligence artificielle » me semble à la fois plus connu et plus cool, je l'utilise pour mes offres de stage, dans une tentative bassement publicitaire d'appâter le chaland.

Ça ressemble à un vieux bug. Normalement, il ne devrait pas y avoir deux commandes dans cette variable, mais une seule… à moins que tu aies bidouillé des trucs à la main.

Normalement ça marche déjà sous mac… enfin j'ai rien pour tester, mais il y a un type qui l'utilise, a priori.

Il y a plus classe que d'afficher l'horloge. Il semblerait qu'en ajoutant des hooks, on peut directement mesurer le temps pris par la commande exécutée : http://www.twistedmatrix.com/users/glyph/preexec.bash.txt

C'est plus intéressant, car, a priori, on peut alors n'afficher le temps pris par la dernière commande que s'il dépasse un certain seuil. J'envisage de mettre ça dans le liquid prompt, mais faut voir si ça ne deviens pas trop ingérable niveau temps d'exécution du prompt, justement.

Après mesures il semblerait que les regexp ne soient pas l'élément discriminant :

$ ./mtime.sh 10000 < load_commands | sort
6.05    uptime | awk '{print substr($10,0,length($10))}'
6.15    uptime | sed  "s/^.*average: \([0-9]\.[0-9][0-9]\),.*$/\1/"
6.17    uptime | awk '{ sub(",","",$10); print $10}'
6.23    uptime | awk 'BEGIN { FS = " |," } {print $17}'
8.02    uptime | awk '{print $10}'| sed -e 's/,//'

Mais tu gagnes quand même :-)

Je ne connais pas Zsh, mais le diff ne semble pas si différent qu'en bash… y aurait-il moyen de regrouper les deux dans le même script avec une détection du type de shell ?

Le bug sur la batterie est corrigé.

J'ai rajouté des variables en tête de fichier pour permettre de configurer les seuils d'affichage pour la batterie et la charge.

Perso, j'aime bien garder un seuil élevé car je m'habitue beaucoup trop aux widgets sur X, ils sont toujours affichés, dans un coin que je regarde rarement, avec toujours la même apparence… alors que l'apparition d'un truc sur le prompt me saute aux yeux !

On peut assez facilement changer les couleurs… ceci étant dit, le gris empêche d'utiliser beaucoup des couleurs ANSI… peut-être en ajoutant un fond noir partout ?

Je ne sais pas si ça vaut le coup d'avoir une config à part pour gérer ça.

La dernière version fixe ce bug en ne gardant que logname.

Peut-être en bidouillant quelque chose avec colout : https://github.com/nojhan/colout

Il y en a plusieurs, mais pour moi, le plus prometteur est sans conteste TermKit : http://acko.net/blog/on-termkit/

J'en prend bonne note. C'est con, d'ailleurs, comme erreur, parce que les stagiaires qui passent par chez nous sont toujours enchantés d'être passé et d'avoir été bien encadré (enfin je crois).

Je veux bien publier, mais il faudrait savoir où… on a fait les mailing-lists du domaine, quelques écoles… d'autres idées ?

Clairement. Le coup du type qui aligne des options intéressantes à ses diplômes, sur son CV, mais qui n'a rien à montrer et qui n'est pas capable d'expliquer en quoi son code est cool… c'est déprimant.

Mettez vos projets sur vos CV et expliquez ce que vous avez fait de cool dans vos lettres e-mails de motivation et épargnez-moi les banalités du genre « je souhaite valoriser mes compétences en systèmes d'information »… peut-être que ça m'évitera des faux négatifs :-)

Dans quel but ? Implémenter un algo juste pour l'implémenter ?

Quasiment, en fait. L'algo est très généraliste et sert aussi bien à te faire un emploi du temps qu'à gérer des ascenseurs (je schématise). Donc, oui, il s'agit surtout de dev.

Un types spécialisé dans le parallélisme et dans l'IA ? C'est une bonne perle rare quand même.

En fait on cherche un stagiaire ! C'est à dire un type intéressé par ça, pas spécialiste. Le stagiaire, on va l'encadrer et le former, en espérant qu'il reste chez nous après. Ce qui est difficile c'est de trouver des gens capable d'apprendre vite et d'être intéressés.

Foutaises! j'ai bon, j'ai gagné le business loto ?

C'est pourtant un résumé tout à fait correct et loin d'un pipotron. Sans doute mal tourné~ va falloir quand même revoir ton détecteur à pipeau.

on sait absolument pas quel lien il y a avec l'offre de stage.

L'algo, c'est sur lui qu'il faut travailler. Je peux difficilement être plus vulgarisant sans tomber dans le pipeau, justement…

Alors tu dis qu'on doit utiliser MPI, mais finalement tu dois le comparer à des implémentations sous MPI ?

Il y a du code de déjà fait, avec différentes schémas de parallélisation. Le stage est là soit pour bosser à fond sur l'une, soit pour comparer les existantes, etc. Les goûts du stagiaires comptent beaucoup dans l'orientation du sujet, en fait.

Ensuite rien ne définit les avantages (salaires, repas, transport, offres possibles après, cifre ? )

C'est le genre de trucs dont je viens de me rendre compte que c'était différenciateur avec la concurrence, en effet. Va falloir que je me mette au marketing RH :-)

C'est un peu dur de devoir se taper l'envoi d'e-mails à 36 écoles…

Pour le contexte, j'ai rédigé l'annonce qu'il m'aurait plu d'avoir quand je cherchait un stage, avec des termes à fouiller un peu, pensant naïvement que c'était un moyen comme un autre de détecter le stagiaire motivé.

En fait, je crois que j'ai mal estimé que le rapport offre/demande est très en défaveur des employeurs :-)