Je ne vais pas m’étendre sur les nouveautés, elles sont toutes listées sur le site web.

Pour ceux que ça intéresse, je compte rajouter pas mal de tutos sur ce blog dans les prochaines semaines. Ca sera en grande partie des explications sur les nouveautés, et une reprise du fichier d’aide, vu que les gens lisent les blogs, mais pas l’aide intégrée … :p

Amusez-vous bien avec cette nouvelle version, et n’hésitez pas à passer sur le forum pour signaler tout problème, ou laisser des encouragements.

Et si le coeur vous en dit, un petit don via Paypal, ça fait toujours plaisir.

PS : Cet article n’apparait que maintenant, car j’ai eu un gros crash sur la Base de Données du blog …

Bill2’s Process Manager v3.4 devrait donc sortir vendredi 6 Novembre 2009, ou au pire, dans le Week-end.

Alors, pressés d’essayer cette nouvelle mouture ?

Au passage, j’ai mis à jour le fichier d’aide (qu’il me faudra encore relire), et j’ai commencé à bosser sur le site web, en vue de la publication de la v3.4, qui devrait donc arriver fin Octobre / début Novembre 2009, si tout va bien.

Je suis satisfait du résultat, même si sur l’ordi de ma femme, le programme plante parfois sans raison : juste Windows Vista qui indique que BPM a « cessé de fonctionner »   Super pratique à corriger comme bug !

Quoi qu’il en soit, cette version va en ravir plus d’un, du moins, je l’espère.

Depuis fin Septembre, j’ai fini de bosser sur la Beta 7, qui comporte toutes les nouvelles fonctions, et dont le développement devait servir à régler les derniers problèmes.
Du coup, les fichiers sont partis vers certains traducteurs, et de mon côté, en cherchant à optimiser le programme, j’ai encore trouvé quelques bugs (dont certains très gros !)

Je suis en bonne voie vers la version « RC1″, qui incorpore déjà une nouvelle traduction en  … japonais
Mais il faut vraiment que je me motive pour le fichier d’aide par contre …

La Beta 6 a été testé avec succès pour tout ce qui concerne les fonctions touchant aux processeurs HT, et une préversion de la Beta 7 est en cours de test.
Cette dernière doit normalement corriger les rares cas de crashs que certains utilisateurs ont eu lors de la sauvegardes des options et/ou des règles, ou encore lors de la création du fichier « running.txt », utilisé pour gérer le multi-utilisateur et les instances uniques.

La relecture de la partie française est en cours, mais je cherche toujours un testeur « fort en anglais », qui pourrait corriger la traduction, avant que j’envoi le tout vers d’autres « pays » … Avis aux amateurs.

Bon, il me reste à bosser en parallèle sur le fichier d’aide et la mise à jour du site Web.
Je reste confiant pour une sortie durant le courant d’octobre 2009.

En gros, le but du jeu, c’est d’être averti par une info bulle lorsque le taux d’utilisation d’un CPU dépasse un certain seuil.
Est-ce que ça va vous servir ? Ou est-ce qu’il faudrait plus de possibilités ?

Si personne ne souhaite voir ce genre de fonction, alors ça va me permettre de « gagner du temps ».
En effet, j’attends d’avoir terminé l’intégration de toutes les fonctionnalités et nouveautés, pour envoyer les fichiers à traduire.
Vu qu’il y a pas mal de boulot, je n’ai pas envie d’envoyer des « mises à jour » aux traducteurs, ils auront déjà bien assez de travail à fournir.

Alors, quel est votre avis : est-ce que des fonctions de surveillance des taux CPU doivent être intégrées rapidement ?

La colonne règle n'indique pas les bonnes valeurs

En configurant mon nouvel ordi au boulot, j’ai tout de suite commencé par installer BPM v3.3.1.2, et créer quelques groupes et règles.
C’est ainsi que je suis tombé sur un petit bug, qui ne bloque absolument pas le programme, et qui fausse simplement les statistiques.

