KiCad 5.1.5

В Buster почти завезли свежий KiCad. Почти — потому что из-за глючного dwz(1) он не собирается в buster'овом окружении; видимо это и держит мейнтейнеров — все остальное уже спортировано. Но можно собрать самому, указав при сборке DEB_BUILD_OPTIONS=nostrip (не надо задумываться причём тут "strip", это особая дебхелперовая магия). Билд при этом несколько распухнет. Ну или в теории можно всосать свежий dwz/unstable (не пробовал). А! Еще понадобится glm/unstable, но там без проблем. Далее как обычно: apt-get source, dch --bpo, dch --local ~local, sbuild или dpkg-buildpackage (предпочитаю первый).

Получаем тонны багфиксов, новых фич вроде бы нет. Замечу что по-моему это вообще первый релиз из ветки 5.1, которым можно пользоваться не ловя ежеминутно ассерты.

This entry was originally posted at https://ex0-planet.dreamwidth.org/87962.html. Please comment there using OpenID.

The Devil and the Almighty Blues

Класс, пацаны ваще ребята.

Стилистически — Джим Моррисон с Пинк Флойдом поют нам блюз с того света :-)

Но чернуха, в плохом настроении лучше не слушать.



This entry was originally posted at https://ex0-planet.dreamwidth.org/87562.html. Please comment there using OpenID.

... ought to be enough, 30 лет спустя


The technology has some limitations — RISC is not appropriate for all computing applications, and the software for such machines is still being developed. But for a number of work-station makers, the quick speed fix promised by RISC has proved to be an irresistible attraction.


Отсюда

This entry was originally posted at https://ex0-planet.dreamwidth.org/87215.html. Please comment there using OpenID.

ретро-прозрение

В связи с тем, что простуженная голова работает плохо, томный вечер пятницы был посвящен чтению туплению в различные тексты и посты на тему всяческого ретрокомпьютинга.

И вот, читаю я про эти ваши "Эволюшены", "Нексты" и прочие "Веги" и как-то так внезапно понимаю, что самое важное в ретрокомпьютинге — уметь вовремя остановиться...

This entry was originally posted at https://ex0-planet.dreamwidth.org/86894.html. Please comment there using OpenID.

music for programming

Внезапне обнаружил что кодинг очень неплохо заходит под саундтрек из TA: Kingdoms



Там на канале еще есть.

Кстати, это тот же самый Джереми Соул, который делал музыку к Icewind Dale, Morrowind, Skyrim, Neverwinter Nights, Unreal 2 (как ни странно!) и еще куче других игр.

This entry was originally posted at https://ex0-planet.dreamwidth.org/86700.html. Please comment there using OpenID.

Ужосы городка

Ну что, кому-то не нравился немецкий Schneider и ABB? Дораха? Воротили нос от китайских IEK и TDM Electric — качество, видите ли, не то?

Вот вам тогда электроавтоматика от лучших производителей из ДНР (ага, именно оттуда)! Скоро на всех прилавках.

https://mysku.ru/blog/russia-stores/76283.html


PS. Как ЭТО попало на российские прилавки спрашивать, видимо, бессмысленно. Но наводит на кое-какие размышления.

This entry was originally posted at https://ex0-planet.dreamwidth.org/86318.html. Please comment there using OpenID.

@#$%!!!

2019, а питон все еще интегрируется с пакетными менеджерами примерно никак.

Ненавижу stdeb, ненавижу самого питона, ненавижу его яйца, ненавижу подход "сначала ввяжемся, потом будем разбираться как это работает". Ненавижу всех. А особенно, особенно неестественный интеллект, работающий по принципу "файл указан, но не нашёлся? Игнорируем, в ходе деплоймента поймаем проблему". "В воздухе точно не останемся", sooqa.

ps. Нет, pypi не предлагать. Это еще больший кал.

pps. И pypi2deb тоже ненавижу.

ppps. Отдельный луч поноса авторам, лепящим в корне какой-нибудь manage.sh или build.sh, без которого стандартным образом ничего не работает.

