Pull to refresh
39
0
Павлов Николай Александрович @ZyXI

Инженер

Не обязательно. У моего телефона (Ulefone Armor 20WT) нормальный безопасный пароль и доступ по отпечатку пальцев — и телефон периодически отказывается разблокироваться пока я не наберу пароль. И это не что‐то, что я специально настроил. И если я внезапно захочу набирать длинный пароль при каждом включении экрана мне достаточно удалить все отпечатки пальцев.

Этот же пароль используется для различных вещей вроде добавления новых отпечатков.

UTF-8 — вполне себе 8‐битная кодировка. Проблема легко пропадает, если основная (по числу пользователей) часть производителей ПО договариваются, что zip архив содержит имена в UTF-8 и модифицирует ПО соответственно. А т.к. имена в других 8‐битных кодировках с высокой степенью вероятности либо ASCII — валидный текст в UTF-8, — либо не валидный текст в UTF-8, то для открытия старых архивов вполне можно использовать локальную кодировку, если там не валидные имена. Всё ещё будут проблемы с открытием новых архивов в старых версиях ПО, но тут ничего сделать не получится.

Правда, я предпочитаю просто всегда использовать ASCII, так что понятия не имею, произошло ли что‐то подобное. Быстрое гугление показывает, что похоже вместо детектирования по невалидному UTF-8 в формат zip добавили возможность указания того, что используется UTF-8 — и произошло это ещё в 2006.

А зачем ИБП? Если ИБП не с двойным преобразованием, то ИБП в таком случае ничего не делает, кроме собственно обеспечения бесперебойного питания. Двойное преобразование тоже не имеет практического смысла при наличии разделительного трансформатора.
Кстати, а ИБП или стабилизаторы напряжения с двойным преобразованием тоже должны давать нужную развязку (если отключить bypass и если производитель не решил, что одну из линий питания нужно пропускать напрямую).

Относительно стабильности температуры: олово плавится и позволяет сделать из себя перемычку даже на выставленных 210℃, мелкие резисторы и всякие многоножки типа QFP (и даже QFN, если, конечно, речь не про контакт под пузом) я обычно паяю при выставленных 240℃, танталовые конденсаторы (точнее, тот их контакт, что соединён с полигоном на том же слое) и гребёнки 2,54 мм для комфортной пайки требуют уже 250—260℃, для чего‐то вроде проводов с сечением 0,35 мм² лучше выставить 280℃. Это с жалом K («большой топорик»).

Нормальные индукционные паяльники тоже разогревают быстро. У меня YIHUA-900H, нагревает жало менее, чем за 10 с. Совместим с аналогичными индукционными паяльниками от Quick (их жала легче достать), теплового сопротивления на контакте нагревателя и жала нет, т.к. используется другой способ нагрева, температура по ощущениям стабильная, но сенсор (то ли обычная термопара, то ли терморезистор, вставляется в жало туда же, куда у обычных паяльников нагревательный элемент) всё же измеряет температуру основания жала, так что при смене типа жала температуру приходится менять.
Плюсом то, что нагревается жало, а остальной металл нагревается от жала — впрочем, насколько я понимаю, если нагреватель встроить в жало, то будет примерно то же самое, с поправкой на то, что жалу будет легче нагреть подходящие к нему проводники.

Модифицированная синусоида — это частое явление при работе от недорогих ИБП, если они работают на батарее или являются ИБП с двойным преобразованием (т.е. работают либо в режиме сеть → постоянное напряжение → инвертор, либо батарея → инвертор). Правда, зачем запитывать паяльную станцию от ИБП мне не ясно, тем более что ИБП, рассчитанный на мощности, необходимые для нормальной пайки (т.е. для работы фена/стола для подогрева/ИК станции/печи — что‐то из этого, скорее всего будет) уже не такой уж недорогой и, скорее всего, будет иметь нормальную синусоиду.

Не заметил, что это перевод…

А можно спросить, что не так с релизацией макета в KiCAD? По моему опыту проектирования дорожек с дугами у последнего KiCAD всё лишь немного хуже, чем у Altium 18 (не знаю, как у более новых) — т.е. не так удобно, как обычные дорожки под 45° из‐за того, что всякое перетаскивание не работает (точнее, производит дорожки под 45°), но если вы не собираетесь делать что‐то вроде ведения параллельно 32 дорожек от микросхемы A к микросхеме B, то неудобства не такие уж большие.

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

Насколько я понимаю, логика здесь другая: не «никому SSO не нужно», а сначала «SSO может иногда ухудшить производительность и точно увеличит кодовую базу» с последующим «…, а ещё пересмотр решения нарушит обратную совместимость: мы пообещали в документации определённые особенности внутреннего представления и теперь часть unsafe кода зависит от них».
И насчёт выкинем: SSO был до 1.0?


