Привет, Хабр!

Когда вы пишете вот такую строчку:

const N: u64 = fib(50);

внутри компилятора происходит странное. rustc не генерирует машинный код для fib, не зовёт процессор и не подставляет ответ откуда-то сбоку. Он берёт вашу функцию, разворачивает её в промежуточное представление и исполняет шаг за шагом прямо у себя внутри, на маленькой виртуальной машине.

И вот вопрос, на который мало кто может ответить с ходу: а кто конкретно это исполняет? Где живёт тот интерпретатор? Почему 255 + 1 в const падает с ошибкой компиляции, а в рантайме просто паникует? Почему можно посчитать таблицу из тысячи элементов циклом, но нельзя написать if a < b для дженерика? И почему 0.0 / 0.0 в const официально разрешили вести себя недетерминированно?

Погнали разбираться.

Какая техническая область развивается практически всю историю человечества, идя с ним рука об руку и, несмотря на все прошедшие века и технические изменения, — до сих пор, в основе своей, находится на том же уровне, что и многие тысячи лет назад? 

И это безусловно — бритьё! :-)

Привет, Хабр!

#[derive(Serialize, Deserialize)] это какая-то одна строка в коде. На холодной сборке за ней прячется двадцать с лишним секунд компиляции, даже если в проекте больше ничего нет. Откройте cargo build --timings на любом не самом маленьком проекте с serde, и serde_derive почти наверняка окажется в первой тройке самых медленных крейтов. При том что в самом serde_derive всего несколько тысяч строк.

Между этой строкой и этими секундами лежит вся инфраструктура процедурных макросов: TokenStream, syn, quote, proc-macro2, watt. Пройдёмся по ней в этой статье.

Раз уж пошла такая песня, я решил добить вопрос с выводом изображения по HDMI на плате Zynq Mini. В предыдущей статье мы уже разобрали как это сделать в baremetal-сценарии, теперь пришла пора дополнить дизайн для возможности вывода системной консоли Linux, при том, что у Zynq-7000 нет своего видеоконтроллера и весь видеотракт (DMA, генератор таймингов, TDMS-кодер) должен быть построен внутри FPGA, а затем быть проброшен в Linux. 

Всем, кому интересна данная тема - добро пожаловать под кат!

Любой кто имел дело с лазерами, например, в самом простом варианте, даже баловался с обычной красной лазерной указкой, замечал, наверное, одно интересное явление: если навести лазерный луч на какую-либо поверхность — поверхность оказывается как бы покрытой ярко сияющими мелкими блёстками, и этот эффект тем более заметен, чем с большего размера лазерный луч светит на поверхность — просто-напросто, из-за обычно неидеальности оптической системы лазера, бытовые недорогие лазерные указки красного цвета имеют достаточно большое* расхождение луча и этот луч освещает достаточно большую площадь, на которой этот эффект становится ещё более заметен. 

В прошлом, я думал, что «ну, просто луч настолько яркий, что подсвечивает малейшие шероховатости, ничего странного» — однако, как выясняется, науке этот эффект давно известен, за ним скрывается очень интересное явление и он может быть применён весьма любопытными способами! 

Что такое световое перо? Предок современного стилуса?

Хороший вопрос. Шестьдесят лет назад операторы ЭВМ пользовались им точно так же, как мы сегодня стилусом: тыкали в экран, чтобы отметить самолёт-нарушитель, набросать чертеж детали для будущего самосвала или поставить точку на графике. На первый взгляд — два поколения одной и той же идеи.

Но при общей задумке механика работы у них совершенно разная. Стилус просто просто отмечает место «тыка» на сенсорном экране. А световое перо… Впрочем, давате я расскажу всю историю этого удивительного гаджета, а заодно и про принцип его действия.

Еще вы узнаете, почему на современных мониторах классическое световое перо бесполезно. И, скорее всего, удивитесь: есть шанс, что вы сами держали его в руках и даже не подозревали об этом.

