cmd.exe использует кодировку настроенную в системе. И системные вызовы используют её. Если по вашему оно работает не так, как вы думаете,то это не значит что оно говно, вы просто не разобрались.
И второе: альтернативы для простых и не очень скриптов которые массово запускаются, например, при сборке - не существует. Запуск pwsh или python существенно дольше, хоть и функций сильно больше, но они нужны далеко не всегда, и это говно надо ставить, а кмд доступен из коробки.
Так, как настроена система. Есть же понятие ACP (ANSI Code Page). Вот в региональных настройках можно выбрать желаемую, щас по моему флажок для utf8 есть. Можно в реестре по старинке. Кодовая страница для utf8 - 65001.
cmd-файлы в ansi и соотв должны следовать настройкам системы.
В начале статьи есть некоторая тавтология, в погоне за объяснить простое простым, а в результате по моему ничего не объяснили.
Выглядит он примерно следующим образом. Интерпретатор быстро компилирует JS-код в байт "на лету". Полученный байт код начинает исполняться и параллельно обрабатывается оптимизатором.
Интерпретатор по определению ничего не генерирует и тем более не компилирует. Компиляцией занимается компилятор. То о чем вы пишите в целом - так и называется - многоуровневая компиляция (tiered compilation).
то фактически используется объединение типов FileForReading|FileForWriting|FileForReadingAndWriting
Отличный пример отвратительной реализации чего-то что этим не является.
Я рад что где-то есть развитая система типов, но, использовать её ради оберток вокруг файловых дескрипторов - это как то перебор. С файлами можно не только в читать и писать, а файл, а точнее его хэндл/дескриптор можно передать в другой процесс, например, по пайпу на всех ОС (ну точнее не во всех по пайпу, но смысл телепортации есть во всех "настоящих" ОС).
Иначе говоря вы ввели 3 абстракции, 3 типа и это универсально не применимо, потому что кроме RW есть и "Other" операции.
Это конечно отлично, что вы осведомлены о разрешенных операциях на этапе компиляции, только, это все обычно утыкается в обычный булевый флаг-параметр, который совсем не всегда константа и весь этот выпендреж едет лесом. Всего-то надо позвать функцию ОС и сделать это удобно.
Я использую Arch, но как я уже и сказал, я совсем не любитель раста. Я не могу сказать, что противник, потому что хейтить его нет времени. Мне попадались вроде интересные проекты, но если все утрировать, то да: мне тоже кажется что в основном там задача переизобрести что-то, непонятно назвать и это еще нормально, новое поколение подросло, ну и старое играется. Но пихать эти чудовища рассказывая параллельно про мифическую безопасность во все дыры - тут я совершенно с вами согласен.
Насчет C++, то если сделать то о чем говорите вы - то он им перестанет быть. И на совместимости он держится не в последнюю очередь. Но и пользователей у него сильно больше чем десяток человек, так что комитет вполне резонно занимается тем чем и должен.
Я не минусовал, и где-то даже с вами согласен. Проблема в том, что неважно кто прочитает ваше сообщение - каждый найдет с чем с вами не согласится в 2/3 сообщения. Если сократить - то вы сказали что все херово, все херня, все дураки а ты один умный. За такое вы получите еще не один минус, не нужно обижаться на это и обращать внимание.
Продумывайте язык, хотите свой, хотите развивайте существующие. В обоих случаях, у вас пропадет желание в пустую критиковать.
Я лично с вами совершенно согласен, что mod, fun, mut и прочие fun-овские конструкции в раст - выглядят как минимум странно. Но это просто синтаксис, к нему можно привыкнуть.
А вот подменять понятия, доступа к памяти через арены и другими трюками что б уговорить бороу чекер и называть это безопасным и активно/агрессивно рекламировать эту херню - я согласен, что тут перегиб. Если люди не могут написать безопасный парсер, безопасный рендер шрифтов на C/C++ и внезапно переписывают это на Rust - так это потому что у них можется и хочется, и с безопасностью это никак не связано. Пока что все такие проекты строго хуже своих оригиналов, увы, потому что делают свою работу - херово. И дело не в языке здесь, а что молодежь игнорирует накопленный опыт.
Ну я почти понял что вы имели ввиду, спасибо за терпение. Но, все равно рекомендация делать транзакции с минимальной длительностью никуда не деваются. Отсюда и оптимистичная модель "блокировки" и т.п. Само собою от длинных транзакций на несколько часов некуда не денешься, но это больше про отчеты. А в UI устраивать длинные транзакции обычно вроде как и не надо.
Но хочу подчеркнуть, что я тут не спорю совсем: если есть работающее решение, которое удовлетворяет бизнес требованиям - оно по определению правильное.
Мне не очень понятно все равно, что вы имеете ввиду: "отсоединенная" модель победила, клиентские курсоры нужны но для очень специфических задач. После исполнения запроса вы десериализовали результат в удобную форму и связи с БД никакой нет, соединение закрыто и висит разве что в пуле но ничем не владеет.
Я верю вам (в сложностях - сам сталкивался с плохим кодом который... даже проще чем вы описываете, но бажил), но вы описываете какие-то страсти. Циклы через БД? Это принципиально не возможно, она полностью от вас отделена протоколом обмена. Как-то просто сумбурно намешали.
Я возможно придираюсь, но все таки, event loop, message loop, message dispatcher - по сути разгребает очередь задач/событий/сообщений и выполняет их диспетчеризацию (иначе говоря вызывает обработчики сообщений).
Стэк применяется или в смысле структуры данных, но ниже вы пишете об очередях. Или под стэком вызовов подразумевается непосредственно это самое, ну т.е. call stack. Но это точно не имеет отношения к циклу обработки сообщений.
У вас же эта фраза выделена жирным, подразумевается что вы акцентировали на этом внимание и из текста вроде бы как эта фраза должна была что-то объяснить. Если вы использовали стэк вызовов как собирательный образ, типа как стэк технологий - в том смысле что он обслуживает сразу несколько очередей, например микро-таски и потом таски а между этим где-то лэйаут, обслуживание отладчика, и еще чего-нибудь - то, имхо - формулировочка крайне неудачная.
Не только просто привыкли, но и есть области где эффективное представление объектов памяти - достигается некоторыми трюками, но дает отличные бонусы. При этом C++ позволяет реализовать вменяемое API вокруг этого.
Ну, к примеру, если у вас есть дискриминатор type и поле данные-или-указатель, то практически все управляемые среды не согласятся с вами, они осведомлены о управляемом указатели и будут его трассировать. В тоже время сборщик мусора на C++ с ручным визитером объекта позволит реализовать любые фантазии, хотя в сумме решение на C++ будет конечно значительно дороже.
Из известных мне примеров где творят нечто необычное, это clang (дискриминатор в младших битах указателя), Chromium/Blink (GC+сжатые указатели+хороший аллокатор), V8 (сжатые указатели + small integer).
А не надо подходить проще. Человек выше написал несусветный бред про 16.5мс и какую-то ебанутую стратегию шедулинга для юзерских процессов. Шедулинг при всех недостатках винды абсолютно точно не работает так, просто потому что он такой же как в линуксе: preemptive, и шедулинг происходит исключительно на уровне потоков. Никаких процессов для него не существует физически. И при желании, нет абсолютно никаких проблем выжрать хоть тыщу ядер на винде, было бы желание. Но, желания насколько я увидел - нет, есть только желание поносить винду, и зачем-то во все это впутать COM от котрого надо держаться подальше, просто потому что в своем софте он не нужен.
Это всё не важно: есть размер сектора и связанная с ним адресация и команды через физический интерфейс работающие в этой адресации. Какие там оптимизации используются на стороне устройства в общем случае - не известны от слова совсем.
Изначальный пойнт был не про это, а про, то, что размер сектора и размер кластера в конкретной файловой системе - не одно и тоже. Заодно есть еще размер страницы памяти, обычно они хотя бы кратны.
Более того, файл может быть вообще на NFS, или быть пайпом соединенным с вашим виртуальным терминалом, и все эти инсинуации про размер сектора на воображаемом диске с 4К - не имеют под собой никаких оснований.
А еще структуры можно передавать по ref, и List<T> никто использовать не заставляет. В итоге если реализуется условно "база данных" (набор таблиц), то зачастую получается так же сэкономить на том, что ссылаться на элемент достаточно по индексу, который может быть uint16 и uint32 (ну или знаковые, как угодно). Ну и для всего этого не нужно делать десятки тысяч аллокаций на куче. Доступ к таким данным организовывается через структуры-курсоры/врапперы, которые знают как правильно сходить в контекст (ссылка+индекс+версия, например = 16 байт). Да, получается ужасная косвенность, но такое вполне применяется.
В общем, надо понимать чего хочется достичь. А заинлайненный Add в цикле бенчмарка - это, согласен - вообще не особо интересно, да и не показательно. Тем более сравнивается заведлмо проигрышный вариант, с копированием тяжелых структур (>64 байта).
Ух вы какие умные. Неверная конфигурация шины DDR5 выясняется за 8-12 часов полной нагрузки а иногда и нужно 24+ часов что бы выловить сбой. То что система с виду загрузилась - вообще ничего не значит, значит только что оно вообще в принципе способно работать.
Да, согласен. Все мои HDD тоже имеют 512, хотя они старые, а свежие никуда пока не приткнул. :) Они уже успели устареть.
Насчет эмуляции блочного устройства и SSD - так и HDD их эмулируют уже довольно давно, и чо они там делают - одному богу известно. Кто-то с SSD кэшем на борту, кто-то с херпоймешь-какой-черепичной-записью. Остались вот пара старичков которые просто работают. :)
А еще некоторые SSD могут в ограниченную дедупликацию, что с увеличением размера сектора будет требовать больших напрягов от него. Правда кто это точно умеет - надежно не понять никак.
PS: А насчет размера сектора на nvme - обжогся недавно лично, при чем, т.к. я ставил сразу RAID1 (btrfs), то новоустановленная система выживала исправляя/регистрируя от 50К до 100К ошибок. Правда потом она забыла fstab и пришлось думать активнее. )) Хотя оборудование уже к тому моменту было испытано на нагрузке, и просто не связал эти факты и мучался, грешил на управление питанием дисками. Вернул на дефолт и все сразу стало нормально,и никаких проблем с этим динамическим засыпанием проблем нет. Одно хорошо, заодно и прошивку обновил (но она не помогла).
Вот только на даже не самых современных машинах это не имеет смысла, т.к. сектора в любом используемом в настоящее время HDD/SSD имеют размер не меньше 4 Кб.
Вы несколько заблуждаетесь в обосновании (в объяснении почему так). На всех современных устройствах, включая nvme диски обычно используется размер сектора в 512 байт. В nvme вы можете выбрать поддерживаемый размер сектора и отформатировать диск как надо, и 4K будет более "быстрым". Однако и этому не стоит верить на слово: устройство легко может глючить, даже если оно и говорит что поддерживает 4K. UPD: Т.е. размер кластера выбираемый при форматировании раздела - к этому отношения не имеет. Сектора - это про адресуемые единицы на устройстве.
Размер же страницы памяти, а так же блока файловой системы - вообще с этим напрямую не связаны, но эффективнее конечно (и то не всегда), если они будут равны. Но, все таки ни то ни другое к секторам диска отношения вообще не имеет.
Использование экстент в файловой системе с гранулярностью в 16К - вполне себе обычная практика.
cmd.exe использует кодировку настроенную в системе. И системные вызовы используют её. Если по вашему оно работает не так, как вы думаете,то это не значит что оно говно, вы просто не разобрались.
И второе: альтернативы для простых и не очень скриптов которые массово запускаются, например, при сборке - не существует. Запуск pwsh или python существенно дольше, хоть и функций сильно больше, но они нужны далеко не всегда, и это говно надо ставить, а кмд доступен из коробки.
Так, как настроена система. Есть же понятие ACP (ANSI Code Page). Вот в региональных настройках можно выбрать желаемую, щас по моему флажок для utf8 есть. Можно в реестре по старинке. Кодовая страница для utf8 - 65001.
cmd-файлы в ansi и соотв должны следовать настройкам системы.
Закрылили бы питон как уебище, но к сожалению новость не про это.
Вроде бы неплохо, наискось пробежал, спасибо.
В начале статьи есть некоторая тавтология, в погоне за объяснить простое простым, а в результате по моему ничего не объяснили.
Интерпретатор по определению ничего не генерирует и тем более не компилирует. Компиляцией занимается компилятор. То о чем вы пишите в целом - так и называется - многоуровневая компиляция (tiered compilation).
Отличный пример отвратительной реализации чего-то что этим не является.
Я рад что где-то есть развитая система типов, но, использовать её ради оберток вокруг файловых дескрипторов - это как то перебор. С файлами можно не только в читать и писать, а файл, а точнее его хэндл/дескриптор можно передать в другой процесс, например, по пайпу на всех ОС (ну точнее не во всех по пайпу, но смысл телепортации есть во всех "настоящих" ОС).
Иначе говоря вы ввели 3 абстракции, 3 типа и это универсально не применимо, потому что кроме RW есть и "Other" операции.
Это конечно отлично, что вы осведомлены о разрешенных операциях на этапе компиляции, только, это все обычно утыкается в обычный булевый флаг-параметр, который совсем не всегда константа и весь этот выпендреж едет лесом. Всего-то надо позвать функцию ОС и сделать это удобно.
Не удивительно, что c11l не применяется аж нигде.
Я использую Arch, но как я уже и сказал, я совсем не любитель раста. Я не могу сказать, что противник, потому что хейтить его нет времени. Мне попадались вроде интересные проекты, но если все утрировать, то да: мне тоже кажется что в основном там задача переизобрести что-то, непонятно назвать и это еще нормально, новое поколение подросло, ну и старое играется. Но пихать эти чудовища рассказывая параллельно про мифическую безопасность во все дыры - тут я совершенно с вами согласен.
Насчет C++, то если сделать то о чем говорите вы - то он им перестанет быть. И на совместимости он держится не в последнюю очередь. Но и пользователей у него сильно больше чем десяток человек, так что комитет вполне резонно занимается тем чем и должен.
Я не минусовал, и где-то даже с вами согласен. Проблема в том, что неважно кто прочитает ваше сообщение - каждый найдет с чем с вами не согласится в 2/3 сообщения. Если сократить - то вы сказали что все херово, все херня, все дураки а ты один умный. За такое вы получите еще не один минус, не нужно обижаться на это и обращать внимание.
Продумывайте язык, хотите свой, хотите развивайте существующие. В обоих случаях, у вас пропадет желание в пустую критиковать.
Я лично с вами совершенно согласен, что mod, fun, mut и прочие fun-овские конструкции в раст - выглядят как минимум странно. Но это просто синтаксис, к нему можно привыкнуть.
А вот подменять понятия, доступа к памяти через арены и другими трюками что б уговорить бороу чекер и называть это безопасным и активно/агрессивно рекламировать эту херню - я согласен, что тут перегиб. Если люди не могут написать безопасный парсер, безопасный рендер шрифтов на C/C++ и внезапно переписывают это на Rust - так это потому что у них можется и хочется, и с безопасностью это никак не связано. Пока что все такие проекты строго хуже своих оригиналов, увы, потому что делают свою работу - херово. И дело не в языке здесь, а что молодежь игнорирует накопленный опыт.
Ну я почти понял что вы имели ввиду, спасибо за терпение. Но, все равно рекомендация делать транзакции с минимальной длительностью никуда не деваются. Отсюда и оптимистичная модель "блокировки" и т.п. Само собою от длинных транзакций на несколько часов некуда не денешься, но это больше про отчеты. А в UI устраивать длинные транзакции обычно вроде как и не надо.
Но хочу подчеркнуть, что я тут не спорю совсем: если есть работающее решение, которое удовлетворяет бизнес требованиям - оно по определению правильное.
Мне не очень понятно все равно, что вы имеете ввиду: "отсоединенная" модель победила, клиентские курсоры нужны но для очень специфических задач. После исполнения запроса вы десериализовали результат в удобную форму и связи с БД никакой нет, соединение закрыто и висит разве что в пуле но ничем не владеет.
Я верю вам (в сложностях - сам сталкивался с плохим кодом который... даже проще чем вы описываете, но бажил), но вы описываете какие-то страсти. Циклы через БД? Это принципиально не возможно, она полностью от вас отделена протоколом обмена. Как-то просто сумбурно намешали.
Я возможно придираюсь, но все таки, event loop, message loop, message dispatcher - по сути разгребает очередь задач/событий/сообщений и выполняет их диспетчеризацию (иначе говоря вызывает обработчики сообщений).
Стэк применяется или в смысле структуры данных, но ниже вы пишете об очередях. Или под стэком вызовов подразумевается непосредственно это самое, ну т.е. call stack. Но это точно не имеет отношения к циклу обработки сообщений.
У вас же эта фраза выделена жирным, подразумевается что вы акцентировали на этом внимание и из текста вроде бы как эта фраза должна была что-то объяснить. Если вы использовали стэк вызовов как собирательный образ, типа как стэк технологий - в том смысле что он обслуживает сразу несколько очередей, например микро-таски и потом таски а между этим где-то лэйаут, обслуживание отладчика, и еще чего-нибудь - то, имхо - формулировочка крайне неудачная.
Вот еще фраза: "Event Loop следит за стеком вызовов и очередью событий.".
Просто интересно, как вы себе представляете что бы цикл следил за стэком вызовов? :)
Не только просто привыкли, но и есть области где эффективное представление объектов памяти - достигается некоторыми трюками, но дает отличные бонусы. При этом C++ позволяет реализовать вменяемое API вокруг этого.
Ну, к примеру, если у вас есть дискриминатор type и поле данные-или-указатель, то практически все управляемые среды не согласятся с вами, они осведомлены о управляемом указатели и будут его трассировать. В тоже время сборщик мусора на C++ с ручным визитером объекта позволит реализовать любые фантазии, хотя в сумме решение на C++ будет конечно значительно дороже.
Из известных мне примеров где творят нечто необычное, это clang (дискриминатор в младших битах указателя), Chromium/Blink (GC+сжатые указатели+хороший аллокатор), V8 (сжатые указатели + small integer).
Какой такой Event Bus? Нет такого, не было и не нужно.
А не надо подходить проще. Человек выше написал несусветный бред про 16.5мс и какую-то ебанутую стратегию шедулинга для юзерских процессов. Шедулинг при всех недостатках винды абсолютно точно не работает так, просто потому что он такой же как в линуксе: preemptive, и шедулинг происходит исключительно на уровне потоков. Никаких процессов для него не существует физически. И при желании, нет абсолютно никаких проблем выжрать хоть тыщу ядер на винде, было бы желание. Но, желания насколько я увидел - нет, есть только желание поносить винду, и зачем-то во все это впутать COM от котрого надо держаться подальше, просто потому что в своем софте он не нужен.
Это всё не важно: есть размер сектора и связанная с ним адресация и команды через физический интерфейс работающие в этой адресации. Какие там оптимизации используются на стороне устройства в общем случае - не известны от слова совсем.
Изначальный пойнт был не про это, а про, то, что размер сектора и размер кластера в конкретной файловой системе - не одно и тоже. Заодно есть еще размер страницы памяти, обычно они хотя бы кратны.
Более того, файл может быть вообще на NFS, или быть пайпом соединенным с вашим виртуальным терминалом, и все эти инсинуации про размер сектора на воображаемом диске с 4К - не имеют под собой никаких оснований.
А еще структуры можно передавать по ref, и List<T> никто использовать не заставляет. В итоге если реализуется условно "база данных" (набор таблиц), то зачастую получается так же сэкономить на том, что ссылаться на элемент достаточно по индексу, который может быть uint16 и uint32 (ну или знаковые, как угодно). Ну и для всего этого не нужно делать десятки тысяч аллокаций на куче. Доступ к таким данным организовывается через структуры-курсоры/врапперы, которые знают как правильно сходить в контекст (ссылка+индекс+версия, например = 16 байт). Да, получается ужасная косвенность, но такое вполне применяется.
В общем, надо понимать чего хочется достичь. А заинлайненный Add в цикле бенчмарка - это, согласен - вообще не особо интересно, да и не показательно. Тем более сравнивается заведлмо проигрышный вариант, с копированием тяжелых структур (>64 байта).
А графички красивые :) Автор молодец.
Ух вы какие умные. Неверная конфигурация шины DDR5 выясняется за 8-12 часов полной нагрузки а иногда и нужно 24+ часов что бы выловить сбой. То что система с виду загрузилась - вообще ничего не значит, значит только что оно вообще в принципе способно работать.
Да, согласен. Все мои HDD тоже имеют 512, хотя они старые, а свежие никуда пока не приткнул. :) Они уже успели устареть.
Насчет эмуляции блочного устройства и SSD - так и HDD их эмулируют уже довольно давно, и чо они там делают - одному богу известно. Кто-то с SSD кэшем на борту, кто-то с херпоймешь-какой-черепичной-записью. Остались вот пара старичков которые просто работают. :)
А еще некоторые SSD могут в ограниченную дедупликацию, что с увеличением размера сектора будет требовать больших напрягов от него. Правда кто это точно умеет - надежно не понять никак.
PS: А насчет размера сектора на nvme - обжогся недавно лично, при чем, т.к. я ставил сразу RAID1 (btrfs), то новоустановленная система выживала исправляя/регистрируя от 50К до 100К ошибок. Правда потом она забыла fstab и пришлось думать активнее. )) Хотя оборудование уже к тому моменту было испытано на нагрузке, и просто не связал эти факты и мучался, грешил на управление питанием дисками. Вернул на дефолт и все сразу стало нормально,и никаких проблем с этим динамическим засыпанием проблем нет. Одно хорошо, заодно и прошивку обновил (но она не помогла).
Вы несколько заблуждаетесь в обосновании (в объяснении почему так). На всех современных устройствах, включая nvme диски обычно используется размер сектора в 512 байт. В nvme вы можете выбрать поддерживаемый размер сектора и отформатировать диск как надо, и 4K будет более "быстрым". Однако и этому не стоит верить на слово: устройство легко может глючить, даже если оно и говорит что поддерживает 4K. UPD: Т.е. размер кластера выбираемый при форматировании раздела - к этому отношения не имеет. Сектора - это про адресуемые единицы на устройстве.
Размер же страницы памяти, а так же блока файловой системы - вообще с этим напрямую не связаны, но эффективнее конечно (и то не всегда), если они будут равны. Но, все таки ни то ни другое к секторам диска отношения вообще не имеет.
Использование экстент в файловой системе с гранулярностью в 16К - вполне себе обычная практика.