Issue #67 resolved
Tymoteusz Oleniecki
created an issue

0.9.12 CABSflex -i 1no5

[DEBUG]     CABS:     Loading restraints...                                                       (00:00:07)
[CRITICAL]  CABSflex: float argument required, not NoneType float argument required, not          
                      NoneType: float argument required, not NoneType                             (00:00:07)
Traceback (most recent call last):
  File "/home/oleniecki/cabsdock/CABS/__main__.py", line 55, in run
    job.run()
  File "/home/oleniecki/cabsdock/CABS/job.py", line 178, in run
    self.setup_cabs_run()
  File "/home/oleniecki/cabsdock/CABS/job.py", line 394, in setup_cabs_run
    mc_steps=self.mc_steps
  File "/home/oleniecki/cabsdock/CABS/cabs.py", line 126, in __init__
    exclude = CabsRun.load_excluding(protein_complex.protein.exclude, excluding_distance, ids)
  File "/home/oleniecki/cabsdock/CABS/cabs.py", line 238, in load_excluding
    return '%i %f\n' % (len(excl), dist) + '\n'.join(
TypeError: float argument required, not NoneType

after excluding option disappearance in CABSflex -- CabsRun.load_excluding method gets None as first argument which causes fail.

following code in appropriate method fixes that bug, but it should included in polymorphism of CabsTask/FlexTask.run method.

if not excl:
    return ''

Comments (10)

  1. Tymoteusz Oleniecki reporter

    dla mnie chill, zdziwiłem się tylko. :) sprawdziłem, że

    if not excl:
        return '%i %f\n' % (0, 0.0)
    

    działa przyzwoicie.

    no i jak zawsze gorąco polecam odpalenie testów przed wrzuceniem poprawek do repo. nawet przy pracy z CABSem parę razy żałowałem, że się nie zastosowałem do tej zasady. ^^

  2. Maciej Ciemny

    Okazało się, że gałąź „release”, którą testowałem, nie jest aktualna (była w niej wersja 0.9.11) - testy dotyczyły więc poprzedniej wersji kodu. Myślę, że najlepiej będzie aktualizać gałąź „release” do wersji kodu, która trafiła do ściągalnego tarballa (dla ułatwienia testów i dokumentacji kolejnych wersji). @Sebastian Kmiecik

  3. Mateusz Kurciński

    Moja procedura postępowania jest taka (i od pewnego czasu staram się jej trzymać):

    • nowe zmiany do 'develop' i na tym robimy testy
    • jak testy ok to do develop -> master
    • jak się zbierze wystarczająco zmian, to master -> release -> nowy tarball
  4. Maciej Ciemny

    Niestety, błąd był po mojej stronie. Źle zrozumiałem, i sądziłem, że testy maja dotyczyć nowego release'a - aktualnego stanu w gałęzi.

    Będę pamiętał na przyszłość i puszczal testy z developa.

  5. Michal Jamroz

    ehhh hopaki, testy jednostkowe są dla leszczy. wystarczy nie robić błędów.

    wlazłem tu bo chciałem sprawdzić co tam u Was słychać, ale jak już tu wlazłem to dodam, że - conajmniej na gitlab (ale pewnie i bitbucket) jest coś takego jak pipeline - można sobie napisać ymla, który będzie coś uruchamiał w dockerze. Np właśnie testy jednostkowe po każdym push'u.

    Fajna sprawa i można to bardziej konfigurować - np. warunkowe wysyłanie/tworzenie release'u jeśli testy pójdą wyśmienicie, albo wysyłanie miliona maili z obwisłymi cycorusami do developerów - jeśli nie.

    w sęsie to o czym napisał Mateusz da się całkowicie zautomatyzować używając gitlab.

    Pozdro z otchłani, Michał kichał

  6. Log in to comment