En effet, la colonne « règles » m’affichait des informations érronnées, car en ayant simplement configuré des règles avec « actions spéciales », j’avais des règles qui étaient indiquées.
Le bug est « simple » : le système ne tiens pas compte du fait que la case « Définir l’affinité » est activée ou pas dans la règle !
Et comme chaque règle définit par défaut l’affinité sur au moins un processeur, le calcul est donc faussé.

La résolution du problème sera assez simple, et j’en profiterai pour vérifier que la recherche des règles correspondantes retourne elle aussi les bons résultats.
Toutes les corrections seront présentes dans la prochaine version 3.4.0.0.

Petit Edit : d’ailleurs, si vous avez repéré d’autres bugs dans les stats, ou si vous voulez voir apparaitre de nouvelles infos, n’hésitez pas à m’en faire part.
Et comme je le disais dans mon précédent article, les stats intègrent déjà un nouvel onglet, dont je ne dévoilerais pas la fonction pour l’instant

Au passage, j’ai paufiné les nouvelles fonctions ajoutées dans les beta précédentes.
Cette version est parfaitement utilisable. En effet, j’ai maintenant pris l’habitude de travailler chaque nouvelle fonction jusqu’au bout : tant qu’une nouveauté n’est pas stable, la beta n’est pas terminée.
Ensuite viennent les détails, que je règle avec les betas suivantes. Ce qui me permet, à chaque nouvelle étape de travailler uniquement deux points : l’intégration d’une nouvelle fonction, et la finalisation des précédents ajouts.

Mais j’ai encore du travail. Est-ce que ça vous intéresserait de pouvoir personnaliser un peu plus la fenêtre principale, et d’avoir un meilleur choix des informations affichées ?

Ca sera justement l’objet de la prochaine Beta.
A moins que je ne m’occupe dès maintenant de la fonction de mise en pause des processus …

Mais je me suis aperçu qu’actuellement, seules 2 couleurs sont réellement utiles : 

- les processus non gérables (en rouge)
- les processus dont la priorité a été diminuée automatiquement (en jaune)

Je pense que d’avoir utiliser des couleurs pour différencier les règles « simples » et « avancées » n’était pas un bonne idée.
En effet, qu’un processus n’ait pas la même priorité suivant l’état de la fenêtre n’est sans doute pas l’info la plus pertinance.
En revanche, savoir si un processus est affecté par une règle avec répartition automatique de la charge (affinité), ou alors si il a seulement des actions spéciales, ça peut être utile.

Tout ça pour dire que je compte supprimer les couleurs correspondant aux règles « simples » et « avancées », en n’utilisant qu’une seule couleur pour les règles avec définition de priorité et affinité.
Pour être honnête, j’ai surtout besoin de pouvoir gérer « facilement » une couleur de plus pour une des nouvelles fonctionnalités que je suis en train de mettre en place. Et multiplier le nombre de couleurs est rarement un choix judicieux. Donc je pense tout simplement « simplifier » et « diminuer » le nombre de couleurs.

Alors avant d’aller plus loin, j’aimerai avoir vos avis, et surtout connaître vos habitudes d’utilisation : quels sont, à votre avis, les processus qui nécessitent le plus une mise en avant via une couleur spécifique ?
N’hésitez-pas à me proposer des « types » processus auxquels je n’aurais pas pensé (sauf les « services », je n’ai pas encore de moyen fiable et simple pour les détecter …)

• gestion de l’HT dans les graphiques de perf (identification des CPU)
• Indentification des CPU HT dans les Stats
• Affichage de l’affinité qui indique les CPU HT

La Beta 3 se dote aussi de nouvelles fonctions de « recherche ». Je n’en dis pas plus pour le moment, mais vous verrez, à l’usage, c’est très pratique lorsqu’on cherche une règle ou un processus en particulier.