Bug semaine nClock

[critor]

Pour moi, entre 1970 et 2038 il ne s'écoule qu'un peu plus de 2 milliards de secondes, soit juste 31 bits (2³¹ secondes).

Ah mais oui... Levak a dû utiliser un entier signé, ce qui gâche le 32ème bit pour un signe toujours positif.
Mais peut-être n'avait-il pas le choix techniquement, aucune idée.

[critor]

Voilà déjà la dernière version 1.0.8, avec le bug du calcul du jour de la semaine désormais corrigé :
archives_voir.php?id=4416

Comme vous pouvez voir, nous sommes bien jeudi et non plus samedi :


Pour les autres bugs je ne promets rien - j'ai déjà passé suffisamment d'heures là-dessus pour aujourd'hui.

[Levak]

J'ai horreur de me replonger dans du code que j'ai écrit avant 2013.
Donc aucune surprise que maintenir les programmes que j'ai écrit avant cette période là ne me chante guère. Pour la petite histoire, en 2013, on m'a lavé le cerveau, à vomir du C pendant 5 mois. Ca s'appelle l'ING1 à Epita pour ceux qui connaissent. Depuis cette date, j'ai une tolérance au code moche se rapprochant de 0.

Par ailleurs, j'ai lâché le développement sur Nspire lorsque que j'ai compris que maintenir des hooks cross-platform (différents OS et types de Nspire) n'était pas toujours possible suivant les modifications effectuées par TI. C'est marrant sur le moment, mais très très vite chiant d'updates en updates. J'essaie donc de m'épanouir sur d'autres sujets qui n'ont rien à voir avec le monde des calculatrices (qui de plus, ne me sont plus d'aucune utilité maintenant que j'ai mon diplôme en poche).

En tout cas, je suis heureux de voir que l'effort commun permet de ressusciter des programmes open-source, dont les miens. Malheureusement, comme Critor l'a remarqué, mon silence calque mon désintéressement progressif de cet univers.

PS: Je savais de très longue date qu'il y avait un bug sur les années bissextiles, juste jamais eu le temps de m'y replonger. IIRC j'avais tout fait en 2 soirées à tout craché, pas étonnant qu'il y ait ce genre de coquilles.

[GalacticPirate]

@critor Merci !
@Levak Dommage, tu auras été un membre important de la communauté Espérons qu'Adriweb ne lâche pas non plus les calculatrices

[Adriweb]

Ca fait assez longtemps que j'ai laché les calculatrices en elles-mêmes (ou au moins par rapport à ce que j'ai pu faire par le passé), je ne fais désormais presque plus que du dev. desktop et web (ça peut certes tourner autour de l'univers des calculatrices, mais c'est pas sur calculatrice comme avant...).

[critor]

@Adriweb
Ce n'est pas comme si tu ne faisais plus rien du tout non plus.
Tu participes à CEmu qui tourne sur TI-Nspire, et tu as participé à Mandragore/Androides/Crystann pour TI-83 Premium CE.
Et même si tu n'es plus à l'initiative de nouveaux projets, cela ne t'empêche nullement de maintenir ce qui existe déjà.

@Levak
Tu ne t'en rends peut-être pas compte, mais tu as des utilisateurs/fans/adorateurs sur tous les continents, et il est bien dommage de les abandonner ainsi.
Quant à la maintenance des hooks, tu devrais consulter le code source de nSonic. C'est deux fois plus simple à maintenir que ce que tu as fait dans nClock.

[critor]

Voilà, je pense avoir corrigé le bug de Hayleia.

La fonction convertissant la date en timestamp pour le stockage machine était fausse.
Il suffisait d'afficher le timestamp et de le comparer à ce que ça aurait dû donner pour s'en rendre compte.
Je l'ai globalement réécrite :

Code: Select all

unsigned long date2timestamp(int year, int month, int day, int hr, int min, int sec) {
   int cyear;
    sec = time2timestamp(hr, min, sec);
    int ly = isLeapYear(year);
    for(--month; month > 0; --month)
        day += maxDayInMonth(month, ly);
   day--;
   day+=365*(year-1970);
   for(cyear=1972;cyear<year;cyear+=4)
      day+=isLeapYear(cyear);
    return sec + day*86400;
}