This entry was originally posted at https://ex0-planet.dreamwidth.org/86116.html. Please comment there using OpenID.

TDD: Trauma Driven Design

... Или Tool Driven Design, кому как больше нравится...

Как-то вдруг внезапно осознал, что всё что стоит за концепцией, например, "инкапсуляции" (как это понимается обычно в современном ООП) — всего лишь чья-то боль по поводу невозможности быстро найти и заменить все вхождения паттерна А на паттерн Б.

Ну, то есть, натурально, какой-нибудь восемьдесят восьмой год, сидит бородач в свитере перед монитором и кодовой базой в 100K-200K SLOC и понимает, что вместо "foo->bar = 640" надо бы писать какое-нибудь "updateGeometry(&foo, 640, 480)". И с инструментарием уровня турбо си восемьдесят восьмого года это — ЖОПА. Ну, каждый кто с подобным встречался поймёт. Все мы знаем, что прижилось решение просто запретить программерам писать "foo->bar = 640".

И вот сейчас в исторической перспективе становится понятно, что возникшую проблему можно было решить миллионом разных способов. Во всяком там энтерпрайзе куда более злобные изменения прокатывают под названием "рефакторинга", а возникающая при этом боль сглаживается контролем версий, разными там автотестами, итд итп. Чего в восемьдесят восьмом году просто не было, или было в рудиментарном виде. И если бы что-то из этого успело чуть пораньше, то никакой "парадигмы" ООП могло бы и не быть, а просто была бы рекомендация уровня best practices делать всё на ADT. А если не догадались сразу — ну чтож, бывает, линтер со статическим анализатором в помощь.

Интересно, сколько там, внизу, еще живет поспешных, неуклюжих, ad hoc решений заматеревших со временем в "концепции"?

This entry was originally posted at https://ex0-planet.dreamwidth.org/85982.html. Please comment there using OpenID.

Rigol + Sigrok, вечер перестает быть томным

Люблю человекочитаемые протоколы. Можно подсоединиться телнетом и поизучать внимательно что происходит.

Как следует из upd к прошлому посту, проблема проявила себя и в raw tcp mode, где в принципе нет никакого rpc, а есть простой текстовый (протоколом это трудно назвать) обмен: туда команды в ascii, обратно такие же ответы (ну иногда с примесью binary, но это неважно). И, собственно, если поставить развертку помедленнее, внимательно смотреть за происходящим на экране скопа и сопоставлять это с тём, что печатается в терминале и появляется оттуда, можно выяснить пару интересных подробностей.

Короче говоря, похоже что никакой "проблемы short reads" не существует в принципе. Авторы libsigrok приняли за проблему совершенно штатное поведение скопа, а именно, что пока идет развертка, то полному кадру данных взяться НЕОТКУДА, эти события еще не произошли. Поэтому отдается ровно то что есть на момент прихода команды. Ну а если скоп в этот момент только ждет триггера (или набралось меньше половины кадра, потому что pretrigger, да), то отдается ПОСЛЕДНИЙ полный кадр. Т.е. если sigrok'у по какой-то причине именно полный кадр и нужен, придётся либо останавливать развертку и читать из background memory как сказано в мануале, либо же как-то переделать работу с триггером чтобы гарантированно дожидаться окончания кадра. Вероятнее первое, поскольку если мы хотим работать со скопом как с LA (триггер-записали-вычитали награбленное), то так и надо делать, а чтение "по-живому" из front buffer оставить для live view (или как там эту функцию могли бы назвать маркетологи).

Окей, гугл, как объяснить девелоперам что у них ВСЁ сделано неправильно???

PS. Блин, как неохота загружать в голову еще три бегамайта исходников...

UPD Родные тулзы скопа (Ultraview или как его там) делают ровно то что я описал: нет данных — рисуют кусок графика.

This entry was originally posted at https://ex0-planet.dreamwidth.org/85631.html. Please comment there using OpenID.