В статье вы сделали много ссылок на исследования. Исследования - это здорово, конечно, но им не всегда можно доверять. Вот исследование. Что уж говорить про социологию, где доказательная база строится на статистике, а статистикой можно вертеть как хочешь, чтобы подогнать под подтверждение какого-либо тезиса. Но мое негодование даже не в этом, а в том, что вы решили настолько политически индоктринированную статью выложить на хабре, а не, например, на wonderzine.
Текста написано много, но он будто обо всем и ни о чем. Сразу к примеру перейдем. Итак, в примере операция, которая будто и не требует декомпозиции, декомпозирована на три составляющие. Это, вроде как, должно помочь нам избавиться от узкого горлышка, как пишут в преимуществах.
Давайте подумаем, что произойдет. Первая часть системы быстро (относительно) прочитает все файлы и забьет очередь картинками, которые будут без дела пылиться в оперативной памяти компьютера и ждать своей очереди. Затем по одному их прочитает обработчик, и, сразу по завершении обработки, сейвер их сохранит. Это в общем-то частая проблема, когда приходится обрабатывать видеопоток или что-то подобное, обработка как правило занимает времени больше, чем чтение, поэтому обработать поток видео покадрово - тяжелая для вычислительной машины задача, добавляют балансировщики, которые подают на обработку только ценные кадры. То есть, не очень понятно, а зачем читать условные 100 картинок сразу в оперативную память, если можно их читать по одной?
Возможно, подразумевается, что данный паттерн будет реализован в рамках серверного приложения. То есть, 100 пользователей загрузили свои 100 картинок, и сотый идет в курилку, на обед, играет в теннис, подтягивается на турнике, пока его картинка дождется своей очереди? Понятное дело, что если там нейросети, то без очереди не обойтись. Но если нет инференса тяжелой модели, а просто алгоритмическая часть, как в примере, то почему бы эти сто операций обработки не распараллелить хотя бы на, скажем, три-четыре потока?
Итак, написав прошлые три абзаца, я пришел вот к чему. Нам нужно разделить операцию загрузки картинок (или любых других данных) в ОЗУ (или сначала в какое-нибудь хранилище, а при надобности - из него в ОЗУ) от операции обработки этих картинок (данных), а по завершении обработки пользователю показывался либо результат, либо какое-то сообщение, что все, мол, ок. Причем, это решение должно масштабироваться, а отдельные компоненты должны не зависеть друг от друга, не считая интерфейса взаимодействия между этими компонентами.
Разве это не микросервисы? Окей, тут важен порядок, в отличие от event-driven (если я правильно понял текст из википедии), но что это в корне меняет? Либо в статье что-то не так изложено, либо тут действительно чего-то принципиально нового и не написано...
И конвертируются неправильно. Учитывая, что длины строковых параметров нигде не передаются, функция почти наверняка ожидает нуль-терминированные строки в качестве строковых параметров, а строки в Rust таковыми не являются.
Вы правы, в интернетах пишут, что правильный путь - это использование CString и CStr, которые нуль-терминированы, честно говоря, я теперь удивлен, что у меня все заработало.
И где гарантия, что 300 байтов хватит для каких бы то ни было целей?
Об этом я не упомянул, в документации сказано, что этот параметр должен быть не менее 256 байт.
Ещё: почему вы заводите safe_result только для того, чтобы присвоить в неё значение result?
Изначально я это сделал потому, что result хранит значение внутри unsafe блока, а результат растовской функции мне хотелось возвращать из safe блока. Доступа к result снаружи unsafe не будет - другая область видимости. Можно переписать это вот так
let safe_result: i32 = unsafe {
<...>
let result: c_int = ProMakePanoramaBuf( <...> );
<...>
result
};
И откуда вы вообще взяли эту библиотеку? Поиск в Google по запросу "libPanoMaker" находит только эту статью, а запрос "Xphase Pro PanoMaker" выдаёт какие-то нерелевантные результаты.
Ну, я в последнем же абзаце об этом и написал, это очень сложно гуглится, что является лучшей антирекламой этой камеры. А так, вот.
Мне легче думать, что раз уж разработчики не предоставляют такой интерфейс, значит так надо (мне лень), но спасибо за наводку, может и правда пригодится.
Я давно искал замену юнити, потому что он мне прежде всего не нравится картинкой и быстродействием. Пробовал сначала движки на Rust (лучше всех себя показал rg3d, ныне Fyrox, но он пока даже не в бета-тесте), потом попробовал Flax, но оттолкнуло, что, во-первых, он плохо работает на линуксе (у меня это основная система) а во-вторых, опять же, роялти - непонятно, как мне выплачивать их за границу. Unigine мне очень понравился в плане визуала прежде всего, всякие SSR, SSRTGI и проч. То, что он не очень-то и российский я, видать, упустил, можете ссылку какую-нибудь скинуть, где про это прочитать? 2. Я не шарпист ни разу, прочитал сейчас про асинхронность в нем и не понял, каким образом мне впихнуть Task-async-await в Update? По идее, мне следует создать асинхронный рантайм (потому что все функции управления, которые мне дает движок синхронные), который будет проходить по всем асинхронным задачам и управлять их выполнением (проверять, закончилась ли задача и чем), но хорошая ли это идея, учитывая, что сам движок управляет кучей потоков в рамках своего управления игрой? Может, правда что-то не улавливаю, можете написать пример?
Ну тут надо ещё помнить, что при for it in collection итератор иммутабельный, поэтому for i in range для изменения коллекции тоже имеет место быть. Если правильно помню, в джаве похожая ситуация.
Имхо, Amethyst пока не альтернатива Unity, потыкаться для развлечения можно, но что они там наворотили... Чего только стоят имплементация загрузки ресурсов и несобирающаяся документация на docs.rs. И вроде бы разобраться можно в этом всем, да только скудные возможности отбивают всякую мотивацию. Так что пока надеемся и ждем.
Именно поэтому мы и не можем поговорить с Яндекс.Алисой по душам. Она ведь ждёт вопросов и команд, а мы ей тут свой внутренний мир открываем.
А зачем? Алиса создана не для разговора по душам и не как замена живого общения, а как помощник. Не знаю, как вы, а я себе голосового помощника представляю как нечто, кому(чему) я могу делегировать функции, которые способен выполнить и без него - проверить погоду, узнать время, построить маршрут до пивного ларька. А с помощником я могу его просто попросить - и он это сделает за меня.
Как известно из истории нашей страны, когда-то давно, когда коммунисты хотели создать новую страну им понадобилось разрушить всё, что было создано до них веками. Это было крайне жёстко и безжалостно, но эффективно... Если не разрушить современные неработающие подходы и не развенчать мифы, то ничего нового создать не получится.
Вот только, увы, есть примеры стран, которые достигли больших (ударение на и, вопрос больше-меньше дискуссионный) успехов и без разрушения всего, что было создано до них.
Как по мне, текущая реализация голосового помощника свою функцию выполняет и, как минимум, странно требовать от неё чего-то большего. Никто и не говорит, что г.п. - тот же Вася или Петя, да никто так и не воспринимает их. Всем понятно, что это и для чего. А настоящий ИИ напишут, когда под него будет готова математическая основа, которой, пока что, нет.
Как по мне, просто людей в интернете становится больше, и средний iq в нем же неуклонно падает. Если раньше большинство пользователей считало кликбейты и идиотские соцсети чем-то ненормальным, то сейчас мы живем в реальности, где то самое некогда большинство стало лишним и теперь ищет себе место под солнцем. Но это не хорошо и не плохо, это просто реальность.
Ну и стоит упомянуть, что есть и обратный эффект - у малоизвестных творческих людей появилось место, где они могут самовыражаться. Как бы я ни любил времена форумов, но чего не отнять в современном интернете - обилие независимых музыкантов, чьи песни действительно хочется слушать, а не ставить где-то на фоне.
Зона риска – помещения с повышенной влажностью, а также пресные водоемы.
Наибольшую опасность она представляет, когда температура воздуха достигает 35-40 градусов по Цельсию, так как это идеальные условия для ее размножения.
официально было заявлено, что филадельфийским убийцей является бактерия легионелла, которая обитает в вентиляционных системах и вызывает пневмонию
Ну спасибо за паранойю. Я как раз сижу в +35 под кондиционером в 300 метрах от Волги.
Запоздало, но добавил. Тут дело случая, если в одном файле две сущности делают одно и тоже одним и тем же кодом (или минимально изменённым, например класс1 двигается вправо каждый кадр, а класс2 влево), то тут точно копирование — плохо.
Каждые две недели, вы хотели сказать? Помню ситуацию, когда в 19 году команды жаловались, что не могут подготовиться к мейджору, потому что каждые 2 недели выходит гигантский патч на 2 страницы. Сейчас ситуация не сильно изменилась, так что каждый новый патч — это как газета комсомольская правда.
Честно говоря, второй заголовок я написал будучи в небольшом заблуждении. Для меня стало большим открытием, что в расте есть анонимные классы и что код
trait Identifier<'a>{
fn identify(&self) -> &'a str;
}
fn main(){
let implementor: Box<dyn Identifier> = {
struct Anonymous{}
impl<'a> Identifier<'a> for Anonymous{
fn identify(&self) -> &'a str{
"I have no id..."
}
}
Box::new(Anonymous{})
};
let id = implementor.identify();
}
компилируется. Спасибо за развёрнутый ответ, стало намного понятнее.
Похоже, правое изображение отзеркалено. Если посмотреть его задом наперед, то на снимок отдалённо похоже
В статье вы сделали много ссылок на исследования. Исследования - это здорово, конечно, но им не всегда можно доверять. Вот исследование. Что уж говорить про социологию, где доказательная база строится на статистике, а статистикой можно вертеть как хочешь, чтобы подогнать под подтверждение какого-либо тезиса. Но мое негодование даже не в этом, а в том, что вы решили настолько политически индоктринированную статью выложить на хабре, а не, например, на wonderzine.
Текста написано много, но он будто обо всем и ни о чем. Сразу к примеру перейдем. Итак, в примере операция, которая будто и не требует декомпозиции, декомпозирована на три составляющие. Это, вроде как, должно помочь нам избавиться от узкого горлышка, как пишут в преимуществах.
Давайте подумаем, что произойдет. Первая часть системы быстро (относительно) прочитает все файлы и забьет очередь картинками, которые будут без дела пылиться в оперативной памяти компьютера и ждать своей очереди. Затем по одному их прочитает обработчик, и, сразу по завершении обработки, сейвер их сохранит. Это в общем-то частая проблема, когда приходится обрабатывать видеопоток или что-то подобное, обработка как правило занимает времени больше, чем чтение, поэтому обработать поток видео покадрово - тяжелая для вычислительной машины задача, добавляют балансировщики, которые подают на обработку только ценные кадры. То есть, не очень понятно, а зачем читать условные 100 картинок сразу в оперативную память, если можно их читать по одной?
Возможно, подразумевается, что данный паттерн будет реализован в рамках серверного приложения. То есть, 100 пользователей загрузили свои 100 картинок, и сотый идет в курилку, на обед, играет в теннис, подтягивается на турнике, пока его картинка дождется своей очереди? Понятное дело, что если там нейросети, то без очереди не обойтись. Но если нет инференса тяжелой модели, а просто алгоритмическая часть, как в примере, то почему бы эти сто операций обработки не распараллелить хотя бы на, скажем, три-четыре потока?
Итак, написав прошлые три абзаца, я пришел вот к чему. Нам нужно разделить операцию загрузки картинок (или любых других данных) в ОЗУ (или сначала в какое-нибудь хранилище, а при надобности - из него в ОЗУ) от операции обработки этих картинок (данных), а по завершении обработки пользователю показывался либо результат, либо какое-то сообщение, что все, мол, ок. Причем, это решение должно масштабироваться, а отдельные компоненты должны не зависеть друг от друга, не считая интерфейса взаимодействия между этими компонентами.
Разве это не микросервисы? Окей, тут важен порядок, в отличие от event-driven (если я правильно понял текст из википедии), но что это в корне меняет? Либо в статье что-то не так изложено, либо тут действительно чего-то принципиально нового и не написано...
Вы правы, в интернетах пишут, что правильный путь - это использование CString и CStr, которые нуль-терминированы, честно говоря, я теперь удивлен, что у меня все заработало.
Об этом я не упомянул, в документации сказано, что этот параметр должен быть не менее 256 байт.
Изначально я это сделал потому, что result хранит значение внутри unsafe блока, а результат растовской функции мне хотелось возвращать из safe блока. Доступа к result снаружи unsafe не будет - другая область видимости. Можно переписать это вот так
Ну, я в последнем же абзаце об этом и написал, это очень сложно гуглится, что является лучшей антирекламой этой камеры. А так, вот.
У меня так было несколько раз: на lubuntu 22.04 и на ubuntu 22.04. Оба раза отчаялся и переставлял систему.
Ассетстором не пользовался, какая там проблема?
Мне легче думать, что раз уж разработчики не предоставляют такой интерфейс, значит так надо (мне лень), но спасибо за наводку, может и правда пригодится.
Я давно искал замену юнити, потому что он мне прежде всего не нравится картинкой и быстродействием. Пробовал сначала движки на Rust (лучше всех себя показал rg3d, ныне Fyrox, но он пока даже не в бета-тесте), потом попробовал Flax, но оттолкнуло, что, во-первых, он плохо работает на линуксе (у меня это основная система) а во-вторых, опять же, роялти - непонятно, как мне выплачивать их за границу. Unigine мне очень понравился в плане визуала прежде всего, всякие SSR, SSRTGI и проч. То, что он не очень-то и российский я, видать, упустил, можете ссылку какую-нибудь скинуть, где про это прочитать?
2. Я не шарпист ни разу, прочитал сейчас про асинхронность в нем и не понял, каким образом мне впихнуть Task-async-await в Update? По идее, мне следует создать асинхронный рантайм (потому что все функции управления, которые мне дает движок синхронные), который будет проходить по всем асинхронным задачам и управлять их выполнением (проверять, закончилась ли задача и чем), но хорошая ли это идея, учитывая, что сам движок управляет кучей потоков в рамках своего управления игрой? Может, правда что-то не улавливаю, можете написать пример?
Ну, то есть, все изменяемые в контексте функций типы будут изменяемые и при итерировании
Можно. А если приспичит можно :
где i будет индекс, ai - указатель
Ну тут надо ещё помнить, что при for it in collection итератор иммутабельный, поэтому for i in range для изменения коллекции тоже имеет место быть. Если правильно помню, в джаве похожая ситуация.
Имхо, Amethyst пока не альтернатива Unity, потыкаться для развлечения можно, но что они там наворотили... Чего только стоят имплементация загрузки ресурсов и несобирающаяся документация на docs.rs. И вроде бы разобраться можно в этом всем, да только скудные возможности отбивают всякую мотивацию. Так что пока надеемся и ждем.
А зачем? Алиса создана не для разговора по душам и не как замена живого общения, а как помощник. Не знаю, как вы, а я себе голосового помощника представляю как нечто, кому(чему) я могу делегировать функции, которые способен выполнить и без него - проверить погоду, узнать время, построить маршрут до пивного ларька. А с помощником я могу его просто попросить - и он это сделает за меня.
Вот только, увы, есть примеры стран, которые достигли больших (ударение на и, вопрос больше-меньше дискуссионный) успехов и без разрушения всего, что было создано до них.
Как по мне, текущая реализация голосового помощника свою функцию выполняет и, как минимум, странно требовать от неё чего-то большего. Никто и не говорит, что г.п. - тот же Вася или Петя, да никто так и не воспринимает их. Всем понятно, что это и для чего. А настоящий ИИ напишут, когда под него будет готова математическая основа, которой, пока что, нет.
Как по мне, просто людей в интернете становится больше, и средний iq в нем же неуклонно падает. Если раньше большинство пользователей считало кликбейты и идиотские соцсети чем-то ненормальным, то сейчас мы живем в реальности, где то самое некогда большинство стало лишним и теперь ищет себе место под солнцем. Но это не хорошо и не плохо, это просто реальность.
Ну и стоит упомянуть, что есть и обратный эффект - у малоизвестных творческих людей появилось место, где они могут самовыражаться. Как бы я ни любил времена форумов, но чего не отнять в современном интернете - обилие независимых музыкантов, чьи песни действительно хочется слушать, а не ставить где-то на фоне.
Ну спасибо за паранойю. Я как раз сижу в +35 под кондиционером в 300 метрах от Волги.
"Врожденная потребность не умереть от страшной штуки"
компилируется. Спасибо за развёрнутый ответ, стало намного понятнее.