Zyn-fusion, Helm.

Ostatnio eksperymentuje trochę z soft-syntezatorami na Linuksie i zupełnie przy okazji odkryłem Unfę:

Tobiasz jest żywym dowodem na to, że da się na Linuksie produkować muzykę, a wszystkie dźwięki na tej płycie powstały w zyn-fusion. Dla mnie to jest rewelacyjna zabawa w dźwięki, poznawanie skal i interwałów, których na gitarze nigdy nie mogłem ogarnąć ;), ale zarówno zyn-fusion jak i helm są po prostu świetne.

Minimalizm, czyli i3-wm + connman.

Od kilku lat używałem Plasma Desktop, ale mój sprzęt nie jest bardzo szybki i czas startu tego środowiska zaczął być uciążliwy. Nie byłem przekonany co do tzw. tiling window managerów, jednak powoli zmieniam zdanie.
Zmiany środowiska zwykle generują problemy, które rozsądnie byłoby szybko rozwiązać. U mnie problemem okazał się Network Manager, którego szczerze mówiąc nigdy nie lubiłem. Wszystkie te dodatkowe warstwy (polkity i inne wynalazki) czasem po prostu wchodzą w drogę, jednak connman, jako alternatywa dla Network Managera sprawdził się doskonale i raczej na pewno zostanie u mnie na dłużej.

i3wm najbardziej trafnie określa powyższy zrzut ekranu. Po raz kolejny zdałem sobie sprawę, że tak na prawdę do pełni szczęścia potrzebny mi dobrze działający dostęp do sieci i programy typu dmenu i rofi jako wygodna alternatywa tzw. menu „Start”.

Szybkość i wygoda jest na tyle duża, że oba moje laptopy działają od dziś z i3-wm.

Jackd i PulseAudio.

Jackd + Chromium albo Firefox = problem. Tak się jakoś porobiło w Linuksie, że PulseAudio stało się standardem w obsłudze audio i chyba nie ma w tym nic złego. Mimo tego, że Firefox w Archlinuksie  skompilowany jest z obsługą jackd, to wyjście jackd w FF nie działa. Na szczęście nie jestem z obozu ultra-tradycjonalistów i udało mi się szybko i prosto pożenić jackd z Pulseaudio.

Potrzebny będzie pakiet pulseaudio-jack zawierający module-jack-sink.so i module-jack-source.so​.  Do /etc/pulse/default.pa trzeba dodać te moduły:

load-module module-jack-sink
load-module module-jack-source

Każdorazowo po odpaleniu jackd pulseaudio musi zostać przeładowane: pulseaudio -k, a potem: pactl set-default-sink jack_out. Dzięki temu pulseaudio przekieruje audio systemowe na jackd, co pozwala jak w moim przypadku bębnić w realtime do kawałków na Youtube. Pozytywne jest to, że po ubiciu jackd, PulseAudio przywraca odtwarzanie na defaultowej karcie dźwiękowej „w locie”.

Przykre, że jackd nie jest traktowane jak należy, a użytkowników w niszy audio na Linuksie chyba nie ma wielu i od przynajmniej dekady nic się w temacie nie robi, żeby im ułatwić życie.

i686 out…

Nieźle:

Due to the decreasing popularity of i686 among the developers and the community, we have decided to phase out the support of this architecture.

The decision means that February ISO will be the last that allows to install 32 bit Arch Linux. The next 9 months are deprecation period, during which i686 will be still receiving upgraded packages. Starting from November 2017, packaging and repository tools will no longer require that from maintainers, effectively making i686 unsupported.

 

Aspeqt na github.

Aktualny deweloper Aspeqt pokłócił się z paroma osobami na forum Atari Age i dostał tam bana. W odwecie usunął wszystkie wprowadzone przez niego zmiany od wersji 0.6 do 1.0 i postanowił rozwijać to dalej w zaciszu swojego forum, udostępniając za opłatą. Szkoda.

Wrzuciłem ostatnie udostępione na AAge źródła 1.0.0 preview 6 do repo na Github.

https://github.com/greblus/aspeqt/tree/master

Nie mam jakichś wielkich planów, chciałbym kompilować od czasu do czasu aby działało na aktualnych wersjach bibliotek. Fajnie by było też zrobić nowe gui, bo aktualne jest beznadziejne, zwłaszcza na małych ekranach, ale to w wolnych chwilach.

Pierwszy pomysł jest taki: minimalna geometria okna i dynamiczne dodawanie slotów:

mini_aspeqtUpdate:

Tak sobie niezobowiązująco myślę… Jest port QT5 na Androida: http://doc.qt.io/qt-5/android-support.html muszę się więc zaznajomić z Android NDK. Nawet gdyby trzeba było Gui zrobić od nowa, zdecydowanie jest to do zrobienia.

