DK-

► FG (mini11) 1 ligne à ajouter (cas n°3 : comptes-doublons) • Herve (ref=4034) : doublon associé à Herv_ (ref=3619) déjà rattaché ► total = 25 lignes SOPIAX Herv_ rdbordon eurolidays bjaaland celina2 SDF SIRIUS GMcoeur kastel67 caroline Chris_21 -arno- Vinou chrysoberyl darthmanu PASCAL Je_Peux_Plier Pimprenelle PJ-BB Big_Ben sud BLASON nollyren_e Herve

► Zebulon (mini22) : la meilleure de toutes les miniteams 1 ligne à purger (cas n°1 : comptes introuvables) • _Doug (ref=18874) : encore un compte de Mortbise, mais à 0 pts donc supprimé par Stanford en 2018 4 lignes à ajouter ← à vérifier, mais cela a déjà dû être effectué fin 2017 • [AMD-Hardware.com]_amdlm (ref=275) : ralliement de RyzenX demandé en octobre 2017 auprès de Kana • brunold (ref=3) : ralliement demandé en novembre 2017 auprès de Kana • _Doug_ (ref=524) : correctif de fin 2017 par Kana pour un deuxième compte de notre Mortbise, le premier étant Doug (ref=868) qui était déjà correctement rattaché • [zebilon.fr]_reglyss-junior1 (ref=16297) : correctif de fin 2017 par Kana pour corriger l'erreur de libellé (zebilon) échappant au filtre. Rq : Brunold (avec majuscule) est l'état actuel du cfg, bien que ce soit brunold (sans majuscule) qui est mentionné dans les team51.txt de Stanford. Je laisse Kana décider s'il doit conserver cette majuscule ou la remplacer, j'avoue que je n'ai rien compris aux aventures de cette majuscule volatile... ► total = 11 lignes Benoist Zebulon84 Doug Bull45 OlivierZ [AF]Kyuzo R_34 [AMD-Hardware.com]_amdlm Brunold _Doug_ [zebilon.fr]_reglyss-junior1

► FOUCK (mini25) 1 ligne à ajouter ← à vérifier, mais cela a déjà dû être effectué fin 2017 • daturajd (ref=1103) : oubli de JGP ► total = 7 lignes blackestmajor ErrefferrE_[FR] turlupin Jacques_VALLOIS halo74 nechaophys daturajd

Voici à présent les 13 miniteams à cfg-Ajouts non vide mais inchangé. ► Suisse (mini4) : 4 lignes LostControl minos8 lulubal Heaven_or_Hell ► INpact (mini6) : 5 lignes Rabot carcasse Nistorm dragoonway sthire01 ► GNT (mini7) : 4 lignes mat21 Spyzer tornado2 METHODiK_M ► Nokytech (mini8) : 2 lignes silirius Faap ► LEENFAT (mini9) : 5 lignes linvisible BlindMan albatorcobra vince minusk ► Clubic (mini13) : 2 lignes [Nokytech]_Facedeharicot sentenza ► ENS-Cachan (mini14) : 2 lignes [PPC]_Valatar SStban ► RAH (mini15) : 1 ligne Bud ► GAH (mini17) : 11 lignes kokoyaya athropos_666 Slade HamBzH BilboX youen [clubic]_Lith! Jack82 Rock_Flavour plgeno missbunny ► 3dChips(mini19) : 4 lignes GeoFF cabane88 Sonic9 Noxukan ► UV (mini24) : 4 lignes paulatreides080269 CastorTroy Mec_sympa luluberlu ► PcPerf (mini26) : 2 lignes Foo_Fighters ElectriZ ► DoDFr (mini27) : 1 ligne TheJack200