Что мы знаем о повороте на определённый угол и его удержании в робототехнических системах? 

Думается, что на данный момент, мы все настолько сильно подсели на разнообразные цифровые устройства, алгоритмы и принципы, что нам (наверное, что даже и большинству), зачастую, даже сложно себе представить, что подобная задача может быть решена и кардинально иным способом! :-)  

Тем не менее, в истории существовали (и даже в данный момент существуют!) целый класс абсолютно иных аналоговых устройств, который вполне себе успешно справляется с тем же самым вопросом — и называются подобные устройства «сельсины»…

sizeof(Mutex<()>) в Rust 1.61 на Linux был 40 байт. В Rust 1.62 он стал 5 (точнее, 8 с учётом выравнивания, но базовый overhead 5).

За уменьшением размера в восемь раз стоит полная переписка стандартного Mutex с pthread на futex напрямую, ускорение uncontended locks в 2-3 раза, и десятилетие, которое стандартный Mutex провёл в роли «возьми parking_lot, std::sync::Mutex медленный».

Сегодня заглянем под капот всей этой темы, разберём, что лежит внутри std::sync::Mutex после 1.62, какой алгоритм там используется, почему он на самом деле быстрее pthread, как устроен fairness (точнее, его отсутствие), зачем нужен poisoning, и в каких случаях parking_lot всё ещё имеет смысл тащить в зависимости. Заодно вернёмся к моей старой async-статье и поясним конкретнее, почему в async-задачах std::sync::Mutex это проблема, и при чём тут вообще futex.

Я давно хотел купить плату с Zynq-7020, да такую, чтобы на ней был FMC LPC разъем на который, к примеру, можно было бы установить плату c AD9361 или множеством портов Ethernet, или еще какой-нибудь вариант. И на просторах китайского Aliexpress мне попалась одна такая - TZT RK-ZYNQ7020-F версии 1.1. Я не долго думая сразу ее прикупил и решил что это как раз то, что нужно. И в этой статье хотел бы поделиться своими впечатлениями и обзором того, что на этой плате любезно нам предоставил разработчик. Это будет обзор в несколько ином ключе, без пересказа schematic, а в виде подробного инженерного обзора по подсистемам. Сначала рассмотрим комплектацию, стоимость, затем архитектуру платы, ее внешний вид и что на ней есть. Потом заглянем в питание, reset, clocking и boot. Затем память: DDR3, QSPI, eMMC, microSD. Далее интерфейсы PS: UART, USB, Ethernet, I2C, интерфейсы PL и расширения: FMC, 40-pin, HDMI, MIPI, CAN, RS485, LCD. И в конце - общее впечатление, риски и выводы. Поехали!

Всем интересующимся - добро пожаловать под кат!

PCB-шник

Любой, кто пытался изготавливать печатные платы самостоятельно, сталкивался с тем, что процесс этот довольно медленный и грязный. 

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

Но что же делать со скоростью? Или, вот ещё проблема: зачастую (а особенно при изготовлении относительно габаритных плат) требуется также запастись и относительно большим количеством травящего раствора. 

После чего начинается «задумчивое потряхивание платы в этом растворе, глядя в угол комнаты» :-B, — что безусловно отвлекает от других дел и, к тому же, занимает не сказать, чтобы уж совсем маленькое время… 

Конечно, это всё не является проблемой, если делать печатные платы вам приходится раз от разу, и изредка… Но, всё существенно усложняется, если попытаться делать платы хотя бы малыми сериями — здесь уже любая эффективность будет ко двору, так как за рабочий день их не натрясёшься… 

Тем не менее, есть один интересный способ, с весьма широкими возможностями, который, наверняка, далеко не каждому попадался на глаза! ;-) 

И способ этот — сборка простых установок типа «ротоспрей»…

