В Rust Зависимые типы (на данный момент) — это конкретные типы, которыми может оперировать trait (интерфейс). В общем, это способ замкнуть реализацию трейта на конкретном наборе структур. А зависимые они потому, что, в последствие, достаточно указать один параметр для трейта, чтобы инициализировать остальной набор типов.
Здесь в примере, завтипы не раскрылись в полной мере, потому что для этого надо было бы добавить ещё 1-2 уровня потомков. Но присутствуют:
trait Button<T: ProbablyMutable>
where
Self: Sized,
{
type Parent; // Зависимый тип
}
А потом мы его имплементируем для конкретных типов:
impl<'a, T: ProbablyMutable> Button<T> for WindowButton<'a, T> {
type Parent = &'a Window<'a, T>;
fn new(parent: Self::Parent, id: usize) -> Option<Self>;
}
impl<'a> ButtonMut for WindowButton<'a, Mutable> {
type Parent = Window<'a, Mutable>;
}
В принципе, если у нас появится целая пачка типов, которые нужны трейту — можно также их выводить из одного дженерик-параметра:
impl<'a, T: ProbablyMutable> Button<T> for WindowButton<'a, T> {
type Root = &'a Root<'a, T>;
type Parent = &'a Window<'a, T>;
type Child = WindowButtonText<T>;
fn new(parent: Self::Parent, id: usize) -> Option<Self>;
fn get_text(&self) -> Self::Child;
}
Я не понимаю, почему мы обсуждаем одну проблему, когда статья про другую? И потрудитесь прочитать, пожалуйста: она не «никогда не падает» и «проверяет любые переданные на вход параметры». А предоставляет такой механизм.
Ещё раз: проблема в том, чтобы на этапе компиляции (cargo check) знать, что ты не удалишь трек №2 во время того, как редактируешь что-то на треке №3. Я пытаюсь семантически связать те объекты, которые не связаны в оригинальном API.
Нет, когда я обращаюсь к вектору по индексу Vec::get(), он предлагает мне обработать Option. То же самое делает моя обёртка. Здесь механизм «проверки на валидность» лежит в самом модуле monkey_ffi, который возвращает None, если я прошу объект с id выше, чем у него. И, да, там даже unsafe код есть)
При работе с указателем у нас есть несколько других механизмов. Самый «лобовой» — ptr::is_null(). У меня, допустим, API предоставляет способ валидации указателя: отправляешь ему указатель, а он говорит, можно ли им пользоваться.
Я в этом случае сделал обёртку над обёрткой. Я получаю сырой указатель по методу get(), который внутри проверяет, живой ли указатель и паникует по необходимости. Если хочется проверить без паники — есть метод, который делает то же самое, но возвращает Result.
А, поскольку, эта операция тоже не бесплатная — есть способ выключить эту проверку на время. Допустим, в начале функции валидировать указатель, потом выключить проверки и работать на механизмах rust.
Вот тут можно посмотреть, как оно выглядит в проекте.
С одной стороны — хотелось бы, да. Хотелось бы хранить всё состояние внутри структур rust, и полагаться на встроенные механизмы безопасности. В своём проекте я даже некоторые функции, которые гарантированно выполняются в один вызов так и делаю — фетчу всё то состояние, которое мне необходимо, на его основе создаю свою структуру и работаю с ней. С другой стороны — я пока не нашёл лучшего способа инкапсуляции. С сырыми указателями плохо то, что они просто используются. Они не кричат о том, что их надо проверить на Null, их время жизни ограничено временем жизни переменной указателя и т.п.
Собственно, в этом отношении, работа с «указателями» в этом примере становится не более опасной, чем вызов элемента из вектора по индексу. Я добавляю как минимум гарантии:
того, что, мы сами не поломаем свои же объекты, потому что теперь можно менять один объект за раз
того, что объект умрёт вместе с «родителем» и я не смогу им пользоваться позже.
того, что объект из FFI слоя потребует себя проверить на Null (Option).
Может быть, GUI — не самая лучшая аналогия, потому что редко бывают ситуации, когда у GUI несколько владельцев. И тут можно было бы попробовать хранить копию состояния в структуре, оставляя лишь те проверки, которые отвечают за вход изначальных данных. И общаться с высокоуровневой обёрткой в стиле imgui\egui. Мне просто хотелось что-то более близкое и понятное, чем то, с чем общаюсь сейчас сам.
Но оригинальная среда, из которой я выцепил этот пример — это DAW, где есть треки, на них есть items, у них есть takes, в них есть source, в котором лежат сырые данные. И я физически не могу контролировать то, что происходит в проекте. Также, как мне кажется расточительным тратить на каждую операцию дополнительные O(n) на итерацию, особенно, если оно ещё будет в каждом вызове общаться с FFI: это и так несколько накладно, а про свой API я точно знаю, что можно нарваться на O(n²) за один обход, допустим, миди-событий в треке.
Ну и в принципе, с одной стороны, хотелось проработать пример достаточно для того, чтобы он «крякал», когда monkey_ffi выполняет какую-то операцию. И мог «упасть». А с другой стороны, это пример контроля параметризации мутабельности. Поэтому, чем больше «обвеса» — тем сложнее выцепить основной механизм, который тестирую, и про который рассказываю.
Ну из первого поста про структуру JSON я понял, что и JSON тоже надо руками парсить)
Какие-то ужасы вы рассказываете... Мне казалось, что если библиотеки используется в исходниках как есть — то её тоже надо оптимизировать и брать только то, что надо. А нет — тогда есть /usr/lib и динамическая линковка... Хотя всякие приложения для винды, которые идут в комплекте с полным Net.Runtime в комплекте...
Да, open-source спасёт мир! В принципе, в тестовой версии почувствовать: «Как оно, когда нельзя заработать на информации?» — можно в аудиопродакшне. Когда почти не остаётся способов продавать результат работы, но только лишь монетизировать сервис. Как музыкант, не вижу в этом ничего плохого.
По поводу JSON — я для lua без библиотек писал за кружку кофе парсер, да. Но в любом другом случае предпочту библиотеку, потому что библиотеке скормили уже кучу JSONов, и там наверняка встречались всякие. И не факт, что нет каких-то уязвимостей, которые можно получить, раскрывая JSON в рекурсии, или, там, парся значение из строки. Так что тут выбор в пользу библиотеки оправдан.
Оправдан ещё и тем, что если появляется бага — ты её фиксишь раз и навсегда, а не до следующего раза.
P.S. Тем более, я не уверен, как под капотом работает Java, но мне казалось, что исходники там вполне так себе компилируются и оптимизируются. Вряд ли же она тащит в бинарник всю библиотеку, которую использует...
Доступно. Но это всё-таки не столько проблема «замыканий», сколько времени жизни. Ну и, учитывая, что не каждый день в английской речи используешь слово closure — я статью открыл с интересом узнать о чём-то, чего не знаю :) А оказалось, что это closures.
Я бы вопрос о времени жизни переменных в ... всё время хочется назвать их лямбда-функциями ... в замыканиях развил в вопрос о времени жизни (lifetime, лайфтайм) в общем. Потому что первое прочтение rust book оставило у меня только необходимость аннотации лайфтаймов в функциях, возвращающих референсы.
А вот лайфтайм полей стуктуры, особенно, когда время жизни main() не равно времени жизни программы... В общем, на равне с макросами, лайфтаймы — тот синтаксис, которым очень боязно пользоваться.
А я долго не переходил на vscode именно потому что intellisense заставляет мышкой наводить на имена и ошибки, чтобы их увидеть. В отличие от sublime или того же vim, в которых такой тип взаимодействия в 3-4 раза быстрее.
Ну... Технически (и я так периодически делаю) в этом случае делаешь форк и замыкаешь на нём зависимость. Если хватает сил - мерджишь к себе апстрим. Но в случае кланга тут уже работает принцип демократии... Если что-то нужное тебе мешает коллективу, оно остаётся с тобой...
В этом году на моем округе прошел административный одномандатник за счёт удаленных деревень. Мои друзья съездили в эти деревни и сняли репортаж о том, как там подходят выборы и кто как голосовал (а я с музыкой помог). Люди пришли, проголосовали и выбрали себе депутата от ер.
А в городе не пришли и не проголосовали. Я сам ходил все лето агитировал на муниципальной избирательной кампании - прекрасно знаю, что "наш" избиратель сидел дома)
Ленивая загрузка на мой вкус - бич хабра. Взаимодействие с этим сайтом неторопливое, отложенное. Загрузил 2-3 вкладки, спустился в метро, и 30 минут читаешь. Вместо этого ни картинок, ни комментариев.
Я потому приложением не пользовался, что невозможно там обеспечить самый удобный вариант взаимодействия - пооткрывать во вкладках статьи и в течение недели их из этой очереди поглощать.
Что касается самих комментариев - радует, что они хотя бы стали загружаться. Но вообще уже столько было хороших некривых реализаций на несколько голов выше оригинала, что хочется чтоб уже наконец дали сторонним разработчикам API для логина и рейтинга, и не заставляли есть кактус.
Мне не нравится, что оно тормозит на мобильниках, загружается либо лениво, либо никак. И судя по всему, как тут уже несколько раз сказали, это не проблема механизма рендера, а проблема огромного DOM.
Мне не нравится, что для комментирования надо прокрутить ленту в конец
Что кэш работает очень странно. Я не очень много сайтов посещаю с мобильника, но пока что хабр - единственный, который тратит время и на повторную загрузку, и на то, чтобы после нее ещё раз обновить страницу, потому что на ней лента недельной давности.
Ещё в режиме энергосбережения есть такая байда, что при блокировки экрана чистится кэш браузера. И при разблокировке он загружается заново. В этом случае можно не рассчитывать найти окно просмотра на том же месте, где остановился. А комментарии, если их больше пары десятков - уже листать не могу.
Казалось бы, это, наверное страшные неразрешимые проблемы, которые задают дихотомию: или сайт грузится, или ленив.
Но нет, форумы xenforo лишены всех этих проблем! Отличный редактор, шустрая мобильная версия, якоря всегда на месте.
Давайте вы перенесете бд хабра на движок xenforo? Всем станет хорошо ?
А, сейчас стало понятнее: видно я в первую голову набрёл на такую инстанцию.
Да, почитал joinpeertube.org, идея интересная. Но тут надо хорошо перестроить мозги и понять каким образом в этой федерации лучше существовать конкретно тебе. И пока что у меня все ещё складывается ощущение, что надо завести где-то на чердаке отдельный медиа-сервер с отдельным каналом, чтобы:
а) быть уверенным в завтрашнем дне
б) не иметь в соседях порно или Майнкрафт.
в) поддержать правильную технологию.
То есть то, что сделал blender foundation.
Но нмв, рядовому производителю контента это куда сложнее, чем заплатить 500₽ vimeo. А отдаться на волю какого-то хостера — страшно.
Получается замкнутый круг: инстанций мало, потому что пользователей мало, а пользователей мало, потому что никто не может гарантировать жизнеспособность инстанции в хоть какой-то перспективе. И быть в руках какого-то дяди, которому толком и репутация не нужна. Просто пока он хочет нести в мир хорошее доброе вечное — несёт. А потом…
В этом отношении yt конечно говнюк, но говнюк предсказуемый
Слушайте, а почему у меня в трендах висит сплошная порнуха?)
Иду в описание сайта — вроде оно. Ищу чего-нить посмотреть — ....
И я всё ещё не очень понял, как оно работает: то есть, если я расшариваю видео — его, судя по всему, надо либо каким-то клиентом отдавать круглосуточно (а то не посмотрят), либо...
В общем, пока получается слишком много непонятного в процессе знакомства, и не понятно, где искать ответы...
Не, торренты я тоже раздаю, но и компьютер выключаю и клиент, когда мне нужна полоса в сети. Для торрента — поодождать до ночи, чтобы скачать что-то редкое — не беда, а для видеоплатформы —....
В Rust Зависимые типы (на данный момент) — это конкретные типы, которыми может оперировать trait (интерфейс). В общем, это способ замкнуть реализацию трейта на конкретном наборе структур. А зависимые они потому, что, в последствие, достаточно указать один параметр для трейта, чтобы инициализировать остальной набор типов.
Здесь в примере, завтипы не раскрылись в полной мере, потому что для этого надо было бы добавить ещё 1-2 уровня потомков. Но присутствуют:
А потом мы его имплементируем для конкретных типов:
В принципе, если у нас появится целая пачка типов, которые нужны трейту — можно также их выводить из одного дженерик-параметра:
Я не понимаю, почему мы обсуждаем одну проблему, когда статья про другую?
И потрудитесь прочитать, пожалуйста: она не «никогда не падает» и «проверяет любые переданные на вход параметры». А предоставляет такой механизм.
Ещё раз: проблема в том, чтобы на этапе компиляции (
cargo check) знать, что ты не удалишь трек №2 во время того, как редактируешь что-то на треке №3. Я пытаюсь семантически связать те объекты, которые не связаны в оригинальном API.Нет, когда я обращаюсь к вектору по индексу
Vec::get(), он предлагает мне обработатьOption. То же самое делает моя обёртка. Здесь механизм «проверки на валидность» лежит в самом модулеmonkey_ffi, который возвращаетNone, если я прошу объект с id выше, чем у него. И, да, там даже unsafe код есть)При работе с указателем у нас есть несколько других механизмов. Самый «лобовой» —
ptr::is_null(). У меня, допустим, API предоставляет способ валидации указателя: отправляешь ему указатель, а он говорит, можно ли им пользоваться.Я в этом случае сделал обёртку над обёрткой. Я получаю сырой указатель по методу
get(), который внутри проверяет, живой ли указатель и паникует по необходимости. Если хочется проверить без паники — есть метод, который делает то же самое, но возвращаетResult.А, поскольку, эта операция тоже не бесплатная — есть способ выключить эту проверку на время. Допустим, в начале функции валидировать указатель, потом выключить проверки и работать на механизмах rust.
Вот тут можно посмотреть, как оно выглядит в проекте.
С одной стороны — хотелось бы, да. Хотелось бы хранить всё состояние внутри структур rust, и полагаться на встроенные механизмы безопасности. В своём проекте я даже некоторые функции, которые гарантированно выполняются в один вызов так и делаю — фетчу всё то состояние, которое мне необходимо, на его основе создаю свою структуру и работаю с ней.
С другой стороны — я пока не нашёл лучшего способа инкапсуляции. С сырыми указателями плохо то, что они просто используются. Они не кричат о том, что их надо проверить на Null, их время жизни ограничено временем жизни переменной указателя и т.п.
Собственно, в этом отношении, работа с «указателями» в этом примере становится не более опасной, чем вызов элемента из вектора по индексу. Я добавляю как минимум гарантии:
того, что, мы сами не поломаем свои же объекты, потому что теперь можно менять один объект за раз
того, что объект умрёт вместе с «родителем» и я не смогу им пользоваться позже.
того, что объект из FFI слоя потребует себя проверить на Null (Option).
Может быть, GUI — не самая лучшая аналогия, потому что редко бывают ситуации, когда у GUI несколько владельцев. И тут можно было бы попробовать хранить копию состояния в структуре, оставляя лишь те проверки, которые отвечают за вход изначальных данных. И общаться с высокоуровневой обёрткой в стиле imgui\egui. Мне просто хотелось что-то более близкое и понятное, чем то, с чем общаюсь сейчас сам.
Но оригинальная среда, из которой я выцепил этот пример — это DAW, где есть треки, на них есть items, у них есть takes, в них есть source, в котором лежат сырые данные. И я физически не могу контролировать то, что происходит в проекте. Также, как мне кажется расточительным тратить на каждую операцию дополнительные O(n) на итерацию, особенно, если оно ещё будет в каждом вызове общаться с FFI: это и так несколько накладно, а про свой API я точно знаю, что можно нарваться на O(n²) за один обход, допустим, миди-событий в треке.
Ну и в принципе, с одной стороны, хотелось проработать пример достаточно для того, чтобы он «крякал», когда
monkey_ffiвыполняет какую-то операцию. И мог «упасть». А с другой стороны, это пример контроля параметризации мутабельности. Поэтому, чем больше «обвеса» — тем сложнее выцепить основной механизм, который тестирую, и про который рассказываю.Бот хороший. Сайту хотелось бы более внятной навигации. Юристы и карточки - огонь. Знаю новосибирских юристов, и поражаюсь их эффективностью.
Но больше всего в овдинфо мне нравится дизайн ?
Статья, похоже, написана лучше, чем книга, да...
Ну из первого поста про структуру JSON я понял, что и JSON тоже надо руками парсить)
Какие-то ужасы вы рассказываете... Мне казалось, что если библиотеки используется в исходниках как есть — то её тоже надо оптимизировать и брать только то, что надо. А нет — тогда есть /usr/lib и динамическая линковка... Хотя всякие приложения для винды, которые идут в комплекте с полным Net.Runtime в комплекте...
Да, open-source спасёт мир!
В принципе, в тестовой версии почувствовать: «Как оно, когда нельзя заработать на информации?» — можно в аудиопродакшне. Когда почти не остаётся способов продавать результат работы, но только лишь монетизировать сервис. Как музыкант, не вижу в этом ничего плохого.
По поводу JSON — я для lua без библиотек писал за кружку кофе парсер, да. Но в любом другом случае предпочту библиотеку, потому что библиотеке скормили уже кучу JSONов, и там наверняка встречались всякие. И не факт, что нет каких-то уязвимостей, которые можно получить, раскрывая JSON в рекурсии, или, там, парся значение из строки. Так что тут выбор в пользу библиотеки оправдан.
Оправдан ещё и тем, что если появляется бага — ты её фиксишь раз и навсегда, а не до следующего раза.
P.S. Тем более, я не уверен, как под капотом работает Java, но мне казалось, что исходники там вполне так себе компилируются и оптимизируются. Вряд ли же она тащит в бинарник всю библиотеку, которую использует...
Доступно. Но это всё-таки не столько проблема «замыканий», сколько времени жизни. Ну и, учитывая, что не каждый день в английской речи используешь слово closure — я статью открыл с интересом узнать о чём-то, чего не знаю :) А оказалось, что это closures.
Я бы вопрос о времени жизни переменных в ... всё время хочется назвать их лямбда-функциями ... в замыканиях развил в вопрос о времени жизни (lifetime, лайфтайм) в общем. Потому что первое прочтение rust book оставило у меня только необходимость аннотации лайфтаймов в функциях, возвращающих референсы.
А вот лайфтайм полей стуктуры, особенно, когда время жизни
main()не равно времени жизни программы... В общем, на равне с макросами, лайфтаймы — тот синтаксис, которым очень боязно пользоваться.А я долго не переходил на vscode именно потому что intellisense заставляет мышкой наводить на имена и ошибки, чтобы их увидеть. В отличие от sublime или того же vim, в которых такой тип взаимодействия в 3-4 раза быстрее.
Ну... Технически (и я так периодически делаю) в этом случае делаешь форк и замыкаешь на нём зависимость. Если хватает сил - мерджишь к себе апстрим.
Но в случае кланга тут уже работает принцип демократии... Если что-то нужное тебе мешает коллективу, оно остаётся с тобой...
Мне кажется, что это хороший вариант для составления ТЗ. А потом уж пусть дизайнер работает
В этом году на моем округе прошел административный одномандатник за счёт удаленных деревень. Мои друзья съездили в эти деревни и сняли репортаж о том, как там подходят выборы и кто как голосовал (а я с музыкой помог). Люди пришли, проголосовали и выбрали себе депутата от ер.
А в городе не пришли и не проголосовали. Я сам ходил все лето агитировал на муниципальной избирательной кампании - прекрасно знаю, что "наш" избиратель сидел дома)
Посмотрите - называется "Сузунская аномалия"
https://rmmedia.ru
VI-CONTROL
Ну что это такое? Я перехожу на комментарий по ссылке с десктопного Firefox — и не попадаю на него?((( Приходится искать через ctrl+f
Жж. Пагинация, дерево, тыщщи комментариев.
Но в целом xenforo удобнее по пользовательскому опыту
Ленивая загрузка на мой вкус - бич хабра. Взаимодействие с этим сайтом неторопливое, отложенное. Загрузил 2-3 вкладки, спустился в метро, и 30 минут читаешь. Вместо этого ни картинок, ни комментариев.
Я потому приложением не пользовался, что невозможно там обеспечить самый удобный вариант взаимодействия - пооткрывать во вкладках статьи и в течение недели их из этой очереди поглощать.
Что касается самих комментариев - радует, что они хотя бы стали загружаться. Но вообще уже столько было хороших некривых реализаций на несколько голов выше оригинала, что хочется чтоб уже наконец дали сторонним разработчикам API для логина и рейтинга, и не заставляли есть кактус.
Мне не нравится, что оно тормозит на мобильниках, загружается либо лениво, либо никак. И судя по всему, как тут уже несколько раз сказали, это не проблема механизма рендера, а проблема огромного DOM.
Мне не нравится, что для комментирования надо прокрутить ленту в конец
Что кэш работает очень странно. Я не очень много сайтов посещаю с мобильника, но пока что хабр - единственный, который тратит время и на повторную загрузку, и на то, чтобы после нее ещё раз обновить страницу, потому что на ней лента недельной давности.
Ещё в режиме энергосбережения есть такая байда, что при блокировки экрана чистится кэш браузера. И при разблокировке он загружается заново. В этом случае можно не рассчитывать найти окно просмотра на том же месте, где остановился. А комментарии, если их больше пары десятков - уже листать не могу.
Казалось бы, это, наверное страшные неразрешимые проблемы, которые задают дихотомию: или сайт грузится, или ленив.
Но нет, форумы xenforo лишены всех этих проблем! Отличный редактор, шустрая мобильная версия, якоря всегда на месте.
Давайте вы перенесете бд хабра на движок xenforo? Всем станет хорошо ?
Я недавно собирал простенькую приложу на python для корректной девочки в классе подруги. Всё проклял, пока смог сделать нормальную сбоку под win.
А потом оказалось, что у девочки на нетбуке убунту
А, сейчас стало понятнее: видно я в первую голову набрёл на такую инстанцию.
Да, почитал joinpeertube.org, идея интересная. Но тут надо хорошо перестроить мозги и понять каким образом в этой федерации лучше существовать конкретно тебе. И пока что у меня все ещё складывается ощущение, что надо завести где-то на чердаке отдельный медиа-сервер с отдельным каналом, чтобы:
а) быть уверенным в завтрашнем дне
б) не иметь в соседях порно или Майнкрафт.
в) поддержать правильную технологию.
То есть то, что сделал blender foundation.
Но нмв, рядовому производителю контента это куда сложнее, чем заплатить 500₽ vimeo. А отдаться на волю какого-то хостера — страшно.
Получается замкнутый круг: инстанций мало, потому что пользователей мало, а пользователей мало, потому что никто не может гарантировать жизнеспособность инстанции в хоть какой-то перспективе. И быть в руках какого-то дяди, которому толком и репутация не нужна. Просто пока он хочет нести в мир хорошее доброе вечное — несёт. А потом…
В этом отношении yt конечно говнюк, но говнюк предсказуемый
Слушайте, а почему у меня в трендах висит сплошная порнуха?)
Иду в описание сайта — вроде оно. Ищу чего-нить посмотреть — ....
И я всё ещё не очень понял, как оно работает: то есть, если я расшариваю видео — его, судя по всему, надо либо каким-то клиентом отдавать круглосуточно (а то не посмотрят), либо...
В общем, пока получается слишком много непонятного в процессе знакомства, и не понятно, где искать ответы...
Не, торренты я тоже раздаю, но и компьютер выключаю и клиент, когда мне нужна полоса в сети. Для торрента — поодождать до ночи, чтобы скачать что-то редкое — не беда, а для видеоплатформы —....