А в чём смысл запускать [ --… ] (с закрывающей скобкой) и test --…? В статье же написано, что второе работать и не должно (точнее, должно, но только как проверка пустоты строки), а второе может показывать help/version только потому что без закрывающей скобки команда некорректна.
В моей Gentoo округлённые до КиБ размеры совпадают с вашими. Должно быть связано либо с версией coreutils (у меня — 8.32), либо с разрядностью системы (64).
Не знаю, как китайцы, но Резонит пишет, что могут сделать переходное отверстие 0,1 мм за совсем дорого (точнее, с ценой «по запросу»). Не вижу, где было бы написано, что использовался jlcpcb.
Если вы не испарите часть корпуса самолёта одним коротким импульсом, то тепло просто рассеется сначала по корпусу, потом в атмосфере. Мелкий космический мусор же можно сравнительно медленно нагреть до испарения — скидывать тепло он может лишь медленно излучением и побыстрее — испаряя вещество с поверхности, что собственно и нужно. Я не думаю, что для такой цели будут использовать мощные импульсные лазеры, если можно обойтись чем‐то попроще. С птицами примерно то же самое, только с охлаждением у них похуже.
Операторы лазера, правда, могут попытаться попасть в глаза птице, пилоту или пассажирам (птице легче — их не защищает стекло, тем самым требуя использовать оптические системы наведения, и меньше вероятность, что между лазером и глазом будет корпус). Их даже испарять не потребуется.
Версию не помню, но это KiCAD-5* не более, чем двухмесячной давности. Но проверять лучше на последней ночной сборке, может там всё же сделали сортировку перед сохранением, тем более что это некритично, а 5* должны заменить на 6*, надеюсь, скоро.
И результат будет отдельным файлом, при этом решающим только задачу «получить список файлов в архиве без распаковки». Смещения начала файлов в нём не указаны, так что достать один файл он вам не поможет, даже если вы используете несжатый архив. Во всяком случае, именно так выглядит результат создания index‐файла с помощью --index-file.
Вообще некоторой доработкой формата можно было бы добиться нужного эффекта: просто научите tar дописывать этот index‐файл в конец архива (для совместимости: не в виде файла, а просто в виде некорректных данных после конца архива) и передавать xz параметр --block-list с такими значениями, чтобы один файл соответствовал одному блоку. Но это мало кому нужно, и вызывает необходимость что‐то делать с разными особыми случаями вроде «что делать, если файл обрезали после того, как tar передал --block-list но до того, как он начал запаковывать файл» (вопрос, в принципе, решаемый, если вы засунете xz внутрь tar или сделаете так, чтобы xz принимал на вход поток команд, а не просто поток данных).
А в PCB вы добавили на плату что‐то — KiCAD вам всё остальное, что вы не трогали, сохранил в другом порядке. Иногда даже работает, когда вы ничего не изменили, но перезаполнили все полигоны (т.е. запустили DRC с соответствующей галочкой).
Не удивлюсь, если в шестой версии он также будет всё переупорядочивать в schematic: там теперь более читаемые s-expr вместо того, что вы написали выше.
Символическая ссылка — это технически обычный файл, содержащий путь к тому файлу, на который он ссылается и имеющий атрибут, указывающий, что это символическая ссылка. Чтобы сохранять их вам нужно просто иметь возможность считывать и сохранять этот атрибут и читать содержимое файла‐ссылки вместо содержимого того файла, куда она указывает. Замечу, что вас при этом вообще никак не интересует, куда указывает символическая ссылка.
Сохранения информации вида «этот файл имеет тот же inode, что и файл X за пределами архива» (т.е. сохранения «жёстких ссылок») от архиватора не ожидают и, наоборот, все сильно расстроятся, если архиватор будет это делать (поскольку это либо уязвимость, либо бесполезная информация, либо повреждение распакованного файла). Сохранять информацию вида «это тот же файл, что и файл Y в архиве» можно, распаковывать потом с использованием жёстких ссылок — тоже, но обычно никто не заморачивается, поскольку жёсткие ссылки используются сильно реже.
Для динамически типизированных языков расширение типа не представляет только технической проблемы. Вам всё ещё нужно понять, как это отразится на реальных программах: будет ли при этом легче/сложнее программисту допустить ошибку, будет ли легче/сложнее понимать программу, …
Расширение типа на usize | T вместо чего‐то вроде бросания исключения или завершения программы означает, что если программист ошибочно пропустил 0 в индекс, то ошибка обнаружится не в месте возникновения, а там, где вы попытаетесь использовать usize как T и не сможете. Более того, большинство новичков будут с непривычки читать array[0] как получение первого элемента. Хуже пожалуй только LabVIEW’шная выдача значения по‐умолчанию при выходе за границы: тут, скорее всего, при ошибке программа просто станет работать в режиме «мусор на входе — мусор на выходе», а вы будете долго думать, откуда на входе появился мусор.
Это плюс одно сравнение, если n не константа, и, что намного важнее, тип выражения a[0] для массива [T] внезапно становится usize | T вместо просто T. Это абсолютно никому не нужно, даже выдавать «значение по‐умолчанию» как делает LabVIEW со всеми выходами за границы массива и то лучше.
Поправьте меня если я неправ, но зная про Pascal и его строки только разные слухи я могу предположить, что
Это относится только к строкам.
Если в Pascal есть тип строки, позволяющий строки длиннее 255 байт, то у этого типа длину строки таким образом получить не получится.
CMake — это ещё ничего. Я вот для своих проектов по привычке использую пути, безопасные (не требующие экранирования) для bash, а коллеги используют пути вида D:\Испытания 2020\…. Обычно всё работает, но иногда вылезает что‐то вроде «openssh не может открыть указанный ему в командной строке конфиг» или «LabVIEW внезапно решил начать падать при открытии именно этого моего проекта именно из этого пути». Не буду говорить про LabVIEW, но OpenSSH — тоже весьма значимый проект. И, в отличие от CMake, теперь поставляется вместе с Windows.
Странно, что у вас в списке есть 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/…, и смотрят результат все (включая меня) текстовым редактором.
А в чём смысл запускать
[ --… ](с закрывающей скобкой) иtest --…? В статье же написано, что второе работать и не должно (точнее, должно, но только как проверка пустоты строки), а второе может показывать help/version только потому что без закрывающей скобки команда некорректна.В моей Gentoo округлённые до КиБ размеры совпадают с вашими. Должно быть связано либо с версией coreutils (у меня — 8.32), либо с разрядностью системы (64).
Не знаю, как китайцы, но Резонит пишет, что могут сделать переходное отверстие 0,1 мм за совсем дорого (точнее, с ценой «по запросу»). Не вижу, где было бы написано, что использовался jlcpcb.
Если вы не испарите часть корпуса самолёта одним коротким импульсом, то тепло просто рассеется сначала по корпусу, потом в атмосфере. Мелкий космический мусор же можно сравнительно медленно нагреть до испарения — скидывать тепло он может лишь медленно излучением и побыстрее — испаряя вещество с поверхности, что собственно и нужно. Я не думаю, что для такой цели будут использовать мощные импульсные лазеры, если можно обойтись чем‐то попроще. С птицами примерно то же самое, только с охлаждением у них похуже.
Операторы лазера, правда, могут попытаться попасть в глаза птице, пилоту или пассажирам (птице легче — их не защищает стекло, тем самым требуя использовать оптические системы наведения, и меньше вероятность, что между лазером и глазом будет корпус). Их даже испарять не потребуется.
Версию не помню, но это KiCAD-5* не более, чем двухмесячной давности. Но проверять лучше на последней ночной сборке, может там всё же сделали сортировку перед сохранением, тем более что это некритично, а 5* должны заменить на 6*, надеюсь, скоро.
И результат будет отдельным файлом, при этом решающим только задачу «получить список файлов в архиве без распаковки». Смещения начала файлов в нём не указаны, так что достать один файл он вам не поможет, даже если вы используете несжатый архив. Во всяком случае, именно так выглядит результат создания index‐файла с помощью
--index-file.Вообще некоторой доработкой формата можно было бы добиться нужного эффекта: просто научите tar дописывать этот index‐файл в конец архива (для совместимости: не в виде файла, а просто в виде некорректных данных после конца архива) и передавать xz параметр
--block-listс такими значениями, чтобы один файл соответствовал одному блоку. Но это мало кому нужно, и вызывает необходимость что‐то делать с разными особыми случаями вроде «что делать, если файл обрезали после того, как tar передал--block-listно до того, как он начал запаковывать файл» (вопрос, в принципе, решаемый, если вы засунетеxzвнутрь tar или сделаете так, чтобыxzпринимал на вход поток команд, а не просто поток данных).А в PCB вы добавили на плату что‐то — KiCAD вам всё остальное, что вы не трогали, сохранил в другом порядке. Иногда даже работает, когда вы ничего не изменили, но перезаполнили все полигоны (т.е. запустили DRC с соответствующей галочкой).
Не удивлюсь, если в шестой версии он также будет всё переупорядочивать в schematic: там теперь более читаемые s-expr вместо того, что вы написали выше.
Символическая ссылка — это технически обычный файл, содержащий путь к тому файлу, на который он ссылается и имеющий атрибут, указывающий, что это символическая ссылка. Чтобы сохранять их вам нужно просто иметь возможность считывать и сохранять этот атрибут и читать содержимое файла‐ссылки вместо содержимого того файла, куда она указывает. Замечу, что вас при этом вообще никак не интересует, куда указывает символическая ссылка.
Сохранения информации вида «этот файл имеет тот же inode, что и файл X за пределами архива» (т.е. сохранения «жёстких ссылок») от архиватора не ожидают и, наоборот, все сильно расстроятся, если архиватор будет это делать (поскольку это либо уязвимость, либо бесполезная информация, либо повреждение распакованного файла). Сохранять информацию вида «это тот же файл, что и файл Y в архиве» можно, распаковывать потом с использованием жёстких ссылок — тоже, но обычно никто не заморачивается, поскольку жёсткие ссылки используются сильно реже.
А ещё присваивание там не statement, просто оно возвращает
(), а не присвоенное значение. PlaygroundДля динамически типизированных языков расширение типа не представляет только технической проблемы. Вам всё ещё нужно понять, как это отразится на реальных программах: будет ли при этом легче/сложнее программисту допустить ошибку, будет ли легче/сложнее понимать программу, …
Расширение типа на
usize | Tвместо чего‐то вроде бросания исключения или завершения программы означает, что если программист ошибочно пропустил 0 в индекс, то ошибка обнаружится не в месте возникновения, а там, где вы попытаетесь использоватьusizeкакTи не сможете. Более того, большинство новичков будут с непривычки читатьarray[0]как получение первого элемента. Хуже пожалуй только LabVIEW’шная выдача значения по‐умолчанию при выходе за границы: тут, скорее всего, при ошибке программа просто станет работать в режиме «мусор на входе — мусор на выходе», а вы будете долго думать, откуда на входе появился мусор.Это плюс одно сравнение, если
nне константа, и, что намного важнее, тип выраженияa[0]для массива[T]внезапно становитсяusize | Tвместо простоT. Это абсолютно никому не нужно, даже выдавать «значение по‐умолчанию» как делает LabVIEW со всеми выходами за границы массива и то лучше.Поправьте меня если я неправ, но зная про Pascal и его строки только разные слухи я могу предположить, что
CMake — это ещё ничего. Я вот для своих проектов по привычке использую пути, безопасные (не требующие экранирования) для bash, а коллеги используют пути вида
D:\Испытания 2020\…. Обычно всё работает, но иногда вылезает что‐то вроде «openssh не может открыть указанный ему в командной строке конфиг» или «LabVIEW внезапно решил начать падать при открытии именно этого моего проекта именно из этого пути». Не буду говорить про LabVIEW, но OpenSSH — тоже весьма значимый проект. И, в отличие от CMake, теперь поставляется вместе с Windows.Странно, что у вас в списке есть 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.