В детстве мне попалась история про алмаз Низама. Большой индийский камень, гордость хайдарабадского двора. И якобы один ювелир, чтобы проверить, настоящий ли он, ударил по нему сверху другим камнем. А алмаз взял и раскололся.

Фразу из той статьи я запомнил дословно: «Он перепутал твердость с хрупкостью».

Я перечитал ее несколько раз. А разве это не одно и то же? К сожалению, в моем детстве не было Интернета и тогда я не смог найти ответа на этот вопрос. 

Но, спустя годы, я снова вспомнил эту историю и мне стало интересно с ней разобраться. Я погрузился в изучение вопроса. Почему же алмаз так легко разбить, ведь если что-то твердое — оно же должно быть и прочным? Логично ведь.

Нет, не логично.

Алмаз и правда твердый. Самый твердый минерал из тех, что встречаются в природе. И при этом он хрупкий — расколоть его проще, чем кажется. Две эти вещи прекрасно живут в одном камне и друг другу не мешают. Просто слова «твердый» и «хрупкий» в обиходе мы употребляем как антонимы одного и того же. А в материаловедении это два разных свойства, и измеряются они по-разному.

Насколько правдива сама байка про ювелира — отдельный вопрос. Алмаз Низама существовал, это факт, и по описаниям у него действительно был скол на плоскости. А вот сцена с ударом сверху вызывает сомнения. Но что бы там реально не приключилось, легенда отлично показывает физику твердости/хрупкости. И сейчас мы с ней разберемся.

^{Project 326}

Продолжение статьи (начало ТУТ).

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

Кроме того, как мы видим, существовала проблема и выгорания стержней — а людям хотелось бы чего-то более долговечного (полное время работы дуговых источников света измерялось всего лишь часами, в ходе чего стержни сгорали в них до конца), да и свет их был избыточно ярким — что, безусловно, наверное, хорошо, для освещения площади посреди города, но уже «не совсем» для какой-нибудь уютной кухни…

Наверное, с самого начала человеческой истории, люди осознали, что «свет — это хорошо, а тьма — таит в себе опасность»: охотники знают, что, кажущийся таким тихим и безжизненным лес, в тёмное время суток превращается в самое настоящее густонаселённое место — множество обитателей фауны выходят по своим делам и лес наполняется необычными звуками и неожиданными (не всегда приятными) встречами, избежать которых (или специально искать их, в зависимости от того, «на какой стороне» находится объект —  жертвы или хищника) можно было только обладая особыми свойствами организма, в частности зрения, слуха, обоняния. 

Исторически, человек всё более и более уступал в этом истинным представителям дикой природы: человеческое зрение не позволяло ему видеть в темноте также уверенно, как это делают многие дикие звери; обоняние не позволяло заранее почуять опасность; отсутствие больших и подвижных ушных раковин — также не могло потягаться с дикими зверями… 

Думается, что именно поэтому, активная деятельность человека всё более и более сосредотачивалось на светлом времени суток, а затем, с момента эпохального события (или событий), затерявшегося в веках — открытия огня, человек понял, что теперь, всё в его руках: «день» может наступить в любое время суток, равно как и безопасность!  

С того времени утекло много воды, и безопасность человека теперь обеспечивается зачастую иными средствами, чем освещение… Но, тем не менее, несмотря на прошедшую лавину времени, создание и совершенствование источников света всё также находится в значительной степени, в центре внимания людей, приводя к довольно интересным результатам…

Вопрос на засыпку: кто придумал бит? Если вы ответите «Клод Шеннон», то будете неправы, бит он не придумывал. Но без Шеннона сухая концепция его коллеги по Bell Джона Тьюки вряд ли бы обрела такую популярность и легла в основу современного мира.

А еще Шеннон не придумывал Булеву алгебру, энтропию и логарифмическую меру количества информации. Если честно, то изобретатель из него так себе.

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

