chimrod a écrit 1073 commentaires

Il semblerait que le site ait été racheté : http://bmpx.backtrace.info/ .

Je ne vois pas de trace du code sur github… ça semble mort !

Pourquoi pas ~/.x-blasterdominator histoire de faire comme tout le monde? (Sans parler du coté binaire des fichiers de config…)

Pitié ! Un standard existe, autant l'utiliser !!

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

J'utilise sieve pour trier les courriers et les placer dans les bons répertoires. Avant je passais par procmail mais les règles étaient compliquées et sieve a davantage de paramètres.

Je me suis aussi fait un petit script python qui me supprime les mails lu de plus 30 jours qui ne sont pas marqués important, histoire de faire le ménage : à part mon dossier personnel, qui contient les échanges « humains », tous les mails de mailing list, cron, rss, sont purgés au bout d'un moment. Je ne rencontre pas trop de problème avec les mails au final, j'ai même choisi de recevoir mes flux rss directement dans mes mails.

Tout ça est facilité par le fait que j'administre mon propre serveur mail (auto hébergement).

Ça c'est pour le côté historique, du côté pratique, est-on aussi libre sous tizen que maemo (j'ai un n900) :

• un vrai terminal et pas une émulation
• installer gcc et compiler ses propres applis directement sur le téléphone ?
• pouvoir installer un chroot ?
• installer openssh ?

J'ai peur que la politique de sécurité m'empêche de mettre les mains dans le système comme je le souhaite…

Que je sois un nœud de sortie ou non, l'usage qui sera fait des données qui transitent reste le même.

Je me souviens, au moment où j'ai commencé l'autohébergement, Tor m'a fait plonger dans l'administration du système : j'ai rapidement su maitriser fail2ban, iptable et apache mod security ; visiblement, il doit y avoir des scripts qui scannent les ips des nœuds de sortie de Tor pour y tester toutes les failles de sécurité possible. Je pense qu'aujourd'hui ça n'a pas du aller en s'améliorant.

Aujourd'hui je ne conseillerai pas l'installation d'un serveur Tor à quelqu'un qui ne maitrise pas son système, c'est vraiment jouer avec le feu.

Je l'ai fait, il y a 4 ou 5 ans je ne sais plus trop…

Aujourd'hui mon ip est encore bannie de 4chan, et je ne sais pas à quoi d'autre ma connexion internet à servi.

J'ai arrêté le jour où j'ai sniffé les connexions qui sortaient de mon réseau : ça n'était que des tentatives de connexion sur des forums ou des comptes mail yahoo, je ne voyais pas l’intérêt d'encourager ça.

Maintenant je préfère plutôt freenet (le contenu est tout autant discutable, mais comme il n'y a pas d'interaction possible avec le web, ça fait un bon un compromis entre anonymat et illégalité ).

J'ai tout d'abord été gêné par le côté promotionnel de la dépêche, qui donne l'impression d'un service gratuit basé sur des ll. En allant voir les sources, je vois que la page github explique comment l'installer chez soi, ce qui ne m'a pas paru évident à la lecture de la dépêche, mais me convient parfaitement.

À tester et pour donner sa chance au produit !

C'est lumineux !

Basé sur le simulateur d'asi77 : asi77.free.fr

Bref on tourne en boucle…

Mais c'est vrai aussi que des traitements parallèle de data pourrait être sympa (map fold/reduce en multicpu).

