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 (9)

  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. Log in to comment