/* Topic des codeurs [7] */

Steap · Le 30/03/2012, à 00:08

Rolinh a écrit :

Je m'amuserais à le porter sur BSD à l'occasion (voir même OSX) mais je voulais déjà implémenter les options les plus utiles/vitales.

Porté sur FreeBSD Je t'envoie le patch à l'adresse précisée dans les sources, ou tu préfères que je mette ça quelque part sur la page de dfc ?

Rolinh · Le 30/03/2012, à 00:16

Woao
Tu peux me l'envoyer a l'adresse précisée dans la manpage puis je le mergerais en mentionnant ton nom ;-)
Merci beaucoup en tout cas!

Steap · Le 30/03/2012, à 02:59

C'est fait

Je t'ai envoyé un petit patch mercredi matin, et je viens de recevoir une Delivery Status Notification.

Kanor · Le 30/03/2012, à 08:11

urllib est sympa quand tu fais une ou deux requête mais si tu a besoin de faire plein de requête je te conseil d'utiliser httplib2
il gère différente fonctionnalité permettant d'optimiser le temps de réponse (compression des requête , utilisation de etag, cache …)
http://diveintopython3.ep.io/http-web-services.html

Kanor · Le 30/03/2012, à 09:27

Ça semble intéressant
http://tagide.com/blog/2012/03/research … languages/

The Uploader · Le 30/03/2012, à 09:35

SUPPORT_JOKE @ Ruby

Rolinh · Le 30/03/2012, à 15:28

Steap a écrit :

Je viens de recevoir une Delivery Status Notification.

Un soucis avec le firewall de mon serveur ^^

J'ai bien reçu ton patch maintenant mais je ne sais pas du tout quelle révision il concerne et je t'avoue que je ne suis pas trop motivé à le merger à la main vu la longueur...
Tu peux me re-envoyer un patch? Le plus beau serait de m'en faire un avec git format-patch

The Uploader · Le 30/03/2012, à 15:43

git format-patch FTW!

Kanor · Le 30/03/2012, à 16:52

Ça t ecrit tes commit sous la forme d un fichier patch (+ ou - un diff ) que tu peux appliquer en faisant un git am

Etoma · Le 30/03/2012, à 21:23

@ Kanor : Danke pour le lien

Rolinh · Le 30/03/2012, à 21:34

Il y a des messages qui sont partis aux oubliettes ou bien c'est moi?

Sinon, dfc 2.2.0 est de sortie

Merci grim pour le micropatch

grim7reaper · Le 31/03/2012, à 13:32

Rolinh a écrit :

Merci grim pour le micropatch

De rien

Si tu passes par là, je te signale un souci pour le paquet 64-bit :

résolution des dépendances...
recherche des conflits entre paquets...

Cibles (1) : dfc-2.1.0-1

Taille totale de téléchargement :       0,01 MiB
Taille totale installé :                0,06 MiB

Procéder à l'installation ? [O/n] 
:: Récupération des paquets du dépôt archlinuxfr...
Erreur : échec de récupération du fichier « dfc-2.1.0-1-x86_64.pkg.tar.xz » depuis repo.archlinux.fr : The requested URL returned error: 404
Avertissement : échec de récupération de certains fichiers depuis archlinuxfr
Erreur : la validation de la transaction a échoué (erreur de la bibliothèque de téléchargement)
Des erreurs se sont produites, aucun paquet n'a été mis à jour.

Rolinh · Le 31/03/2012, à 15:08

Ah? j'ai l'impression que la base de données du dépôt archlinuxfr est corrompue. J'ai bien mis en ligne la 2.2.0 mais on dirait que la base reste sur la 2.1.0...
Je vais essayer de le réuploader et sinon je contacterais les admins.

EDIT: il me semble que c'est bon là. Tu peux confirmer?

Dernière modification par Rolinh (Le 31/03/2012, à 15:10)

grim7reaper · Le 31/03/2012, à 15:31