Il y a parmap qui fait ça (mais avec des bindings C, on n'est plus dans Ocaml pur).

Peut être est-ce la création de Ocaml pro ?

En fait, j'ai l'impression que le langage commence à monter son propre environnement : Gestionnaire de paquets, librairies avancées, ce qui manquait pour sortir d'un simple langage théorique. Il reste encore beaucoup à faire (compiler sous windows reste encore une épreuve), mais ça commence à bouger. Je ne connais pas assez Ocaml pro pour savoir s'ils accompagnent le mouvement ou s'ils donnent une nouvelle dynamique.

Ocaml est plombé par la gestion des threads. Il n'est pas possible de faire de code multithreadé en ocaml, à cause du garbage collector.

Des tentatives pour compiler une version compatible ont été tentées (oc4mc), mais n'ont jamais été intégrées dans la branche principale, et ne le seront jamais (des messages sur la ml que je ne retrouve plus en écrivant ce post disent en gros que des solutions pour faire du calcul distribué existent et fonctionnent bien, gérer plusieurs processus nativement n'est donc pas à l'ordre du jour).

C'est un peu le problème qu'avait rencontré python il y a quelques années, mais avait réussi à s'en sortir.

En dehors de ça, j'ai l'impression que le langage Ocaml recommence à faire parler de lui, après quelques années en sommeil. Un regain pour le fonctionnel ?

C'est toi ?

D'un côté je peux comprendre, visiblement tout le monde trouve ça intéressant, ce qui explique la note du journal et de la dépêche, d'un autre côté, à part enchérir sur ce côté nostalgique (que tout le monde ici n'a pas forcément connu), je pense que ça doit être difficile de réagir.

Le livre m'a fait aussi ressortir tous ces souvenirs, et je me suis rendu compte qu'à côté de cette scène francophone (n'oublions pas les québécois), il y a eu une scène internationale, toute aussi active. C'était sûrement plus difficile à l'époque d'échanger, internet n'étais pas aussi développé (et pour cause !), et la jeunesse des acteurs fait qu'ils ont surtout échangé dans leur langue maternelle ce qui a créé des communautés locales.

Ce que je trouve étrange, c'est qu'il n'y ait pas eu plus d'analyse de cette scène. Pour avoir mis un pied dans la socio (courant post-moderne toussa), je pense qu'il y aurait matière à analyser dans ces histoires.

Non je n'ai pas lu d'autres livres qui analysent ce thème. Mais j'espère qu'ici il y ait certains lecteurs qui ont des choses à apporter ?

Je comprend que lorsqu'on écrit un journal qui parle d'une émission de radio, on répond qu'il y a peu de commentaires et c'est normal car ça n'est pas pratique à écouter. Par contre ici, les textes sont disponibles; si certains ont des retours à faire, c'est l'occasion de le faire !

ça fait un petit moment que le développement ne bouge plus (quasi 2 ans).

J'utilise feed2imap en maildir depuis un petit moment déjà (2 ans ?). J'ai rencontré un problème lors de la republication d'un élément et ai pris le temps d'écrire un correctif pour ça. Je n'ai pas eu de réponse à mon message sur la ML, par contre ma demande de pull a été acceptée au bout de qques mois.

Depuis tout tourne parfaitement, et je n'ai pas besoin de voir le développement évoluer.

il ne fonctionnerait pas bien avec ruby 1.9…

Aucune idée, j'utilise la version du trunk et n'ai pas rencontré de problème :

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

Voila l'article qui me l'avait fait découvrir (via le planet-libre)

De mon côté j'utilise feed2imap, il permet de synchroniser les flux rss avec un compte imap (ou un maildir si il tourne sur la machine du serveur mail).

Je n'ai donc pas à me soucier de synchroniser les flux lus, non lus, puisqu'ils s'agit de mails comme les autres — cerise sur le gâteau, il m'arrive même de transférer un article par mail si je pense qu'il peut intéresser d'autres personnes.

Je n'ai pas de lecteur dédié pour lire mes flux, thunderbird le plus souvent.

Pour t'aider :

https://www.youtube.com/watch?v=8yapXaWsZ9g

Pour appuyer ta réponse, j'ajouterai que l'inférence de type se fait sur les signatures, pas sur l'implémentation de celles-ci.

Donc quand tu as :

module type Ai =
  sig
    type a
    type b
    val f : b -> a
  end

L'implémentation de a et b est masquée, et leur type n'est pas déterminé; il s'agit d'un nouveau type que tu viens de créer, et non pas une appellation différente d'un type existant.

C'est utile si tu veux masquer l'implémentation d'un type. Par exemple, ton set a pour type t et tu n'as pas à savoir comment il est implémenté dans ton module. Tu n'as pas besoin de savoir que t est implémenté comme suit :

  type 'a set =
    | Empty
    | Node of 'a set * 'a * 'a set * int

et le compilateur tu génèrera une erreur si tu passes ton tupple là où il fallait passer le type de ton set.

Donc : utiliser les type de module c'est bien, ça permet de créer des foncteurs partageant les même types, et simplifier la documentation. Par contre, réduire une module à un type, c'est mal, ça casse l'inférence de type, il vaut mieux laisser le compilateur inférer pour toi les types de ton module.

Pour conclure, je remercie mon cursus pour ses cours d'épistémologie :)

C'est un domaine qui m'a toujours intéressé, mais qui n'est pas facile à aborder; je ne sais pas trop par où commencer… Est-ce que tu connais un bouquin d'introduction à l'epistémologie ? Pour avoir une idée des courant et les différentes pensées : Popper, Lakatos, Kuhn etc. ?

Si tu utilises un langage de programmation fonctionnelle, pas trop, puisque l'opérateur de pipe est un opérateur de composition de fonctions (avec un sens de lecture inversé).

J'ai pris l'habitude d'utiliser le |> de batteries qui permet de composer les fonctions de cette manière.

Par contre il faut reconnaître que l'on ne voit pas souvent de composition de fonction dans les langages non fonctionnels (ok, python est un peu à part), et c'est dommage. C'est dans ce sens ou je dis que ça change la manière d'écrire le code, on change de paradigme : on n'est plus en train d'appliquer une méthode à objet, mais on prend un objet dans un contexte, et on lui applique une série de traitement pour le transformer en un autre objet.

Bon je m'arrête là car ça n'est pas le sujet de la dépêche, et l'on parle de la même chose…

En fait, si on prend l'exemple des listes donné dans la dépêche, la syntaxe en pipe est plutôt équivalente à :

operation3 ( operation2 ( operation1 ( data ) ) )

et là, la différence est claire, les pipes sont beaucoup plus lisibles pour moi…

Je n'ai pas vu dans la doc si c'étais lazy ou non (c'est à dire, comme dans vrai pipe unix, attend que la sortie soit traitée avant de prendre la prochaine entrée).

En tout cas l'utilisation du | pour traiter les données en séquence est vraiment bien trouvée, ça fait partie des choses qui changent la manière dont on écrit le code…

Yeeeahh !

Je viens de tester et la compilation passe ! Merci beaucoup, j'aurai jamais pensé à ça…

Elles diffèrent, bien évidement !

Dans poker_defs.h (le source est ici):

#undef USE_INT64
#ifdef HAVE_UINT64_T
typedef uint64_t        uint64;
#define USE_INT64 1
#elif defined(HAVE_LONG_LONG)
typedef unsigned long long      uint64;
#define USE_INT64 1
#elif SIZEOF_LONG == 8
typedef unsigned long           uint64;
#define USE_INT64 1
#elif defined(UINT64_TYPE)
typedef UINT64_TYPE             uint64;
#define USE_INT64 1
#endif

et pour ocaml (j'ai pas trouvé de source en ligne ):

#if SIZEOF_INT == 4
typedef int int32;
typedef unsigned int uint32;
#define ARCH_INT32_PRINTF_FORMAT ""
#elif SIZEOF_LONG == 4
typedef long int32;
typedef unsigned long uint32;
#define ARCH_INT32_PRINTF_FORMAT "l"
#elif SIZEOF_SHORT == 4
typedef short int32;
typedef unsigned short uint32;
#define ARCH_INT32_PRINTF_FORMAT ""
#else
#error "No 32-bit integer type available"
#endif

#if defined(ARCH_INT64_TYPE)
typedef ARCH_INT64_TYPE int64;
typedef ARCH_UINT64_TYPE uint64;
#else
#  ifdef ARCH_BIG_ENDIAN
typedef struct { uint32 h, l; } uint64, int64;
#  else
typedef struct { uint32 l, h; } uint64, int64;
#  endif
#endif

Est-ce que ce genre d'incompatibilité arrive souvent ? Est-ce un bug ?

note : sur la capture, je ne sais pas d'où viens le rectangle noir (problème d'import ?), et j'ai voulu faire vite : je ne vais pas passer ma soirée devant le PC.

Sur ce, bon réveillon !