Запрещение звёздочек в имени файла — это защита от дурака в неправильном месте. В *sh вам даже пробелы в имени проблем доставят — теперь запретить пробелы в ядре? Просто кому‐то надо было собраться и исправить язык командной оболочки пока не было слишком поздно (т.е. слишком много скриптов).
Нет. Вы формируете в личном кабинете заказ: указываете технологические параметры печатной платы и прикладываете файлы, необходимые для производства (у нас это пачка герберов и NC Drill file). При этом в интерфейсе указывается примерная цена (по опыту больше похоже на нижнюю границу). Потом на проект смотрит инженер, предлагает (или не предлагает) что‐то исправить и, когда все исправления сделаны, выдаёт итоговую цену. Обычно инженер отвечает в тот же или на следующий день (рекорд: отправка проекта на производство в течении четверти часа от создания заказа).
Теоретически за этот промежуток времени (от четверти часа до дня) можно набрать заказов на всю заготовку. Практически я в это как‐то не верю — но, возможно, нас просто быстро обслуживают.
Ничего не поменялось. В нашей компании обычно нужна доставка готовых плат за неделю, иногда бывают форс‐мажоры, когда плата нужна ещё вчера. Резонит делает довольно быстро, весьма часто доставляет больше плат, чем нужно.
Относительно масок: сейчас они берут +1 500 рублей за нестандартную маску и отрезают возможность сверхсрочного заказа. За нестандартную (т.е. не‐белую при не‐белой маске) шелкографию ещё отрезают возможность заказать на каких‐либо линиях, кроме долгого крупносерийного производства с договорной ценой (подозреваю, что это линия «отошлём вашу плату китайцам»). Но вы всё ещё можете заказать не‐зелёную плату без увеличения цены: есть вариант использования белой маски и зелёных надписей. Выглядит отлично, пока вы не начнёте собственно паять: любая грязь (в т.ч. пригоревший флюс) весьма заметна. Впрочем, это хороший повод её оттереть потщательнее.
Насколько я понял, 1 500 рублей берётся один раз за заказ и не умножается на коэффициенты срочности.
В linux речь идёт, вообще‐то, совершенно не о чувствительности к регистру. Имя файла здесь — это произвольный набор байт, в котором не может быть только косой черты (прямой, обратная может быть), разделяющей каталоги, и нулевого байта, исторически означающего конец строки. Это позволяет обрабатывать доступ к файлам весьма эффективно: вам не нужно нормализовывать имена перед сравнением и делать кэши нормализованных имён просто чтобы файловый доступ работал быстро (где‐то на хабре, кстати, проскакивала статья про эти кэши).
Соответственно в linux если вы не хотите помнить «где большие буквы», то вы просто настраиваете автодополнение. В GUI оно обычно так и работает (и не настраивается), в командной строке — не всегда. Может быть не очень удобно, но это делает разработку linux проще, а доступ к файлам быстрее. (Ещё, конечно, это создаёт целый класс ошибок (иногда потенциально приводящих к уязвимостям) в скриптах на *sh, но тут я бы спрашивал с разработчиков языка и с тех, кто до сих пор его не заменил.)
Конечно есть и ещё один минус: если имя файла — произвольная последовательность байт, то сразу начинается проблема с определением, в какой кодировке оно записано и, соответственно, как интерпретировать имя файла для отображения в GUI. К счастью, современные системы все просто используют UTF-8, а во всех стандартных каталогах ASCII.
Этот вариант только вносит совершенно лишний хаос: непонятно какие приставки когда чего означают. Оперативка 8 ГБ, к сожалению 8 ГиБ, просто пока «ложь» в вашу пользу вы не хотите её замечать. Бодрейт, к примеру, никогда не измерялся в замаскированных под килобиты в секунду кибибитах в секунду.
Кроме того, ряд киби‐, меби‐, … идёт без дробных и промежуточных префиксов, что не нарушает целостности системы. А сам стандарт, на который вы ссылаетесь, прямо пишет вещи вроде
The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states “This practice frequently leads to confusion and is deprecated.” Further confusion results from the popular use of a “megabyte” consisting of 1 024 000 bytes to define the capacity of the familiar “1.44-MB” diskette.
и
Contrast with the SI prefix mega (M) equal to 106, as in a 1-Mb/s data transfer rate, which is equal to 1 000 000 bits per second.
. Т.е. они прямо написали, что стандарт указывает такие множители только для отражения текущего способа использования. И даже привели несколько примеров когда они используются по‐другому. И ещё, там нигде нет определения тера‐ и бо́льших множителей, тогда как сейчас жёсткий диск на N ТБ довольно частое явление.
«Литровая» бутылка тут не в тему, литровой её называете вы потому что вам лениво произносить «бутылка ёмкостью 930 мл». И они честно пишут 930 мл и даже не имеют ввиду, что 1 мл = 1/1 024 л. Для того, чтобы с этим что‐то сделать нужен закон о том, что объёмы жидкостей в упаковках должны быть выбраны из указанных в законе ряда номиналов, никакое изменение определения «мили‐» или «литр» тут не поможет.
Ещё один человек не знает, что переменные в bash нужно окружать кавычками. Сравните
a=( a "" b )
for e in ${a[@]} ; do
echo \"$e\"
done
с
a=( a "" b )
for e in "${a[@]}" ; do
echo \"$e\"
done
. Ну и кроме того, в bash в массиве можно хранить только строки. И вообще это единственный скалярный тип: сравните вывод
i=11-1
declare -i i
declare -p i
у bash и zsh (или ksh, кстати). В bash нет никаких скалярных типов, кроме строки, а declare не приводит к исполнению арифметических выражений уже имеющихся в переменной, поэтому это выведет declare -i i="11-1" — если бы переменная была бы типизирована, то такое было бы в принципе невозможно (впрочем, они могли бы притворится, что типизированные переменные у них есть, а реально всё равно хранить строки). В zsh же есть типы и строку поместить в целочисленную переменную не получится, поэтому declare не может не сконвертировать i в число, поэтому код выведет typeset -i i=10. (В ksh — declare -i i=10.)
Rust не ограничен try!.. И с таким подходом я не могу не знать, есть ли у функции «исключения». В go могли бы сделать и лучше. Но, тем не менее, порядок исполнения там весьма ясен. Мне вполне нравится работать в Python, в некоторых случаях оставляя длинные traceback’и как сообщения об ошибках, а в некоторых ловя всё подряд и запихивая в лог. Но я никогда бы не выбрал ни [Micro]Python (ни C++) для embedded, даже если бы мог (если для конкретной ИС есть нужный компилятор) (хотя C++ далеко не за исключения, тем более что их можно отключить): прокидывание «максимума полезной информации» — это последняя вещь, что мне здесь нужна, потому что её ещё надо как‐то достать. А вот однозначный порядок исполнения (хотя и нарушаемый иногда прерываниями) весьма полезен. И Rust мне весьма понравился (хотя я делал на нём один‐единственный проект, только проект сразу был прошивкой для stm’ки).
Я, наверное, не ясно высказался: я не против ни исключений, ни goto. Я просто вижу, что исключения легко могут быть хуже goto, особенно если отладочную информацию в них не положить.
Только теперь вы уже не можете быть уверены в том, как будет исполняться программа. Наличие исключений — это как замаскированный (и ограниченный до «только вверх по стёку») longjump практически из любого места программы. Если есть checked exceptions то у вас хотя бы есть идея о том, что может быть выброшено. Но обычно их нет. Отлично понимаю авторов Rust и Go, у которых нет исключений в традиционном виде, а то что есть не предполагается для использования таким образом. Часто механизм удобен, но идея их использования в сложноотлаживаемых приложениях (у меня в основном embedded) мне не нравится.
Туда можно отлично перетащить archive.org. И хостинги для всякой мелочи (блоги, сайты‐визитки, …). Если результат будет удобнее, то пользователи будут вполне охотно работать.
Надо просто принять закон, обязующий компании хранить все полученные данные о пользователях неограниченное время. Тогда все находящиеся в стране, принявшей закон, компании получат (частичную) защиту от GDPR (а сама страна получит ухудшение репутации и, может быть, что‐то ещё похуже). Как думаете, кто‐нибудь так сделает?
И, кстати, gdb ещё и напишет вам размер прошивки при выполнении команды load. Получение его из ELF — это ещё одна лишняя команда. А bin файл может содержать лишние нули.
Вопрос не в том, сколько она длится. Вопрос, зачем оно вообще нужно? Кроме того, bin‐файл это один непрерывный кусок данных без каких‐либо смещений. Что означает, что во‐первых, если там будут разрывы (а они будут если сказать компоновщику распихать секции по разным регионам памяти), то вы будете отправлять лишние нули. И, во‐вторых, смещение должны указать вы, что является абсолютно бесполезным копированием магических чисел. И зачем говорить «отправь файл на устройство по адресу X», если можно просто сказать «отправь файл на устройство»?
Openocd предоставляет сервер, связывающийся по протоколу удалённой отладки. Gdb умеет отправлять прошивку серверу, которые отправляет её дальше на устройство, но т.к. с пользователем в этом случае взаимодействует именно gdb, а openocd просто запускается один раз где‐то в фоне, то это «gdb отправляет файлы».
Ещё я бы убрал возню с main.bin. St-link нормально поддерживается openocd, а gdb умеет отправлять на устройство ELF файлы. (Дамп памяти тоже можно gdb сделать, но я не знаю, как делать это эффективно.) Зачем записывать с st-flash, если можно сразу познакомить с gdb, тем более что отладчик всё равно понадобится для реальной разработки?
Насколько я вижу на картинках, CapsLock там всё ещё есть. И левый Ctrl. Так что если бы у меня вдруг оказался MacBook, то Vim я использовал бы также: нашёл как настроить, чтобы на левом Ctrl оказался Esc, а на CapsLock оказался левый Ctrl. Так гораздо удобнее. Ну и ещё Esc и <C-[> — это в Vim одно и то же.
Я такого, кстати, не предлагал. Компиляторы сейчас умные, могут часто что‐то вывести. Rust вот вставил проверку на выход за пределы массива, с расчётом на то, что компилятор во многих случаях её обратно уберёт. (Оверхед на декремент на фоне этого выглядит такой мелочью…)
Другим безопасным вариантом отрицательной индексации тогда будет использование разных типов для положительных и отрицательных индексов (предполагая статически типизированный язык, в динамически типизированных предложение имеет мало смысла). Т.е., к примеру, у вас положительные индексы типа usize, отрицательные типа isize и всё остальное индексом быть не может. Константам компилятор пропишет правильный тип автоматически, но никаких (в Rust) автоматических приведений типа нет.
По‐моему самое сложное в рисовании такого сумматора — это найти определение «суперпараллельного переноса». Гугл его не знает. После этого после применения метода Куайна отлично рисуются любые цифровые схемы, где не нужно учитывать задержки.
// Я как‐то даже писал программу на Python, которая генерировала отчёт на LaTeX о том, как создать «программу для светофора» (читай: конечный автомат; на входе меандр от таймера, на выходе сигналы светофора), оптимизируя именно методом Квайна. Конечно, можно было и написать руками: в программе не было ни одного стороннего модуля (т.е. я не использовал готовое решение), только стандартная библиотека Python. Но зачем нам тогда технологии?
Ничего не поняли, потому что я много пишу на C — обращение к элементам что со структурой struct { Type *elements; } data;, что со структурой struct { Type elements[]; } data; будет выглядеть как data.elements[i]. Вы правы, тут будет пересчёт, но C это успешно скрывает.
Со служебной информацией не согласен: этот пересчёт производится в аллокаторе, независимо от вашего желания. Но перед этим всё равно будет инкремент, потому что шансы на то, что компилятор вставит тело free() в вашу функцию сейчас равны нулю. (И, кстати, все ли аллокаторы хранят служебные данные перед выделенной памятью?)
С тем, что с современными десктопными системами пересчёт индекса будет незаметен я согласен. Но в нишу C вы не пролезете. И, главное, не только пользователи будут допускать ошибки с непривычки. Но и у вас будут ошибки — как я говорил выше, первая реализация языка не пишется на самом языке, а мало что из списка ЯП с первым индексом‐единицей подходит для создания нового языка.
Запрещение звёздочек в имени файла — это защита от дурака в неправильном месте. В *sh вам даже пробелы в имени проблем доставят — теперь запретить пробелы в ядре? Просто кому‐то надо было собраться и исправить язык командной оболочки пока не было слишком поздно (т.е. слишком много скриптов).
Нет. Вы формируете в личном кабинете заказ: указываете технологические параметры печатной платы и прикладываете файлы, необходимые для производства (у нас это пачка герберов и NC Drill file). При этом в интерфейсе указывается примерная цена (по опыту больше похоже на нижнюю границу). Потом на проект смотрит инженер, предлагает (или не предлагает) что‐то исправить и, когда все исправления сделаны, выдаёт итоговую цену. Обычно инженер отвечает в тот же или на следующий день (рекорд: отправка проекта на производство в течении четверти часа от создания заказа).
Теоретически за этот промежуток времени (от четверти часа до дня) можно набрать заказов на всю заготовку. Практически я в это как‐то не верю — но, возможно, нас просто быстро обслуживают.
Ничего не поменялось. В нашей компании обычно нужна доставка готовых плат за неделю, иногда бывают форс‐мажоры, когда плата нужна ещё вчера. Резонит делает довольно быстро, весьма часто доставляет больше плат, чем нужно.
Относительно масок: сейчас они берут +1 500 рублей за нестандартную маску и отрезают возможность сверхсрочного заказа. За нестандартную (т.е. не‐белую при не‐белой маске) шелкографию ещё отрезают возможность заказать на каких‐либо линиях, кроме долгого крупносерийного производства с договорной ценой (подозреваю, что это линия «отошлём вашу плату китайцам»). Но вы всё ещё можете заказать не‐зелёную плату без увеличения цены: есть вариант использования белой маски и зелёных надписей. Выглядит отлично, пока вы не начнёте собственно паять: любая грязь (в т.ч. пригоревший флюс) весьма заметна. Впрочем, это хороший повод её оттереть потщательнее.
Насколько я понял, 1 500 рублей берётся один раз за заказ и не умножается на коэффициенты срочности.
В linux речь идёт, вообще‐то, совершенно не о чувствительности к регистру. Имя файла здесь — это произвольный набор байт, в котором не может быть только косой черты (прямой, обратная может быть), разделяющей каталоги, и нулевого байта, исторически означающего конец строки. Это позволяет обрабатывать доступ к файлам весьма эффективно: вам не нужно нормализовывать имена перед сравнением и делать кэши нормализованных имён просто чтобы файловый доступ работал быстро (где‐то на хабре, кстати, проскакивала статья про эти кэши).
Соответственно в linux если вы не хотите помнить «где большие буквы», то вы просто настраиваете автодополнение. В GUI оно обычно так и работает (и не настраивается), в командной строке — не всегда. Может быть не очень удобно, но это делает разработку linux проще, а доступ к файлам быстрее. (Ещё, конечно, это создаёт целый класс ошибок (иногда потенциально приводящих к уязвимостям) в скриптах на *sh, но тут я бы спрашивал с разработчиков языка и с тех, кто до сих пор его не заменил.)
Конечно есть и ещё один минус: если имя файла — произвольная последовательность байт, то сразу начинается проблема с определением, в какой кодировке оно записано и, соответственно, как интерпретировать имя файла для отображения в GUI. К счастью, современные системы все просто используют UTF-8, а во всех стандартных каталогах ASCII.
Этот вариант только вносит совершенно лишний хаос: непонятно какие приставки когда чего означают. Оперативка 8 ГБ, к сожалению 8 ГиБ, просто пока «ложь» в вашу пользу вы не хотите её замечать. Бодрейт, к примеру, никогда не измерялся в замаскированных под килобиты в секунду кибибитах в секунду.
Кроме того, ряд киби‐, меби‐, … идёт без дробных и промежуточных префиксов, что не нарушает целостности системы. А сам стандарт, на который вы ссылаетесь, прямо пишет вещи вроде
и
. Т.е. они прямо написали, что стандарт указывает такие множители только для отражения текущего способа использования. И даже привели несколько примеров когда они используются по‐другому. И ещё, там нигде нет определения тера‐ и бо́льших множителей, тогда как сейчас жёсткий диск на N ТБ довольно частое явление.
«Литровая» бутылка тут не в тему, литровой её называете вы потому что вам лениво произносить «бутылка ёмкостью 930 мл». И они честно пишут 930 мл и даже не имеют ввиду, что 1 мл = 1/1 024 л. Для того, чтобы с этим что‐то сделать нужен закон о том, что объёмы жидкостей в упаковках должны быть выбраны из указанных в законе ряда номиналов, никакое изменение определения «мили‐» или «литр» тут не поможет.
Ещё один человек не знает, что переменные в bash нужно окружать кавычками. Сравните
с
. Ну и кроме того, в bash в массиве можно хранить только строки. И вообще это единственный скалярный тип: сравните вывод
у bash и zsh (или ksh, кстати). В bash нет никаких скалярных типов, кроме строки, а declare не приводит к исполнению арифметических выражений уже имеющихся в переменной, поэтому это выведет
declare -i i="11-1"— если бы переменная была бы типизирована, то такое было бы в принципе невозможно (впрочем, они могли бы притворится, что типизированные переменные у них есть, а реально всё равно хранить строки). В zsh же есть типы и строку поместить в целочисленную переменную не получится, поэтому declare не может не сконвертироватьiв число, поэтому код выведетtypeset -i i=10. (В ksh —declare -i i=10.)Rust не ограничен try!.. И с таким подходом я не могу не знать, есть ли у функции «исключения». В go могли бы сделать и лучше. Но, тем не менее, порядок исполнения там весьма ясен. Мне вполне нравится работать в Python, в некоторых случаях оставляя длинные traceback’и как сообщения об ошибках, а в некоторых ловя всё подряд и запихивая в лог. Но я никогда бы не выбрал ни [Micro]Python (ни C++) для embedded, даже если бы мог (если для конкретной ИС есть нужный компилятор) (хотя C++ далеко не за исключения, тем более что их можно отключить): прокидывание «максимума полезной информации» — это последняя вещь, что мне здесь нужна, потому что её ещё надо как‐то достать. А вот однозначный порядок исполнения (хотя и нарушаемый иногда прерываниями) весьма полезен. И Rust мне весьма понравился (хотя я делал на нём один‐единственный проект, только проект сразу был прошивкой для stm’ки).
Я, наверное, не ясно высказался: я не против ни исключений, ни goto. Я просто вижу, что исключения легко могут быть хуже goto, особенно если отладочную информацию в них не положить.
Только теперь вы уже не можете быть уверены в том, как будет исполняться программа. Наличие исключений — это как замаскированный (и ограниченный до «только вверх по стёку») longjump практически из любого места программы. Если есть checked exceptions то у вас хотя бы есть идея о том, что может быть выброшено. Но обычно их нет. Отлично понимаю авторов Rust и Go, у которых нет исключений в традиционном виде, а то что есть не предполагается для использования таким образом. Часто механизм удобен, но идея их использования в сложноотлаживаемых приложениях (у меня в основном embedded) мне не нравится.
Туда можно отлично перетащить archive.org. И хостинги для всякой мелочи (блоги, сайты‐визитки, …). Если результат будет удобнее, то пользователи будут вполне охотно работать.
Надо просто принять закон, обязующий компании хранить все полученные данные о пользователях неограниченное время. Тогда все находящиеся в стране, принявшей закон, компании получат (частичную) защиту от GDPR (а сама страна получит ухудшение репутации и, может быть, что‐то ещё похуже). Как думаете, кто‐нибудь так сделает?
Если нельзя использовать динамическую линковку, то можно задействовать
dlopen().И, кстати, gdb ещё и напишет вам размер прошивки при выполнении команды
load. Получение его из ELF — это ещё одна лишняя команда. А bin файл может содержать лишние нули.Вопрос не в том, сколько она длится. Вопрос, зачем оно вообще нужно? Кроме того, bin‐файл это один непрерывный кусок данных без каких‐либо смещений. Что означает, что во‐первых, если там будут разрывы (а они будут если сказать компоновщику распихать секции по разным регионам памяти), то вы будете отправлять лишние нули. И, во‐вторых, смещение должны указать вы, что является абсолютно бесполезным копированием магических чисел. И зачем говорить «отправь файл на устройство по адресу X», если можно просто сказать «отправь файл на устройство»?
Openocd предоставляет сервер, связывающийся по протоколу удалённой отладки. Gdb умеет отправлять прошивку серверу, которые отправляет её дальше на устройство, но т.к. с пользователем в этом случае взаимодействует именно gdb, а openocd просто запускается один раз где‐то в фоне, то это «gdb отправляет файлы».
Ещё я бы убрал возню с main.bin. St-link нормально поддерживается openocd, а gdb умеет отправлять на устройство ELF файлы. (Дамп памяти тоже можно gdb сделать, но я не знаю, как делать это эффективно.) Зачем записывать с st-flash, если можно сразу познакомить с gdb, тем более что отладчик всё равно понадобится для реальной разработки?
Насколько я вижу на картинках, CapsLock там всё ещё есть. И левый Ctrl. Так что если бы у меня вдруг оказался MacBook, то Vim я использовал бы также: нашёл как настроить, чтобы на левом Ctrl оказался Esc, а на CapsLock оказался левый Ctrl. Так гораздо удобнее. Ну и ещё Esc и
<C-[>— это в Vim одно и то же.Гм. Я сейчас посмотрел на то, где эти проверки есть. Получилось, что
unsafeкод с функцией доступа к массиву по индексу без проверки.Собственно, я думал будет больше языков без проверок для системного программирования. Оказывается, нет. Все делают проверки.
Я такого, кстати, не предлагал. Компиляторы сейчас умные, могут часто что‐то вывести. Rust вот вставил проверку на выход за пределы массива, с расчётом на то, что компилятор во многих случаях её обратно уберёт. (Оверхед на декремент на фоне этого выглядит такой мелочью…)
Другим безопасным вариантом отрицательной индексации тогда будет использование разных типов для положительных и отрицательных индексов (предполагая статически типизированный язык, в динамически типизированных предложение имеет мало смысла). Т.е., к примеру, у вас положительные индексы типа
usize, отрицательные типаisizeи всё остальное индексом быть не может. Константам компилятор пропишет правильный тип автоматически, но никаких (в Rust) автоматических приведений типа нет.По‐моему самое сложное в рисовании такого сумматора — это найти определение «суперпараллельного переноса». Гугл его не знает. После этого после применения метода Куайна отлично рисуются любые цифровые схемы, где не нужно учитывать задержки.
// Я как‐то даже писал программу на Python, которая генерировала отчёт на LaTeX о том, как создать «программу для светофора» (читай: конечный автомат; на входе меандр от таймера, на выходе сигналы светофора), оптимизируя именно методом Квайна. Конечно, можно было и написать руками: в программе не было ни одного стороннего модуля (т.е. я не использовал готовое решение), только стандартная библиотека Python. Но зачем нам тогда технологии?
Ничего не поняли, потому что я много пишу на C — обращение к элементам что со структурой
struct { Type *elements; } data;, что со структуройstruct { Type elements[]; } data;будет выглядеть какdata.elements[i]. Вы правы, тут будет пересчёт, но C это успешно скрывает.Со служебной информацией не согласен: этот пересчёт производится в аллокаторе, независимо от вашего желания. Но перед этим всё равно будет инкремент, потому что шансы на то, что компилятор вставит тело
free()в вашу функцию сейчас равны нулю. (И, кстати, все ли аллокаторы хранят служебные данные перед выделенной памятью?)С тем, что с современными десктопными системами пересчёт индекса будет незаметен я согласен. Но в нишу C вы не пролезете. И, главное, не только пользователи будут допускать ошибки с непривычки. Но и у вас будут ошибки — как я говорил выше, первая реализация языка не пишется на самом языке, а мало что из списка ЯП с первым индексом‐единицей подходит для создания нового языка.