Yep, ça fonctionne

Rolinh · Le 31/03/2012, à 15:49

Cool
Et les notifications par e-mail pour gw-computing.net devraient maintenant fonctionner. Plus facile pour suivre les issues (je t'ai répondu à propos de la feature #49 )

Rolinh · Le 31/03/2012, à 16:53

Bon, je n'ai pushé la 2.2.0 dans archlinuxfr que pour quelques minutes puisque maintenant, la 2.3.0 est disponible.
Je pense que toutes les options vraiment utiles ont été ajoutées mais si vous voyez autre chose, il suffit de me le signaler.

grim7reaper · Le 31/03/2012, à 17:49

Tiens, il semblerait que tu t’attaques bientôt aux différents formats de sorties (HTML, CSV, TeX, texte simple), je ne sais pas ce que tu envisages mais j’ai une idée sur la façon de le faire.
Il semble que tu aies plusieurs fonctions d’affichage (disp_header, disp_sum, disp_bar, disp_at et disp_perct), au lieu de foutre plein de if partout pour appeler la bonne fonction en fonction du format souhaité tu pourrais faire un truc du genre :
- une structure Display qui contient des pointeurs de fonctions :

typedef void (*Disp_header) (struct list*);
typedef void (*Disp_sum)    (struct list*, double, double, double, double, double);
typedef void (*Disp_bar)    (double);
typedef void (*Disp_at)     (double, double);
typedef void (*Disp_perct)  (double);

typedef struct
{
    Disp_header print_header;
    Disp_sum    print_sum;
    Disp_bar    print_bar;
    Disp_at     print_at;
    Disp_perct  print_perct;
} Display;

- une fonction qui initialise comme il faut les pointeurs de fonctions selon le format demandé :

    switch(format) /* format étant une enum par exemple. */
    {
    case TEXT:
        disp_text(&disp);
        break;
    case HTML:
        disp_html(&disp);
        break;
    case CSV:
        disp_csv(&disp);
        break;
     /* … */
    }

Les fonctions disp_* étant du style :

void disp_html(Display* disp)
{
    disp->print_header = html_disp_header;
    disp->print_sum = html_disp_sum;
    disp->print_bar = html_disp_bar;
    disp->print_at = html_disp_at;
    disp->print_perct = html_disp_perct;
}

Sachant que les fonction html_* seront définies dans html.h/html.c, et idem pour le CSV, le TeX, …
- et à l’utilisation, c’est très simple :

…
disp.print_perct(perct)
…

Et là ça t’affichera automatiquement dans le bon format sans te faire chier à coup de if/else

L’avantage de cette architecture, c’est que l’ajout d’un nouveau format ne modifiera pas le code de dfc.c, tu auras juste à ajouter une clause au switch et ajouter un couple de fichier .h/.c pour gérer le nouveau format.

Dernière modification par grim7reaper (Le 31/03/2012, à 17:50)

Rolinh · Le 31/03/2012, à 18:22

Et ben... ça c'est de l'explication!

Ton idée semble bien mais je t'avouerais que je n'ai pas encore trop réfléchis à comment je pourrais implémenter ceci.
Le truc, c'est que mes fonctions disp_* servent pour l'affichage en console. Je ne suis pas sur que les besoins soit les mêmes pour formater pour CSV par exemple.
Tout ce dont j'ai besoin, c'est des infos que je collecte via fetch_info. Les fonctions disp_* devront être différentes de toute façon.
En revanche, je pense que j'implémenterais tout ça dans des nouveaux fichiers. dfc.c ne devrait plus trop bouger à part pour des optimisations parce que je pense que toutes les fonctionnalités souhaitables sont implémentées.

grim7reaper · Le 31/03/2012, à 18:28

Oui, après ça dépend ce que tu veux faire, je suis parti du principe que dfc propose un type de sortie commun quelque soit le format de sortie choisi.
Tu veux dire quoi par

Rolinh a écrit :

Je ne suis pas sur que les besoins soit les mêmes pour formater pour CSV par exemple

?

Rolinh · Le 31/03/2012, à 18:39

Ce que je veux dire, c'est qu'il n'y a aucun ajustements à faire en fonction de la taille des noms, etc. On ne s'en occupe pas puisque pour ce format, les données sont séparées par des virgules. Cela change beaucoup de l'output en console.

grim7reaper · Le 31/03/2012, à 18:54

Où est le problème ?
Les fonctions csv_disp_* n’appelleront pas tes fonctions de troncature alors que les fonctions text_disp_* oui.

Rolinh · Le 31/03/2012, à 18:56

Ah oui tiens, j'ai dû mal comprendre (un comble!).

Tiens, je me posais une autre question: comment cela se passe-t-il pour traduire un programme comme dfc?

grim7reaper · Le 31/03/2012, à 18:59

gettext.
Pas trop le temps là, je détaille un peu plus tard si besoin

Rolinh · Le 31/03/2012, à 19:00

Tu m'as donné une piste. Normalement, ça devrait me suffire
Merci.

grim7reaper · Le 31/03/2012, à 19:20

Ok. Je pense aussi, c’est pas les ressources qui manquent.
Cela dit, si tu as des questions tu sais où les poser

Sinon, si tu es OK pour ma proposition de gestion des formats de sortie je peux déjà adapter le code existant (sortie console en texte simple) pour qu’il utilise cette architecture et te soumettre un patch.

Dernière modification par grim7reaper (Le 31/03/2012, à 19:25)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#426 Le 30/03/2012, à 00:08

Re : /* Topic des codeurs [7] */

#427 Le 30/03/2012, à 00:16

Re : /* Topic des codeurs [7] */

#428 Le 30/03/2012, à 02:59

Re : /* Topic des codeurs [7] */

#429 Le 30/03/2012, à 08:11

Re : /* Topic des codeurs [7] */

#430 Le 30/03/2012, à 09:27

Re : /* Topic des codeurs [7] */

#431 Le 30/03/2012, à 09:35

Re : /* Topic des codeurs [7] */

#432 Le 30/03/2012, à 15:28

Re : /* Topic des codeurs [7] */

#433 Le 30/03/2012, à 15:43

Re : /* Topic des codeurs [7] */

#434 Le 30/03/2012, à 16:52

Re : /* Topic des codeurs [7] */

#435 Le 30/03/2012, à 21:23

Re : /* Topic des codeurs [7] */

#436 Le 30/03/2012, à 21:34

Re : /* Topic des codeurs [7] */

#437 Le 31/03/2012, à 13:32

Re : /* Topic des codeurs [7] */

#438 Le 31/03/2012, à 15:08

Re : /* Topic des codeurs [7] */

#439 Le 31/03/2012, à 15:31

Re : /* Topic des codeurs [7] */

#440 Le 31/03/2012, à 15:49

Re : /* Topic des codeurs [7] */

#441 Le 31/03/2012, à 16:53

Re : /* Topic des codeurs [7] */

#442 Le 31/03/2012, à 17:49

Re : /* Topic des codeurs [7] */

#443 Le 31/03/2012, à 18:22

Re : /* Topic des codeurs [7] */

#444 Le 31/03/2012, à 18:28

Re : /* Topic des codeurs [7] */

#445 Le 31/03/2012, à 18:39

Re : /* Topic des codeurs [7] */

#446 Le 31/03/2012, à 18:54

Re : /* Topic des codeurs [7] */

#447 Le 31/03/2012, à 18:56

Re : /* Topic des codeurs [7] */

#448 Le 31/03/2012, à 18:59

Re : /* Topic des codeurs [7] */

#449 Le 31/03/2012, à 19:00

Re : /* Topic des codeurs [7] */

#450 Le 31/03/2012, à 19:20

Re : /* Topic des codeurs [7] */

Pied de page des forums