Я замечу, что описанная в статье строка с SSO имеет четыре варианта: Box, &str, &'static str, small string. Почти наверняка в std такое бы не появилось, это оптимизация под конкретную задачу с допущениями, которые неприемлемы для стандартной библиотеки.

Я как‐то заказал у Резонита трафарет в котором на слое паяльной пасты сделал дополнительные отверстия, не соответствующие посадочным площадкам. Прислали трафарет без этих отверстий.
Я им написал, что трафарет неправильный и пусть они бесплатно переделают. Выяснилось, что Резонит не использует по‐умолчанию слой пасты для трафаретов, а генерирует их как‐то из других слоёв, кажется, из слоя маски — и, соответственно, этих отверстий там не должно было быть и, по их мнению, всё в порядке.
После указания на то, что, во‐первых, на сайте про это не слова, но написано про герберы для трафаретов в качестве одного из трёх вариантов заказа (второй — проекты из CAD, третий — трафарет можно заказать для платы, но без деталей относительно того, на основе чего он будет создаваться), во‐вторых, слой пасты в проекте предназначен именно для трафаретов и его использование ожидается от производителя и, в‐третьих, даже если бы я хотел приложить герберы повторно при заказе трафарета по проекту платы это сделать нельзя, они признали что не правы в части невозможности при заказе трафарета для платы повторно приложить герберы, которые я уже приложил при заказе платы, всё же переделали этот трафарет и сказали, что теперь при таких заказах можно прикладывать дополнительные файлы. Но на сайте всё ещё не сказано, что при заказе трафарета для платы слой пасты будет игнорироваться — возможно, правда, теперь не можно прикладывать дополнительный файлы, а обязательно их прикладывать — пока необходимости заказывать ещё трафаретов у меня не возникало.

Достаточно одного потока и связного списка определённого в виде


struct linked_list;
int linked_list_node_number(const struct linked_list *);
const struct linked_list *linked_list_next(const struct linked_list *);

extern const struct linked_list *start;

Попробуйте помодифицировать что‐то, не получив Undefined Behaviour. Для разумных программистов можно даже удалить все const — одной инкапсуляции достаточно.

Хочу спросить у Вас — как сохраняются разварки и поводки после воздействия лазером? Пережигает, не деформируются ли они?

Насколько я понимаю, лазер до них просто не достреливает, так что не пережигаются. Деформируются — не знаю, нас беспокоит наличие соединения кристалла с платой, а не форма проволочек. Если вскрытие неудачное, то мы смотрим, из‐за чего, так что я могу сказать, что бывали случаи, когда лаборатория пережигала проволочки, предположительно, кислотой (лазер бы выглядел по‐другому) или случайно застреливала микросхему лазером. Бывали и случаи, когда проволочки касались друг друга и их нужно было просто аккуратно отвести друг от друга — так что иногда от чего‐то деформируются. Не уверен, что от лазера.


И еще очень интересно, для чего нужно сохранить работоспособность открытого кристалла? Как это можно использовать?

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

Лазер для декапсуляции удобен, если не достреливать до кристалла. У нашей компании есть лаборатория, где производится декапсуляции, в том числе методом химического травления, причём нам требуется делать декапсуляцию без потери работоспособности. В ней стоит лазер для гравировки металла. Последовательность, насколько я знаю, обычно такая: сделать рентгеновские фотографии схемы сверху и сбоку, чтобы определить где именно находится кристалл. Частично удалить лазером корпус над или под кристаллом, не доходя до кристалла. Закончить работу уже кислотой.
Я думаю, если лазер будет портить схему (наш уж точно портит), то с канифолью этот метод тоже можно совместить, особенно если учесть отсутствие необходимости сохранять работоспособность — можно позволить себе оставлять более тонкий слой, не беспокоясь о том, что лазер убьёт микросхему. Просто оставляете немного корпуса над кристаллом, потом дотравляете канифолью, тратя меньше времени на этот этап. Вместо рентгеновских снимков прожигаете отверстие до кристалла там, где маркировки не ожидается и определяете толщину так: что‐то вроде «убрать прямоугольник над кристаллом толщиной 0,1 мм, в центре убрать ещё 0,1 мм и проверить, не показался ли кристалл, если кристалл нигде не показался, повторить процедуру (избегая центра)».

Готовых библиотек под Si5351 полно.

Я не сильно искал — мне нужно было сделать генерацию значений регистров для неё на LabVIEW, так что я нашёл одну какую‐то библиотеку с понятным кодом (C++ и под arduino) и переписал.


Только у нее есть проблемы с управлением фазой на низких частотах и она исключительно 3.3V.

Я не использовал её ни для чего, кроме генерации одного тактового сигнала 3,3 В, но datasheet говорит, что она может генерировать сигнал ещё и для номиналов 1,8 и 2,5 В. Её ядро, правда, согласно тому же datasheet запитать придётся минимум от 2,5 В. У неё есть какие‐то проблемы с пониженным питанием?

