Несмотря на название, doctest не предназначен для написания документации и тестирования кода из примеров. Это просто хороший и быстрый фреймворк для тестирования, функционально аналогичный Google Test и Catch2. Для генерации документации С++ обычно использует doxygen, но ни разу не встречал плагинов к нему, который бы запускал бы юниты из документации (это не значит, что их совсем нет, это значит, что я с ними не сталкивался).
Ви так говорите, словно компилятор без пользователей живёт. Собственно про это и вопрос - считаем мы это как приложение проходящее обозначенный критерий или считаем, что это калькулятор, пусть и немного более замороченный. Что могло бы пройти этот критерий? Редакторы кода (zed, helix) не проходят, потому что у них есть unsafe, приложенька на каком-нибудь tauri/dioxus тоже, т.к. фреймворк содержит unsafe, но если мы считаем это допустимым в пределах библиотеки, но не собственного приложении, то внезапно критерий начнут проходить немало приложений.
вообще ни разу не выглядит. особенно Euler+ на Hackerrank. Многие задачи поставлены так, что иногда требуют передний край математики, ибо построение даже простейших граничных условий приводит к тупику.
Сравниваю с классическими компилируемыми языками в нишу которых воткнулся Rust, поэтому в сравнении с ними это принципиально новая фича. C, C++, C#, D - вроде никто из них до сих пор не поддеживает доктесты, но это не точно. В каком-нибудь JS с появлением node/npm тоже могли появиться, но в природе с ними не сталкивался. Аналогичная история с python - видел только примеры автоматической генерации, но не встречал автотестов в doc комментариях. Про эрланг ничего особо не знаю, ну а ржавый gleam начал появляться видимо с появлением Rust 1.0 те самые 10 лет назад - у кого доктесты были подсмотрены - вопрос открытый.
Компилятор языка написан на Rust и весь рантайм к нему вроде тоже на нём - по ссылке репа, справа в сайдбаре с инфой можно посмотреть распределение языков. Считаем ли мы компилятор и рантайм языка продвинутым калькулятором или таки относим его к легитимным приложениям сложнее калькулятора?
Я не о низком уровне, который реализован авторами языка и протестирован всеми, кто язык использует.
Так и я не про unsafe в std, а ровно тот unsafe который появляется непосредственно в проекте некалькулятора.
Несомненно. А раст — единственный язык, победивший эту проблему? А существует хоть одно приложение, чуть сложнее калькулятора, в котором не используется ансейф?
Кажется это принципиально невозможно, ибо общение с той же OS во многих случаях оборачивается вызовом сишных API - zed что-то там мутит с unix stream, uv - WinAPI дёргает, helix и zellij интегрируют плагины на wasm, которые могут быть на произвольном языке, что опять же - unsafe граница между языками. А так, чтобы оно никак не взаимодействовало с системой или другими языками и было сложнее калькулятора. Можно ли считать gleam продвинутым калькулятором или пойдёт под категорию?
Асинхронность в Rust хоть и является незавершённой частью языка, но не «костылём»:
К сожалению - является именно костылём. Во-первых раскраска функций даёт несколько отличный синтаксис и инвалидирует работу borrow checker, позволяет писать честные асинхронные безопасные дедлоки.
Вторая проблема, что синтаксический сахар для асинхронности на самом деле генерирует некоторый не самый хороший код с точки зрения архитектуры и расширять его больно, а в определённых ситуациях приходится ещё и костыли дописывать, чтобы асинк можно было использовать адекватно. Так что всё таки костыль.
Отдельно стоит заметить, что некоторые дизайнерские решения относительно API стандартной библиотеки также вызывают вопросы, т.к. то что в Хаскелл было сделано для всех и сразу в Rust имеет несколько полу-копипастных частных имплементаций - всякие map на Option один из таких примеров.
Всегда актуальная документация и тесты
Это в общем-то не языковая проблема. Добавить генерацию документации не слишком сложно, а вот поддерживать её актуальность - проблема. Из принципиальных фишек cargo doc есть то что сниппеты кода в документации автоматически можно тестировать, да.
Здесь и далее «крабы» — это Rust-разработчики. Это связано с «талисманом» языка: красным крабом.
Это не совсем так. Маскотом Rust является cRUSTacean - то бишь ракооборазный. Так что не только в доте раки зимуют.
Собственно, гугл подсказывает, что самый быстрый спасательный кораблик держит в районе 40-50 км/ч. 2-3 корабля на траектории чтобы покрыть окрестность в часов 5-10 не так сложно, однако кажется так никто не делает и проще по факту связаться со спасателями, ближайшими к точке. Да и автономность САС наверняка достаточна, чтобы поболтаться на воде те же пару суток. Главное пеленг не забыть активировать. Гравитация новоотбывшим не страшна, так как речь про пилотируемые запуски с прибрежного космодрома, а не про спускаемые модули для членов экипажей длительных миссий.
летать на скорости 500 км/ч
Подозреваю, что в открытом море такое проворачивать просто опасно. По речке-то ещё ладно, может в прибрежных морских водах ещё куда ни шло.
Забавно наблюдать как карма комментария шатается из плюса в минус и обратно - я никогда особо не интерсовался подробностями ракетных систем/ракеторстроения в принципе и поэтому все вопросы и утверждения закономерно делались с колокольни хоть и технически подкованного, но всё же обывателя, а не эксперта. Но теперь всем миром просветили меня о наличии системы САС и событиях её срабатывания. Спасибо вам, люди. Без сарказазма.
главное чтобы вы понимали, что в таком виде оно не очень ecs. std::map представляет собой бинарное дерево, то есть ноды дерева расположены где-то в случайном месте памяти. ECS же старается сделать так чтобы одинаковые компоненты лежали как можно ближе друг дргу для cache locality. В классическом SoA оно выглядело бы как-то так
То есть некоторые линейные массивы, последовательная обработка которых отлично предсказывалась процессорным branch predictor. В случае map такого не будет происходить, т.к. обход бинарного дерева не будет проходить по последовательной памяти, а по веткам дерева. std::unordered_map или std::flat_map могут исправить эту ситуацию.
Ну и отдельно стоит заметить, что любой std::*map обычно принимает два шаблонных параметра - тип ключа и тип собственно элемента, так что ваш пример не соберётся.
Ну и обновление в ECS обычно происходит на уровне систем, а не на уровне энтитей.
for (auto [_,tran]: t) tran.tick(); // update transform system
for (auto [_,phys]: p) phys.tick(); // update physics system
/*the rest of systems*/
Мономорфизация генериков. Чем больше вложенных типов в ваших угловых скобках, тем сложнее выводить тип финальной функции, не говоря уже о проблемах параллелизации этого процесса.
Вторая замедляющая компиляцию штука - активное наваливание макросов на всё что можно. Макрос генерирует больше кода. Больше кода - больше компилировать. А уж если макрос генерирует вызовы генериков, то добавляется ещё и первый пункт. Вот и получается не быстро.
Особнячком стоит процесс финальной кодогенерации для некоторых таргетов. Генерация кода под wasm, например, не сказать чтобы быстрая и даже демка из wasm-pack будет генерировать wasm бинарь довольно заметное время. Поэтому, если вам сложилось заниматься вебнёй, то мои вам соболезнования, вам придётся биться на мечах с соседом. Впрочем, пока не изобрели языка, где аналогичные действия происходили бы быстрее.
Всегда есть возможность выбросить комбайн и скрафтить собственный специализированнй пайплайн, который почти наверняка окажется быстрее, но большинство не станут этим заниматься.
Как минимум отметьте на картинках/анимации размеры элементов, чтобы можно было наблюдать, что размеры действительно не меняются. Ещё лучше - показать полное построение с помощью циркуля и линейки. Отдельно - показать пруф для площади параллелограмма. В идеале доказать, что диагональ стыковки параллелограммов тоже должна быть гипотенузой. Что должно как бы быть следствием из того для чего мы должны построить доказательство.
Я хз существует ли вообще принципиальная возможность в аварийных ситуациях как-то безопасно сбросить экипаж с поднимающейся ракеты. Даже для имеющихся космодромов. Проводились ли испытания этой системы, если таки имеется возможность.
Наличие флота который можно было бы куда-то отправить в любом случае страдает от большого разброса по диапазону, куда мог бы приземлиться или приводниться спускаемая часть с экипажем. Наличие флота, который бы мониторил пару тысяч километров океана на траектории звучит как небылица. Сомневаюсь, что какая-либо из стран делает что-то подобное. Дешевле и проще сделать достаточно испытаний, чтобы ракета точно не упала.
Разработка подробного протокола возможно является проблемой для разрешения пилотируемых запусков, но сомневаюсь по причинам озвученными автором.
По данным компании YouGov на 2023 год, настольными играми увлечены 19% населения мира
Учитывая, что ребята занимаются маркетинговым анализом сомневаюсь, что реальные цифры близки к этому. Плюс считались "board games or cards", что отнесёт какой-нибудь покер, преферанс или блэкджек к той же категории. Так что ваш личный опыт с "по пальцам пересчитать" вероятнее ближе к истине.
Однако, вы обозначили игры в сегменте образования, то есть в сфере, где люди учатся и учат. Не могу сказать, что там совсем нет игр, но это определённо не та же категория, что и просто настольные игры. В большинстве случаев у этих игр цель сделать геймификацию некоторого процесса обучения. Как вы понимаете у сферы образования не сказать чтобы большой запрос на игры в ввиду уровня их применимости. Дошкольники ещё не умеют в математику, школьникам уже особо некогда, а у студентам и без этого найдётся во что сыграть.
Образовательные настольные игры же это тоже немного иная категория и сильно зависит от того, что в него включать.
Вы думаете, что разглядеть математическую идею в прикладном процессе - это магия.
Магией зову обычно вещи, которые либо придуманы на ходу и не имеют научных обоснований (вжух рукой собирает облака для дождя) либо что-то выше моего собственного уровня понимания (интерпространственная теория Тейхмюллера). Для ребёнка, который не особо любит учиться и с горем пополам и калькулятором едва пользуется таблицей умножения даже собирание кубика Рубика будет магией, куда уж там ему про какие-нибудь группы поворотов задумываться или стратегии для го придумать. Если у вас нет кнута или пряника для того чтобы тот потратил время на изучение вопроса (читай, удержать внимание), то он почти наверняка не станет этого делать и ближайший айпад с матч3 вас победит по интересности.
часто содержат в себе возможности для линейного, квадратичного или экспоненциального роста
Вы же не будете ради обучения учить играть людей в Eve интегрируя его с обучением Excel. Сложность алгоритмов обычно прикидывается в голове, а минимакс рассчитывается предварительно на листочке. Никто не рисует графики для подобного. По крайней мере не ручками.
Покрыть бы школьную программу и научить минимуму необходимых полезных навыков - уже хорошо.
Опять же - большинство игр имеет довольно узкую математическую сферу - что-нибудь из комбинаторики, теории групп, может там графы, теория игр с экономикой и что-нибудь про программирование. Это будет интересно небольшому кругу ботаников, но не среднему ученику - дети ни в какие периоды не хотели учиться и ситуация принципиально не меняется, поэтому даже геймификация процесса не сильно помогает, а уж заинтересовать какими-то внутренними механизмами игры просто играя в неё ради желания победы - ещё большая редкость. Особенно, если вы не планируете держать какие-нибудь состязательные лиги для мириады различных игр, чтобы была хоть какая-нибудь конкуренция для мотивации желания той самой победы - осторожность с азартом, как вы понимаете, с этим не сказать чтобы стыкуется.
Там тоже писалось много где о восстановлении месяцами, хотя Аэрофлот решил проблемы в считанные дни.
Есть разница между восстановлением работоспособности и восстановлением всех данных. Первое необходимо делать быстро, второе будет происходить очень долго. Если конечно у них не было какого-нибудь ультра бэкапа
Откуда дровишки про генетику? Не слышал, чтобы были какие-то сопутствующие исследования, связывавшие влияние каких-нибудь генов с СДВГ.
в отличие от хаскелистов
Несмотря на название, doctest не предназначен для написания документации и тестирования кода из примеров. Это просто хороший и быстрый фреймворк для тестирования, функционально аналогичный Google Test и Catch2. Для генерации документации С++ обычно использует doxygen, но ни разу не встречал плагинов к нему, который бы запускал бы юниты из документации (это не значит, что их совсем нет, это значит, что я с ними не сталкивался).
https://github.com/gleam-lang/gleam
Ви так говорите, словно компилятор без пользователей живёт. Собственно про это и вопрос - считаем мы это как приложение проходящее обозначенный критерий или считаем, что это калькулятор, пусть и немного более замороченный. Что могло бы пройти этот критерий? Редакторы кода (zed, helix) не проходят, потому что у них есть unsafe, приложенька на каком-нибудь tauri/dioxus тоже, т.к. фреймворк содержит unsafe, но если мы считаем это допустимым в пределах библиотеки, но не собственного приложении, то внезапно критерий начнут проходить немало приложений.
вообще ни разу не выглядит. особенно Euler+ на Hackerrank. Многие задачи поставлены так, что иногда требуют передний край математики, ибо построение даже простейших граничных условий приводит к тупику.
Сравниваю с классическими компилируемыми языками в нишу которых воткнулся Rust, поэтому в сравнении с ними это принципиально новая фича. C, C++, C#, D - вроде никто из них до сих пор не поддеживает доктесты, но это не точно. В каком-нибудь JS с появлением node/npm тоже могли появиться, но в природе с ними не сталкивался. Аналогичная история с python - видел только примеры автоматической генерации, но не встречал автотестов в doc комментариях. Про эрланг ничего особо не знаю, ну а ржавый gleam начал появляться видимо с появлением Rust 1.0 те самые 10 лет назад - у кого доктесты были подсмотрены - вопрос открытый.
Компилятор языка написан на Rust и весь рантайм к нему вроде тоже на нём - по ссылке репа, справа в сайдбаре с инфой можно посмотреть распределение языков. Считаем ли мы компилятор и рантайм языка продвинутым калькулятором или таки относим его к легитимным приложениям сложнее калькулятора?
Так и я не про unsafe в std, а ровно тот unsafe который появляется непосредственно в проекте некалькулятора.
Кажется это принципиально невозможно, ибо общение с той же OS во многих случаях оборачивается вызовом сишных API - zed что-то там мутит с unix stream, uv - WinAPI дёргает, helix и zellij интегрируют плагины на wasm, которые могут быть на произвольном языке, что опять же - unsafe граница между языками. А так, чтобы оно никак не взаимодействовало с системой или другими языками и было сложнее калькулятора. Можно ли считать gleam продвинутым калькулятором или пойдёт под категорию?
К сожалению - является именно костылём. Во-первых раскраска функций даёт несколько отличный синтаксис и инвалидирует работу borrow checker, позволяет писать честные асинхронные безопасные дедлоки.
Вторая проблема, что синтаксический сахар для асинхронности на самом деле генерирует некоторый не самый хороший код с точки зрения архитектуры и расширять его больно, а в определённых ситуациях приходится ещё и костыли дописывать, чтобы асинк можно было использовать адекватно. Так что всё таки костыль.
Отдельно стоит заметить, что некоторые дизайнерские решения относительно API стандартной библиотеки также вызывают вопросы, т.к. то что в Хаскелл было сделано для всех и сразу в Rust имеет несколько полу-копипастных частных имплементаций - всякие map на Option один из таких примеров.
Это в общем-то не языковая проблема. Добавить генерацию документации не слишком сложно, а вот поддерживать её актуальность - проблема. Из принципиальных фишек cargo doc есть то что сниппеты кода в документации автоматически можно тестировать, да.
Это не совсем так. Маскотом Rust является cRUSTacean - то бишь ракооборазный. Так что не только в доте раки зимуют.
Собственно, гугл подсказывает, что самый быстрый спасательный кораблик держит в районе 40-50 км/ч. 2-3 корабля на траектории чтобы покрыть окрестность в часов 5-10 не так сложно, однако кажется так никто не делает и проще по факту связаться со спасателями, ближайшими к точке. Да и автономность САС наверняка достаточна, чтобы поболтаться на воде те же пару суток. Главное пеленг не забыть активировать. Гравитация новоотбывшим не страшна, так как речь про пилотируемые запуски с прибрежного космодрома, а не про спускаемые модули для членов экипажей длительных миссий.
Подозреваю, что в открытом море такое проворачивать просто опасно. По речке-то ещё ладно, может в прибрежных морских водах ещё куда ни шло.
Забавно наблюдать как карма комментария шатается из плюса в минус и обратно - я никогда особо не интерсовался подробностями ракетных систем/ракеторстроения в принципе и поэтому все вопросы и утверждения закономерно делались с колокольни хоть и технически подкованного, но всё же обывателя, а не эксперта. Но теперь всем миром просветили меня о наличии системы САС и событиях её срабатывания. Спасибо вам, люди. Без сарказазма.
главное чтобы вы понимали, что в таком виде оно не очень ecs. std::map представляет собой бинарное дерево, то есть ноды дерева расположены где-то в случайном месте памяти. ECS же старается сделать так чтобы одинаковые компоненты лежали как можно ближе друг дргу для cache locality. В классическом SoA оно выглядело бы как-то так
То есть некоторые линейные массивы, последовательная обработка которых отлично предсказывалась процессорным branch predictor. В случае map такого не будет происходить, т.к. обход бинарного дерева не будет проходить по последовательной памяти, а по веткам дерева. std::unordered_map или std::flat_map могут исправить эту ситуацию.
Ну и отдельно стоит заметить, что любой std::*map обычно принимает два шаблонных параметра - тип ключа и тип собственно элемента, так что ваш пример не соберётся.
Ну и обновление в ECS обычно происходит на уровне систем, а не на уровне энтитей.
Мономорфизация генериков. Чем больше вложенных типов в ваших угловых скобках, тем сложнее выводить тип финальной функции, не говоря уже о проблемах параллелизации этого процесса.
Вторая замедляющая компиляцию штука - активное наваливание макросов на всё что можно. Макрос генерирует больше кода. Больше кода - больше компилировать. А уж если макрос генерирует вызовы генериков, то добавляется ещё и первый пункт. Вот и получается не быстро.
Особнячком стоит процесс финальной кодогенерации для некоторых таргетов. Генерация кода под wasm, например, не сказать чтобы быстрая и даже демка из wasm-pack будет генерировать wasm бинарь довольно заметное время. Поэтому, если вам сложилось заниматься вебнёй, то мои вам соболезнования, вам придётся биться на мечах с соседом. Впрочем, пока не изобрели языка, где аналогичные действия происходили бы быстрее.
Всегда есть возможность выбросить комбайн и скрафтить собственный специализированнй пайплайн, который почти наверняка окажется быстрее, но большинство не станут этим заниматься.
Как минимум отметьте на картинках/анимации размеры элементов, чтобы можно было наблюдать, что размеры действительно не меняются. Ещё лучше - показать полное построение с помощью циркуля и линейки. Отдельно - показать пруф для площади параллелограмма. В идеале доказать, что диагональ стыковки параллелограммов тоже должна быть гипотенузой. Что должно как бы быть следствием из того для чего мы должны построить доказательство.
Я хз существует ли вообще принципиальная возможность в аварийных ситуациях как-то безопасно сбросить экипаж с поднимающейся ракеты. Даже для имеющихся космодромов. Проводились ли испытания этой системы, если таки имеется возможность.
Наличие флота который можно было бы куда-то отправить в любом случае страдает от большого разброса по диапазону, куда мог бы приземлиться или приводниться спускаемая часть с экипажем. Наличие флота, который бы мониторил пару тысяч километров океана на траектории звучит как небылица. Сомневаюсь, что какая-либо из стран делает что-то подобное. Дешевле и проще сделать достаточно испытаний, чтобы ракета точно не упала.
Разработка подробного протокола возможно является проблемой для разрешения пилотируемых запусков, но сомневаюсь по причинам озвученными автором.
Информационная война никуда не делась. Собсна украинские хакеры там бахвалились "да мы там всё под чистую вынесли", что СМИ в итоге и тиражировали.
Я так понимаю речь об этом
Учитывая, что ребята занимаются маркетинговым анализом сомневаюсь, что реальные цифры близки к этому. Плюс считались "board games or cards", что отнесёт какой-нибудь покер, преферанс или блэкджек к той же категории. Так что ваш личный опыт с "по пальцам пересчитать" вероятнее ближе к истине.
Однако, вы обозначили игры в сегменте образования, то есть в сфере, где люди учатся и учат. Не могу сказать, что там совсем нет игр, но это определённо не та же категория, что и просто настольные игры. В большинстве случаев у этих игр цель сделать геймификацию некоторого процесса обучения. Как вы понимаете у сферы образования не сказать чтобы большой запрос на игры в ввиду уровня их применимости. Дошкольники ещё не умеют в математику, школьникам уже особо некогда, а у студентам и без этого найдётся во что сыграть.
Образовательные настольные игры же это тоже немного иная категория и сильно зависит от того, что в него включать.
Магией зову обычно вещи, которые либо придуманы на ходу и не имеют научных обоснований (вжух рукой собирает облака для дождя) либо что-то выше моего собственного уровня понимания (интерпространственная теория Тейхмюллера). Для ребёнка, который не особо любит учиться и с горем пополам и калькулятором едва пользуется таблицей умножения даже собирание кубика Рубика будет магией, куда уж там ему про какие-нибудь группы поворотов задумываться или стратегии для го придумать. Если у вас нет кнута или пряника для того чтобы тот потратил время на изучение вопроса (читай, удержать внимание), то он почти наверняка не станет этого делать и ближайший айпад с матч3 вас победит по интересности.
Вы же не будете ради обучения учить играть людей в Eve интегрируя его с обучением Excel. Сложность алгоритмов обычно прикидывается в голове, а минимакс рассчитывается предварительно на листочке. Никто не рисует графики для подобного. По крайней мере не ручками.
Опять же - большинство игр имеет довольно узкую математическую сферу - что-нибудь из комбинаторики, теории групп, может там графы, теория игр с экономикой и что-нибудь про программирование. Это будет интересно небольшому кругу ботаников, но не среднему ученику - дети ни в какие периоды не хотели учиться и ситуация принципиально не меняется, поэтому даже геймификация процесса не сильно помогает, а уж заинтересовать какими-то внутренними механизмами игры просто играя в неё ради желания победы - ещё большая редкость. Особенно, если вы не планируете держать какие-нибудь состязательные лиги для мириады различных игр, чтобы была хоть какая-нибудь конкуренция для мотивации желания той самой победы - осторожность с азартом, как вы понимаете, с этим не сказать чтобы стыкуется.
Есть разница между восстановлением работоспособности и восстановлением всех данных. Первое необходимо делать быстро, второе будет происходить очень долго. Если конечно у них не было какого-нибудь ультра бэкапа
тем более, что Рогозин уже давно не у дел и в Крыму там что-то управляет.