FTDI też działa: http://www.ftdichip.com/Android.htm (sprawdzałem na tablecie z 4.2.2 i faktycznie, wygląda że to działa out-of-the-box).

Myślę, że przy odrobinie wolnego czasu można by to ze sobą pożenić. Jest w TME nawet FTDI w wersji zintegrowanej z kablem. SIO2PC zmieści się we wtyczce SIO. Dałoby się z tego zrobić coś fajnego ;).

Update: AspeQt na Androida tutaj.

Printf() pod Windows.

Printf() pod Windows okazuje się sporo wolniejszy niż pod Linuksem.

printf_windowsParadoksalnie, jak widać powyżej, pythonowy print() jest ~3x szybszy od printf() z biblioteki standardowej Mingw-w64. Pod Linuksem na odwrót, 4x wolniejszy względem tego z libc.stdio:

print_linux


Poczytałem stdio.h i doszedłem do tego, że gdy  -D__USE_MINGW_ANSI_STDIO=1 używana jest funkcja printf() z Mingw (ponad 11 razy wolniejsza od printf() pod Linuksem) i tak jest „by default”.

Jeśli do gcc dodam  -D__USE_MINGW_ANSI_STDIO=0, używana jest wersja printf() z msvcrt.dll. Mimo, że ta funkcja ma swoje braki, różnica jest dość znaczna:

$ time ./fib_mingw_printf.exe 300000 > /dev/null

real 0m5.513s
user 0m0.000s
sys 0m0.031s

$ time ./fib_msvcrt_printf.exe 300000 > /dev/null

real 0m1.081s
user 0m0.015s
sys 0m0.000s


Jeszcze jedna ciekawostka: przekierowanie do /dev/null w MSYS2 (które jest prawdopodobnie mapowane na NUL) pod Windows jest powolne. Przekierowanie do pliku jest ~2x szybsze:

$ time ./fib_msvcrt_printf.exe 300000 > output.txt

real 0m0.562s
user 0m0.000s
sys 0m0.015s

(Pod Linuksem bez różnicy).


Na szczęście %timeit pozwala się przekonać, że kod generowany w tej samej wersji gcc pod Windows i pod Linuksem jest niemal tak samo wydajny.

Cython – kompilacja programów w Pythonie mingw-w64 dla Windows.

Dawno nie miałem takiej motywacji do programowania. Cztery dni poszukiwań, grzebania w strzępkach dokumentacji i przykładach. W końcu się udało. Ale od początku. Postanowiłem trochę odświeżyć wiadomości o Pythonie i natrafiłem na Cythona, który mnie zafascynował, ale miałem problem z kodowaniem argumentów programów (sys.argv) do obiektów unikodowych pod Windows (argv w Windows jest w UTF-16, wchar_t **). W żaden sposób nie dało się ich dekodować do Unicode, a binarki dla Linuksa działały bez problemu. Pal licho argv ale to samo dotyczyło kodowania nazw plików. Przetestowałem kilkadziesiąt funkcji C-API Pythona i nic.  Skonwertowanie windowsowych szerokich argumentow (wchar_t **) argv z UTF-16 do UTF-8 wydawało się niemożliwe. Aż w jakimś archiwum ircowym trafiłem na wzmiankę, że bez flagi -municode mingw-gcc nie obsługuje pod Windows poprawnie kodowania linii cmd.

Co ciekawe, od początku wydawało mi się celowe generowanie entrypoint-a przez Cythona dla Windows jako:

int wmain(int argc, wchar_t **argv)

Okazuje się, że po dodaniu -municode do gcc mingw-w64 jako entrypoint traktuje właśnie wmain() i używa odpowiednich wersji funkcji z obsługą unicode. Niestety w mingw-gcc 4.8.1 nie ma opcji -municode i wiele osób pewnie z tego powodu ma problemy.  W gcc-4.8.1 z mingw-w64 działa jak należy, jest nawet o tym informacja na stronie projektu:

http://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/

Szkoda, że wcześniej tego nie znalazłem ;(.

aconv

Przykładowa konwersja i kompilacja wygląda tak, w Windows w MSYS:

/c/Python34/Scripts/cython.exe -3 --embed aconv.py
gcc aconv.c -I /c/mingw/python/include/python3.4m -L /c/mingw/python/lib/ -lpyth
on3.4m -municode -o aconv

Podsumowując. Bardzo mnie to cieszy. W Cythonie, poza niemal pełną zgodnością z Pythonem można includować nagłówki z bibliotek w C i bezpośrednio z nich korzystać w modułach pythonowych, z całą dobrocią typów C a pozwala na przyspieszenie kluczowych fragmentów kodu i kompilację nawet całych programów skonwertowanych do C. A w składni wygląda to jak Python.

Pełen respect dla twórców Cythona.