Странно, что у вас в списке есть geda-project (про который я почти ничего не слышал), но нет KiCAD. И я, кажется, понимаю, почему ничего не слышал:
На сайте среди сборок по ссылке в разделе «Windows Binaries» можно найти релизы 2011 года и сборки snapshot’ов до 2017. Другими словами, под Windows они «не работают». На самом деле в разделе загрузок SF есть какой‐то pcbinst-4.2.2.exe (изменённый почти на месяц позже pcb-4.2.2.tar.gz) с ажно 72‐мя загрузками с начала февраля прошлого года, но я его нашёл только потому, что искал дату релиза и где бы посмотреть на репозиторий исходного кода, не скачивая его. Есть ли установщики для других частей gEDA я не проверял.
Не знаю, что с footprint’ами и символами для схем в библиотеке по‐умолчанию, но тот же https://componentsearchengine.com/ поддерживает KiCAD, но не gEDA.
Разработка практически не идёт. Здесь есть релиз 13‐месячной давности, релиз 2‐годовой давности и т.д. Там же можно видеть как между commit’ами проходят недели или месяцы, а число изменённых строк исчисляется десятками, в редких случаях сотней‐другой строк. (У gschem дела вроде немного получше идут, что нелогично: pcb должно быть сложнее, значит, требовать больше внимания.)
То, что у меня и в QRCode не очень умеет. Я как‐то отсканировал серийный номер мультиметра им, так он его корректно отсканировал, после чего показал сообщение с общим смыслом «я насканировал X, это не URI и я не знаю, как открыть, поэтому пошёл ты нафиг, скопировать не дам».
Я решил проблему, написав дополнение для Vim, транслитерирующее ввод: такой подход позволяет использовать только одну (английскую) раскладку для ввода (для которой я ещё и освоил слепую печать), хотя и не всегда удобен. Думал как‐нибудь написать на замену что‐то более системное — разобраться, как вводятся иероглифы и сделать по аналогии, но до этого как‐то не дошло.
Либерализм в синтаксисе ни к чему хорошему не приводит. Лучше простой и однозначный синтаксис, без вольностей.
С таблицами не всё так однозначно. Ваш вариант лучше markdown, когда в ячейках много текста, но его не удобно читать и с большим количеством колонок он не очень удобен. Вариант markdown лучше читается, если в таблице немного нешироких колонок, но редактировать его неудобно. Лучше всего с таблицами в reStructuredText, где их четыре варианта (но из четырёх вариантов grid table, правда, весьма неудобен для написания и не слишком нужен): simple table для таблиц без большого количества текста в столбцах, csv для отображения чего‐то генерируемого, list на случай, когда текст не влезает нормально в simple. Эти три нормально редактируются и два из трёх (кроме csv) нормально читаются (насколько вообще нормально могут читаться таблицы в plaintext).
Зачем вообще нужно, чтобы таблицы можно было записать единственным способом?
У автора есть выбор: вставить сноску или переформулировать текст, чтобы было понятно куда ведёт ссылка. Второе предпочтительнее независимо от поддержки сносок.
Это не значит, что все так делают.
Да, ничего страшного не произойдёт.
Просто будет некрасиво.
Вы хотите писать как попало, но получать что хотите? Довольно бессмысленная хотелка.
Почему «как попало»? Я хочу, чтобы в исходниках было красиво, а в HTML хотя бы читаемо.
Отвыкайте уже говорить за всех. Да и от незначимости пробелов тоже отвыкайте. Python, YAML, TOML, Tree — полно языков со значимыми пробелами. А в остальных языках по рукам всё равно бьют линтеры, приучая внимательно относиться ко всем символам.
А сколько языков со значимыми пробелами в середине строки? В Python, YAML и TOML если вы можете написать в каком‐то месте один пробел, то превращение его в два может изменить семантику ровно в двух случаях:
Вы находитесь внутри строкового литерала или чего‐то подобного, где пробел имеет значение «байт 0x20».
Вы находитесь в начале строки, где пробел означает отступ.
Если в этих языках пробел в некоторой позиции просто разделяет токены, его всегда можно безбоязненно удваивать, что очень часто используется для выравнивания.
(Возможно, за исключением tree. Я его не использовал и не знаю спецификации.)
Это должно быть понятно из текста ссылки, а не из урла.
Кому должно? Язык это как‐то гарантирует?
Ставьте пробел после последнего слова и оно не будет переноситься.
Чтобы пробел оказался в ссылке? Кроме того, я говорил про слишком короткую строку из‐за URL. Пробел с этим не поможет ровным счётом никак.
Проверьте сами: …
Markdown хорош в том числе потому, что на нём можно писать письма в plain text и их будут понимать в таком виде. Судя по тому, что я увидел на сайте, у вас новая строка — это всегда новый абзац, а элемент списка не может содержать несколько абзацев. Первое неприемлемо для писем в plain text. Второе — просто недостаток по сравнению с markdown.
Для этого есть преформатированные блоки.
Это не в тему. Если я хочу что‐то выровнять в исходном коде, это не значит, что я хочу что‐то выровнять в результирующем HTML. (Или что оно там не выравнивается другими средствами, впрочем к вашему языку это не относится.) Или, скорее, это не значит, что я считаю, что оформление текста как кода будет выглядеть лучше, чем отсутствие выравнивания в результате.
И везде, пробелы тут не уникальны.
Нажать пробел два раза не проблема — вам даже не нужно промахиваться клавишей. Или скопировать что‐то, ошибившись с границей на символ. Заметить это сложно, всего лишь два пробела не производят визуального мусора. Кроме того, все имевшие дело с программированием привыкли, что за некоторыми исключениями количество пробелов не имеет значения, что делает результат ошибки неожиданным.
Сокращалка ссылок означает, что я не могу посмотреть на ссылку и решить, нужно ли мне по ней переходить вообще.
Кроме того, это никак не решает другую проблему: если текст в формате markdown пишется для того, чтобы читали собственно текст в формате markdown, а не получаемый из него HTML¹, то при ограничении ширины одной строки в N символов (от N тут зависит только то, насколько часто возникает проблема, поэтому я не привёл конкретное число), без такого синтаксиса будет часто встречаться ситуация, когда одна строка слишком короткая (и, возможно, содержит только часть текста ссылки), а на следующей URL и последнее слово текста ссылки. Иметь слишком короткую строку мне не нравится, как и разрывать текст ссылки в случае, если он состоит из нескольких слов. Загромождать текст URL, когда URL ведёт на какой‐то справочный материал, нужный только тем, кто не знает термин из текста ссылки, тоже не очень.
И что не так с поддержкой таких ссылок? Там же не требуется оставлять ссылки в порядке их упоминания в тексте или даже присваивать им номера.
Кстати, двойной пробел не годится по таким же соображениям: если текст пишется, чтобы читаться «как есть», а не в виде HTML, то двойной пробел в тексте может возникнуть как минимум по следующим причинам:
Отступ. И да, иногда начинать даже абзац с кода, встроенного в строку, нужно. А тут вопрос, можно ли начать строку с кода, что совсем не то же самое.
Конец предложения. В английском языке, вообще‐то, (было) принято делать двойной пробел после конца предложения, просто это сейчас мало кто соблюдает. В качестве примера можете посмотреть в документацию Vim. В русском языке, насколько мне известно, такого принято не было, но вы ведь не только для русского предлагаете?
Выравнивание. Иногда текст выглядит лучше, если какой‐то элемент расположен строго под другим.
Просто ошибка.
Замечу, что только конец предложения и выравнивание не могут появится у того, кто беспокоится только о результирующем HTML. Отступ возникнет при использовании списков. Ошибка может быть допущена всегда. А ещё конец предложения абсолютно корректен во всех других известных мне форматах разметки, и может даже быть привычкой: посмотрите, к примеру, на сообщения Bram Moolenaar в vim-dev.
¹: Ситуация у меня возникает, как правило, в трёх случаях:
если нет штатной возможности использовать форматирование;
если я хочу отправить письмо в виде простого текста;
если я пишу README — обычно то, для чего я пишу README не выкладывается на github/…, и смотрят результат все (включая меня) текстовым редактором.
bool вообще‐то уже хранится как u1, с довеском из семи бит, всегда равных нулю, существующим исключительно по технических причинам. А вот единичную систему счисления для чисел почему‐то не используют.
Вообще, если рассматривать bool как u1, то никаких разных семантик нет. Кроме того, подход, когда операторов слишком много, делает изучение языка и чтение программ ещё сложнее.
Если вам очень нужны дополнительные операторы, то для их реализации всегда можно использовать макросы. По крайней мере, так тот, кто будет читать программу, будет знать, что значение дополнительных операторов нужно начинать искать в документации на присутствующий в коде макрос. А вы сами дважды подумаете, нужно ли вам заморачиваться с не слишком лёгкими в реализации макросами, или вам достаточно будет функций.
Не понял, кто устанавливает детали вплотную и причём тут ленточка? Если плата не разведена, то нужно настраивать DRC. Если плата разведена, то ленточка не поможет: либо вы нагреваете феном/ИК и тогда после нагревания припой сам притянет компонент на место, достаточно иметь какой‐то зазор между компонентами. Либо вы паяете паяльником, тогда вам будет не до ленточки, потому что если вы не держите компонент пинцетом, то он встаёт на дыбы (я про мелкие SMD резисторы и конденсаторы). Или сдвигается паяльником куда‐то не туда.
Зачем нужны отдельно not и побитовое отрицание, если ! либо будет делать то же, что и not, либо его нельзя будет применить к булевым, а not в любом случае нельзя применить ко не‐булевым? && и || — это особый случай из‐за short-circuit и, соответственно, необходимости особого отношения со стороны компилятора.
error: expected expression, found reserved identifier `_`
--> src/main.rs:2:20
|
2 | println!("{}", _);
| ^ expected expression
error[E0425]: cannot find value `_s` in this scope
--> src/main.rs:3:20
|
3 | println!("{}", _s);
| ^^ not found in this scope
Ещё где‐то на Rust’овских форумах где‐то было обсуждение по поводу того, что let _ = foo приводит к немедленному освобождению foo, а сохранение в неиспользуемую переменную — к освобождению по выходу из контекста, из‐за чего что‐то работало неправильно.
Кроме того, т.к. в начале скрипта написано #!/bin/bash, то в этом скрипте можно просто использовать shopt -s nullglob и никаких проблем с пустыми каталогами не будет.
Насколько мне известно, в lua можно спокойно все переносы строк заменять на пробелы (с обычным исключением в виде многострочных строковых литералов). Вот ещё и пробелы убрать часто будет нельзя, но сделать программу для удаления тех, каких можно, довольно легко.
А почему, кстати, вы говорите именно про переносы строк? Перенос строки, пробел, точка с запятой или ещё какой разделитель все занимают по одному байту, а вам важно уменьшить число служебных символов в принципе (чему больше мешает do…end вместо фигурных скобок, чем какие‐то там новые строки), а не конкретно переносов строк.
Один нужно как‐то перенацеливать. Перед массивом можно поставить оптику так, чтобы разные лазеры в результате стреляли в разные стороны. Второе работает намного быстрее и меньше изнашивается.
Потому что для того, чтобы stdout был перенаправлен в title.html оболочке нужно сначала настроить stdout, а потом запустить exec, чтобы заменить себя на cat: cat не может настроить сам себе stdout, о > title.html знает только оболочка, это не аргумент cat. Т.к. в данном случае вы попросили обрезать выходной файл, то последовательность действий выглядит примерно так:
Оболочка клонирует себя, создавай дочерний процесс.
В дочернем процессе настраивается stdout: открывается файл title.html (сразу с обрезанием), закрывается старый stdout, открытый файл становится новым stdout.
С настроенным stdout дочерний процесс, бывший клоном оболочки, заменяет себя на cat.
cat читает файл и выдаёт его в stdout, но файл‐то уже обрезан!
Точная последовательность и реализация зависит от оболочки, некоторые оболочки почему‐то даже предпочитают сохранить старый stdout куда‐то, заменить его на новый и только потом клонировать себя, после завершения же дочернего процесса закрыть новый stdout и вернуть старый на место. Если хотите посмотреть, как делает ваша оболочка, то запустите strace $SHELL -c 'cat title.html > title.html'.
Но в любом случае, вы не сможете получить отличного поведения никаким образом, пока > title.html не станет аргументом, который интерпретирует cat (точнее, ваша замена cat, потому как сам cat такого не умеет): оболочка просто не может обрезать файл после чтения (которое ещё и будет выполняться кусками вперемешку с записью), а использование временных файлов или чего‐то в этом роде противоречит спецификации конструкции перенаправления вывода.
Тупо non‐reentrant VI? А где хранятся данные? В контролах или сдвиговых регистрах?
В сдвиговых регистрах. Хранить что‐то в контролах неудобно. Но в тесте была именно action engine — т.е. все операции типа «считать, изменить, записать» должны происходить внутри VI — ещё одна причина использовать всё же DVR, хоть они и медленнее. Защищать доступ к VI семафорами смысла не имеет — семафоры в LabVIEW очень, очень медленные.
Варианту же все равно надо указывать какой тип надо десериализировать, так же ж?
Variant выдаст вам ошибку, если вы десериализовываете не то, что сериализовали. Точнее, если вы десериализовываете во что‐то, что не может быть неявно приведено из того, что вы десериализовали.
Я ж енумом выбираю как десерализировать и обрабатывать данные, какие еще ошибки?
Данные сериализуются и отправляются в одном месте, а десериализовываются и обрабатываются в другом. Если вы сериализовали не то, что ожидается для данного значения enum, то будет ошибка. А т.к. это комбинация enum+variant, а не ADT, и компилятор ничего не проверяет, то вы вполне можете так сделать.
Если вы сериализуете в LabVIEW с помощью flatten to string с выкидыванием типа (самый простой способ получить сериализацию в бинарный формат, я именно так сохраняю в бинарный журнал), то при десериализации на другом конце ошибок в принципе не будет, если десериализовывать стандартными средствами, или возможность детектирования того, что что‐то пришло не то, будет ограничена (можно вручную проверить размер, иногда присутствие определённого шаблона в enum, но не более того — сериализованный таким образом кластер с четырьмя байтами от одного целого вы никогда не отличите).
Нет. В СУВТ переключатель хранится отдельно от значений. Кстати, в СУВТ и структуры можно вставлять, и юнионы, и указатели, и даже другие СУВТ.
Отдельно или нет, в структуре struct { enum TypeEnum { a, b, c } type; union { double a; int64_t b; uint64_t c; } }type без #pragma pack займёт не менее 8 байт из‐за выравнивания. Если СУВТ означает не структуру с union и enum, а что‐то ещё вроде struct { enum TypeEnum type; void *data; }, то это как‐то неоптимально, а б64 для type начинает выглядеть странно.
Кстати, в LabVIEW есть аналог сишного указателя (data value reference) — очень удобно шарить данные в параллельных VI и участках схем, при этом атомарность операций доступа к данным обеспечивается in place element structure, необходимой для доступу к ним. Советую попробовать.
DVR из‐за этой атомарности не слишком хороший аналог указателя: слишком тормозит на блокировках. Лучше, чем ничего, но я как‐то проверял параллельный доступ на запись с разной реализацией «глобальных» переменных. Всех побила реализация типа «action engine» с приоритетом subroutine и non‐reentrant типом исполнения. Учитывая, что non‐reentrant тип исполнения — это по сути та же критическая секция (и, кстати, DVR бил всё остальное до того, как я догадался проверить ускорение от subroutine), то DVR могли бы и не проигрывать.
Это меня сильно расстроило, т.к. я к тому времени в своём проекте уже избавился от всего подряд глобального (т.е. non‐reentrant VI и глобальных переменных в обоих видах) и вводить что‐то из этого обратно совершенно не собирался. И да, я использую DVR. В каком‐то из LabVIEW в DVR даже добавили возможность параллельного чтения (т.е. два разных потока могут читать данные из одного DVR одновременно; записать, конечно, ни один не может).
Хорошее замечание. Я в Лабвью решаю эту проблему комбинацией енума и сериализированных в строку данных, которые потом десериализируются и обрабатываются в зависимости от значения енума. Вручную делать это неудобно и в Метапроге я для подобных случаев делаю СУВТ.
При использовании variant вы получите ошибку в runtime и довольно быструю сериализацию. Если сериализовывать чем‐то вроде flatten to string (тот же variant, но можно выкинуть тип), то вы сэкономите память, но ошибку при посылке не того типа можно и не получить. Если сериализовывать чем‐то вроде JSON, то ошибку вы получите, но расходы на (де)сериализацию сильно увеличатся, т.к. variant ближе к представлению в памяти.
Здесь СУВТ — это структура из беззнакового 64-битного (б64) переключателя и юниона из трех возможных типов. Значению переключателя 17 соответствует беззнаковый 8-битный (б8) тип, значению переключателя 86 — 64-битная дробь, он же float/double, значению переключателя 9 — знаковое 64-битное. Обратите внимание, что в отличие от Лабвью знаковые типы обозначаются отдельным от беззнаковых цветом (светло-голубым).
А почему 64‐битного? Это для любой СУВТ так или здесь дело в том, что из‐за присутствия д64 и з64 переключатель будет в любом случае занимать по сути 8 байт из‐за выравнивания и метапрог просто не даёт об этом факте забыть?
Это ужас. Когда такое ввели? Я толком не пользовался Лабвью после 2013, ради совместимости с ХР.
В 2017. В 2018 ещё добавили type specialization structure, позволяющую иметь несколько вариантов диаграм. Разумеется, в духе утиной типизации вместо того, чтобы сделать способ описания типа в переключателе диаграммы выбор конкретного варианта осуществляется путём перебора всех вариантов по порядку, пока какой‐то из них не скомпилируется. Конкретные ошибки компиляции у mallable VI вы в 2018 не увидите: сведения об ошибке ограничиваются тем, что LabVIEW не находит подходящий вариант.
В общем, mallable VI полезные и я их часто использую, но выглядят они как будто программисты решали задачу «нам нужны generic’и — давайте сделаем их как можно проще, чтобы сделать их как можно быстрее к релизу».
Удивляюсь как можно так тупить вместо того, чтобы придумать СУВТ. Да и вообще сделать LabVIEW NXG не на самом LabVIEW, а на какой-то унылой скриптухе от M$ — чистейшей воды идиотизм.
Вообще‐то далеко не самый плохой выбор для UI, сама LabVIEW в этом отношении была бы хуже. И, насколько я понял, это переделка в первую очередь UI и формата хранения VI — и то, и то всё равно нужно было сделать давно, а то что это за графический язык без zoom, зато с IDE, которая падает, если падает компилятор, и который сохраняется в формате, совершенно неудобном для использования с VCS. Компилятор у NXG вроде остался тот же, на основе LLVM.
Странно, что у вас в списке есть geda-project (про который я почти ничего не слышал), но нет KiCAD. И я, кажется, понимаю, почему ничего не слышал:
То, что у меня и в QRCode не очень умеет. Я как‐то отсканировал серийный номер мультиметра им, так он его корректно отсканировал, после чего показал сообщение с общим смыслом «я насканировал X, это не URI и я не знаю, как открыть, поэтому пошёл ты нафиг, скопировать не дам».
Я решил проблему, написав дополнение для Vim, транслитерирующее ввод: такой подход позволяет использовать только одну (английскую) раскладку для ввода (для которой я ещё и освоил слепую печать), хотя и не всегда удобен. Думал как‐нибудь написать на замену что‐то более системное — разобраться, как вводятся иероглифы и сделать по аналогии, но до этого как‐то не дошло.
С таблицами не всё так однозначно. Ваш вариант лучше markdown, когда в ячейках много текста, но его не удобно читать и с большим количеством колонок он не очень удобен. Вариант markdown лучше читается, если в таблице немного нешироких колонок, но редактировать его неудобно. Лучше всего с таблицами в reStructuredText, где их четыре варианта (но из четырёх вариантов grid table, правда, весьма неудобен для написания и не слишком нужен): simple table для таблиц без большого количества текста в столбцах, csv для отображения чего‐то генерируемого, list на случай, когда текст не влезает нормально в simple. Эти три нормально редактируются и два из трёх (кроме csv) нормально читаются (насколько вообще нормально могут читаться таблицы в plaintext).
Зачем вообще нужно, чтобы таблицы можно было записать единственным способом?
Это не значит, что все так делают.
Просто будет некрасиво.
Почему «как попало»? Я хочу, чтобы в исходниках было красиво, а в HTML хотя бы читаемо.
А сколько языков со значимыми пробелами в середине строки? В Python, YAML и TOML если вы можете написать в каком‐то месте один пробел, то превращение его в два может изменить семантику ровно в двух случаях:
Если в этих языках пробел в некоторой позиции просто разделяет токены, его всегда можно безбоязненно удваивать, что очень часто используется для выравнивания.
(Возможно, за исключением tree. Я его не использовал и не знаю спецификации.)
Кому должно? Язык это как‐то гарантирует?
Чтобы пробел оказался в ссылке? Кроме того, я говорил про слишком короткую строку из‐за URL. Пробел с этим не поможет ровным счётом никак.
Markdown хорош в том числе потому, что на нём можно писать письма в plain text и их будут понимать в таком виде. Судя по тому, что я увидел на сайте, у вас новая строка — это всегда новый абзац, а элемент списка не может содержать несколько абзацев. Первое неприемлемо для писем в plain text. Второе — просто недостаток по сравнению с markdown.
Это не в тему. Если я хочу что‐то выровнять в исходном коде, это не значит, что я хочу что‐то выровнять в результирующем HTML. (Или что оно там не выравнивается другими средствами, впрочем к вашему языку это не относится.) Или, скорее, это не значит, что я считаю, что оформление текста как кода будет выглядеть лучше, чем отсутствие выравнивания в результате.
Нажать пробел два раза не проблема — вам даже не нужно промахиваться клавишей. Или скопировать что‐то, ошибившись с границей на символ. Заметить это сложно, всего лишь два пробела не производят визуального мусора. Кроме того, все имевшие дело с программированием привыкли, что за некоторыми исключениями количество пробелов не имеет значения, что делает результат ошибки неожиданным.
Сокращалка ссылок означает, что я не могу посмотреть на ссылку и решить, нужно ли мне по ней переходить вообще.
Кроме того, это никак не решает другую проблему: если текст в формате markdown пишется для того, чтобы читали собственно текст в формате markdown, а не получаемый из него HTML¹, то при ограничении ширины одной строки в N символов (от N тут зависит только то, насколько часто возникает проблема, поэтому я не привёл конкретное число), без такого синтаксиса будет часто встречаться ситуация, когда одна строка слишком короткая (и, возможно, содержит только часть текста ссылки), а на следующей URL и последнее слово текста ссылки. Иметь слишком короткую строку мне не нравится, как и разрывать текст ссылки в случае, если он состоит из нескольких слов. Загромождать текст URL, когда URL ведёт на какой‐то справочный материал, нужный только тем, кто не знает термин из текста ссылки, тоже не очень.
И что не так с поддержкой таких ссылок? Там же не требуется оставлять ссылки в порядке их упоминания в тексте или даже присваивать им номера.
Кстати, двойной пробел не годится по таким же соображениям: если текст пишется, чтобы читаться «как есть», а не в виде HTML, то двойной пробел в тексте может возникнуть как минимум по следующим причинам:
Замечу, что только конец предложения и выравнивание не могут появится у того, кто беспокоится только о результирующем HTML. Отступ возникнет при использовании списков. Ошибка может быть допущена всегда. А ещё конец предложения абсолютно корректен во всех других известных мне форматах разметки, и может даже быть привычкой: посмотрите, к примеру, на сообщения Bram Moolenaar в vim-dev.
¹: Ситуация у меня возникает, как правило, в трёх случаях:
Кстати, валидный JSON — это ещё и валидный YAML.
boolвообще‐то уже хранится какu1, с довеском из семи бит, всегда равных нулю, существующим исключительно по технических причинам. А вот единичную систему счисления для чисел почему‐то не используют.Вообще, если рассматривать
boolкакu1, то никаких разных семантик нет. Кроме того, подход, когда операторов слишком много, делает изучение языка и чтение программ ещё сложнее.Если вам очень нужны дополнительные операторы, то для их реализации всегда можно использовать макросы. По крайней мере, так тот, кто будет читать программу, будет знать, что значение дополнительных операторов нужно начинать искать в документации на присутствующий в коде макрос. А вы сами дважды подумаете, нужно ли вам заморачиваться с не слишком лёгкими в реализации макросами, или вам достаточно будет функций.
Не понял, кто устанавливает детали вплотную и причём тут ленточка? Если плата не разведена, то нужно настраивать DRC. Если плата разведена, то ленточка не поможет: либо вы нагреваете феном/ИК и тогда после нагревания припой сам притянет компонент на место, достаточно иметь какой‐то зазор между компонентами. Либо вы паяете паяльником, тогда вам будет не до ленточки, потому что если вы не держите компонент пинцетом, то он встаёт на дыбы (я про мелкие SMD резисторы и конденсаторы). Или сдвигается паяльником куда‐то не туда.
А что такое «анмэндж/нативный код» у Rust?
Зачем нужны отдельно
notи побитовое отрицание, если!либо будет делать то же, что иnot, либо его нельзя будет применить к булевым, аnotв любом случае нельзя применить ко не‐булевым?&&и||— это особый случай из‐за short-circuit и, соответственно, необходимости особого отношения со стороны компилятора.Это не переменная: попробуйте скомпилировать
Сразу видно, что
_s— переменная, а_— нет.Ещё где‐то на Rust’овских форумах где‐то было обсуждение по поводу того, что
let _ = fooприводит к немедленному освобождениюfoo, а сохранение в неиспользуемую переменную — к освобождению по выходу из контекста, из‐за чего что‐то работало неправильно.Кроме того, т.к. в начале скрипта написано
#!/bin/bash, то в этом скрипте можно просто использоватьshopt -s nullglobи никаких проблем с пустыми каталогами не будет.Насколько мне известно, в lua можно спокойно все переносы строк заменять на пробелы (с обычным исключением в виде многострочных строковых литералов). Вот ещё и пробелы убрать часто будет нельзя, но сделать программу для удаления тех, каких можно, довольно легко.
А почему, кстати, вы говорите именно про переносы строк? Перенос строки, пробел, точка с запятой или ещё какой разделитель все занимают по одному байту, а вам важно уменьшить число служебных символов в принципе (чему больше мешает
do…endвместо фигурных скобок, чем какие‐то там новые строки), а не конкретно переносов строк.Один нужно как‐то перенацеливать. Перед массивом можно поставить оптику так, чтобы разные лазеры в результате стреляли в разные стороны. Второе работает намного быстрее и меньше изнашивается.
Потому что для того, чтобы stdout был перенаправлен в title.html оболочке нужно сначала настроить stdout, а потом запустить exec, чтобы заменить себя на cat: cat не может настроить сам себе stdout, о
> title.htmlзнает только оболочка, это не аргументcat. Т.к. в данном случае вы попросили обрезать выходной файл, то последовательность действий выглядит примерно так:cat.catчитает файл и выдаёт его в stdout, но файл‐то уже обрезан!Точная последовательность и реализация зависит от оболочки, некоторые оболочки почему‐то даже предпочитают сохранить старый stdout куда‐то, заменить его на новый и только потом клонировать себя, после завершения же дочернего процесса закрыть новый stdout и вернуть старый на место. Если хотите посмотреть, как делает ваша оболочка, то запустите
strace $SHELL -c 'cat title.html > title.html'.Но в любом случае, вы не сможете получить отличного поведения никаким образом, пока
> title.htmlне станет аргументом, который интерпретируетcat(точнее, ваша заменаcat, потому как самcatтакого не умеет): оболочка просто не может обрезать файл после чтения (которое ещё и будет выполняться кусками вперемешку с записью), а использование временных файлов или чего‐то в этом роде противоречит спецификации конструкции перенаправления вывода.В сдвиговых регистрах. Хранить что‐то в контролах неудобно. Но в тесте была именно action engine — т.е. все операции типа «считать, изменить, записать» должны происходить внутри VI — ещё одна причина использовать всё же DVR, хоть они и медленнее. Защищать доступ к VI семафорами смысла не имеет — семафоры в LabVIEW очень, очень медленные.
Variant выдаст вам ошибку, если вы десериализовываете не то, что сериализовали. Точнее, если вы десериализовываете во что‐то, что не может быть неявно приведено из того, что вы десериализовали.
Данные сериализуются и отправляются в одном месте, а десериализовываются и обрабатываются в другом. Если вы сериализовали не то, что ожидается для данного значения enum, то будет ошибка. А т.к. это комбинация enum+variant, а не ADT, и компилятор ничего не проверяет, то вы вполне можете так сделать.
Если вы сериализуете в LabVIEW с помощью flatten to string с выкидыванием типа (самый простой способ получить сериализацию в бинарный формат, я именно так сохраняю в бинарный журнал), то при десериализации на другом конце ошибок в принципе не будет, если десериализовывать стандартными средствами, или возможность детектирования того, что что‐то пришло не то, будет ограничена (можно вручную проверить размер, иногда присутствие определённого шаблона в enum, но не более того — сериализованный таким образом кластер с четырьмя байтами от одного целого вы никогда не отличите).
Отдельно или нет, в структуре
struct { enum TypeEnum { a, b, c } type; union { double a; int64_t b; uint64_t c; } }typeбез#pragma packзаймёт не менее 8 байт из‐за выравнивания. Если СУВТ означает не структуру с union и enum, а что‐то ещё вродеstruct { enum TypeEnum type; void *data; }, то это как‐то неоптимально, а б64 дляtypeначинает выглядеть странно.DVR из‐за этой атомарности не слишком хороший аналог указателя: слишком тормозит на блокировках. Лучше, чем ничего, но я как‐то проверял параллельный доступ на запись с разной реализацией «глобальных» переменных. Всех побила реализация типа «action engine» с приоритетом subroutine и non‐reentrant типом исполнения. Учитывая, что non‐reentrant тип исполнения — это по сути та же критическая секция (и, кстати, DVR бил всё остальное до того, как я догадался проверить ускорение от subroutine), то DVR могли бы и не проигрывать.
Это меня сильно расстроило, т.к. я к тому времени в своём проекте уже избавился от всего подряд глобального (т.е. non‐reentrant VI и глобальных переменных в обоих видах) и вводить что‐то из этого обратно совершенно не собирался. И да, я использую DVR. В каком‐то из LabVIEW в DVR даже добавили возможность параллельного чтения (т.е. два разных потока могут читать данные из одного DVR одновременно; записать, конечно, ни один не может).
При использовании variant вы получите ошибку в runtime и довольно быструю сериализацию. Если сериализовывать чем‐то вроде flatten to string (тот же variant, но можно выкинуть тип), то вы сэкономите память, но ошибку при посылке не того типа можно и не получить. Если сериализовывать чем‐то вроде JSON, то ошибку вы получите, но расходы на (де)сериализацию сильно увеличатся, т.к. variant ближе к представлению в памяти.
А почему 64‐битного? Это для любой СУВТ так или здесь дело в том, что из‐за присутствия д64 и з64 переключатель будет в любом случае занимать по сути 8 байт из‐за выравнивания и метапрог просто не даёт об этом факте забыть?
В 2017. В 2018 ещё добавили type specialization structure, позволяющую иметь несколько вариантов диаграм. Разумеется, в духе утиной типизации вместо того, чтобы сделать способ описания типа в переключателе диаграммы выбор конкретного варианта осуществляется путём перебора всех вариантов по порядку, пока какой‐то из них не скомпилируется. Конкретные ошибки компиляции у mallable VI вы в 2018 не увидите: сведения об ошибке ограничиваются тем, что LabVIEW не находит подходящий вариант.
В общем, mallable VI полезные и я их часто использую, но выглядят они как будто программисты решали задачу «нам нужны generic’и — давайте сделаем их как можно проще, чтобы сделать их как можно быстрее к релизу».
Вообще‐то далеко не самый плохой выбор для UI, сама LabVIEW в этом отношении была бы хуже. И, насколько я понял, это переделка в первую очередь UI и формата хранения VI — и то, и то всё равно нужно было сделать давно, а то что это за графический язык без zoom, зато с IDE, которая падает, если падает компилятор, и который сохраняется в формате, совершенно неудобном для использования с VCS. Компилятор у NXG вроде остался тот же, на основе LLVM.