IRC stats

[CrazyCat]

J'ai démarré ce projet il y a peu de temps, en réfléchissant à la refonte du site de zeolia.net.
En effet, j'ai constaté que les pages de statistiques des canaux n'étaient pas compatibles avec les appareils mobiles, pisg commençant à dater légèrement.

Mon idée est donc de stocker directement en base de données l'activité d'un canal, avec parfois certains pré-calculs (comme le nombre de mots d'une ligne) afin de pouvoir les exploiter plus simplement qu'en ayant à parser les fichiers logs.

La source (en cours d'évolution) se trouve sur gitlab.

Pré-requis
Outre un eggdrop, il faut:

• le package mysqltcl (et donc un serveur MySQL quelque part). Au départ je pensais faire un système plus portable avec sqlite3 mais si plusieurs eggdrops doivent alimenter le système, cela pose des problèmes de lock
  
• optionnellement le package hook pour que le script puisse être appelé par d'autres scripts.
  

Fonctionnement
Le script fonctionne de manière très basique en enregistrant les pub/action/join/part/quit/nick/topic/kick ainsi que le nombre de mots (après avoir supprimé tous les codes et les caractères non-alphanumériques ou non-espaces).
Avec les eggdrops récents et si le réseau le permet (et que l'utilisateur est enregistré auprès des services), c'est le nom du compte de l'utilisateur sur les services plutôt que son nick qui est enregistré, ce qui permettra à terme de limiter la consommation du nick-tracking (qui sera dans le script plutôt qu'en post-analyse).

Et pour des raisons de RGPD, seules les infos essentielles aux stats sont enregistrées, pas de host, d'IP ou quoi que ce soit pouvant ressembler à une donnée personnelle.

Notas

• Le script est dans le projet "ChanRelay" car bien qu'il soit totalement autonome, il me sert aussi de plugin pour ChanRelay 5 (log des canaux distants dans le meta-canal), c'est d'ailleurs la raison d'être de l'utilisation des hooks.
  
• Le modèle de la base de données sera fourni assez rapidement, avec les vues associées
  

Ce script est très simple, l'intérêt du projet sera surtout sur le front-end

[MenzAgitat]

Le script fonctionne de manière très basique en enregistrant les pub/action/join/part/quit/nick/topic/kick ainsi que le nombre de mots (après avoir supprimé tous les codes et les caractères non-alphanumériques ou espaces).

Ca va être plus simple comme ça, le nombre de mots sera toujours 1 si tu supprimes tous les espaces.

[CrazyCat]

Bien vu, corrigé en non-espaces :)

[ZarTek]

J'ai regardé le code de chanrelay/statirc.tcl c'est un code propre et claire.

J'aime bien l'idée des hooks lorsque le package est chargé. Ca laisse la possibilité a des utilisations plus large.

---

Je me demandais si c'étais volontaire d'avoir

Code:

    if {[string match -nocase *account-notify* [cap ls]]} {
        cap req account-notify
    }

et ensuite de recharger le cap req account-notify dans la procedure:

Code:

    proc init {} {
        if {![string match *account-notify* [cap enabled]] && [string match -nocase *account-notify* [cap ls]]} {
            cap req account-notify
        }
        array set ::statirc::dbconn $::statirc::db
    }

Je vois ca ici https://gitlab.com/tcl-scripts/chanrelay...rc.tcl#L33 et j'ai l'impression que c'est redondant ?

---

je remarque l'utilisation de  [clock seconds] en plus de [clock format ..]  Je ne sais pas si y a une raison particulière a utiliser  comme ceci :

Code:

[clock format [clock seconds] -format "%G-%m-%d %T"]

car  strftime  est plus court, plus lisible, et plus rapide :

Code:

[strftime "%G-%m-%d %T"]

J'ai fait un teste sur un millions d'itérations entre les deux et la moyenne est :
51.246017 microseconds per iteration pour

Code:

[clock format [clock seconds] -format "%G-%m-%d %T"]

et
32.350437 microseconds per iteration pour

Code:

[strftime "%G-%m-%d %T"]

---

Pour la  procédure

Code:

canlog

elle retourne 0 ou 1 (valeur booléenne), il peut être utiliser comme condition booléenne de ce fait. (ou pas)

Code:

if {[::statirc::canlog $chan $nick]==1} { ... }

Code:

if {[::statirc::canlog $chan $nick]} { .. }

---

Je le réécris , je trouve que c'est du beau boulot.

[CrazyCat]

Je me demandais si c'étais volontaire d'avoir

Code:

    if {[string match -nocase *account-notify* [cap ls]]} {
        cap req account-notify
    }

et ensuite de recharger le cap req account-notify dans la procedure:

Code:

    proc init {} {
        if {![string match *account-notify* [cap enabled]] && [string match -nocase *account-notify* [cap ls]]} {
            cap req account-notify
        }
        array set ::statirc::dbconn $::statirc::db
    }

Je vois ca ici https://gitlab.com/tcl-scripts/chanrelay...rc.tcl#L33 et j'ai l'impression que c'est redondant ?

Effectivement le chargement initial est une scorie de mes tests, mais ce n'est pas un script finalisé.

je remarque l'utilisation de  [clock seconds] en plus de [clock format ..]  Je ne sais pas si y a une raison particulière a utiliser  comme ceci :

Code:

[clock format [clock seconds] -format "%G-%m-%d %T"]

car  strftime  est plus court, plus lisible, et plus rapide :

Code:

[strftime "%G-%m-%d %T"]

J'ai fait un teste sur un millions d'itérations entre les deux et la moyenne est :
51.246017 microseconds per iteration pour

Code:

[clock format [clock seconds] -format "%G-%m-%d %T"]

et
32.350437 microseconds per iteration pour

Code:

[strftime "%G-%m-%d %T"]

Aucune raison particulière hormis l'habitude

Pour la  procédure

Code:

canlog

elle retourne 0 ou 1 (valeur booléenne), il peut être utiliser comme condition booléenne de ce fait. (ou pas)

Code:

if {[::statirc::canlog $chan $nick]==1} { ... }

Code:

if {[::statirc::canlog $chan $nick]} { .. }

Aucun changement au niveau des performances, mais comme je ne retourne pas un true/false, je peux potentiellement retourner une valeur autre que binaire et exploitable. Et je dirais même plus, le === me manque même si dans le cas de ce script, on a pas besoin de conditions fortes.