Если нужно управляемое тактирование для прототипов, то лучше взять какой‐нибудь из Si5351 — они дают от 8 кГц до 160 МГц и при необходимости несколько каналов. Правда, рассчитывать значения регистров для этих схем непросто, но к ним есть как документация (и программа) от производителя, так и минимум одна готовая реализации с открытым кодом.

И это объясняет индексацию по code point как именно? Вы вполне можете поступить как в Rust: индексация по code unit (в данном случае байтам), но попытка создать подстроку только с частью code point приводит к ошибке, требует предварительного преобразования строки в массив байт или требует использования unsafe и считается ошибкой программиста в случае успеха.
И вполне понятно, зачем они это сделали: так одновременно получается индексация за O(1) и при этом вы не платите в четыре раза больше байт за строку/не усложняете себе жизнь поддержкой трёх возможных размеров code unit и не занимаетесь постоянным перегоном в/из UTF-8. Реализации разных операций со строками это обычно либо совсем не усложняет, либо добавляет простые проверки на попадание на границы символов.

Сложность/невозможность работы за чужими компьютерами.

Сильно зависит от пользователя. Я использую programming dvorak с некоторыми дополнениями на компьютере и просто набираю двумя пальцами за чужими компьютерами — обычно мне не нужно что‐то долго набирать в этих случаях.


Очень сложный/неудобный набор на мобильной клавиатуре. Swipe вообще перестаёт адекватно распознавать жесты.

Зачем вообще менять раскладку мобильной клавиатуры? Всё равно десятипальцевый метод использовать не получится.


2 набора шорткатов при переключении языков РУС ↔ ENG. При использовании русского языка шорткаты остаются привязанными к QWERTY.

В своё время меня это достаточно задолбало, чтобы я нашёл способ решить проблему. Решилась она, оказывается, очень просто: я взял свой проект programming dvorak для MS keyboard layout creator и заменил в нём английские буквы на русские и также цифровой ряд. В результате получилась стандартная русская раскладка с дополнительными символами, которые были добавлены в мой проект programming dvorak, при этом всякие <C-?>/<A-?>/… стали использовать расположение английских букв из проекта, который был взят за основу.
Хотя, конечно, это хак и хорошо бы MS KLC позволял бы настроить расположение английских букв для клавиатурных сочетаний более очевидным способом.

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

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


Я не понимаю, о чём вы.

Дополнительный код. Все отрицательные числа в нём больше, чем положительные, если вы сравниваете число, как если бы оно было беззнаковым. Многие современные компиляторы знают, что i32val >= len || i32val < 0 — это то же самое, что и (i32val as u32) >= len (при условии, что известно, что len >= 0). Вот, к примеру, результат компиляции на Rust:


use core::hint::unreachable_unchecked;

pub fn invalid_index(index: usize, len: usize) -> bool {
    index >= len
}

pub unsafe fn invalid_index_i_unsafe(index: isize, len: isize) -> bool {
    if len < 0 { unsafe { unreachable_unchecked() } }
    index >= len || index < 0
}

pub fn invalid_index_i(index: isize, len: isize) -> bool {
    index >= len || index < 0
}

playground::invalid_index:
    cmpq    %rsi, %rdi
    setae   %al
    retq

playground::invalid_index_i_unsafe:
    cmpq    %rsi, %rdi
    setae   %al
    retq

playground::invalid_index_i:
    cmpq    %rsi, %rdi
    setge   %cl
    testq   %rdi, %rdi
    sets    %al
    orb %cl, %al
    retq

Многомерных массивов может «не быть»: я не говорю о том, что язык их не поддерживает (хотя иногда и такое бывает), а о том, что способ их реализации не подходит для вашей задачи. Из языков, которыми достаточно часто пользуюсь лично я, многомерные массивы вида «один большой кусок памяти плюс набор размеров массива» (один из наиболее производительных вариантов) со всеми размерами определяемыми во время исполнения без библиотек поддерживает только LabVIEW. (Со сторонними библиотеками — все, если не считать различные DSL.)

На самом деле нет: в качестве базового адреса используется адрес на одну ячейку перед первым.

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


Если мы про Python, Java и т.п. языки, отказавшиеся от поддержки беззнаковых целых, то сравнения с нулём всё равно не избежать.

В общем, для компьютера разницы нет никакой, разница есть только для людей.

У Python есть отдельная семантика для отрицательных индексов. Конкретно для него был бы другой вопрос, если бы он начинал индексы с единицы: почему в нуле дырка (или что‐то ещё более неожиданное).
У Java: нет, сравнение с нулём все ещё не нужно на большинстве машин, если вспомнить, как представляются знаковые целые в памяти.


Для компьютера разница была пока улучшения в процессоре и оптимизирующих компиляторах её не убрали.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity