Flatcam na Linuksie, czyli burdel zwany Python
: 21 lis 2022, 22:23
Uparłem się zainstalować Flatcam na Xubuntu 22.04.
Do tej pory używałem wersji dla Windows uruchamianej pod wine, ale z tym to zawsze są jakieś problemy...
Opis instalacji znalazłem kiedy już walczyłem z ostatnim problemem, najwyraźniej tym razem nie miałem szczęścia...
https://bitbucket.org/jpcgt/flatcam/iss ... t-64476836
Autor opisu trochę namieszał, brak pyserial w systemie to nie jest żaden błąd, tylko po prostu brak.
Natomiast brakuje informacji o sprawie wyjątkowo ważnej, mianowicie że program jest pisany pod Windows i ma windowsowe kodowanie końca linii. W takiej sytuacji rozwiązaniem jest wydanie w głównym folderze programu polecenia
Jeśli nie ma w systemie dos2unix, to trzeba go najzwyczajniej zainstalować przez apt.
Potem jest sprawa wykonywalności FlatCAM.py
Autor co prawda nie popełnił żadnego błędu, ale wybrał metodę uruchamiania uciążliwą pod Linuksem, mianowicie przez polecenie python3 FlatCAM.py
Pod Linuksem jednak jest wygodniej dodać na początku pliku oraz nadać plikowi atrybut wykonywalności, co daje możliwość uruchomienia programu podając tylko jego nazwę.
No dobra, czas na pierwsze uruchomienie programu.
Kończy się to wywaleniem komunikatu o błędzie:
Typowy debilny komunikat Pythona, "moduł nie ma atrybutu" i szukaj wiatru w polu...
Na szczęście Google już o tym wie i jak ktoś sprytny to znajdzie.
Wytłumaczenie jest wyjątkowo proste i sprowadza się do mojego ulubionego powiedzenia, że "Python to nie jest zwykły burdel, to jest burdel w którym każdy klient przestawia meble po swojemu"...
O ile jeszcze można zrozumieć niekompatybilność Pythona 2,7 z 3.0, no po prostu się nie dało, to jak wytłumaczyć niekompatybilność Pythona 3.9 z 3.10 ???
Otóż tym razem jakiś kretyn sobie wymyślił, że moduł "collections" będzie się od teraz nazywał "collections.abc"...
Zmiana niewielka, ale zupełnie wystarczająca żeby mnóstwo kodu napisanego wcześniej przestało działać wyświetlając debilny komunikat "moduł nie ma atrybutu"...
Podobnie jest z ezdxf.math.vector, który od teraz nazywa się ezdxf.math a Vector nazywa się Vec3 ...
Skutek identyczny.
Powyższe błędy da się usunąć edytując odpowiednie pliki, ale z vispy namieszali już tak, że nie ma wyjścia i trzeba odinstalować najnowszą wersję (0.12) i zainstalować starą (0.7)...
No to już jest najzwyklejsze psucie systemu, bo cholera wie co nie zadziała, bo dla odmiany będzie potrzebowało wersji 0.12 a nie 0.7...
No ale wyjścia nie ma.
Po tej walce program daje się uruchomić i chyba wszystko działa jak potrzeba.
Ale Pythonowi dobrze na przyszłość nie wróżę, bo ostatnio czego bym nie próbował uruchomić, to bez dłubania w kodzie nie daje rady.
Podobne cyrki miałem z dxf2gcode, gdzie dla odmiany konwersja typów odbywała się dotychczas z automatu, a teraz jakiś debil wymyślił że musi być jawnie deklarowana, co też skutkuje wywaleniem debilnego komunikatu błędu i zamknięciem programu...
Do tej pory używałem wersji dla Windows uruchamianej pod wine, ale z tym to zawsze są jakieś problemy...
Opis instalacji znalazłem kiedy już walczyłem z ostatnim problemem, najwyraźniej tym razem nie miałem szczęścia...
https://bitbucket.org/jpcgt/flatcam/iss ... t-64476836
Autor opisu trochę namieszał, brak pyserial w systemie to nie jest żaden błąd, tylko po prostu brak.
Natomiast brakuje informacji o sprawie wyjątkowo ważnej, mianowicie że program jest pisany pod Windows i ma windowsowe kodowanie końca linii. W takiej sytuacji rozwiązaniem jest wydanie w głównym folderze programu polecenia
Kod: Zaznacz cały
find . -type f -print0 | xargs -0 dos2unix
Potem jest sprawa wykonywalności FlatCAM.py
Autor co prawda nie popełnił żadnego błędu, ale wybrał metodę uruchamiania uciążliwą pod Linuksem, mianowicie przez polecenie python3 FlatCAM.py
Pod Linuksem jednak jest wygodniej dodać na początku pliku
Kod: Zaznacz cały
#!/usr/bin/python3
No dobra, czas na pierwsze uruchomienie programu.
Kończy się to wywaleniem komunikatu o błędzie:
Kod: Zaznacz cały
AttributeError: module 'collections' has no attribute 'MutableSequence'
Typowy debilny komunikat Pythona, "moduł nie ma atrybutu" i szukaj wiatru w polu...
Na szczęście Google już o tym wie i jak ktoś sprytny to znajdzie.
Wytłumaczenie jest wyjątkowo proste i sprowadza się do mojego ulubionego powiedzenia, że "Python to nie jest zwykły burdel, to jest burdel w którym każdy klient przestawia meble po swojemu"...
O ile jeszcze można zrozumieć niekompatybilność Pythona 2,7 z 3.0, no po prostu się nie dało, to jak wytłumaczyć niekompatybilność Pythona 3.9 z 3.10 ???
Otóż tym razem jakiś kretyn sobie wymyślił, że moduł "collections" będzie się od teraz nazywał "collections.abc"...
Zmiana niewielka, ale zupełnie wystarczająca żeby mnóstwo kodu napisanego wcześniej przestało działać wyświetlając debilny komunikat "moduł nie ma atrybutu"...
Podobnie jest z ezdxf.math.vector, który od teraz nazywa się ezdxf.math a Vector nazywa się Vec3 ...
Skutek identyczny.
Powyższe błędy da się usunąć edytując odpowiednie pliki, ale z vispy namieszali już tak, że nie ma wyjścia i trzeba odinstalować najnowszą wersję (0.12) i zainstalować starą (0.7)...
No to już jest najzwyklejsze psucie systemu, bo cholera wie co nie zadziała, bo dla odmiany będzie potrzebowało wersji 0.12 a nie 0.7...
No ale wyjścia nie ma.
Po tej walce program daje się uruchomić i chyba wszystko działa jak potrzeba.
Ale Pythonowi dobrze na przyszłość nie wróżę, bo ostatnio czego bym nie próbował uruchomić, to bez dłubania w kodzie nie daje rady.
Podobne cyrki miałem z dxf2gcode, gdzie dla odmiany konwersja typów odbywała się dotychczas z automatu, a teraz jakiś debil wymyślił że musi być jawnie deklarowana, co też skutkuje wywaleniem debilnego komunikatu błędu i zamknięciem programu...