[Appel au test] Refactoring des TimeSpec de Linknx
20 views
Skip to first unread message
Cyrille Defranoux
Jan 20, 2019, 11:00:39 AM1/20/19
to Eibd / Linknx / KnxWeb
Bonjour à tous,
Après de nombreux week-ends d'effort et de longues discussions par email avec Othmar qui m'a aidé à trouver la bonne solution et que je remercie vivement ici, j'ai enfin une version fonctionnelle.
Cette zone de code étant critique pour le fonctionnement de linknx, j'y suis allé avec la plus grande prudence. Je me suis appuyé sur les tests unitaires implémentés par le passé pour m'assurer que je n'avais rien cassé. Mais la base de tests ne couvre certainement pas tous les cas possibles, aussi je sollicite l'aide des volontaires sur ce forum pour tester cette nouvelle version avec leur propre configuration afin de vérifier que tout se passe bien.
Ceux qui le souhaitent peuvent aussi relire et commenter la pull request en cours : https://github.com/linknx/linknx/pull/39
Enfin, je précise que cette nouvelle version a modifié le comportement sur certains cas obscurs :
- la prochaine occurrence d'un 29 février après le 29/02/2016 est désormais le 29/02/2020 qui correspond à la prochaine année bissextile. Auparavant, c'était le 01/03/2017 qui était sélectionné (notez la translation sur le mois suivant). Je pense que le nouveau comportement est plus intuitif !
Suite à un retour de bug remonté par le forum allemand en fin d'année dernière, j'ai procédé à une réécriture importante du code qui calcule la prochaine occurrence d'une règle. La décision de cette réécriture a été prise du fait de la complexité de cette zone de code. Elle contenait de nombreuses subtilités piégeuses et la logique même du calcul était inutilement complexe. Le code de la branche master contient déjà une correction temporaire du bug initial mais il s'agit plus d'un pansement que d'une véritable correction.
Après de nombreux week-ends d'effort et de longues discussions par email avec Othmar qui m'a aidé à trouver la bonne solution et que je remercie vivement ici, j'ai enfin une version fonctionnelle.
Cette zone de code étant critique pour le fonctionnement de linknx, j'y suis allé avec la plus grande prudence. Je me suis appuyé sur les tests unitaires implémentés par le passé pour m'assurer que je n'avais rien cassé. Mais la base de tests ne couvre certainement pas tous les cas possibles, aussi je sollicite l'aide des volontaires sur ce forum pour tester cette nouvelle version avec leur propre configuration afin de vérifier que tout se passe bien.
Pour contribuer à cette phase de test :
- téléchargez le code source sur la branche periodictask_rework2 : https://github.com/linknx/linknx/archive/periodictask_rework2.zip (Attention à ne pas prendre la branche master puisque ces modifications ne sont pas encore fusionnées avec le tronc commun).
- faites une copie de sauvegarde de votre exécutable linknx actuel (utilisez 'which linknx' pour savoir où il se trouve)
- compilez et installez
- exécutez cette nouvelle version de linknx pendant quelques jours en vérifiant que tout se passe correctement. La durée utile du test dépend bien entendu de votre configuration, à vous de voir.
- en cas de problème, envoyez-moi un email ou répondez à ce sujet.
Quelques idées de points méritant le plus d'attention :
- les conditions timer de type "variable", "sunset", "sunrise" ou "noon" sont les plus susceptibles de souffrir d'une régression
- les conditions utilisant un offset
- la communication via l'interface XML par socket TCP
Enfin, je précise que cette nouvelle version a modifié le comportement sur certains cas obscurs :
- la prochaine occurrence d'un 29 février après le 29/02/2016 est désormais le 29/02/2020 qui correspond à la prochaine année bissextile. Auparavant, c'était le 01/03/2017 qui était sélectionné (notez la translation sur le mois suivant). Je pense que le nouveau comportement est plus intuitif !
- les conditions sur des dates "non naturelles" comme le 31/04 de chaque année (il n'y a que 30 jours en avril) causent désormais une erreur à la lecture de la configuration XML. Auparavant, une contraine sur un 31 avril était traduite de façon transparente en 01/05. C'est peu probable que ce genre de condition ait été écrite dans une config statique mais si certains d'entre vous génèrent leur config via un script, un dépassement de la borne naturelle pourrait intervenir plus facilement. Il en va de même pour tous les paramètres d'un TimeSpec : heure, minute, mois et jour.
Ce changement de comportement a été nécessaire pour clarifier la spécification qui était floue sur ces cas limites. Si ces modifications vous posent un problème, merci de me contacter pour en discuter.
Merci d'avance pour votre aide. C'est votre chance pour donner votre avis avant que les modifications passent dans la branche master :)
Cyrille
Cyrille Defranoux
Jan 20, 2019, 11:03:53 AM1/20/19
to Eibd / Linknx / KnxWeb
Je précise un détail : comme il s'agit d'une version de développement, il faut exécuter le script bootstrap.sh à la racine des sources avant de tenter une compilation. Ce script génère le script "configure" qui vous permet à son tour de générer les makefiles.
Cyrille Defranoux
Mar 27, 2019, 5:15:15 PM3/27/19
to Eibd / Linknx / KnxWeb
Reply all
Reply to author
Forward
0 new messages