Je commence mes listes et explications. Il y en a 29, que je vais donc répartir en plusieurs posts, alors siouplé ne postez pas au milieu... Je rappelle que pour chacune des 29 miniteams, je liste pour l'instant uniquement la partie Ajouts de son cfg, et en référence à son état de l'été 2017. Pour commencer doucement, voici les 9 miniteams à cfg-Ajouts précédemment vides et restant vides : ► KE (mini10) ► TSLN (mini12) ► PC-info (mini16) ► PCA (mini18) ► Cooling-Masters (mini20) ► QuaddXmas (mini21) ► AMD-Hardware (mini23) ► Techage (mini28) ► LesNumeriques (mini29)

Ok, merci à vous deux. J'appliquerai donc ces trois consignes pour finaliser les listes, ainsi que la précaution sur les id-kana au lieu des id-stanford, avant de convertir mes tableurs sous une forme présentable ici. La suite en fin d'aprèm.

Le blème, c'est que Stanford ne m'indique QUE les trois derniers chiffres de l'IP : https://apps.foldingathome.org/cpu Un modo pourrait peut-être s'assoir sur sa déontologie et comparer à celles qui arrivent sur Zeb...

Je suis sur la piste d'une IP Address : xxx.xxx.xxx.102 et de deux CPUid : 1DF7FA5BAE93BC80 et 1EF7FA5BAE93BC80.

En même temps, une telle puissance de feu, ça me rappelle kekchoz...

Et moi, même si tu en as douté, je me torture avec ce genre de trucs depuis 2 ans...

Non. Ce n'est pourtant pas déjà Noël, et pis de toute façon, je n'ai pas été si sage cette année... Mais compte sur moi, je vais mener mon enquête pour traquer l'angélique généreux. Je suppose que je peux rayer le Qurab de la liste des suspects ?