La fonction inverse recréant une date affichable à partir du timestamp machine était également fausse.
Réécrite également :

Code: Select all

void timestamp2day(unsigned long t, int * year, int * month, int * day) {
   *year=1970;
   int leap_year=0;
   while(t>=365+leap_year) {
      (*year)++;
      t-=365+leap_year;
      leap_year=isLeapYear(*year);
   }
    *month = 1;
    int max_day = maxDayInMonth(*month, leap_year);
    while(t >= max_day) {
        t -= max_day;
        ++*month;
        max_day = maxDayInMonth(*month, leap_year);
    }
   *day=t+1;
}

Selon les cas, les deux erreurs pouvaient globalement se compenser ou s'ajouter, ce qui créait dans ce dernier cas un décalage plus important pouvant passer à la veille ou au lendemain.



J'en ai également profité pour mettre le programme à la norme POSIX, et donc corriger le bug du 19 janvier 2038.
(qui se produisait initialement en 2039 à cause de toute la collection de bugs concernant la date)

Le timetamp est désormais un "unsigned long", ce qui lui permet d'utiliser intégralement les 32-bits (au lieu de 31 bits pour un "signed long", le dernier bit étant réservé au signe).
En théorie, nClock peut donc désormais fonctionner sans aucun problème sur votre TI-Nspire jusqu'au 7 février 2106 à 6h 28min 15s.

En pratique ce n'était pas tout à fait le cas, il y avait encore un décalage puisque le problème arrivait dès le 6 février... ce qui m'a conduit à découvrir un 3ème bug sur les années bissextiles, décidément...
Précédemment, il s'agissait de bugs concernant le changement de millénaire (année 2000), le test d'année bissextile qui était mal recodé à plusieurs endroits oubliait cette vérification, au lieu d'utiliser la fonction dédiée isLeapYear().
Ce nouveau bug concernait l'année 2100 cette fois-ci, la fonction isLeapYear() considérant que tout changement de siècle était une année bissextile, alors que c'est exactement le contraire à la seule exception près des changements de millénaire.



La programmation d'un test d'année bissextile étant un exercice type que j'ai régulièrement vu en soutien scolaire avec des étudiants commençant une 1ère année de cursus informatique, je suis assez surpris du nombre important de bugs - au sens où je ne m'attendais vraiment pas à avoir à déboguer et corriger autant de choses.


Bref, nClock 1.0.9 : archives_voir.php?id=4416
Merci de me dire si vous constatez encore des problèmes de dates.

[critor]

J'ai mis à jour nClock en version 1.0.10, suite à un bug de luminosité pour les écrans couleur signalé sur cnCalc.org :
viewtopic.php?t=17795&p=195757#p195757


Sinon, il me semble rester encore plein de bugs.

Notamment le fait que la configuration semble se corrompre assez facilement. Je l'ai constaté lors de changements d'OS, avant même de commencer à maintenir le programme, mais pas que.
Je ne comprends pas du tout comment c'est possible, mais il faut bien se rendre à l'évidence.

Avec une configuration corrompue, on a plein de choses :

• position de la mini-horloge hors-écran avec nombre de bugs d'affichage, souvent très difficile à corriger avec les flèches...
• compte à rebours activé en années, qui interdit de changer la position de la mini-horloge (message "fin de compte à rebours" en anglais à chaque tentative de déplacement)

Renommer le programme nClock en 'uninstall' semble parfois même ne pas résoudre le problème.
La communauté cnCalc.org qui a constaté ces problèmes comme moi, a sorti un programme de nettoyage de la configuration nClock.
N'hésitez donc pas à l'utiliser, si l'horloge se met à délirer :
archives_voir.php?id=400728

[Levak]

Pour supprimer la config de nClock, il suffit d'utiliser TI-Nspire Computer Link Software. Le .config y est visible. Suite à ça, un ptit redémarrage juste pour la forme.

[Ti64CLi++]

Sinon, avec un utilitaire tel que Simple File Browser de gameblabla, on peut aussi le supprimer