История Клода Шеннона заслуживает отдельного рассказа, потому что это тот тип ученых, который лично мне ближе всего. Не изобретатель чего-то концептуального, а практик до мозга костей, который с ходу видит, куда можно приспособить удачную идею.

В прошлой статье мы собрали готовый образ Linux и запустили I2C Master Controller который живет в ПЛИС и управляется драйвером предоставляющим в ОС доступ к нему как типовому I2C-контроллеру. В этой, заключительной части из общей серии статей, я хотел бы филигранно отшлифовать все мелкие недочеты и привести примеры утилит, которые могли бы отправлять нужные нам данные на I2C OLED-дисплей SSD1306, например температуру кристалла, время или что-нибудь еще. 

Всем кому интересна тема - го под кат! :)

В прошлой части мы подробно разобрали завязку сюжета: немцы освоили магнитные мины и это стало головной болью для Великобритании. Впрочем, британцы разобрались, с чем столкнулись, и даже нашли, что противопоставить. Во второй части мы узнаем, как действовал СССР и какова роль Курчатова во всей этой истории.

Не знаю как для вас, но мне всегда казалось очень странным, что, любой энтузиаст, желающий собирать какие-либо самоделки на базе микроконтроллеров, всегда сталкивается с весьма странной проблемой: как подключить двигатели наиболее простым способом?!  

Потому что, самое первое, с чем придётся иметь дело при попытках разобраться с этим вопросом, так это с тем, что в глаза бросается просто какое-то безумное количество плат расширения, какое-то безумное количество датчиков, подключаемых удобным и не совсем образом…. 

А двигатели? А двигатели в пролёте в прокруте (на первый взгляд)…:-B 

Ниже я рассмотрел пару решений, которые нашёл для себя в разные моменты времени в прошлом — возможно, они, в чём-то, будут полезны и для вас! ;-) 

Спросите случайного человека, с чем у него ассоциируется фигура Игоря Курчатова. Скорее всего, вспомнят советскую ядерную бомбу. Кто-то добавит про знаменитую бородку или аэропорт Челябинска (Ииииигорь!). На этом, как правило, всё.

А зря. Ведь до того, как Игорь Васильевич стал главным человеком в советском атомном проекте, он успел завершить другую задачу. Настолько важную и срочную, что её делали прямо на причале, под бомбёжкой.

И это настоящий исторический детектив. В нем есть загадочные взрывы кораблей, новейшие (на тот момент) разработки, расследования с риском для жизни и, наконец, яркая, но успешная развязка.

Сразу предупрежу: все части статьи, где описываются не физические принципы, а конкретные события, написаны с опорой на воспоминания участников. Местами они спорны или противоречат друг другу. На сам сюжет и уж тем более на физику это особого влияния не оказывает, но за прошедшие десятилетия кое-что приукрасили. Хотя какой хороший исторический детектив без прикрас?

На Хабре есть серия статей, касающаяся заблуждений программистов о, казалось бы, простых вещах: о времени, почтовых адресах, именах и даже дверях. Я недавно пообщался с ребятами, пилящими медицинский софт, и решил собрать набор таких же заблуждений, только применительно к врачебному делу. А чтобы было чуть интереснее, собрал это в виде истории, которой позавидует любой индийский фильм или турецкий сериал.

Итак, перед нами молодой джун Игорь (здесь и далее все имена и фамилии вымышлены), который работает в компании, разрабатывающей софт для больниц. Его только что отправили разгребать легаси-код для ПО, установленного во множестве родильных домов. Одновременно в больницу поступила Елена Соколова, благополучно беременная двойней - будущий кармический спутник Игоря. Но не в романтическом смысле - просто благодаря Елене наш Игорь пройдет через множество Edge-случаев...

В прошлой статье мы подробно разобрали феномен цветных коробок (в первую очередь голубых) для взлома аналоговых телефонных сетей в США. В этой части мы поговорим, какие варианты взломов практиковали в нашей стране.