CORRECTIONS DE DEUXIÈME TYPE : corriger quelques vieilles erreurs dans les fichiers cfg hérités de JGP Ces erreurs datent de bien avant octobre 2017 (quelques unes avaient déjà été corrigées fin 2017, mais le traitement ébauché manquait de rigueur). Pour assainir la situation, j'ai, entre autres sources, relié aux cfg actuels toutes les demandes de rattachement du « Topic où l'on dit à JGP Soldat dans quelle division on veut être » sur le forum 2003-2017 de l'AF. Après examen dudit topic, je recense 227 (edit : rectif après recomptage) demandes valides de rattachement, qui devraient donc être inscrites, par ordre chronologique, dans la partie Ajouts du cfg de la miniteam de destination. Pour chacune des demandes validées par JGP (cf. sa clause de la « demande personnelle »), j'ai relevé dans mon tableur le numéro du ou des posts du topic la justifiant. Cependant, les cfg de 2017 comportaient déjà un grand nombre d'inscriptions non vérifiables par ce topic : il s'agit probablement de rattachements antérieurs à janvier 2003. Je suppose qu'un topic analogue existait sur le précédent forum (mesdiscussions.net chez les PPC), avant son crash qui a conduit à la création en 2003 (déjà par JWhy !) du forum dédié chez mesdiscussions.net. Malgré mes recherches, je ne suis pas parvenue à retrouver les messages, aussi dans le tableur j'ai signalé par un ? (au lieu d'un numéro de post) ces rattachements non vérifiables. NB : Pour ne pas surcharger notre présente discussion, j'enverrai le tableur récapitulant ces justifications sur le Casimages ou le Googledrive de Zebteam. Fin 2017, j'avais déjà entrepris une révision des cfg, mais faute d'un outil comme les dk-ref, je ne m'en sortais pas... Quelques modifs ont à l'époque déjà été appliquées à certains cfg par Kana, mais pour plus de clarté, je vais repartir de leur état d'octobre 2017 (c'est celui encore disponible sur fleucorp.net). Remarque : Certains plieurs ont été inscrits avec une casse différente de celle actuellement en vigueur, mais cela ne justifie pas de correction, du moins pour l'instant ; au cas où le besoin revienne, ceux-ci sont également signalés dans le tableur que j'archiverai chez Zebteam. Je propose de lister aujourd'hui, miniteam par miniteam, toutes les modifications à apporter dans la section Ajouts. On étudiera ensuite (demain ou plus tard) la pertinence des mots-clés, et en dernier les exclusions, càd la section Retraits. Mais auparavant, j'ai besoin qu'on décide d'une procédure pour chacun des trois cas suivants, qui se retrouvent dans de nombreux cas d'affectation. ► cas n°1 (comptes introuvables) : Que fait-on avec les inscriptions de comptes introuvables ? De nombreux comptes introuvables proviennent probablement de plieurs ayant bien formulé une demande de rattachement conforme et effectivement inscrite dans les Ajouts des cfg par JGP, mais quand ces plieurs - soit se sont totalement plantés dans le libellé leur identifiant lors de la demande de rattachement - soit n'ont finalement jamais plié sous le compte annoncé - soit n'ont plié que des wu à 0 pts et le compte concerné a donc depuis été supprimé par Stanford alors logiquement le compte annoncé est absent du team51.txt actuel. Doit-on purger les cfg de ces lignes de comptes inexistants ? ► cas n°2 (lignes redondantes) : Que fait-on avec les inscriptions en double ? Exemple : chez France, les plieurs AxelBSD et mahieu ont chacun formulé deux fois la même demande, deux fois inscrite dans le cfg parJGP. Il faut bien sûr conserver la première occurence de la demande, mais doit-on purger les cfg des lignes en double ? ► cas n°3 (comptes-doublons) : Que fait-on avec les comptes-doublons ? Exemple : olivier.dupre correspond à deux identifiants-stanford, différenciés par un suffixe de numérotation par le script de Kana : - olivier.dupre (ref=3787) - olivier.dupre (2) (ref=15457) Le plieur a demandé à être affecté à France, et la ligne olivier.dupre figure bien dans les Ajouts de France. Mais seul le premier des deux comptes-stanford est actuellement affecté à France, et l'autre reste non-associé. (je suppose que chez Kana, le script de renommage s'effectue AVANT celui de répartition). Considère-t-on : - que seul le rattachement du premier est justifié ? (auquel cas, on n'ajoute rien au cfg) - que tous les doublons devraient être rattachés ? (auquel cas il faudrait soit les inscrire avec leurs suffixes (2), (3) etc dans Ajouts de chaque cfg d'affectation, soit modifier l'ordre des scripts mais là je n'y connais que dalle...) Et enfin, une question uniquement à @Kana-chan : Dans ton traitement, il me semble que le renommage se fait AVANT la répartition, et c'est pourquoi je suppose que les listes doivent être rédigées avec les identifiants de TON team51.txt plutôt qu'avec ceux strictement conformes au team51.txt officiel de Stanford. Me trompé-je ? Voili voilou, je vous laisse le temps de répondre à mes quatre questions (les listes que je posterai dépendront évidemment des choix adoptés dans les cas n°1, 2 et 3 présentés ci-dessus, et de la méthode indiquée par Kana).

D'acc. Donc à demain (pas avant midi) pour la liste complète des Ajouts suite à une demande à JGP (ou à Kana).

Dire que je m'étais promis de surveiller l'heure ce soir...

Précision : pour les correctifs de type 2, les erreurs sur les cfg relèvent des cas suivants : - JGP a oublié la demande : à ajouter - JGP s'est trompé de miniteam : à corriger. - le plieur a renouvelé sa demande → doublon inutile : à supprimer (ou pas...) - le plieur a fait une demande mais le pseudo déclaré est introuvable dans la liste de tous les comptes, et aucun ne s'en approche : à supprimer (ou pas...) - le plieur a mal déclaré son pseudo → l'exception est inopérante : à corriger Concernant le dernier cas, la plupart des déclarations erronées sont dues à une erreur de casse, qui était alors en vigueur. Désormais ces erreurs ne sont plus préjudiciables, et se sont automatiquement corrigées quand Kana a aboli la casse dans son script. Ces erreurs de casse ne sont peut-être pas toutes imputables au plieur ou à JGP, il semble que Stanford ait déjà joué avec ça, en particulier avec les caractères spéciaux. Pour preuve, ces exemples de « doublons » provenant probablement d'un seul compte initialement : - Hervé → Herv_ et Herve - jéjé → j_j_ et jeje - François_Duchesne → Fran_ois_Duchesne et Francois_Duchesne - Maïté → Ma_t_ et Maite - les comptes comportant Québec → Qu_bec et Quebec - les comptes comportant Montréal → Montr_al et Montreal Il y a aussi probablement eu des bizarreries avec des comptes comportant le caractère @ (ou encore #, et sans doute aussi d'autres caractères spéciaux) qui, une fois tronqués par Stanford, ont produit autant de doublons apparents. Par exemple, le compte T actuellement 24ème de l'AF (réf=11) est à l'origine un user [email protected], et probablement que ses doublons (ref 641 et 15581) sont aussi des déclinaisons de ce [email protected]. De même, les multiples Paul relèvent probablement de ce genre de troncature, et les autres doublons également. D'où la nécessité de traiter rigoureusement les demandes de rattachement, afin de récupérer aussi les comptes artificiellement créés ou modifiés par Stanford, à l'insu du plieur.

Je suis bien d'accord, et je te répète que j'en rajouterai une couche dans le tuto pour dissuader les nouveaux d'utiliser d'autres caractères spéciaux que ceux que tu cites. Mais si je te pose la question, c'est précisément pour savoir s'il est possible d'envisager un filtre du type >France afin de cibler des pseudos DÉJÀ EXISTANTS, car 16 pseudos contiennent cette séquence. Si non, ces 16 là seront à inscrire dans les Ajouts. @nthor : Je finis de construire la liste des rapatriements liés aux demandes validées sur le topic de JGP dans l'ancien forum de l'AF (parce qu'il y a eu certaines erreurs, que je n'ai pas toutes déjà corrigées fin 2017). Ceci afin de vérifier les Ajouts/Retraits de tous les cfg (correctifs type 2). Ensuite, par miniteam, on listera tous les noms à affecter afin d'affiner les filtres, de façon à avoir le moins possible d'exceptions dans les Ajouts/Retraits (correctifs type 3). Ça te convient comme méthode ?

178 avec Calc. Le truc, c'est de gérer conjointement tous les filtres... Petite question à @Kana-chan : un filtre contenant >France, ça va coincer (à cause du caractère > que tu adores) ?

Moui, je suis assez d'accord avec Nthor. D'ailleurs il faut que je pense à modifier le tuto d'instal : pour les nouveaux plieurs, je vais insister sur le respect des balises précisées, en particulier les crochets [xxx] : ça serait tellement simple si tout le monde savait lire... Sinon, le déplacement que je devais faire dans deux jours vient juste d'être reporté (en raison des grèves probables), je suis donc un peu moins pressée de boucler les cfg, d'autant plus que là tout de suite, j'ai une montagne de trucs à régler concernant ce report. Du coup je prendrai demain le temps de tester les deux méthodes pour la balise _FR, afin de comparer les nombres d'inscriptions que chacune nécessite. De retour ce soir.

Possible, mais je ne parierai pas là-dessus ! Tu as sans doute raison pour les associés, mais il reste tous les autres, soit la moitié de l'AF. De toute façon, quelque soit l'option choisie, tu auras à compléter de temps en temps les exceptions du cfg de France, en surveillant la destination des nouveaux comptes. C'est ok pour toi ?

PS : je reviens ce soir avec un pavé sur les bourdes de JGP (= correctifs de type 2).

Et ce n'est pas le seul.... RETOUR AUX CORRECTIFS DE PREMIER TYPE Pb (a1) et (b1) : Pour résoudre ce binz dû au filtre _FR du cfg de France, qui ramène illégitimement trop de comptes, il faudra donc : - soit conserver ce filtre, et inscrire tous les noms du (a1) et du (b1) dans la section Retraits du cfg - soit virer ce filtre, et déclarer plein de noms légitimes (ex : Booba_FR) dans la section Ajouts. Quelle que soit l'option choisie, pour les futurs nouveaux comptes comportant cette séquence, il faudra poursuivre la liste des exceptions en fonction de la destination supposée du plieur. L'alternative n'est pas très réjouissante, et je veux bien un avis sur la solution à choisir. Pb (a2), (b2) et (b3) avec les filtres Paris et hfr de France : le même genre de choix serait possible, mais là je pense qu'il est plus logique de simplement conserver ces filtres en inscrivant ces trois seuls comptes pour l'instant concernés dans les Retraits de France. Pb (a3) avec le filtre QC de Quebec : idem, je propose aussi la conservation du filtre et l'inscription des deux seuls comptes problématiques en Retraits de Quebec Rq : j'ai vérifié dans mes plus anciens les miniteam.txt (d'avant octobre 2018) que ces deux comptes étaient bien (uniquement) : 5916 (PPC)ppattqc → dans PPC 12074 [Inpact]_PhoenixQc → dans Inpact Et pour (c1) et (c2), on conserve telles quelles les inscriptions de JGP (confirmées par une vérif dans d'anciens miniteam.txt) 6736 [Inpact]_Richman_(Quebec) → dans Quebec 11971 [Inpact]_France → dans Inpact Question n°2 : Concernant le filtre _FR, on choisit quelle option ? J'ai besoin d'une décision pour poursuivre la définition des cfg.

Tout de même, c'est juste une initiative de JGP, il n'y a de trace nulle part de demande de la part des plieurs ! Et il y a des dizaines de cas de ce type, la majorité des exclusions dans les cfg relèvent de la même situation, et je suppose qu'en tel cas de conflit entre plusieurs miniteams, il favorisait la première dans l'ordre de rédaction de l'identifiant. Bref, sauf si je remets vite la main sur de vieux fichiers de miniteams.txt invalidant cette option, on conservera ce qui est écrit dans les exclusions des cfg, qu'importe d'où ça sort.

Pff, oui, grosse faaaatigue... Merci. Et justement je viens juste de retrouver le post-it où j'avais résolu cette question ! Donc ok pour (c1) et (c2). (a3) : Je dois encore rechercher si j'ai des vieux txt des miniteams, d'avant la modif de la casse, pourvoir comment c'était réparti avant. Mais si je ne trouve pas, on gardera comme ça : 5916 (PPC)ppattqc → dans PPC 12074 [Inpact]_PhoenixQc → dans Inpact (b1) : 14542 [INnpact]_FRANCK Non, pour l'instant, il est bien dans France. À tort, évidemment. Autrement dit, si on ne lui applique pas le filtre _FR, il redeviendra non-associé. Mais vu le INnpact (un n de trop) il est manifeste que le plieur voulait rallier Inpact : on corrigera ça dans l'étape 3, demain ou vendredi.

@nthor : Ci-dessus la liste complète des corrections de type 1. Je veux bien que tu vérifies, et que tu me donnes ton avis. Je prépare pour ce soir un post pour les corrections de type 2. Celles de type 3 seront probablement pour demain, et c'est surtout là que j'aurai besoin d'avis. Ensuite seulement, je pourrai finaliser les cfg pour les filer à Kana.

Vous aussi vous m'avez manqué... mais parfois l'irl est parfois intraitable, et la 4G défaillante. Suis à peine de retour, je n'ai même pas le temps de lire tous les topics en retard, car je suis overbookée et je dois encore m'absenter dès ce weekend. Mais je serai là en fin de semaine prochaine, pour les bûches de Noël.