Jump to content


Photo

Bug in TimerSanityCheck


  • Please log in to reply
4 replies to this topic

#1 rhinoceros

  • Senior Member
  • 569 posts

+23
Neutral

Posted 2 November 2011 - 08:38

Er zit een lelijke bug in 'TimerSanityCheck.py'. Dit probleem is te zien bij het toevoegen
van een timer maar ook bij direct recording in InfoBarGenerics. Aan het einde wordt de
simultimer getest. Wanneer de lijst minder dan 2 elementen heeft gaat het fout. De bug is
dat dit geen bug is. Er is weliswaar een kanaal dat niet geselecteerd kan worden. Maar dat
is een konflikt als en alleen als er een overlap is. Wanneer simultimer maar 1 timer heeft
dan is er dus geen overlap en ook geen konflikt.

De patch is bijgevoegd als diff bestand tezamen met de base-line versie(s).
Attached File  TimerSanityCheck.zip   2.95KB   11 downloads

"Het enige wat we leren van de geschiedenis is dat we niets leren van geschiedenis.", Georg Wilhelm Friedrich Hegel, 1831


Re: Bug in TimerSanityCheck #2 rhinoceros

  • Senior Member
  • 569 posts

+23
Neutral

Posted 4 November 2011 - 08:15

Het schijnt dat nog niemand hier tegenaan gelopen is. Het is eenvoudig te testen. Start een timer. Daarna een tweede timer die niet in de tijd overlapt maar die wel een kanaal gebruikt op een andere frequentie, band polarisatie of tuner zodat de beide kanalen niet gelijktijdig bekeken kunnen worden. De fake timers worden dan gelijktijdig gestart waardoor een conflict onstaat, maar er is geen overlap in de tijd. De timers kunnen dus gerust gebruikt worden. Maar de TimerSanityCheck weigert dit. Def outmelding is ook fout want er wordt een conflict gemeld tussen één timer ?!

"Het enige wat we leren van de geschiedenis is dat we niets leren van geschiedenis.", Georg Wilhelm Friedrich Hegel, 1831


Re: Bug in TimerSanityCheck #3 littlesat

  • PLi® Core member
  • 57,510 posts

+709
Excellent

Posted 4 November 2011 - 09:52

Ik zal het morgen of zo testen en dan committen. Deze commit is eigenlijk te eenvoudig voor woorden. Maar de "Bug: unknown Conflict!" geeft me wel een beetje een onderbuik gevoel dat er toch nog iets anders stuk kan gaan. Weet je zeker dat de patch alleen het bovenstaande scenario opvangt?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Bug in TimerSanityCheck #4 rhinoceros

  • Senior Member
  • 569 posts

+23
Neutral

Posted 5 November 2011 - 11:01

Ja, ik had ook zo'n onderbuik gevoel. Ik heb goed gekeken naar de logica. Er is waarschijnlijk in verschillende generaties gewerkt aan deze code. Het resultaat is nu niet zo transparant meer. Uiteindelijk is de programmeur die deze laatste opmerking heeft geschreven niet meer zeker geweest van zijn zaak. De konflikt analyse is nodeloos ingewikkeld, maar wel juist zover ik het zie. Tot op dit laatste punt dan. De engelsen hebben dan zo'n mooi gezegde. The proof is in testing of the pudding ...

"Het enige wat we leren van de geschiedenis is dat we niets leren van geschiedenis.", Georg Wilhelm Friedrich Hegel, 1831


Re: Bug in TimerSanityCheck #5 littlesat

  • PLi® Core member
  • 57,510 posts

+709
Excellent

Posted 5 November 2011 - 14:53

Ik heb die code nog eens bekeken... En ik kan alleen tot de conclusie komen dat ze daar een return True vergeten zijn. Als je minder dan twee in de lijst hebt dan kan er geen conflict zijn :DBuiten die extra meding die geprint wordt heeft die if dan ook geen enkele toegevoegde waarde.

Edited by littlesat, 5 November 2011 - 14:55.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users