6,2 Мб, webm,1080x1080, 0:06
Хуже нет
737 Кб, webm,480x480, 0:05
Пока что не очень понял
45 Кб, 749x396Мб на этомм писать а мб нет, не знаю он слишком располагает к тому чтобы писать шизу типа https://paste.ee/p/FIZkH И ансейф немного сложно, например я очень не сразу понял почему https://paste.ee/p/dpYPe эта прога на скрине крашится
Более лимение жсон парсер https://godbolt.org/z/6PWhTT8r6 на самом деле мне он не нужен, а нужен хмл парсер, просто я ничего никогда не парсил, поэтому попробовал сначала что-то попроще. Получилось ужасно если честно
101 Кб, 480x640>>650387
Вообще в идеале твой парсер должен уметь работать, не имея всю строку в памяти, а читая куски по мере необходимости. Я себе сделал гибридный вариант:
— У парсера есть поля s: StringView (текущий буфер) + sp: SizeUint (позиция в буфере), через которые ты можешь удобно работать с куском текста в памяти. 99,8% времени этого достаточно; типичная ситуация — это тебе нужно прочитать число из 4 цифр, при этом sp = 1000, а s.n (размер буфера) = 65536, то есть всё число присутствует в памяти, и для осуществления желаемого можно так же, как с единственной строкой, натравить стандартную функцию преобразования строки в число на 4 символа в буфере, s.chars[sp..sp+3].
— Если ты достигаешь конца буфера (нужно прочитать число, но sp = 65534 и s.n = 65536 — доступны только 2 символа, и все они являются цифрами, так что неизвестно, это всё число или нет), ты вызываешь функцию ReadMore, которая читает новый блок — и, если нужно (если sp < s.n), переносит хвост старого блока, начиная с sp, в начало нового. Так что после неё s.chars[sp] продолжает указывать на начало числа, и в конце концов ты всё-таки заимеешь всё число в памяти, сведя случай к предыдущему.
Например, при разборе текста «someNumber = 1234; someOtherNumber = 5678» до ReadMore ситуация может быть
(где | — позиция sp.)
После ReadMore она станет
— s[sp] продолжает указывать на начало числа, а части перед sp полагаются больше никого не интересующими и разрешёнными для отбрасывания.
Вообще в идеале твой парсер должен уметь работать, не имея всю строку в памяти, а читая куски по мере необходимости. Я себе сделал гибридный вариант:
— У парсера есть поля s: StringView (текущий буфер) + sp: SizeUint (позиция в буфере), через которые ты можешь удобно работать с куском текста в памяти. 99,8% времени этого достаточно; типичная ситуация — это тебе нужно прочитать число из 4 цифр, при этом sp = 1000, а s.n (размер буфера) = 65536, то есть всё число присутствует в памяти, и для осуществления желаемого можно так же, как с единственной строкой, натравить стандартную функцию преобразования строки в число на 4 символа в буфере, s.chars[sp..sp+3].
— Если ты достигаешь конца буфера (нужно прочитать число, но sp = 65534 и s.n = 65536 — доступны только 2 символа, и все они являются цифрами, так что неизвестно, это всё число или нет), ты вызываешь функцию ReadMore, которая читает новый блок — и, если нужно (если sp < s.n), переносит хвост старого блока, начиная с sp, в начало нового. Так что после неё s.chars[sp] продолжает указывать на начало числа, и в конце концов ты всё-таки заимеешь всё число в памяти, сведя случай к предыдущему.
Например, при разборе текста «someNumber = 1234; someOtherNumber = 5678» до ReadMore ситуация может быть
>s = "someNumber = |12"
(где | — позиция sp.)
После ReadMore она станет
>s= "|1234; someOthe"
— s[sp] продолжает указывать на начало числа, а части перед sp полагаются больше никого не интересующими и разрешёнными для отбрасывания.
108 Кб, 1022x960Я купил это и мне вообще всё равно, мне вообще всё равно
Ещё не очень понял, в чём конкретно проблема. То ли в том, что невозможно нормально реализовать автозакрытие кавычек, то ли в том, что невозможно реализовать нормальный редактор текста с фичами сложнее подстветки синтаксиса.
Я не знаю, у меня проблемы с мозгом. Ну точнее знаю. Что они есть.
Я не знаю, у меня проблемы с мозгом. Ну точнее знаю. Что они есть.
Я вообще не понимаю, неужели нет никакого нормального способа без макросов достать из дженерик параметра какие-то компайл-тайм данные. Как вот это, например, https://paste.ee/p/acGQ1 переписать так, чтобы не приходилось вручную повторять всё. Я максимум додумался так сделать https://paste.ee/p/ChBMj, но тут проблема в том, что мне нужна эта константа при определении метода в трейте.
Я вообще не понима, неужели нет никакого нормального способа перестать быть лоу айкью дауном.
Я вообще не понима, неужели нет никакого нормального способа перестать быть лоу айкью дауном.
8 Кб, 1120x1120Самый лучший формат картинок, потому что он единственный, который мой лоу айкью мозг может реализовать https://netpbm.sourceforge.net/doc/ppm.html. Настолько самый лучший, что его 20 лет назад выпилили из фаерфокса https://bugzilla.mozilla.org/show_bug.cgi?id=197530. Хочу умереть.
22 Кб, 549x408Это то, как отображаются жсоны в фаерфоксе, абсолютно бесполезный визуальный мусор двоеточие в конце каждого ключа, которое выглядит как часть самого ключа, потому что оно даже цветом не отличается. Особенно плохо выглядит когда сам ключ может содержать на конце что-то вроде двоеточия.
Я не знаю, я постоянно на подобное напарываюсь, и можно было бы списать на то, что софт слишком сложный, чтобы избегать даже таких очевидных проблем, что это и не проблемы вовсе, а я просто придираюсь, но я сейчас задумался, что я так-то сам часть проблемы, потому что я в жизни своей никогда не создавал никаких баг репортов после того, как напарывался на подобные вещи. Ну я на английском просто плохо говорю ещё, умереть хочется, короче.
Я не знаю, я постоянно на подобное напарываюсь, и можно было бы списать на то, что софт слишком сложный, чтобы избегать даже таких очевидных проблем, что это и не проблемы вовсе, а я просто придираюсь, но я сейчас задумался, что я так-то сам часть проблемы, потому что я в жизни своей никогда не создавал никаких баг репортов после того, как напарывался на подобные вещи. Ну я на английском просто плохо говорю ещё, умереть хочется, короче.
Я не могу, у меня болит голова от раста, я хочу выпилиться как минимум из-за того, что там это, например, не реализовано https://rust-lang.github.io/rfcs/1210-impl-specialization.html я не понимаю, а зачем вообще нужны все эти трейты, писать код, абстрагированный от реализации, если я не могу банально сделать две реализации одного метода в зависимости от того, какие трейты имплементирует какой-то дженерик параметр. Это всё просто слишком сложно для моего мозга, какой-то бред, можно тогда не использовать трейты в принципе и прописывать конкретные типы, и тогда уже можно не писать на расте, а писать просто на си, даже не на плюсах, шаблоны же тоже тогда не потребуются.
Я не знаю, что делать с таким критическим падением айкью, мне плохо, постоянно какие-то нечитаемые ошибки с борров чекером, я устал, я хочу подохнуть. Я не чувствую, что пишу то, что хочу, я чувствую, что пишу то, что хочет rustc. Вот, небольшой кусок мусорного кода https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d997d44761f61669b3546aa13ee3c7bf я хотел сделать, чтобы advance мог скипать байты, если он выходит за границы того, что уже прочитано. Я не понимаю, как это сделать без чтения ненужных байтов в буфер и без io::Seek. Окей, есть io::copy и io::sink(), попробовал переписать https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d6593f809fcc6f260a0d6f0e39db994c всё у меня слишком маленький айкью, чтобы понять, а что не так, зачем take мувает внутрь себя источник, откуда он читает, что вообще происходит.
Что вот мне делать, переписать, чтобы он не сам читал, а у него спрашивали, что он хочет сделать: скипнуть байты, прочесть сколько-то байтов, и потом пушили в него байты что ли, но это же бред, а может лучше просто выпилиться, потому что жить с таким маленьким айкью это просто уже невозможно.
Я не знаю, что делать с таким критическим падением айкью, мне плохо, постоянно какие-то нечитаемые ошибки с борров чекером, я устал, я хочу подохнуть. Я не чувствую, что пишу то, что хочу, я чувствую, что пишу то, что хочет rustc. Вот, небольшой кусок мусорного кода https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d997d44761f61669b3546aa13ee3c7bf я хотел сделать, чтобы advance мог скипать байты, если он выходит за границы того, что уже прочитано. Я не понимаю, как это сделать без чтения ненужных байтов в буфер и без io::Seek. Окей, есть io::copy и io::sink(), попробовал переписать https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d6593f809fcc6f260a0d6f0e39db994c всё у меня слишком маленький айкью, чтобы понять, а что не так, зачем take мувает внутрь себя источник, откуда он читает, что вообще происходит.
Что вот мне делать, переписать, чтобы он не сам читал, а у него спрашивали, что он хочет сделать: скипнуть байты, прочесть сколько-то байтов, и потом пушили в него байты что ли, но это же бред, а может лучше просто выпилиться, потому что жить с таким маленьким айкью это просто уже невозможно.
>>668663
Если прописать use std::io::Read, то всё будет работать. Или если вместо
писать
то тоже будет работать.
Я понятия не имею, почему так. Проблема, видимо, в том, что в трейте Read есть только take(self, ...). Но в этом файле std::io::impls https://github.com/rust-lang/rust/blob/9fa6b3c15758e85657d5be051cfa57022a8bbe57/library/std/src/io/impls.rs#L17 есть отдельно реализация трейта Read для &mut Read. Но почему он сам не может разобраться, что можно использовать реализацию из impls, я не понимаю.
Минимальный пример как-то так выглядит:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=46d6d0474f2dd91d1b0bc33de05225b5
>>668693
Проблема не столько в расте, сколько в слишком низком айкью, который ещё и продолжает уменьшаться.
Если прописать use std::io::Read, то всё будет работать. Или если вместо
> self.source.by_ref().take(...)
писать
> io::Read::take(self.source.by_ref(), ...)
то тоже будет работать.
Я понятия не имею, почему так. Проблема, видимо, в том, что в трейте Read есть только take(self, ...). Но в этом файле std::io::impls https://github.com/rust-lang/rust/blob/9fa6b3c15758e85657d5be051cfa57022a8bbe57/library/std/src/io/impls.rs#L17 есть отдельно реализация трейта Read для &mut Read. Но почему он сам не может разобраться, что можно использовать реализацию из impls, я не понимаю.
Минимальный пример как-то так выглядит:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=46d6d0474f2dd91d1b0bc33de05225b5
>>668693
Проблема не столько в расте, сколько в слишком низком айкью, который ещё и продолжает уменьшаться.
>>668663
У меня появилось в мыслях, что можно было бы маркерами сделать два отдельных типа и в них сделать две отдельных реализации одного и того же метода. Но там всё равно без макросов в итоге не обойтись для реализации остальных методов, которые не зависят от того, какие трейты реализованы, но хотят вызывать методы, которые от реализованных трейтов зависят https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52707488453b2530ddf0d268a505c477. Ну либо так https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52707488453b2530ddf0d268a505c477 и я даже не знаю, что из этого хуже.
Но это даже не решение проблемы, что два отдельных типа приходится делать — это так-то бред.
У меня появилось в мыслях, что можно было бы маркерами сделать два отдельных типа и в них сделать две отдельных реализации одного и того же метода. Но там всё равно без макросов в итоге не обойтись для реализации остальных методов, которые не зависят от того, какие трейты реализованы, но хотят вызывать методы, которые от реализованных трейтов зависят https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52707488453b2530ddf0d268a505c477. Ну либо так https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52707488453b2530ddf0d268a505c477 и я даже не знаю, что из этого хуже.
Но это даже не решение проблемы, что два отдельных типа приходится делать — это так-то бред.
>>670968
Вообще ещё одна шизо-идея — это заставить самого пользователя реализовывать трейт Skippable. Сделать просто два макроса с двумя реализациями. Ну как, просто, там нужно будет как минимум заморочиться, если у структуры, для которой трейт реализуется, есть дженерик параметры, например. И вроде как вместе с min_specialization, которая вроде как по крайней мере не unsound, можно сделать одну дефолтную реализацию и пользователь может через макрос уточнить её https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b878b49b9ef2210b03a6163e1c887f27. То есть в худшем случае используется дефолтная реализация.
Вообще ещё одна шизо-идея — это заставить самого пользователя реализовывать трейт Skippable. Сделать просто два макроса с двумя реализациями. Ну как, просто, там нужно будет как минимум заморочиться, если у структуры, для которой трейт реализуется, есть дженерик параметры, например. И вроде как вместе с min_specialization, которая вроде как по крайней мере не unsound, можно сделать одну дефолтную реализацию и пользователь может через макрос уточнить её https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b878b49b9ef2210b03a6163e1c887f27. То есть в худшем случае используется дефолтная реализация.
>>668663
Ну в смысле, что он не будет вызывать read, не будет владеть буфером, куда читает, а будет только по указателю, который ему дают. Наверное, это лучше, не знаю, потому что более гранулярное апи получится, которое проще переиспользовать и бла-бла-бла https://youtu.be/ZQ5_u8Lgvyk, но важнее, что мне тогда не приходится использовать трейты.
Ещё в предыдущем >>650387 варианте у меня в голове была какая-то стрёмная идея, что токенизатор должен по очереди пытаться распарсить токены, про которые он знает, и, наверное, я думал, что это сделает реализацию довольно прямолинейной и будет легко добавлять новые типы токенов, но по факту получился довольно нечитабельный код.
Во-первых, жсон токенизатор всё не должен беспокоится о валидности строк, чисел и ключевых слов по типу true или false, он просто должен проглатывать все эти вещи до следующей кавычки или до следующего разделительного символа. То есть опять же, более гранулярное апи, пусть пользователь сам разбирается с валидацией utf-16 булшита в жсон строках, что там с числами и так далее.
Ещё же тут дело в том, что если я читаю жсон, чтобы извлечь из него какую-то информацию, я, скорее всего, знаю, какая у него схема и поэтому мне необязательно нужно полностью его структуру в память сохранять. Возможно, я просто хочу получить только значения по какому-то конкретному ключу.
Во-вторых, у токенизатора должен быть контекст: находится он просто жсоне, внутри строки, числа и тд. И в зависимости от контекста он должен по-разному интерпретировать прочитанные символы. И менять контекст по ходу токенизации — это тоже ответственность пользователя: что после открывающей кавычки надо поменять контекст на строку, например.
В общем, токенизатор становится просто функцией от указателя на байты и текущего контекста.
https://godbolt.org/z/88Kfaj9os
Ну это в первом приближении, я просто хотел проверить, смогу ли я хотя бы прожевать тот же жсон.
Но что я так и не придумал, как решить — это как быть с бэктрекгингом. Предыдущий вариант состоял из него целиком и полностью, тут его гораздо меньше, но я не могу придумать, как его избежать полностью. Конкретно многострочные комментарии: когда встречаю звёздочку мне нужно либо сразу прочесть следующий символ, чтобы понять, это конец комментария или нет, либо запомнить, что я прочитал звёздочку и если после неё потом прочитаю слеш, то это конец комментария, либо читать многострочные комментарии кусками и придумывать какой-то дополнительный контекст для токенизатора, в котором он останавливается, если читает слеш, либо не хранить никакого дополнительного состояния параноидально при виде каждого слеша читать, что было перед ним.
Но это всё кривые решения, которые реализованы как какие-то исключения из правил, я хочу умереть.
>переписать, чтобы он не сам читал
Ну в смысле, что он не будет вызывать read, не будет владеть буфером, куда читает, а будет только по указателю, который ему дают. Наверное, это лучше, не знаю, потому что более гранулярное апи получится, которое проще переиспользовать и бла-бла-бла https://youtu.be/ZQ5_u8Lgvyk, но важнее, что мне тогда не приходится использовать трейты.
Ещё в предыдущем >>650387 варианте у меня в голове была какая-то стрёмная идея, что токенизатор должен по очереди пытаться распарсить токены, про которые он знает, и, наверное, я думал, что это сделает реализацию довольно прямолинейной и будет легко добавлять новые типы токенов, но по факту получился довольно нечитабельный код.
Во-первых, жсон токенизатор всё не должен беспокоится о валидности строк, чисел и ключевых слов по типу true или false, он просто должен проглатывать все эти вещи до следующей кавычки или до следующего разделительного символа. То есть опять же, более гранулярное апи, пусть пользователь сам разбирается с валидацией utf-16 булшита в жсон строках, что там с числами и так далее.
Ещё же тут дело в том, что если я читаю жсон, чтобы извлечь из него какую-то информацию, я, скорее всего, знаю, какая у него схема и поэтому мне необязательно нужно полностью его структуру в память сохранять. Возможно, я просто хочу получить только значения по какому-то конкретному ключу.
Во-вторых, у токенизатора должен быть контекст: находится он просто жсоне, внутри строки, числа и тд. И в зависимости от контекста он должен по-разному интерпретировать прочитанные символы. И менять контекст по ходу токенизации — это тоже ответственность пользователя: что после открывающей кавычки надо поменять контекст на строку, например.
В общем, токенизатор становится просто функцией от указателя на байты и текущего контекста.
https://godbolt.org/z/88Kfaj9os
Ну это в первом приближении, я просто хотел проверить, смогу ли я хотя бы прожевать тот же жсон.
Но что я так и не придумал, как решить — это как быть с бэктрекгингом. Предыдущий вариант состоял из него целиком и полностью, тут его гораздо меньше, но я не могу придумать, как его избежать полностью. Конкретно многострочные комментарии: когда встречаю звёздочку мне нужно либо сразу прочесть следующий символ, чтобы понять, это конец комментария или нет, либо запомнить, что я прочитал звёздочку и если после неё потом прочитаю слеш, то это конец комментария, либо читать многострочные комментарии кусками и придумывать какой-то дополнительный контекст для токенизатора, в котором он останавливается, если читает слеш, либо не хранить никакого дополнительного состояния параноидально при виде каждого слеша читать, что было перед ним.
Но это всё кривые решения, которые реализованы как какие-то исключения из правил, я хочу умереть.
>>668663
Ну в смысле, что он не будет вызывать read, не будет владеть буфером, куда читает, а будет только по указателю, который ему дают. Наверное, это лучше, не знаю, потому что более гранулярное апи получится, которое проще переиспользовать и бла-бла-бла https://youtu.be/ZQ5_u8Lgvyk, но важнее, что мне тогда не приходится использовать трейты.
Ещё в предыдущем >>650387 варианте у меня в голове была какая-то стрёмная идея, что токенизатор должен по очереди пытаться распарсить токены, про которые он знает, и, наверное, я думал, что это сделает реализацию довольно прямолинейной и будет легко добавлять новые типы токенов, но по факту получился довольно нечитабельный код.
Во-первых, жсон токенизатор всё не должен беспокоится о валидности строк, чисел и ключевых слов по типу true или false, он просто должен проглатывать все эти вещи до следующей кавычки или до следующего разделительного символа. То есть опять же, более гранулярное апи, пусть пользователь сам разбирается с валидацией utf-16 булшита в жсон строках, что там с числами и так далее.
Ещё же тут дело в том, что если я читаю жсон, чтобы извлечь из него какую-то информацию, я, скорее всего, знаю, какая у него схема и поэтому мне необязательно нужно полностью его структуру в память сохранять. Возможно, я просто хочу получить только значения по какому-то конкретному ключу.
Во-вторых, у токенизатора должен быть контекст: находится он просто жсоне, внутри строки, числа и тд. И в зависимости от контекста он должен по-разному интерпретировать прочитанные символы. И менять контекст по ходу токенизации — это тоже ответственность пользователя: что после открывающей кавычки надо поменять контекст на строку, например.
В общем, токенизатор становится просто функцией от указателя на байты и текущего контекста.
https://godbolt.org/z/88Kfaj9os
Ну это в первом приближении, я просто хотел проверить, смогу ли я хотя бы прожевать тот же жсон.
Но что я так и не придумал, как решить — это как быть с бэктрекгингом. Предыдущий вариант состоял из него целиком и полностью, тут его гораздо меньше, но я не могу придумать, как его избежать полностью. Конкретно многострочные комментарии: когда встречаю звёздочку мне нужно либо сразу прочесть следующий символ, чтобы понять, это конец комментария или нет, либо запомнить, что я прочитал звёздочку и если после неё потом прочитаю слеш, то это конец комментария, либо читать многострочные комментарии кусками и придумывать какой-то дополнительный контекст для токенизатора, в котором он останавливается, если читает слеш, либо не хранить никакого дополнительного состояния параноидально при виде каждого слеша читать, что было перед ним.
Но это всё кривые решения, которые реализованы как какие-то исключения из правил, я хочу умереть.
>переписать, чтобы он не сам читал
Ну в смысле, что он не будет вызывать read, не будет владеть буфером, куда читает, а будет только по указателю, который ему дают. Наверное, это лучше, не знаю, потому что более гранулярное апи получится, которое проще переиспользовать и бла-бла-бла https://youtu.be/ZQ5_u8Lgvyk, но важнее, что мне тогда не приходится использовать трейты.
Ещё в предыдущем >>650387 варианте у меня в голове была какая-то стрёмная идея, что токенизатор должен по очереди пытаться распарсить токены, про которые он знает, и, наверное, я думал, что это сделает реализацию довольно прямолинейной и будет легко добавлять новые типы токенов, но по факту получился довольно нечитабельный код.
Во-первых, жсон токенизатор всё не должен беспокоится о валидности строк, чисел и ключевых слов по типу true или false, он просто должен проглатывать все эти вещи до следующей кавычки или до следующего разделительного символа. То есть опять же, более гранулярное апи, пусть пользователь сам разбирается с валидацией utf-16 булшита в жсон строках, что там с числами и так далее.
Ещё же тут дело в том, что если я читаю жсон, чтобы извлечь из него какую-то информацию, я, скорее всего, знаю, какая у него схема и поэтому мне необязательно нужно полностью его структуру в память сохранять. Возможно, я просто хочу получить только значения по какому-то конкретному ключу.
Во-вторых, у токенизатора должен быть контекст: находится он просто жсоне, внутри строки, числа и тд. И в зависимости от контекста он должен по-разному интерпретировать прочитанные символы. И менять контекст по ходу токенизации — это тоже ответственность пользователя: что после открывающей кавычки надо поменять контекст на строку, например.
В общем, токенизатор становится просто функцией от указателя на байты и текущего контекста.
https://godbolt.org/z/88Kfaj9os
Ну это в первом приближении, я просто хотел проверить, смогу ли я хотя бы прожевать тот же жсон.
Но что я так и не придумал, как решить — это как быть с бэктрекгингом. Предыдущий вариант состоял из него целиком и полностью, тут его гораздо меньше, но я не могу придумать, как его избежать полностью. Конкретно многострочные комментарии: когда встречаю звёздочку мне нужно либо сразу прочесть следующий символ, чтобы понять, это конец комментария или нет, либо запомнить, что я прочитал звёздочку и если после неё потом прочитаю слеш, то это конец комментария, либо читать многострочные комментарии кусками и придумывать какой-то дополнительный контекст для токенизатора, в котором он останавливается, если читает слеш, либо не хранить никакого дополнительного состояния параноидально при виде каждого слеша читать, что было перед ним.
Но это всё кривые решения, которые реализованы как какие-то исключения из правил, я хочу умереть.
https://github.com/rust-lang/rust/blob/c49c4fba1168d8a776ef5207ec28000112191ae2/library/core/src/str/validations.rs#L210-L237
Это типо эвристическая оптимизация, из предположения, что рядом с ASCII символами будут с большой вероятностью другие ASCII символы?
Ещё я как-то, мне надо было хотя бы немного пролистнуть RFC у UTF-8, потому что всё же, например, не любые три байта вида
являются валидным код поинтом. Правда, я чего-то не знаю, почему так сделали.
https://www.rfc-editor.org/rfc/rfc3629#section-4
Например, E0 80 80 — это невалидный код поинт.
Я ещё заметил, что from_utf8 возвращает в ошибке то, до какого момента байты валидны, и там есть ещё unchecked версия, которая просто каст делает. Короче, наверное, лучше этим пользоваться, если использовать std в принципе, чем городить ту кривую ерунду, которую я написал выше.
Нашёл очень доступное для лоу айкью даунов объяснение про LR(0), SLR(1) и LR(1) парсеры:
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/100%20Bottom-Up%20Parsing.pdf
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/110%20LR%20and%20SLR%20Parsing.pdf
Но я не знаю, хватит ли у меня айкью, чтобы реализовать генерацию action/goto таблиц хотя бы для LR(0) грамматик, а LR(0)-парсинг, если что, это когда ты применяешь правило из грамматики к последовательности символов только лишь основываясь на том, какие символы ты успел прочитать, без учёта того, что за ними идёт. То есть, например, в такой грамматике, как я понимаю, невозможно нормально реализовать оператор постинкремента или operator[].
>>672094
Нет, короче, это бред, в этом JsonTokenizerMode нет никакого смысла, усложнение кода ради ничего, в итоге получается одна жирная функция, которая обрабатывает все ситуации, вместо нескольких небольших на каждую отдельную ситуацию, да, очень ГРАНУЛЯРНО, какой же я тупорылый даун. Так, всё, я перепишу нормально, как было с самого начала, только, возможно, без шизомакросов и всё же с фиксированным буфером, куда читается входная строка.
Это типо эвристическая оптимизация, из предположения, что рядом с ASCII символами будут с большой вероятностью другие ASCII символы?
Ещё я как-то, мне надо было хотя бы немного пролистнуть RFC у UTF-8, потому что всё же, например, не любые три байта вида
> 1110xxxx 10xxxxxx 10xxxxxx
являются валидным код поинтом. Правда, я чего-то не знаю, почему так сделали.
https://www.rfc-editor.org/rfc/rfc3629#section-4
Например, E0 80 80 — это невалидный код поинт.
Я ещё заметил, что from_utf8 возвращает в ошибке то, до какого момента байты валидны, и там есть ещё unchecked версия, которая просто каст делает. Короче, наверное, лучше этим пользоваться, если использовать std в принципе, чем городить ту кривую ерунду, которую я написал выше.
Нашёл очень доступное для лоу айкью даунов объяснение про LR(0), SLR(1) и LR(1) парсеры:
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/100%20Bottom-Up%20Parsing.pdf
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/110%20LR%20and%20SLR%20Parsing.pdf
Но я не знаю, хватит ли у меня айкью, чтобы реализовать генерацию action/goto таблиц хотя бы для LR(0) грамматик, а LR(0)-парсинг, если что, это когда ты применяешь правило из грамматики к последовательности символов только лишь основываясь на том, какие символы ты успел прочитать, без учёта того, что за ними идёт. То есть, например, в такой грамматике, как я понимаю, невозможно нормально реализовать оператор постинкремента или operator[].
>>672094
Нет, короче, это бред, в этом JsonTokenizerMode нет никакого смысла, усложнение кода ради ничего, в итоге получается одна жирная функция, которая обрабатывает все ситуации, вместо нескольких небольших на каждую отдельную ситуацию, да, очень ГРАНУЛЯРНО, какой же я тупорылый даун. Так, всё, я перепишу нормально, как было с самого начала, только, возможно, без шизомакросов и всё же с фиксированным буфером, куда читается входная строка.
https://github.com/rust-lang/rust/blob/c49c4fba1168d8a776ef5207ec28000112191ae2/library/core/src/str/validations.rs#L210-L237
Это типо эвристическая оптимизация, из предположения, что рядом с ASCII символами будут с большой вероятностью другие ASCII символы?
Ещё я как-то, мне надо было хотя бы немного пролистнуть RFC у UTF-8, потому что всё же, например, не любые три байта вида
являются валидным код поинтом. Правда, я чего-то не знаю, почему так сделали.
https://www.rfc-editor.org/rfc/rfc3629#section-4
Например, E0 80 80 — это невалидный код поинт.
Я ещё заметил, что from_utf8 возвращает в ошибке то, до какого момента байты валидны, и там есть ещё unchecked версия, которая просто каст делает. Короче, наверное, лучше этим пользоваться, если использовать std в принципе, чем городить ту кривую ерунду, которую я написал выше.
Нашёл очень доступное для лоу айкью даунов объяснение про LR(0), SLR(1) и LR(1) парсеры:
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/100%20Bottom-Up%20Parsing.pdf
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/110%20LR%20and%20SLR%20Parsing.pdf
Но я не знаю, хватит ли у меня айкью, чтобы реализовать генерацию action/goto таблиц хотя бы для LR(0) грамматик, а LR(0)-парсинг, если что, это когда ты применяешь правило из грамматики к последовательности символов только лишь основываясь на том, какие символы ты успел прочитать, без учёта того, что за ними идёт. То есть, например, в такой грамматике, как я понимаю, невозможно нормально реализовать оператор постинкремента или operator[].
>>672094
Нет, короче, это бред, в этом JsonTokenizerMode нет никакого смысла, усложнение кода ради ничего, в итоге получается одна жирная функция, которая обрабатывает все ситуации, вместо нескольких небольших на каждую отдельную ситуацию, да, очень ГРАНУЛЯРНО, какой же я тупорылый даун. Так, всё, я перепишу нормально, как было с самого начала, только, возможно, без шизомакросов и всё же с фиксированным буфером, куда читается входная строка.
Это типо эвристическая оптимизация, из предположения, что рядом с ASCII символами будут с большой вероятностью другие ASCII символы?
Ещё я как-то, мне надо было хотя бы немного пролистнуть RFC у UTF-8, потому что всё же, например, не любые три байта вида
> 1110xxxx 10xxxxxx 10xxxxxx
являются валидным код поинтом. Правда, я чего-то не знаю, почему так сделали.
https://www.rfc-editor.org/rfc/rfc3629#section-4
Например, E0 80 80 — это невалидный код поинт.
Я ещё заметил, что from_utf8 возвращает в ошибке то, до какого момента байты валидны, и там есть ещё unchecked версия, которая просто каст делает. Короче, наверное, лучше этим пользоваться, если использовать std в принципе, чем городить ту кривую ерунду, которую я написал выше.
Нашёл очень доступное для лоу айкью даунов объяснение про LR(0), SLR(1) и LR(1) парсеры:
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/100%20Bottom-Up%20Parsing.pdf
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/110%20LR%20and%20SLR%20Parsing.pdf
Но я не знаю, хватит ли у меня айкью, чтобы реализовать генерацию action/goto таблиц хотя бы для LR(0) грамматик, а LR(0)-парсинг, если что, это когда ты применяешь правило из грамматики к последовательности символов только лишь основываясь на том, какие символы ты успел прочитать, без учёта того, что за ними идёт. То есть, например, в такой грамматике, как я понимаю, невозможно нормально реализовать оператор постинкремента или operator[].
>>672094
Нет, короче, это бред, в этом JsonTokenizerMode нет никакого смысла, усложнение кода ради ничего, в итоге получается одна жирная функция, которая обрабатывает все ситуации, вместо нескольких небольших на каждую отдельную ситуацию, да, очень ГРАНУЛЯРНО, какой же я тупорылый даун. Так, всё, я перепишу нормально, как было с самого начала, только, возможно, без шизомакросов и всё же с фиксированным буфером, куда читается входная строка.
Я пытался https://youtu.be/Si8QRtdjrUA
Всегда казалось, что нет лучше чувства, чем когда осознанно отлыниваешь от каких-то навязанных тебе "обязанностей", не делаешь того, что ты якобы должен делать. Но, на самом деле, это просто обычное состояние, когда тебя не ничего беспокоит, а во все остальные моменты в мыслях крутится постоянно, что а вот завтра придётся что-то делать или что кто-то от меня что-то ожидает, это портит жизнь, это портит моё настроение. Я не могу спокойно жить с осознанием, что моё время мне не принадлежит мне целиком и полностью, что кому-то от меня что-то надо, что кто-то претендует на то, чтобы отнимать у меня жизнь. Всё, чего я когда-либо действительно хотел — это проснуться с осознанием, что я свободен от выдуманных какими-то идиотами обязанностей, никому от меня ничего не надо и у меня в голове не скребутся посторонние мысли на фоне. Да-да, никому и так от меня ничего не надо, если бы я лёг под мостом и помер бы там, никто бы до меня не докопался, всем было бы наплевать. Но меня вынуждают встраиваться в эту долбаную систему, где всем от всех что-то нужно, а потом ещё пытаются внушить, что я это, оказывается, сделал по своей воле, вот захотелось мне повесить на шею цепи, а теперь жалуюсь, что мне тяжело, и вообще нам тоже тяжело, а чем ты лучше? Да в жизни я бы не сделал этого выбора, если бы мог вообще сделать выбор в пользу чего-то другого. Я не могу уже так жить, в какой-то момент становится невозможно терпеть и ты просто бросаешь то, что тебя заставляли делать. А потом тебя спрашивают, а почему так, ну ты же так старался, а теперь всё дропнул, как будто я делаю что-то нелогичное. Как будто то, что я перестал отпиливать себе ногу — это что-то неразумное и раз начал пилить, то надо пилить до конца. А это именно отпиливание своей ноги, нет никакой конечной цели, у меня нет никаких амбиций, мне не нужно ничего этого, меня просто заставляют страдать ради ничего. Это не обмен ресурсов моей силы воли ради достижения какого-то результата, это просто растрата моих сил в никуда, я ничего от этого не получаю, я только теряю. Я не могу так жить, мне нужен отдых, мне нужно, чтобы от меня все отстали, это невозможно больше терпеть, мне не помогает никакой копинг, это просто патовая ситуация, в которой мне, как жертве пыток, привязанной ко стулу, остаётся только ждать, когда смерть освободит меня от страданий.
Всегда казалось, что нет лучше чувства, чем когда осознанно отлыниваешь от каких-то навязанных тебе "обязанностей", не делаешь того, что ты якобы должен делать. Но, на самом деле, это просто обычное состояние, когда тебя не ничего беспокоит, а во все остальные моменты в мыслях крутится постоянно, что а вот завтра придётся что-то делать или что кто-то от меня что-то ожидает, это портит жизнь, это портит моё настроение. Я не могу спокойно жить с осознанием, что моё время мне не принадлежит мне целиком и полностью, что кому-то от меня что-то надо, что кто-то претендует на то, чтобы отнимать у меня жизнь. Всё, чего я когда-либо действительно хотел — это проснуться с осознанием, что я свободен от выдуманных какими-то идиотами обязанностей, никому от меня ничего не надо и у меня в голове не скребутся посторонние мысли на фоне. Да-да, никому и так от меня ничего не надо, если бы я лёг под мостом и помер бы там, никто бы до меня не докопался, всем было бы наплевать. Но меня вынуждают встраиваться в эту долбаную систему, где всем от всех что-то нужно, а потом ещё пытаются внушить, что я это, оказывается, сделал по своей воле, вот захотелось мне повесить на шею цепи, а теперь жалуюсь, что мне тяжело, и вообще нам тоже тяжело, а чем ты лучше? Да в жизни я бы не сделал этого выбора, если бы мог вообще сделать выбор в пользу чего-то другого. Я не могу уже так жить, в какой-то момент становится невозможно терпеть и ты просто бросаешь то, что тебя заставляли делать. А потом тебя спрашивают, а почему так, ну ты же так старался, а теперь всё дропнул, как будто я делаю что-то нелогичное. Как будто то, что я перестал отпиливать себе ногу — это что-то неразумное и раз начал пилить, то надо пилить до конца. А это именно отпиливание своей ноги, нет никакой конечной цели, у меня нет никаких амбиций, мне не нужно ничего этого, меня просто заставляют страдать ради ничего. Это не обмен ресурсов моей силы воли ради достижения какого-то результата, это просто растрата моих сил в никуда, я ничего от этого не получаю, я только теряю. Я не могу так жить, мне нужен отдых, мне нужно, чтобы от меня все отстали, это невозможно больше терпеть, мне не помогает никакой копинг, это просто патовая ситуация, в которой мне, как жертве пыток, привязанной ко стулу, остаётся только ждать, когда смерть освободит меня от страданий.
Не могу переступить через себя, нет сил на это, в какой-то момент всегда иссякает сила воли и всё. Не становится со временем легче. Когда нет никакого смысла в страданиях, через время устаёшь и не можешь продолжать. У большинства нет таких проблем, я уверен, большинство делают то, что им либо хочется, либо то, что они по крайней мере не против делать, а страдаю я один. Я не знаю, может быть, разломать телефон и комп, забиться в угол и там сидеть, это, возможно, лучше, чем каждый день страдать. Мне просто нужно спокойствие, но большинству людей, видимо, этого не нужно и вообще они делают всё, чтобы его избегать, я не хочу, я устал, почему это всё должно происходить со мной, когда это закончится.
Я не могу, я не спал нормально несколько дней из-за того, что постоянно в напряжении из-за того, что мне якобы надо что-то сделать, но я не могу себя пересилить и я в итоге ничего не делаю, сегодня весь день болела голова, болели глаза и хотелось спать, сегодня снова не высплюсь, потому что буду сидеть и пытаться себя заставить себя что-то сделать, но я снова ничего не сделаю, потому что я просто не могу, у меня внутри всё противится, это невозможно побороть. Я не могу, мне нужно просто, чтобы кто-то извне обрубил этот цикл и я освободился от этих страданий.
506 Кб, 1787x2048Я, короче, буду тут писать сколько мне влезет вне зависимости от того, делаю ли я что-то или нет, и я буду постить картинки, какие захочу, мне вообще всё равно, потому что мне грустно, мне плохо, я, короче, сейчас посмотрел немного это https://www.w3.org/Graphics/GIF/spec-gif89a.txt и это должно быть не очень сложно сделать, там просто lzw сжатие, я не знаю зачем, но просто мемный формат: во-первых, в него официально можно пихать мусор (comment extension), во-вторых, можно сохранять rgb888 картинки, если распределить цвета на несколько кадров и рисовать новое поверх предыдущих кадров, в-третьих, это простейший способ сохранить видео.
И со вторым тут две идеи: наивная - все кадры одинакового размера, прозрачный цвет на местах уже закрашенных пикселей, и вторая - попытаться разбить картинку на как можно больше непересекающихся прямоугольников, чтобы не хранить избыточные прозрачные пиксели. Как это сделать - не знаю, наверное, резать пополам пока не найдёшь прямоугольник, где мало цветов, и потом так же, разрезанием пополам пытаться присоединить к нему ещё прямоугольник, чтобы по возможности максимизировать количество цветов. Но я не уверен, что это будет работать лучше, чем наивная идея.
Вариация идеи с прямоугольниками - в глобальной таблице цветов сохранить все самые часто встречающиеся цвета и в первую очередь искать прямоугольники, где много цветов из глобальной таблицы, для которых использовать глобальную таблицу вместо локальных. Ну то есть попытаться сократить повторные цвета среди локальных таблиц. Но тут, мне кажется, это совсем переусложнённый вариант и он точно будет в реальности хуже наивного.
Я начал сегодня писать читалку гифок, но пока что не успел написать даже прогу, которая бы просто проглатывала гифку без разбора. Я постараюсь найти завтра время, чтобы хотя бы просто проглотить гифку.
И со вторым тут две идеи: наивная - все кадры одинакового размера, прозрачный цвет на местах уже закрашенных пикселей, и вторая - попытаться разбить картинку на как можно больше непересекающихся прямоугольников, чтобы не хранить избыточные прозрачные пиксели. Как это сделать - не знаю, наверное, резать пополам пока не найдёшь прямоугольник, где мало цветов, и потом так же, разрезанием пополам пытаться присоединить к нему ещё прямоугольник, чтобы по возможности максимизировать количество цветов. Но я не уверен, что это будет работать лучше, чем наивная идея.
Вариация идеи с прямоугольниками - в глобальной таблице цветов сохранить все самые часто встречающиеся цвета и в первую очередь искать прямоугольники, где много цветов из глобальной таблицы, для которых использовать глобальную таблицу вместо локальных. Ну то есть попытаться сократить повторные цвета среди локальных таблиц. Но тут, мне кажется, это совсем переусложнённый вариант и он точно будет в реальности хуже наивного.
Я начал сегодня писать читалку гифок, но пока что не успел написать даже прогу, которая бы просто проглатывала гифку без разбора. Я постараюсь найти завтра время, чтобы хотя бы просто проглотить гифку.
642 Кб, 1378x2039Я, короче, не успел ничего. Нашёл такой мем https://rust-unofficial.github.io/too-many-lists/fourth-iteration.html связный список на идиоматичном расте, но у меня от него болит голова и я не до конца дочитал. Тут вроде типо в конечном счёте итерация по связному списку из элементов Rc<RefCell<Node>> упирается в то, что сначала тебе нужно запомнить, что ты одолжил голову у списка: Ref<'a, Node>, потом, что ты у одолженной у списка головы одолжил следующий за ней элемент: Ref<'b, Ref<'a, Node>>, потом, что одолжил следующий элемент у предыдущего, который был одолжен у головы, которая была одолжена у списка: Ref<'c, Ref<'b, Ref<'a, Node>>>. И ты при этом должен каким-то образом по ходу итерации держать на руках все эти промежуточные ссылки, а не только самую последнюю, потому что у последующих ссылок лайфтайм вложен в предыдущие, потому что 'a - это лайфтайм списка, 'b - это лайфтайм Ref<'a, Node>, 'c - это лайфтайм Ref<'b, Ref<'a, Node>>> и так далее. Ну вроде, я не до конца понял, короче, нужен гарбаж коллектор, получается. Это вообще просто мем, но там вроде дальше что-то про unsafe есть, но я не читал ещё.
2,1 Мб, 3541x2508Я не сделал, я слишком много думаю и ничего не делаю, а это бесполезно - думать, когда ты тупой, слишком маленький айкью, нет смысла, тем более, когда не особо много времени и есть, и осталось. Это даже не какие-то последовательные мысли, а просто обрывки, которые ни во что не складываются, примерно как когда утром наполовину просыпаешься и ты наполовину в сознании, а наполовину в башке крутятся бредовые остатки сна, который ты потом почти сразу забудешь. Я должен был умереть несколько лет назад, ничего хорошего не было и уже не будет, только страдания от низкого айкью, от тупости. Что, я не могу ничего пообещать. Мне кажется, что настолько всё плохо, что даже, если меня несмертельно ударить по голове молотком, то ничего не изменится, потому что максимум дальше можно только умереть и спрятаться в гроб, уже невозможно сделать хуже. Я купил себе новый проц, но вместе с ним нужна была и новая мать, старую вместе со старым процом положил в коробку, меня тоже нужно положить в горобку, нужно, чтобы кто-то спас меня от такой жизни.
>>686709
С возвращением тебя.
Однажды я курил с обычным пацаном с района, мы стояли и был обычный диалог гоп-стиль ни о чём. Я вижу как к нам идёт один казах, я думаю что он такой же как другой чувак, дескать типичный пацанчик с района и он так себя и вёл, пока я что-то не сказанул про античную философию...
Я люблю поговорить, но глубоких познаний у меня нëт ни в чём, этот казах меня раскатал как ребёнка. У него даже тон изменился, он стал настоящий когда мы начали говорить про философию. А выглядел как обычный "четкий пацан". Я тогда особого внимания не это не обратил.
Сейчас когда начал менять свою жизнь понял, что очень многие люди завидуют мне из-за моего интеллекта, чуствуют себя ниже и это задевает их самолюбие. Поэтому они пытаются меня клюнуть. Вот вчера выряс это с с силой из своей подружки. Я сам считал себя самым последним глупцом на свете, даже совсем не верил своему мнению. Но это потому, что меня всю жизнь подавляла мать, а отца не было, а на самом деле я как Никола Тесла, чуствую это.
А тот парнишка просто скрывал силу, ведь иначе люди не примут. Всегда появляются проблемы когда ты выше в обществе на порядок. Но говорить стоит не со всеми. Ты можешь просто не говорить с людьми или говорить с ними на их языке, как тот казах. Тогда они тебя примут, но главное внутри остаться собой. Поверь в себя.
Бог тебе в помощь.
С возвращением тебя.
>нужно, чтобы кто-то спас меня от такой жизни.
Однажды я курил с обычным пацаном с района, мы стояли и был обычный диалог гоп-стиль ни о чём. Я вижу как к нам идёт один казах, я думаю что он такой же как другой чувак, дескать типичный пацанчик с района и он так себя и вёл, пока я что-то не сказанул про античную философию...
Я люблю поговорить, но глубоких познаний у меня нëт ни в чём, этот казах меня раскатал как ребёнка. У него даже тон изменился, он стал настоящий когда мы начали говорить про философию. А выглядел как обычный "четкий пацан". Я тогда особого внимания не это не обратил.
Сейчас когда начал менять свою жизнь понял, что очень многие люди завидуют мне из-за моего интеллекта, чуствуют себя ниже и это задевает их самолюбие. Поэтому они пытаются меня клюнуть. Вот вчера выряс это с с силой из своей подружки. Я сам считал себя самым последним глупцом на свете, даже совсем не верил своему мнению. Но это потому, что меня всю жизнь подавляла мать, а отца не было, а на самом деле я как Никола Тесла, чуствую это.
А тот парнишка просто скрывал силу, ведь иначе люди не примут. Всегда появляются проблемы когда ты выше в обществе на порядок. Но говорить стоит не со всеми. Ты можешь просто не говорить с людьми или говорить с ними на их языке, как тот казах. Тогда они тебя примут, но главное внутри остаться собой. Поверь в себя.
Бог тебе в помощь.
18,4 Мб, mp4,854x480, 3:09
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1a2cd6377a42dd7dc9df490bf9ddb102
Константные функции в трейтах в принципе нельзя использовать. Вызывать константные методы на не-константах нельзя. Передавать не-константы в константные функции (чтобы вывелся const дженерик с размером массива) нельзя даже, если эти не-константы в самой функции никак не используются. Доступ к константам, определённым, в трейте, есть только через типы, которые имплементируют трейт, но не через переменную этого типа.
В итоге я не знаю, как достать на этапе компиляции размер массива, мне кажется, это невозможно. В плюсах это можно сделать просто через constexpr метод, а здесь результат выполнения const функции считается константным только, если все аргументы у неё константные. Нужен хотя бы аналог decltype.
Вообще с массивами невозможно нормально работать из-за того, что слайсы теряют свой размер даже, если он известен: если array - это [T; N], то array[..] - это всё равно просто &[T]. Можно сделать .get(...).as_ptr().cast::<[T; N]>(), но проверки на то, что слайс не выходит за границы, похоже невозможно сделать в компайл-тайме из-за проблем выше.
Да, клиппи предупреждает, если слайс выходит за границы массива, но клиппи - это не компилятор, что там случилось с if it compiles, it works, это типо всё приколы и несерьёзно что ли. Причём просто доставание элемента по индексу, который выходит за границы - это rustc считает ошибкой, но если слайс выходит за границы - то уже нет.
И что, и какой смысл во всём этом тогда.
Константные функции в трейтах в принципе нельзя использовать. Вызывать константные методы на не-константах нельзя. Передавать не-константы в константные функции (чтобы вывелся const дженерик с размером массива) нельзя даже, если эти не-константы в самой функции никак не используются. Доступ к константам, определённым, в трейте, есть только через типы, которые имплементируют трейт, но не через переменную этого типа.
В итоге я не знаю, как достать на этапе компиляции размер массива, мне кажется, это невозможно. В плюсах это можно сделать просто через constexpr метод, а здесь результат выполнения const функции считается константным только, если все аргументы у неё константные. Нужен хотя бы аналог decltype.
Вообще с массивами невозможно нормально работать из-за того, что слайсы теряют свой размер даже, если он известен: если array - это [T; N], то array[..] - это всё равно просто &[T]. Можно сделать .get(...).as_ptr().cast::<[T; N]>(), но проверки на то, что слайс не выходит за границы, похоже невозможно сделать в компайл-тайме из-за проблем выше.
Да, клиппи предупреждает, если слайс выходит за границы массива, но клиппи - это не компилятор, что там случилось с if it compiles, it works, это типо всё приколы и несерьёзно что ли. Причём просто доставание элемента по индексу, который выходит за границы - это rustc считает ошибкой, но если слайс выходит за границы - то уже нет.
И что, и какой смысл во всём этом тогда.
519 Кб, 2152x4082>>683037
Позавчера вчера сегодня написал всё же что-то короче декодирование, но у меня нет сейчас доделывать, как есть в общем https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa66d48c734dcceb560a79a232760999 это какая-то дефолтная гифка с википедии, я не знаю, зачем я храню lzw коды в хештаблице, ну и бред, вот это эффекты низкого iq, но я не могу уже сейчас доделывать, я рандомно раскрасил, там даже яркость пикселей не вычисляется, я даун тупой
Я не понимаю, почему Rc<[u8]> не хочет становиться владеющим итератором, разве он не владеет данными, постоянно ошибки какие-то, что я ссылку на временное значение делаю. Я просто хотел из impl Iterator<Item = Rc<[u8]>> сделать impl Iterator<Item = u8>, но не выходит, не знаю. С вектором вместо Rc работает, а в чём принципиальная разница между ними - я не понимаю. Наверняка снова какой-то кринж раст момент, который где-то мельком упоминается, что ты какой-то трейт не импортировал или что-то в этом духе, и максимально бесполезное сообщение об ошибке, я бесполезное хочу подохнуть, мне испортили жизнь, руки чешутся что-нибудь разбить + сломать
Винда мусор, всё, она взяла сама по себе ночью всё позакрывала и ребутнулась, чтобы установить апдейт, если у меня будет новая видеокарта, то это будет амд, и я больше не хочу на винде сидеть, просто бред, неюзабельно. Гит тоже помойка неюзабельная, stash push по умолчанию туда пихает и не staged изменения, и staged, и потом после stash pop они объединённые, спасибо огромное, как же тяжело в гите потерять данные, ага, да вообще не понятно что какие команды делают со стейджем
Да всё, ничего хорошего, я хочу подохнуть, потому что слишком низкий iq + мне испортили жизнь + я тупой даун + я тупой даун, я не знаю, что мне делать, я никак не могу дождаться, когда все сдохнут и я тоже, очень нужно уничтожение всех людей, пожалуйста
Позавчера вчера сегодня написал всё же что-то короче декодирование, но у меня нет сейчас доделывать, как есть в общем https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa66d48c734dcceb560a79a232760999 это какая-то дефолтная гифка с википедии, я не знаю, зачем я храню lzw коды в хештаблице, ну и бред, вот это эффекты низкого iq, но я не могу уже сейчас доделывать, я рандомно раскрасил, там даже яркость пикселей не вычисляется, я даун тупой
Я не понимаю, почему Rc<[u8]> не хочет становиться владеющим итератором, разве он не владеет данными, постоянно ошибки какие-то, что я ссылку на временное значение делаю. Я просто хотел из impl Iterator<Item = Rc<[u8]>> сделать impl Iterator<Item = u8>, но не выходит, не знаю. С вектором вместо Rc работает, а в чём принципиальная разница между ними - я не понимаю. Наверняка снова какой-то кринж раст момент, который где-то мельком упоминается, что ты какой-то трейт не импортировал или что-то в этом духе, и максимально бесполезное сообщение об ошибке, я бесполезное хочу подохнуть, мне испортили жизнь, руки чешутся что-нибудь разбить + сломать
Винда мусор, всё, она взяла сама по себе ночью всё позакрывала и ребутнулась, чтобы установить апдейт, если у меня будет новая видеокарта, то это будет амд, и я больше не хочу на винде сидеть, просто бред, неюзабельно. Гит тоже помойка неюзабельная, stash push по умолчанию туда пихает и не staged изменения, и staged, и потом после stash pop они объединённые, спасибо огромное, как же тяжело в гите потерять данные, ага, да вообще не понятно что какие команды делают со стейджем
Да всё, ничего хорошего, я хочу подохнуть, потому что слишком низкий iq + мне испортили жизнь + я тупой даун + я тупой даун, я не знаю, что мне делать, я никак не могу дождаться, когда все сдохнут и я тоже, очень нужно уничтожение всех людей, пожалуйста
436 Кб, 1603x2048Я хочу, наверное, написать препроцессор + парсер сишных хедеров, но это выглядит как что-то слишком сложное и я, наверное, слишком тупой для этого. Типа вообще какой смысл жить если у меня плохой мозг, я каждый день от этого страдаю. Я просто не знаю, как это нормально сделать, ещё и макросы в си слишком сложные, потому что
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "do_something()", то, не прочитав весь код (все дефайны) до этого момента, ты не можешь знать, это макрос или вызов функции, и нужно ли его раскрывать
во-вторых, у функциональных макросов сначала полностью раскрываются аргументы и потом они подставляются в функциональный макрос, то есть ты не сможешь просто по очереди всё раскрывать, придётся вперёд смотреть, например, в "a(b(c(d)))" нужно будет сначала раскрыть d, потом c(раскрытое d), в раскрытии которого тоже могут быть макросы, которые придётся раскрыть
И я не знаю, как хранить всё это в процессе раскрытия макросов, я думал, может быть, в связном списке хранить токены, среди которых могут быть нераскрытые макросы, и понемногу их раскрывать, вставляя на место макросов последовательность других, но это вряд ли сработает как минимум из-за того, что в случае с функциональными макросами придётся как-то запоминать, каким образом изначально было разбиение на аргументы, ну типа
это при раскрытии не должно выдать (a), (b), (c), (d), нужно запомнить, что "a, b" - это первый аргумент у test, а "c, d" - второй. Придётся как-то это учитывать, короче, макросы это не просто search and replace как в текстовых редакторах
И ещё в расте в std нет нормального связного списка, там нет способа вставить в середину за O(1): нельзя разбить связный список на два по позиции курсора, пришлось бы писать свой.
Наверное, придётся делать что-то древовидное и постепенно его раскрывать, типа, если есть такое:
Ну, наверное, читаешь все определения и сохраняешь их в каком-то виде, например
название макроса, названия параметров, определение макроса для function-like макросов:
или название макроса + определение для object-like макросов:
а токены в определении макроса сохраняются так:
И тут Func - это просто что угодно, что выглядит как f(x, y, z), но мы не знаем, это вызов функции или макрос. А Obj - это какой-то идентификатор, за которым нет круглых скобок. И название Func хранится как Obj, потому что оно в теории тоже может раскрыться:
Типа, add сохранился бы как (add, [a, b], [Obj(a), +, Obj(b)]) и потом, когда надо будет делать подстановку, просто меняем Obj(a) на аргументы-последовательности-токенов внутри первого аргумента.
Ну, допустим, пришло время развернуть "f3(add, 1 + 1, 2, 3) == 7". Ты сначала парсишь это как Vec<Token>, ничего не раскрывая:
Потом идёшь и раскрываешь все аргументы у Func, раскрываешь Obj в названиях Func, и просто все Obj макросы тоже раскрываешь. И если попадаются названия макросов у Func, то раскрываешь это всё как function-like макрос:
И, наверное, так придётся утюжить раскрытие каждого макроса до тех пор, пока там не останется нераскрываемых символов, потому что может быть
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "do_something()", то, не прочитав весь код (все дефайны) до этого момента, ты не можешь знать, это макрос или вызов функции, и нужно ли его раскрывать
во-вторых, у функциональных макросов сначала полностью раскрываются аргументы и потом они подставляются в функциональный макрос, то есть ты не сможешь просто по очереди всё раскрывать, придётся вперёд смотреть, например, в "a(b(c(d)))" нужно будет сначала раскрыть d, потом c(раскрытое d), в раскрытии которого тоже могут быть макросы, которые придётся раскрыть
И я не знаю, как хранить всё это в процессе раскрытия макросов, я думал, может быть, в связном списке хранить токены, среди которых могут быть нераскрытые макросы, и понемногу их раскрывать, вставляя на место макросов последовательность других, но это вряд ли сработает как минимум из-за того, что в случае с функциональными макросами придётся как-то запоминать, каким образом изначально было разбиение на аргументы, ну типа
> #define first a, b
> #define second c, d
> #define test(a, b, c, d) (a) (b) (c) (d)
>
> test(first, second)
это при раскрытии не должно выдать (a), (b), (c), (d), нужно запомнить, что "a, b" - это первый аргумент у test, а "c, d" - второй. Придётся как-то это учитывать, короче, макросы это не просто search and replace как в текстовых редакторах
И ещё в расте в std нет нормального связного списка, там нет способа вставить в середину за O(1): нельзя разбить связный список на два по позиции курсора, пришлось бы писать свой.
Наверное, придётся делать что-то древовидное и постепенно его раскрывать, типа, если есть такое:
> #define add(a, b) a + b
> #define f3(f, a, b, c) f(f(a, b), c)
> #if f3(add, 1 + 1, 2, 3) == 7
> idk
> #endif
Ну, наверное, читаешь все определения и сохраняешь их в каком-то виде, например
название макроса, названия параметров, определение макроса для function-like макросов:
> (String, Vec<String>, Vec<Token>)
или название макроса + определение для object-like макросов:
> (String, Vec<Token>)
а токены в определении макроса сохраняются так:
> enum Token {
> Obj(String),
> Func(Obj(String), Vec<Vec<Token>>),
> Seq(Vec<Token>),
> Other(...),
> }
И тут Func - это просто что угодно, что выглядит как f(x, y, z), но мы не знаем, это вызов функции или макрос. А Obj - это какой-то идентификатор, за которым нет круглых скобок. И название Func хранится как Obj, потому что оно в теории тоже может раскрыться:
> #define add(a, b) a + b
> #define test(a, b) f(a, b)
> #define f add
> test(1, 2)
Типа, add сохранился бы как (add, [a, b], [Obj(a), +, Obj(b)]) и потом, когда надо будет делать подстановку, просто меняем Obj(a) на аргументы-последовательности-токенов внутри первого аргумента.
Ну, допустим, пришло время развернуть "f3(add, 1 + 1, 2, 3) == 7". Ты сначала парсишь это как Vec<Token>, ничего не раскрывая:
> [Func(Obj(f3), [Obj(add), Seq([1, +, 1]), 2, 3]), ==, 7]
Потом идёшь и раскрываешь все аргументы у Func, раскрываешь Obj в названиях Func, и просто все Obj макросы тоже раскрываешь. И если попадаются названия макросов у Func, то раскрываешь это всё как function-like макрос:
> [Func(Obj(f3), [Obj(add), Seq([1, +, 1]), 2, 3]), ==, 7]
> [Seq([Func(Obj(add), [Func(Obj(add), [Seq([1, +, 1]), 2]), 3])]), ==, 7]
> [Seq([Func(Obj(add), [Seq([Seq([1, +, 1]), +, 2]), 3])]), ==, 7]
> [Seq([Seq([Seq([Seq([1, +, 1]), +, 2]), +, 3])]), ==, 7]
И, наверное, так придётся утюжить раскрытие каждого макроса до тех пор, пока там не останется нераскрываемых символов, потому что может быть
> #define z 42
> #define y z
> #define x y
> x
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
436 Кб, 1603x2048Я хочу, наверное, написать препроцессор + парсер сишных хедеров, но это выглядит как что-то слишком сложное и я, наверное, слишком тупой для этого. Типа вообще какой смысл жить если у меня плохой мозг, я каждый день от этого страдаю. Я просто не знаю, как это нормально сделать, ещё и макросы в си слишком сложные, потому что
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "do_something()", то, не прочитав весь код (все дефайны) до этого момента, ты не можешь знать, это макрос или вызов функции, и нужно ли его раскрывать
во-вторых, у функциональных макросов сначала полностью раскрываются аргументы и потом они подставляются в функциональный макрос, то есть ты не сможешь просто по очереди всё раскрывать, придётся вперёд смотреть, например, в "a(b(c(d)))" нужно будет сначала раскрыть d, потом c(раскрытое d), в раскрытии которого тоже могут быть макросы, которые придётся раскрыть
И я не знаю, как хранить всё это в процессе раскрытия макросов, я думал, может быть, в связном списке хранить токены, среди которых могут быть нераскрытые макросы, и понемногу их раскрывать, вставляя на место макросов последовательность других, но это вряд ли сработает как минимум из-за того, что в случае с функциональными макросами придётся как-то запоминать, каким образом изначально было разбиение на аргументы, ну типа
это при раскрытии не должно выдать (a), (b), (c), (d), нужно запомнить, что "a, b" - это первый аргумент у test, а "c, d" - второй. Придётся как-то это учитывать, короче, макросы это не просто search and replace как в текстовых редакторах
И ещё в расте в std нет нормального связного списка, там нет способа вставить в середину за O(1): нельзя разбить связный список на два по позиции курсора, пришлось бы писать свой.
Наверное, придётся делать что-то древовидное и постепенно его раскрывать, типа, если есть такое:
Ну, наверное, читаешь все определения и сохраняешь их в каком-то виде, например
название макроса, названия параметров, определение макроса для function-like макросов:
или название макроса + определение для object-like макросов:
а токены в определении макроса сохраняются так:
И тут Func - это просто что угодно, что выглядит как f(x, y, z), но мы не знаем, это вызов функции или макрос. А Obj - это какой-то идентификатор, за которым нет круглых скобок. И название Func хранится как Obj, потому что оно в теории тоже может раскрыться:
Типа, add сохранился бы как (add, [a, b], [Obj(a), +, Obj(b)]) и потом, когда надо будет делать подстановку, просто меняем Obj(a) на аргументы-последовательности-токенов внутри первого аргумента.
Ну, допустим, пришло время развернуть "f3(add, 1 + 1, 2, 3) == 7". Ты сначала парсишь это как Vec<Token>, ничего не раскрывая:
Потом идёшь и раскрываешь все аргументы у Func, раскрываешь Obj в названиях Func, и просто все Obj макросы тоже раскрываешь. И если попадаются названия макросов у Func, то раскрываешь это всё как function-like макрос:
И, наверное, так придётся утюжить раскрытие каждого макроса до тех пор, пока там не останется нераскрываемых символов, потому что может быть
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "do_something()", то, не прочитав весь код (все дефайны) до этого момента, ты не можешь знать, это макрос или вызов функции, и нужно ли его раскрывать
во-вторых, у функциональных макросов сначала полностью раскрываются аргументы и потом они подставляются в функциональный макрос, то есть ты не сможешь просто по очереди всё раскрывать, придётся вперёд смотреть, например, в "a(b(c(d)))" нужно будет сначала раскрыть d, потом c(раскрытое d), в раскрытии которого тоже могут быть макросы, которые придётся раскрыть
И я не знаю, как хранить всё это в процессе раскрытия макросов, я думал, может быть, в связном списке хранить токены, среди которых могут быть нераскрытые макросы, и понемногу их раскрывать, вставляя на место макросов последовательность других, но это вряд ли сработает как минимум из-за того, что в случае с функциональными макросами придётся как-то запоминать, каким образом изначально было разбиение на аргументы, ну типа
> #define first a, b
> #define second c, d
> #define test(a, b, c, d) (a) (b) (c) (d)
>
> test(first, second)
это при раскрытии не должно выдать (a), (b), (c), (d), нужно запомнить, что "a, b" - это первый аргумент у test, а "c, d" - второй. Придётся как-то это учитывать, короче, макросы это не просто search and replace как в текстовых редакторах
И ещё в расте в std нет нормального связного списка, там нет способа вставить в середину за O(1): нельзя разбить связный список на два по позиции курсора, пришлось бы писать свой.
Наверное, придётся делать что-то древовидное и постепенно его раскрывать, типа, если есть такое:
> #define add(a, b) a + b
> #define f3(f, a, b, c) f(f(a, b), c)
> #if f3(add, 1 + 1, 2, 3) == 7
> idk
> #endif
Ну, наверное, читаешь все определения и сохраняешь их в каком-то виде, например
название макроса, названия параметров, определение макроса для function-like макросов:
> (String, Vec<String>, Vec<Token>)
или название макроса + определение для object-like макросов:
> (String, Vec<Token>)
а токены в определении макроса сохраняются так:
> enum Token {
> Obj(String),
> Func(Obj(String), Vec<Vec<Token>>),
> Seq(Vec<Token>),
> Other(...),
> }
И тут Func - это просто что угодно, что выглядит как f(x, y, z), но мы не знаем, это вызов функции или макрос. А Obj - это какой-то идентификатор, за которым нет круглых скобок. И название Func хранится как Obj, потому что оно в теории тоже может раскрыться:
> #define add(a, b) a + b
> #define test(a, b) f(a, b)
> #define f add
> test(1, 2)
Типа, add сохранился бы как (add, [a, b], [Obj(a), +, Obj(b)]) и потом, когда надо будет делать подстановку, просто меняем Obj(a) на аргументы-последовательности-токенов внутри первого аргумента.
Ну, допустим, пришло время развернуть "f3(add, 1 + 1, 2, 3) == 7". Ты сначала парсишь это как Vec<Token>, ничего не раскрывая:
> [Func(Obj(f3), [Obj(add), Seq([1, +, 1]), 2, 3]), ==, 7]
Потом идёшь и раскрываешь все аргументы у Func, раскрываешь Obj в названиях Func, и просто все Obj макросы тоже раскрываешь. И если попадаются названия макросов у Func, то раскрываешь это всё как function-like макрос:
> [Func(Obj(f3), [Obj(add), Seq([1, +, 1]), 2, 3]), ==, 7]
> [Seq([Func(Obj(add), [Func(Obj(add), [Seq([1, +, 1]), 2]), 3])]), ==, 7]
> [Seq([Func(Obj(add), [Seq([Seq([1, +, 1]), +, 2]), 3])]), ==, 7]
> [Seq([Seq([Seq([Seq([1, +, 1]), +, 2]), +, 3])]), ==, 7]
И, наверное, так придётся утюжить раскрытие каждого макроса до тех пор, пока там не останется нераскрываемых символов, потому что может быть
> #define z 42
> #define y z
> #define x y
> x
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
641 Кб, 1119x800>>694315
Во Free Pascal макросы (там нет функциональных, но функциональные должны делаться несложной модификацией, заключающейся в том, что на время их непосредственного раскрытия их аргументы тоже считаются специальными макросами; лет через 10 сам сделаю... ... ...) сделаны следующим образом: штука, которая читает токены (на самом деле символы, но, наверное, это естественно делать на уровне токенов, чтобы проще обрабатывать пустые макросы, конкатенации и т. п.), может быть переключена на новый файл, а по его завершении возвращается к предыдущему. Само по себе это реализует инклюды, но и макросы реализованы как псевдо-файлы, на которые сканер переключается и затем возвращается к предыдущему (настоящему файлу или внешнему макросу). То есть мы работаем не со связным списком токенов, в середине которого периодически устраиваем разворачивания, а со стеком файлов и единственным токеном, читаемым в данный момент.
Это позволяет результату разворачивания макроса быть сколь угодно большим, его существование в памяти целиком не требуется. Конечно, в зависимости от того, в какие конструкции он разворачивается и что с ними происходит дальше, это может не помочь, но, во всяком случае, даже тогда препроцессору делает честь, что с нехваткой памяти упал не он.
Во Free Pascal макросы (там нет функциональных, но функциональные должны делаться несложной модификацией, заключающейся в том, что на время их непосредственного раскрытия их аргументы тоже считаются специальными макросами; лет через 10 сам сделаю... ... ...) сделаны следующим образом: штука, которая читает токены (на самом деле символы, но, наверное, это естественно делать на уровне токенов, чтобы проще обрабатывать пустые макросы, конкатенации и т. п.), может быть переключена на новый файл, а по его завершении возвращается к предыдущему. Само по себе это реализует инклюды, но и макросы реализованы как псевдо-файлы, на которые сканер переключается и затем возвращается к предыдущему (настоящему файлу или внешнему макросу). То есть мы работаем не со связным списком токенов, в середине которого периодически устраиваем разворачивания, а со стеком файлов и единственным токеном, читаемым в данный момент.
Это позволяет результату разворачивания макроса быть сколь угодно большим, его существование в памяти целиком не требуется. Конечно, в зависимости от того, в какие конструкции он разворачивается и что с ними происходит дальше, это может не помочь, но, во всяком случае, даже тогда препроцессору делает честь, что с нехваткой памяти упал не он.
Разбил стекло на телефоне, кинув его об пол, теперь на пальцах постоянно какие-то мелкие крошки от растрескавшегося стекла, надеюсь, они попадут мне в глаза и я ослепну
373 Кб, 1448x2048>>697838
+++
+++
61 Кб, 675x911>>692316
Мега кринж https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d4e5b586dbb2f40abf1f7f2df303ed60 Я перестаю понимать зачем вообще жить хочется уже подохнуть поскорее, потому что вообще ничего хорошего не вижу уже, никакого смысла нету и ничего хорошего не будет
Мега кринж https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d4e5b586dbb2f40abf1f7f2df303ed60 Я перестаю понимать зачем вообще жить хочется уже подохнуть поскорее, потому что вообще ничего хорошего не вижу уже, никакого смысла нету и ничего хорошего не будет
648 Кб, 629x880ffi кринж + аутизм https://gist.github.com/poppyfanboy/30221b602f688faf3ff6903ce89ba878 Ну вроде вручную делать это даже не очень болезненно, но всё равно аутизм. И естественно микрософт выбрали какой-то непонятный формат для описания апи https://learn.microsoft.com/en-us/uwp/winrt-cref/winmd-files почему нельзя было просто хмл какой-нибудь использовать, даже лень смотреть, что это
Ещё этот непонятный wWinMain, но вроде можно ориентироваться на то, как сделано в вайне https://github.com/wine-mirror/wine/blob/master/dlls/winecrt0/exe_wmain.c
Ещё этот непонятный wWinMain, но вроде можно ориентироваться на то, как сделано в вайне https://github.com/wine-mirror/wine/blob/master/dlls/winecrt0/exe_wmain.c
376 Кб, 1761x1761Мемно
https://godbolt.org/z/7n15qWd3E
Я вообще не знал, что у std::span есть второй шаблонный параметр и по дефолту он максимальный size_t и по дефолту std::span - жирный указатель, но если его размер известен в компайл тайме, то он просто указатель
Ну как бы понятно, что надо просто использовать метод .size(), но просто
Но даже с такими возможностями выстрелить себе в голову мне это больше нравится, чем
чем раст с его трейтами >>668663 и с его const функциями >>687871
https://godbolt.org/z/7n15qWd3E
Я вообще не знал, что у std::span есть второй шаблонный параметр и по дефолту он максимальный size_t и по дефолту std::span - жирный указатель, но если его размер известен в компайл тайме, то он просто указатель
Ну как бы понятно, что надо просто использовать метод .size(), но просто
Но даже с такими возможностями выстрелить себе в голову мне это больше нравится, чем
чем раст с его трейтами >>668663 и с его const функциями >>687871
407 Кб, 2000x3000Написал типо читалку UTF-8 символов, которая читает их постепенно откуда-то. И использюущийся в ней аналог BufReader, который может только чуть-чуть консюмить и чуть-чуть дочитывать. В интерфейсе, короче, функции такие, отчасти выбранные под влияением https://github.com/tsoding/sv/blob/master/sv.h:
- посмотреть строку в буфере
- откусить сколько-то байтов (предполагается, что ты сам знаешь, сколько надо откусить, иначе всё сломается)
- прочитать в буфер больше - это все функции ниже делают автоматически при необходимости, я думал сделать этот шаг явным, но, мне кажется, если, например, тебе надо прочесть следующий символ, но он в буфере есть только наполовину, то ну типо, ты в любом случае захочешь прочитать в буфер больше байтов и тут больше вроде ничего умного в общем случае не придумать, поэтому я просто запихнул это в сами функции, из-за этого они мутируют читалку даже, если это просто peek_char
- посмотреть/откусить следующий символ (просто вообще минимум, что от читалки требуется)
- откусить строку от начала буфера, пока выполняется предикат по символу и его номеру (то есть через неё можно, например, откусить первые несколько символов или откусить до следующего пробела)
- откусить от начала буфера до подстроки-разделителя (например, можно откусить до конца многострочного коммента)
- посмотреть, начинается ли буфер с какой-то строки (например, посмотреть, начался ли многострочный коммент)
И для трёх последних функций есть по два варианта, один кусает более уверенно, чем другой. Типо, например, если предикат нигде не выдал false, то один вариант просто откусит строку полностью, а другой выдаст ошибку. Или, если кусаем до какой-то подстроки-разделителя и в конце есть начальный кусок подстроки-разделителя, но ещё непонятно, это реально она или нет, то один вариант молча кусает до этого непонятного кусочка, надеясь разобраться потом, дочитав его в буфер полностью, а другой выдаст ошибку, что типо буфер слишком маленький или источник, откуда читаем, закончился.
Я думал добавить ещё вариант предиката не по отдельным символам, а по окну из нескольких символов, но, во-первых, я пока что не вижу, где такое могло бы мне пригодиться, а, во-вторых, такая функция слишком сложная, чтобы использовать её в простых ситуациях, но недостаточно сложная, чтобы применять её в сложных ситуациях. Типо, если тебе что-то такое нужно, то, скорее всего, тебе этого не хватит и нужны уже будут полноценные паттерны какие-то или регекспы.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4ddd00c02b50063955816444b441ee70
Там жсон типо просто для примера использования, мне сейчас лень переписывать свой жсон парсер так, чтобы он не держал полностью строку в памяти, мне вообще для другого, наверное, даже гораздо более простого, оно нужно. И я сейчас смотрю на это и снова получилось полнейшее говно, которым почти невозможно пользоваться, лайк если хочешь нахуй сдохнуть блять
Я знаю про существование BufReader в std раста, но его проблема в том, что у него какой-то не очень интерфейс: там fill_buf читает больше байтов только, если ты буфер полностью законсюмил. То есть нельзя чуть-чуть законсюмить байтов и чуть-чуть дочитать, если что-то не влезло в буфер.
Ещё я чёто, листая код std, понял, что read в трейте Read так-то требует того, чтобы ему давали инициализированную память, куда он будет писать то, что прочёл. Потому что в теории реализацию read ничего не останавливает просто вернуть Ok(42), ничего не записать, и ты потом прочтёшь мусор в буфере, который так и остался незаполненным, и в расте подобные вещи называют unsound, типо, что можно либу каким-то неправильным образом использовать и получить какую-то уязвимость. Но там сделали вот это https://rust-lang.github.io/rfcs/2930-read-buf.html, частично, пока до не доделали.
Там и до этого в рамках std был костыль, чтобы избегать излишних инициализаций буферов https://github.com/rust-lang/rust/pull/81156/files#r766012221, но теперь типо заменили на костыль, который может использовать кто угодно. Но проблема в том, что теперь им, видимо, придётся везде добавлять эти функции, которые принимают https://doc.rust-lang.org/nightly/std/io/struct.BorrowedCursor.html, чтобы явно показать, что сюда можно передавать неинициализированную память. Тут например https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.html#method.recv_from.
Не знаю, правда, действительно ли стоит с этим заморачиваться, это ещё к тому же чисто типичные растопроблемы, какой ужас, я прочитаю мусор. Ну хотя это может вызвать даже UB вроде, но я не понимаю, почему https://rust.godbolt.org/z/Y9rL-5
Очень много unsafe, но я поэтому написал тесты. Единственное нужно с алиасингом осторожнее быть, например, вот это вроде как UB:
А так вроде как нормально, потому что не создаются промежуточные ссылки, когда ты берёшь второй указатель, после того, как ты взял первый указатель. Типо получается, что у тебя есть, например, одновременно константный указатель и мутабельная ссылка. Что-то такое, короче, я не до конца понимаю https://doc.rust-lang.org/stable/std/ptr/macro.addr_of.html:
Вот можно ли так кастить указатель на слайс я тоже не уверен.
Либо просто только один раз мутабельный указатель взять можно, а не отдельно один мутабельный и один константный.
И это всё компилятор не отлавливает никак. Если у тебя где-то есть указатели, то сам ломай голову с этим, раст сложнее плюсов в разы. Есть miri, но он медленный, не умеет интерпретировать произвольные программы (вроде, например, в FFI он не умеет совсем сейчас) и выдаёт сообщения об ошибках нечитаемые для low iq дебила типа меня.
- посмотреть строку в буфере
- откусить сколько-то байтов (предполагается, что ты сам знаешь, сколько надо откусить, иначе всё сломается)
- прочитать в буфер больше - это все функции ниже делают автоматически при необходимости, я думал сделать этот шаг явным, но, мне кажется, если, например, тебе надо прочесть следующий символ, но он в буфере есть только наполовину, то ну типо, ты в любом случае захочешь прочитать в буфер больше байтов и тут больше вроде ничего умного в общем случае не придумать, поэтому я просто запихнул это в сами функции, из-за этого они мутируют читалку даже, если это просто peek_char
- посмотреть/откусить следующий символ (просто вообще минимум, что от читалки требуется)
- откусить строку от начала буфера, пока выполняется предикат по символу и его номеру (то есть через неё можно, например, откусить первые несколько символов или откусить до следующего пробела)
- откусить от начала буфера до подстроки-разделителя (например, можно откусить до конца многострочного коммента)
- посмотреть, начинается ли буфер с какой-то строки (например, посмотреть, начался ли многострочный коммент)
И для трёх последних функций есть по два варианта, один кусает более уверенно, чем другой. Типо, например, если предикат нигде не выдал false, то один вариант просто откусит строку полностью, а другой выдаст ошибку. Или, если кусаем до какой-то подстроки-разделителя и в конце есть начальный кусок подстроки-разделителя, но ещё непонятно, это реально она или нет, то один вариант молча кусает до этого непонятного кусочка, надеясь разобраться потом, дочитав его в буфер полностью, а другой выдаст ошибку, что типо буфер слишком маленький или источник, откуда читаем, закончился.
Я думал добавить ещё вариант предиката не по отдельным символам, а по окну из нескольких символов, но, во-первых, я пока что не вижу, где такое могло бы мне пригодиться, а, во-вторых, такая функция слишком сложная, чтобы использовать её в простых ситуациях, но недостаточно сложная, чтобы применять её в сложных ситуациях. Типо, если тебе что-то такое нужно, то, скорее всего, тебе этого не хватит и нужны уже будут полноценные паттерны какие-то или регекспы.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4ddd00c02b50063955816444b441ee70
Там жсон типо просто для примера использования, мне сейчас лень переписывать свой жсон парсер так, чтобы он не держал полностью строку в памяти, мне вообще для другого, наверное, даже гораздо более простого, оно нужно. И я сейчас смотрю на это и снова получилось полнейшее говно, которым почти невозможно пользоваться, лайк если хочешь нахуй сдохнуть блять
Я знаю про существование BufReader в std раста, но его проблема в том, что у него какой-то не очень интерфейс: там fill_buf читает больше байтов только, если ты буфер полностью законсюмил. То есть нельзя чуть-чуть законсюмить байтов и чуть-чуть дочитать, если что-то не влезло в буфер.
Ещё я чёто, листая код std, понял, что read в трейте Read так-то требует того, чтобы ему давали инициализированную память, куда он будет писать то, что прочёл. Потому что в теории реализацию read ничего не останавливает просто вернуть Ok(42), ничего не записать, и ты потом прочтёшь мусор в буфере, который так и остался незаполненным, и в расте подобные вещи называют unsound, типо, что можно либу каким-то неправильным образом использовать и получить какую-то уязвимость. Но там сделали вот это https://rust-lang.github.io/rfcs/2930-read-buf.html, частично, пока до не доделали.
Там и до этого в рамках std был костыль, чтобы избегать излишних инициализаций буферов https://github.com/rust-lang/rust/pull/81156/files#r766012221, но теперь типо заменили на костыль, который может использовать кто угодно. Но проблема в том, что теперь им, видимо, придётся везде добавлять эти функции, которые принимают https://doc.rust-lang.org/nightly/std/io/struct.BorrowedCursor.html, чтобы явно показать, что сюда можно передавать неинициализированную память. Тут например https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.html#method.recv_from.
Не знаю, правда, действительно ли стоит с этим заморачиваться, это ещё к тому же чисто типичные растопроблемы, какой ужас, я прочитаю мусор. Ну хотя это может вызвать даже UB вроде, но я не понимаю, почему https://rust.godbolt.org/z/Y9rL-5
Очень много unsafe, но я поэтому написал тесты. Единственное нужно с алиасингом осторожнее быть, например, вот это вроде как UB:
> use std::ptr;
>
> let mut test: [u8; 3] = [0, 1, 2];
> unsafe {
> ptr::copy(
> test.as_ptr().add(1),
> test.as_mut_ptr(),
> 2,
> );
> }
А так вроде как нормально, потому что не создаются промежуточные ссылки, когда ты берёшь второй указатель, после того, как ты взял первый указатель. Типо получается, что у тебя есть, например, одновременно константный указатель и мутабельная ссылка. Что-то такое, короче, я не до конца понимаю https://doc.rust-lang.org/stable/std/ptr/macro.addr_of.html:
> use std::ptr;
>
> let mut test: [u8; 3] = [0, 1, 2];
> unsafe {
> ptr::copy(
> ptr::addr_of!(test).cast::<u8>().add(1),
> ptr::addr_of_mut!(test).cast(),
> 2,
> );
> }
Вот можно ли так кастить указатель на слайс я тоже не уверен.
Либо просто только один раз мутабельный указатель взять можно, а не отдельно один мутабельный и один константный.
И это всё компилятор не отлавливает никак. Если у тебя где-то есть указатели, то сам ломай голову с этим, раст сложнее плюсов в разы. Есть miri, но он медленный, не умеет интерпретировать произвольные программы (вроде, например, в FFI он не умеет совсем сейчас) и выдаёт сообщения об ошибках нечитаемые для low iq дебила типа меня.
407 Кб, 2000x3000Написал типо читалку UTF-8 символов, которая читает их постепенно откуда-то. И использюущийся в ней аналог BufReader, который может только чуть-чуть консюмить и чуть-чуть дочитывать. В интерфейсе, короче, функции такие, отчасти выбранные под влияением https://github.com/tsoding/sv/blob/master/sv.h:
- посмотреть строку в буфере
- откусить сколько-то байтов (предполагается, что ты сам знаешь, сколько надо откусить, иначе всё сломается)
- прочитать в буфер больше - это все функции ниже делают автоматически при необходимости, я думал сделать этот шаг явным, но, мне кажется, если, например, тебе надо прочесть следующий символ, но он в буфере есть только наполовину, то ну типо, ты в любом случае захочешь прочитать в буфер больше байтов и тут больше вроде ничего умного в общем случае не придумать, поэтому я просто запихнул это в сами функции, из-за этого они мутируют читалку даже, если это просто peek_char
- посмотреть/откусить следующий символ (просто вообще минимум, что от читалки требуется)
- откусить строку от начала буфера, пока выполняется предикат по символу и его номеру (то есть через неё можно, например, откусить первые несколько символов или откусить до следующего пробела)
- откусить от начала буфера до подстроки-разделителя (например, можно откусить до конца многострочного коммента)
- посмотреть, начинается ли буфер с какой-то строки (например, посмотреть, начался ли многострочный коммент)
И для трёх последних функций есть по два варианта, один кусает более уверенно, чем другой. Типо, например, если предикат нигде не выдал false, то один вариант просто откусит строку полностью, а другой выдаст ошибку. Или, если кусаем до какой-то подстроки-разделителя и в конце есть начальный кусок подстроки-разделителя, но ещё непонятно, это реально она или нет, то один вариант молча кусает до этого непонятного кусочка, надеясь разобраться потом, дочитав его в буфер полностью, а другой выдаст ошибку, что типо буфер слишком маленький или источник, откуда читаем, закончился.
Я думал добавить ещё вариант предиката не по отдельным символам, а по окну из нескольких символов, но, во-первых, я пока что не вижу, где такое могло бы мне пригодиться, а, во-вторых, такая функция слишком сложная, чтобы использовать её в простых ситуациях, но недостаточно сложная, чтобы применять её в сложных ситуациях. Типо, если тебе что-то такое нужно, то, скорее всего, тебе этого не хватит и нужны уже будут полноценные паттерны какие-то или регекспы.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4ddd00c02b50063955816444b441ee70
Там жсон типо просто для примера использования, мне сейчас лень переписывать свой жсон парсер так, чтобы он не держал полностью строку в памяти, мне вообще для другого, наверное, даже гораздо более простого, оно нужно. И я сейчас смотрю на это и снова получилось полнейшее говно, которым почти невозможно пользоваться, лайк если хочешь нахуй сдохнуть блять
Я знаю про существование BufReader в std раста, но его проблема в том, что у него какой-то не очень интерфейс: там fill_buf читает больше байтов только, если ты буфер полностью законсюмил. То есть нельзя чуть-чуть законсюмить байтов и чуть-чуть дочитать, если что-то не влезло в буфер.
Ещё я чёто, листая код std, понял, что read в трейте Read так-то требует того, чтобы ему давали инициализированную память, куда он будет писать то, что прочёл. Потому что в теории реализацию read ничего не останавливает просто вернуть Ok(42), ничего не записать, и ты потом прочтёшь мусор в буфере, который так и остался незаполненным, и в расте подобные вещи называют unsound, типо, что можно либу каким-то неправильным образом использовать и получить какую-то уязвимость. Но там сделали вот это https://rust-lang.github.io/rfcs/2930-read-buf.html, частично, пока до не доделали.
Там и до этого в рамках std был костыль, чтобы избегать излишних инициализаций буферов https://github.com/rust-lang/rust/pull/81156/files#r766012221, но теперь типо заменили на костыль, который может использовать кто угодно. Но проблема в том, что теперь им, видимо, придётся везде добавлять эти функции, которые принимают https://doc.rust-lang.org/nightly/std/io/struct.BorrowedCursor.html, чтобы явно показать, что сюда можно передавать неинициализированную память. Тут например https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.html#method.recv_from.
Не знаю, правда, действительно ли стоит с этим заморачиваться, это ещё к тому же чисто типичные растопроблемы, какой ужас, я прочитаю мусор. Ну хотя это может вызвать даже UB вроде, но я не понимаю, почему https://rust.godbolt.org/z/Y9rL-5
Очень много unsafe, но я поэтому написал тесты. Единственное нужно с алиасингом осторожнее быть, например, вот это вроде как UB:
А так вроде как нормально, потому что не создаются промежуточные ссылки, когда ты берёшь второй указатель, после того, как ты взял первый указатель. Типо получается, что у тебя есть, например, одновременно константный указатель и мутабельная ссылка. Что-то такое, короче, я не до конца понимаю https://doc.rust-lang.org/stable/std/ptr/macro.addr_of.html:
Вот можно ли так кастить указатель на слайс я тоже не уверен.
Либо просто только один раз мутабельный указатель взять можно, а не отдельно один мутабельный и один константный.
И это всё компилятор не отлавливает никак. Если у тебя где-то есть указатели, то сам ломай голову с этим, раст сложнее плюсов в разы. Есть miri, но он медленный, не умеет интерпретировать произвольные программы (вроде, например, в FFI он не умеет совсем сейчас) и выдаёт сообщения об ошибках нечитаемые для low iq дебила типа меня.
- посмотреть строку в буфере
- откусить сколько-то байтов (предполагается, что ты сам знаешь, сколько надо откусить, иначе всё сломается)
- прочитать в буфер больше - это все функции ниже делают автоматически при необходимости, я думал сделать этот шаг явным, но, мне кажется, если, например, тебе надо прочесть следующий символ, но он в буфере есть только наполовину, то ну типо, ты в любом случае захочешь прочитать в буфер больше байтов и тут больше вроде ничего умного в общем случае не придумать, поэтому я просто запихнул это в сами функции, из-за этого они мутируют читалку даже, если это просто peek_char
- посмотреть/откусить следующий символ (просто вообще минимум, что от читалки требуется)
- откусить строку от начала буфера, пока выполняется предикат по символу и его номеру (то есть через неё можно, например, откусить первые несколько символов или откусить до следующего пробела)
- откусить от начала буфера до подстроки-разделителя (например, можно откусить до конца многострочного коммента)
- посмотреть, начинается ли буфер с какой-то строки (например, посмотреть, начался ли многострочный коммент)
И для трёх последних функций есть по два варианта, один кусает более уверенно, чем другой. Типо, например, если предикат нигде не выдал false, то один вариант просто откусит строку полностью, а другой выдаст ошибку. Или, если кусаем до какой-то подстроки-разделителя и в конце есть начальный кусок подстроки-разделителя, но ещё непонятно, это реально она или нет, то один вариант молча кусает до этого непонятного кусочка, надеясь разобраться потом, дочитав его в буфер полностью, а другой выдаст ошибку, что типо буфер слишком маленький или источник, откуда читаем, закончился.
Я думал добавить ещё вариант предиката не по отдельным символам, а по окну из нескольких символов, но, во-первых, я пока что не вижу, где такое могло бы мне пригодиться, а, во-вторых, такая функция слишком сложная, чтобы использовать её в простых ситуациях, но недостаточно сложная, чтобы применять её в сложных ситуациях. Типо, если тебе что-то такое нужно, то, скорее всего, тебе этого не хватит и нужны уже будут полноценные паттерны какие-то или регекспы.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4ddd00c02b50063955816444b441ee70
Там жсон типо просто для примера использования, мне сейчас лень переписывать свой жсон парсер так, чтобы он не держал полностью строку в памяти, мне вообще для другого, наверное, даже гораздо более простого, оно нужно. И я сейчас смотрю на это и снова получилось полнейшее говно, которым почти невозможно пользоваться, лайк если хочешь нахуй сдохнуть блять
Я знаю про существование BufReader в std раста, но его проблема в том, что у него какой-то не очень интерфейс: там fill_buf читает больше байтов только, если ты буфер полностью законсюмил. То есть нельзя чуть-чуть законсюмить байтов и чуть-чуть дочитать, если что-то не влезло в буфер.
Ещё я чёто, листая код std, понял, что read в трейте Read так-то требует того, чтобы ему давали инициализированную память, куда он будет писать то, что прочёл. Потому что в теории реализацию read ничего не останавливает просто вернуть Ok(42), ничего не записать, и ты потом прочтёшь мусор в буфере, который так и остался незаполненным, и в расте подобные вещи называют unsound, типо, что можно либу каким-то неправильным образом использовать и получить какую-то уязвимость. Но там сделали вот это https://rust-lang.github.io/rfcs/2930-read-buf.html, частично, пока до не доделали.
Там и до этого в рамках std был костыль, чтобы избегать излишних инициализаций буферов https://github.com/rust-lang/rust/pull/81156/files#r766012221, но теперь типо заменили на костыль, который может использовать кто угодно. Но проблема в том, что теперь им, видимо, придётся везде добавлять эти функции, которые принимают https://doc.rust-lang.org/nightly/std/io/struct.BorrowedCursor.html, чтобы явно показать, что сюда можно передавать неинициализированную память. Тут например https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.html#method.recv_from.
Не знаю, правда, действительно ли стоит с этим заморачиваться, это ещё к тому же чисто типичные растопроблемы, какой ужас, я прочитаю мусор. Ну хотя это может вызвать даже UB вроде, но я не понимаю, почему https://rust.godbolt.org/z/Y9rL-5
Очень много unsafe, но я поэтому написал тесты. Единственное нужно с алиасингом осторожнее быть, например, вот это вроде как UB:
> use std::ptr;
>
> let mut test: [u8; 3] = [0, 1, 2];
> unsafe {
> ptr::copy(
> test.as_ptr().add(1),
> test.as_mut_ptr(),
> 2,
> );
> }
А так вроде как нормально, потому что не создаются промежуточные ссылки, когда ты берёшь второй указатель, после того, как ты взял первый указатель. Типо получается, что у тебя есть, например, одновременно константный указатель и мутабельная ссылка. Что-то такое, короче, я не до конца понимаю https://doc.rust-lang.org/stable/std/ptr/macro.addr_of.html:
> use std::ptr;
>
> let mut test: [u8; 3] = [0, 1, 2];
> unsafe {
> ptr::copy(
> ptr::addr_of!(test).cast::<u8>().add(1),
> ptr::addr_of_mut!(test).cast(),
> 2,
> );
> }
Вот можно ли так кастить указатель на слайс я тоже не уверен.
Либо просто только один раз мутабельный указатель взять можно, а не отдельно один мутабельный и один константный.
И это всё компилятор не отлавливает никак. Если у тебя где-то есть указатели, то сам ломай голову с этим, раст сложнее плюсов в разы. Есть miri, но он медленный, не умеет интерпретировать произвольные программы (вроде, например, в FFI он не умеет совсем сейчас) и выдаёт сообщения об ошибках нечитаемые для low iq дебила типа меня.
U+3000 больше не работает, а U+2800 в спам-листе, ясно
>>666460
У меня снова началась эта шиза, потому что мне хуёво блять и я либо сижу и нихуя не делаю, либо занимаюсь хуйнёй, заново переписал конфиг, не глядя на старый-старый, который я даже не использовал в пользу старого более минималистичного. Но получил в итоге примерно то же самое, но на этот раз более-менее разобрался с ленивой загрузкой плагинов, благодаря чему оно хотя бы стартовый экран с меню относительно быстро почти мгновенно открывает, тупо потому что почти ничего не грузит. Корову не я нарисовал, я её украл
Стартовый экран почти бесполезный, там полезное только это перейти в папку с конфигами за одно нажатие кнопки
https://github.com/stevearc/oil.nvim вот это вот прикольно, можно редактировать дерево файлов так же, как текстовые буферы в виме, не надо разбираться со всякими непонятными биндингами
https://github.com/andymass/vim-matchup и это, но только из-за того, что % из дефолтного вима не работает нормально в некоторых ситуациях
https://github.com/debugloop/telescope-undo.nvim и это, но это по сути просто более удобный интерфейс для взаимодействия со встроенной фичей в виме undolist. Типа у меня постоянно проблема в том, что я что-то пишу, потом делаю несколько раз undo, потому что написал кринж, пишу снова, а потом вспоминаю, что я хочу скопировать что-то из текста, который я убрал через undo, и в любом нормальном текстовом редакторе этот текст безвозвратно пропадает
Дерево файлов как дерево и дерево символов не нужны, я обычно просто поиском по названиям по файлам и функциям перемещаюсь
Но я не знаю, стоит ли оно вообще того, есть ли смысл в более сложном автодополнении, чем просто по словам в текущем файле. Я до сегодняшнего сколько-то месяцев использовал максимально минималистичный конфиг неовима, где из плагинов были только vim-surround и цветовая схема, и не то чтобы чувствовал себя сильно обделённым. И то, я думаю, не должно быть сложно написать свой примитивный кеймап для того, чтобы поставить скобки или кавычки вокруг выделения. Типа в виме просто автоматом есть маркеры < и > вокруг последнего выделения, просто на них прыгаешь, вставляешь символы, прыгаешь на изначальную позицию и всё.
С использованием netrw тоже, наверное, можно смириться.
В виме даже греп есть встроенный. Поиск и замену на несколько файлов немного неудобно делать (нужно сначала через vimgrep добавить файлы в quickfix, а потом cdof сделать), но тоже терпимо
https://neovim.io/doc/user/digraph.html#digraphs-use и про это тоже не знал, полезно для меня, потому что я слишком тупой, чтобы запомнить даже несколько юникодовых кодов для часто исопльзуемых символов, которых нет на клаве
Для дебаггинга есть просто gdb, там, оказывается, тупо есть графический режим, где показывается исходный код и для того же раста можно даже настроить сорсмапы для стд. И оно даже на винде почти работает (старая 12 версия работает нормально, а 13 версия и актуальный на сегодня trunk - нет, ну это вот типичный виндовс экспириенс, что ничего не работает). В виме даже есть встроенный плагин для gdb (termdebug), но он как-то не очень работает. Этот получше https://github.com/sakhnik/nvim-gdb и поддерживает lldb ещё
Мне, наверное, надо просто сделать опцию в конфиге, чтобы можно было либо выключить все плагины, либо оставить только минимальный набор (точно без LSP).
После того, как меня заставили пойти в рабство, моя жизнь испортилась окончательно и я хочу нахуй сдохнуть, мне не хочется заниматься этой хуйнёй, я не хочу говнокодить на говноязыке какую-то непонятную хуйню, на которую мне максимально похуй, и мне физически тяжело делать то, что мне не хочется. А в последние несколько недель я и перестал делать, и по сути жду, когда меня пошлют уже нахуй и уволят, потому что так жить невозможно, это буквально рабство, я ничего взамен не получаю, мне нахуй не нужны деньги, точнее, нахуй не нужны такие копейки, какие мне дают, их в жизни моей не скопится в разумные сроки (максимум за год) столько, чтобы хватило на свой дом и жить в нём до конца жизни. А больше нахуй не нужно ничего, ты такие маленькие деньги можешь потратить только на всякую бесполезную хуйню.
Ну разъебал я телефон окончательно об стену, купил новый, но мне телефон так-то не очень-то нужен. Болезни в большинстве случаев сами проходят, зубы, да похуй на зубы: их просто год не чистишь, они обрастают защитой из зубного камня и всё. Что блять на них покупать, шоколадки? да в рот я ебал шоколадки, они все на вкус говно и меня тошнит от них, я не хочу нихуя, я ебал всё и всех в рот, ненавижу. Охуенная трата сил и часов своей жизни в никуда
https://github.com/PowerShell/PowerShell/issues/1908 на это наткнулся, в cmd это просто работало. Я не буду больше пользоваться павершелом, это невозможно. И вингетом тоже, потому что он легко может рандомно заруинить установленную прогу при обновлении. Или установить что-то без нужных зависимостей, но это вообще на винде всегда так, что устанавливаешь что-то, а потом разбираешься, каких dll не хватает. И вскодом, потому что обычно это ещё более худший опыт настройки плагинов, чем в неовиме: куча каких-то жсонов, в которые иногда можно встраивать ${переменные}, нельзя прописать в жсоне просто список плагинов, чтобы вскод сам их установил, нужно обязательно мышкой прокликивать установку.
Микрософт портит мне жизнь. И скриптовые языки тоже, я ненавижу питон, я не понимаю, зачем он существует, ты пробуешь что угодно установить, написанное на нём, и выясняется, что у него есть какие-то платформозависимые зависимости, колёса какие-то, что они то ли компилируются, то ли там бинарники скачиваются, что тебе нужен мейк, сишный компилятор и что в итоге оно всё равно не компилится и выдаёт километр ошибок. Это просто типичный опыт вызова pip install, на винде так точно. На линуксе наверняка иногда тоже, потому что у тебя необязательно установлены все зависимости и естественно pip install не может их подтянуть, это же всего лишь пакетный менеджер для кроссплатформенного языка
Да и другие скриптовые языки, для них у тебя на компе обязательно должен быть установлен интерпретатор и, скорее всего, ещё и пакетный менеджер к нему, потому что миллион зависимостей является данностью для любой проги на скриптовом языке. Нельзя просто запустить прогу, потому что проги никакой нет, у тебя есть только куча бесполезных текстовых файлов
У меня типа просто есть скрипт, который скачивает всякую ерунду, но из-за того, что он написан на жс, я не могу его запустить, мне придётся устанавливать ноду и я так думаю, что ну это слишком сложно, обойдусь
У меня снова началась эта шиза, потому что мне хуёво блять и я либо сижу и нихуя не делаю, либо занимаюсь хуйнёй, заново переписал конфиг, не глядя на старый-старый, который я даже не использовал в пользу старого более минималистичного. Но получил в итоге примерно то же самое, но на этот раз более-менее разобрался с ленивой загрузкой плагинов, благодаря чему оно хотя бы стартовый экран с меню относительно быстро почти мгновенно открывает, тупо потому что почти ничего не грузит. Корову не я нарисовал, я её украл
Стартовый экран почти бесполезный, там полезное только это перейти в папку с конфигами за одно нажатие кнопки
https://github.com/stevearc/oil.nvim вот это вот прикольно, можно редактировать дерево файлов так же, как текстовые буферы в виме, не надо разбираться со всякими непонятными биндингами
https://github.com/andymass/vim-matchup и это, но только из-за того, что % из дефолтного вима не работает нормально в некоторых ситуациях
https://github.com/debugloop/telescope-undo.nvim и это, но это по сути просто более удобный интерфейс для взаимодействия со встроенной фичей в виме undolist. Типа у меня постоянно проблема в том, что я что-то пишу, потом делаю несколько раз undo, потому что написал кринж, пишу снова, а потом вспоминаю, что я хочу скопировать что-то из текста, который я убрал через undo, и в любом нормальном текстовом редакторе этот текст безвозвратно пропадает
Дерево файлов как дерево и дерево символов не нужны, я обычно просто поиском по названиям по файлам и функциям перемещаюсь
Но я не знаю, стоит ли оно вообще того, есть ли смысл в более сложном автодополнении, чем просто по словам в текущем файле. Я до сегодняшнего сколько-то месяцев использовал максимально минималистичный конфиг неовима, где из плагинов были только vim-surround и цветовая схема, и не то чтобы чувствовал себя сильно обделённым. И то, я думаю, не должно быть сложно написать свой примитивный кеймап для того, чтобы поставить скобки или кавычки вокруг выделения. Типа в виме просто автоматом есть маркеры < и > вокруг последнего выделения, просто на них прыгаешь, вставляешь символы, прыгаешь на изначальную позицию и всё.
С использованием netrw тоже, наверное, можно смириться.
В виме даже греп есть встроенный. Поиск и замену на несколько файлов немного неудобно делать (нужно сначала через vimgrep добавить файлы в quickfix, а потом cdof сделать), но тоже терпимо
https://neovim.io/doc/user/digraph.html#digraphs-use и про это тоже не знал, полезно для меня, потому что я слишком тупой, чтобы запомнить даже несколько юникодовых кодов для часто исопльзуемых символов, которых нет на клаве
Для дебаггинга есть просто gdb, там, оказывается, тупо есть графический режим, где показывается исходный код и для того же раста можно даже настроить сорсмапы для стд. И оно даже на винде почти работает (старая 12 версия работает нормально, а 13 версия и актуальный на сегодня trunk - нет, ну это вот типичный виндовс экспириенс, что ничего не работает). В виме даже есть встроенный плагин для gdb (termdebug), но он как-то не очень работает. Этот получше https://github.com/sakhnik/nvim-gdb и поддерживает lldb ещё
Мне, наверное, надо просто сделать опцию в конфиге, чтобы можно было либо выключить все плагины, либо оставить только минимальный набор (точно без LSP).
После того, как меня заставили пойти в рабство, моя жизнь испортилась окончательно и я хочу нахуй сдохнуть, мне не хочется заниматься этой хуйнёй, я не хочу говнокодить на говноязыке какую-то непонятную хуйню, на которую мне максимально похуй, и мне физически тяжело делать то, что мне не хочется. А в последние несколько недель я и перестал делать, и по сути жду, когда меня пошлют уже нахуй и уволят, потому что так жить невозможно, это буквально рабство, я ничего взамен не получаю, мне нахуй не нужны деньги, точнее, нахуй не нужны такие копейки, какие мне дают, их в жизни моей не скопится в разумные сроки (максимум за год) столько, чтобы хватило на свой дом и жить в нём до конца жизни. А больше нахуй не нужно ничего, ты такие маленькие деньги можешь потратить только на всякую бесполезную хуйню.
Ну разъебал я телефон окончательно об стену, купил новый, но мне телефон так-то не очень-то нужен. Болезни в большинстве случаев сами проходят, зубы, да похуй на зубы: их просто год не чистишь, они обрастают защитой из зубного камня и всё. Что блять на них покупать, шоколадки? да в рот я ебал шоколадки, они все на вкус говно и меня тошнит от них, я не хочу нихуя, я ебал всё и всех в рот, ненавижу. Охуенная трата сил и часов своей жизни в никуда
https://github.com/PowerShell/PowerShell/issues/1908 на это наткнулся, в cmd это просто работало. Я не буду больше пользоваться павершелом, это невозможно. И вингетом тоже, потому что он легко может рандомно заруинить установленную прогу при обновлении. Или установить что-то без нужных зависимостей, но это вообще на винде всегда так, что устанавливаешь что-то, а потом разбираешься, каких dll не хватает. И вскодом, потому что обычно это ещё более худший опыт настройки плагинов, чем в неовиме: куча каких-то жсонов, в которые иногда можно встраивать ${переменные}, нельзя прописать в жсоне просто список плагинов, чтобы вскод сам их установил, нужно обязательно мышкой прокликивать установку.
Микрософт портит мне жизнь. И скриптовые языки тоже, я ненавижу питон, я не понимаю, зачем он существует, ты пробуешь что угодно установить, написанное на нём, и выясняется, что у него есть какие-то платформозависимые зависимости, колёса какие-то, что они то ли компилируются, то ли там бинарники скачиваются, что тебе нужен мейк, сишный компилятор и что в итоге оно всё равно не компилится и выдаёт километр ошибок. Это просто типичный опыт вызова pip install, на винде так точно. На линуксе наверняка иногда тоже, потому что у тебя необязательно установлены все зависимости и естественно pip install не может их подтянуть, это же всего лишь пакетный менеджер для кроссплатформенного языка
Да и другие скриптовые языки, для них у тебя на компе обязательно должен быть установлен интерпретатор и, скорее всего, ещё и пакетный менеджер к нему, потому что миллион зависимостей является данностью для любой проги на скриптовом языке. Нельзя просто запустить прогу, потому что проги никакой нет, у тебя есть только куча бесполезных текстовых файлов
У меня типа просто есть скрипт, который скачивает всякую ерунду, но из-за того, что он написан на жс, я не могу его запустить, мне придётся устанавливать ноду и я так думаю, что ну это слишком сложно, обойдусь
>>666460
У меня снова началась эта шиза, потому что мне хуёво блять и я либо сижу и нихуя не делаю, либо занимаюсь хуйнёй, заново переписал конфиг, не глядя на старый-старый, который я даже не использовал в пользу старого более минималистичного. Но получил в итоге примерно то же самое, но на этот раз более-менее разобрался с ленивой загрузкой плагинов, благодаря чему оно хотя бы стартовый экран с меню относительно быстро почти мгновенно открывает, тупо потому что почти ничего не грузит. Корову не я нарисовал, я её украл
Стартовый экран почти бесполезный, там полезное только это перейти в папку с конфигами за одно нажатие кнопки
https://github.com/stevearc/oil.nvim вот это вот прикольно, можно редактировать дерево файлов так же, как текстовые буферы в виме, не надо разбираться со всякими непонятными биндингами
https://github.com/andymass/vim-matchup и это, но только из-за того, что % из дефолтного вима не работает нормально в некоторых ситуациях
https://github.com/debugloop/telescope-undo.nvim и это, но это по сути просто более удобный интерфейс для взаимодействия со встроенной фичей в виме undolist. Типа у меня постоянно проблема в том, что я что-то пишу, потом делаю несколько раз undo, потому что написал кринж, пишу снова, а потом вспоминаю, что я хочу скопировать что-то из текста, который я убрал через undo, и в любом нормальном текстовом редакторе этот текст безвозвратно пропадает
Дерево файлов как дерево и дерево символов не нужны, я обычно просто поиском по названиям по файлам и функциям перемещаюсь
Но я не знаю, стоит ли оно вообще того, есть ли смысл в более сложном автодополнении, чем просто по словам в текущем файле. Я до сегодняшнего сколько-то месяцев использовал максимально минималистичный конфиг неовима, где из плагинов были только vim-surround и цветовая схема, и не то чтобы чувствовал себя сильно обделённым. И то, я думаю, не должно быть сложно написать свой примитивный кеймап для того, чтобы поставить скобки или кавычки вокруг выделения. Типа в виме просто автоматом есть маркеры < и > вокруг последнего выделения, просто на них прыгаешь, вставляешь символы, прыгаешь на изначальную позицию и всё.
С использованием netrw тоже, наверное, можно смириться.
В виме даже греп есть встроенный. Поиск и замену на несколько файлов немного неудобно делать (нужно сначала через vimgrep добавить файлы в quickfix, а потом cdof сделать), но тоже терпимо
https://neovim.io/doc/user/digraph.html#digraphs-use и про это тоже не знал, полезно для меня, потому что я слишком тупой, чтобы запомнить даже несколько юникодовых кодов для часто исопльзуемых символов, которых нет на клаве
Для дебаггинга есть просто gdb, там, оказывается, тупо есть графический режим, где показывается исходный код и для того же раста можно даже настроить сорсмапы для стд. И оно даже на винде почти работает (старая 12 версия работает нормально, а 13 версия и актуальный на сегодня trunk - нет, ну это вот типичный виндовс экспириенс, что ничего не работает). В виме даже есть встроенный плагин для gdb (termdebug), но он как-то не очень работает. Этот получше https://github.com/sakhnik/nvim-gdb и поддерживает lldb ещё
Мне, наверное, надо просто сделать опцию в конфиге, чтобы можно было либо выключить все плагины, либо оставить только минимальный набор (точно без LSP).
После того, как меня заставили пойти в рабство, моя жизнь испортилась окончательно и я хочу нахуй сдохнуть, мне не хочется заниматься этой хуйнёй, я не хочу говнокодить на говноязыке какую-то непонятную хуйню, на которую мне максимально похуй, и мне физически тяжело делать то, что мне не хочется. А в последние несколько недель я и перестал делать, и по сути жду, когда меня пошлют уже нахуй и уволят, потому что так жить невозможно, это буквально рабство, я ничего взамен не получаю, мне нахуй не нужны деньги, точнее, нахуй не нужны такие копейки, какие мне дают, их в жизни моей не скопится в разумные сроки (максимум за год) столько, чтобы хватило на свой дом и жить в нём до конца жизни. А больше нахуй не нужно ничего, ты такие маленькие деньги можешь потратить только на всякую бесполезную хуйню.
Ну разъебал я телефон окончательно об стену, купил новый, но мне телефон так-то не очень-то нужен. Болезни в большинстве случаев сами проходят, зубы, да похуй на зубы: их просто год не чистишь, они обрастают защитой из зубного камня и всё. Что блять на них покупать, шоколадки? да в рот я ебал шоколадки, они все на вкус говно и меня тошнит от них, я не хочу нихуя, я ебал всё и всех в рот, ненавижу. Охуенная трата сил и часов своей жизни в никуда
https://github.com/PowerShell/PowerShell/issues/1908 на это наткнулся, в cmd это просто работало. Я не буду больше пользоваться павершелом, это невозможно. И вингетом тоже, потому что он легко может рандомно заруинить установленную прогу при обновлении. Или установить что-то без нужных зависимостей, но это вообще на винде всегда так, что устанавливаешь что-то, а потом разбираешься, каких dll не хватает. И вскодом, потому что обычно это ещё более худший опыт настройки плагинов, чем в неовиме: куча каких-то жсонов, в которые иногда можно встраивать ${переменные}, нельзя прописать в жсоне просто список плагинов, чтобы вскод сам их установил, нужно обязательно мышкой прокликивать установку.
Микрософт портит мне жизнь. И скриптовые языки тоже, я ненавижу питон, я не понимаю, зачем он существует, ты пробуешь что угодно установить, написанное на нём, и выясняется, что у него есть какие-то платформозависимые зависимости, колёса какие-то, что они то ли компилируются, то ли там бинарники скачиваются, что тебе нужен мейк, сишный компилятор и что в итоге оно всё равно не компилится и выдаёт километр ошибок. Это просто типичный опыт вызова pip install, на винде так точно. На линуксе наверняка иногда тоже, потому что у тебя необязательно установлены все зависимости и естественно pip install не может их подтянуть, это же всего лишь пакетный менеджер для кроссплатформенного языка
Да и другие скриптовые языки, для них у тебя на компе обязательно должен быть установлен интерпретатор и, скорее всего, ещё и пакетный менеджер к нему, потому что миллион зависимостей является данностью для любой проги на скриптовом языке. Нельзя просто запустить прогу, потому что проги никакой нет, у тебя есть только куча бесполезных текстовых файлов
У меня типа просто есть скрипт, который скачивает всякую ерунду, но из-за того, что он написан на жс, я не могу его запустить, мне придётся устанавливать ноду и я так думаю, что ну это слишком сложно, обойдусь
У меня снова началась эта шиза, потому что мне хуёво блять и я либо сижу и нихуя не делаю, либо занимаюсь хуйнёй, заново переписал конфиг, не глядя на старый-старый, который я даже не использовал в пользу старого более минималистичного. Но получил в итоге примерно то же самое, но на этот раз более-менее разобрался с ленивой загрузкой плагинов, благодаря чему оно хотя бы стартовый экран с меню относительно быстро почти мгновенно открывает, тупо потому что почти ничего не грузит. Корову не я нарисовал, я её украл
Стартовый экран почти бесполезный, там полезное только это перейти в папку с конфигами за одно нажатие кнопки
https://github.com/stevearc/oil.nvim вот это вот прикольно, можно редактировать дерево файлов так же, как текстовые буферы в виме, не надо разбираться со всякими непонятными биндингами
https://github.com/andymass/vim-matchup и это, но только из-за того, что % из дефолтного вима не работает нормально в некоторых ситуациях
https://github.com/debugloop/telescope-undo.nvim и это, но это по сути просто более удобный интерфейс для взаимодействия со встроенной фичей в виме undolist. Типа у меня постоянно проблема в том, что я что-то пишу, потом делаю несколько раз undo, потому что написал кринж, пишу снова, а потом вспоминаю, что я хочу скопировать что-то из текста, который я убрал через undo, и в любом нормальном текстовом редакторе этот текст безвозвратно пропадает
Дерево файлов как дерево и дерево символов не нужны, я обычно просто поиском по названиям по файлам и функциям перемещаюсь
Но я не знаю, стоит ли оно вообще того, есть ли смысл в более сложном автодополнении, чем просто по словам в текущем файле. Я до сегодняшнего сколько-то месяцев использовал максимально минималистичный конфиг неовима, где из плагинов были только vim-surround и цветовая схема, и не то чтобы чувствовал себя сильно обделённым. И то, я думаю, не должно быть сложно написать свой примитивный кеймап для того, чтобы поставить скобки или кавычки вокруг выделения. Типа в виме просто автоматом есть маркеры < и > вокруг последнего выделения, просто на них прыгаешь, вставляешь символы, прыгаешь на изначальную позицию и всё.
С использованием netrw тоже, наверное, можно смириться.
В виме даже греп есть встроенный. Поиск и замену на несколько файлов немного неудобно делать (нужно сначала через vimgrep добавить файлы в quickfix, а потом cdof сделать), но тоже терпимо
https://neovim.io/doc/user/digraph.html#digraphs-use и про это тоже не знал, полезно для меня, потому что я слишком тупой, чтобы запомнить даже несколько юникодовых кодов для часто исопльзуемых символов, которых нет на клаве
Для дебаггинга есть просто gdb, там, оказывается, тупо есть графический режим, где показывается исходный код и для того же раста можно даже настроить сорсмапы для стд. И оно даже на винде почти работает (старая 12 версия работает нормально, а 13 версия и актуальный на сегодня trunk - нет, ну это вот типичный виндовс экспириенс, что ничего не работает). В виме даже есть встроенный плагин для gdb (termdebug), но он как-то не очень работает. Этот получше https://github.com/sakhnik/nvim-gdb и поддерживает lldb ещё
Мне, наверное, надо просто сделать опцию в конфиге, чтобы можно было либо выключить все плагины, либо оставить только минимальный набор (точно без LSP).
После того, как меня заставили пойти в рабство, моя жизнь испортилась окончательно и я хочу нахуй сдохнуть, мне не хочется заниматься этой хуйнёй, я не хочу говнокодить на говноязыке какую-то непонятную хуйню, на которую мне максимально похуй, и мне физически тяжело делать то, что мне не хочется. А в последние несколько недель я и перестал делать, и по сути жду, когда меня пошлют уже нахуй и уволят, потому что так жить невозможно, это буквально рабство, я ничего взамен не получаю, мне нахуй не нужны деньги, точнее, нахуй не нужны такие копейки, какие мне дают, их в жизни моей не скопится в разумные сроки (максимум за год) столько, чтобы хватило на свой дом и жить в нём до конца жизни. А больше нахуй не нужно ничего, ты такие маленькие деньги можешь потратить только на всякую бесполезную хуйню.
Ну разъебал я телефон окончательно об стену, купил новый, но мне телефон так-то не очень-то нужен. Болезни в большинстве случаев сами проходят, зубы, да похуй на зубы: их просто год не чистишь, они обрастают защитой из зубного камня и всё. Что блять на них покупать, шоколадки? да в рот я ебал шоколадки, они все на вкус говно и меня тошнит от них, я не хочу нихуя, я ебал всё и всех в рот, ненавижу. Охуенная трата сил и часов своей жизни в никуда
https://github.com/PowerShell/PowerShell/issues/1908 на это наткнулся, в cmd это просто работало. Я не буду больше пользоваться павершелом, это невозможно. И вингетом тоже, потому что он легко может рандомно заруинить установленную прогу при обновлении. Или установить что-то без нужных зависимостей, но это вообще на винде всегда так, что устанавливаешь что-то, а потом разбираешься, каких dll не хватает. И вскодом, потому что обычно это ещё более худший опыт настройки плагинов, чем в неовиме: куча каких-то жсонов, в которые иногда можно встраивать ${переменные}, нельзя прописать в жсоне просто список плагинов, чтобы вскод сам их установил, нужно обязательно мышкой прокликивать установку.
Микрософт портит мне жизнь. И скриптовые языки тоже, я ненавижу питон, я не понимаю, зачем он существует, ты пробуешь что угодно установить, написанное на нём, и выясняется, что у него есть какие-то платформозависимые зависимости, колёса какие-то, что они то ли компилируются, то ли там бинарники скачиваются, что тебе нужен мейк, сишный компилятор и что в итоге оно всё равно не компилится и выдаёт километр ошибок. Это просто типичный опыт вызова pip install, на винде так точно. На линуксе наверняка иногда тоже, потому что у тебя необязательно установлены все зависимости и естественно pip install не может их подтянуть, это же всего лишь пакетный менеджер для кроссплатформенного языка
Да и другие скриптовые языки, для них у тебя на компе обязательно должен быть установлен интерпретатор и, скорее всего, ещё и пакетный менеджер к нему, потому что миллион зависимостей является данностью для любой проги на скриптовом языке. Нельзя просто запустить прогу, потому что проги никакой нет, у тебя есть только куча бесполезных текстовых файлов
У меня типа просто есть скрипт, который скачивает всякую ерунду, но из-за того, что он написан на жс, я не могу его запустить, мне придётся устанавливать ноду и я так думаю, что ну это слишком сложно, обойдусь
1,9 Мб, 4080x3072Каждый ёбаный день состоит из страданий
14,5 Мб, webm,1280x1024, 4:15
Я обязательно нарисую треугольник, вот завтра начну, честно, если нахуй не сдохну от сердечного приступа завтра, что очень вероятно, потому что жизнь хуйня и я хочу умереть, не получается, нет времени ни на что, потому что его не очень много, я не умею пользоваться доступным и мне слишком хуёво, блять, каждый божий день.mp4
19,5 Мб, webm,1280x1024, 6:17
Не хочется жить больше, я не чувствовал себя живым весь день, вечером сильно болела голова из-за страданий, и только ночью стало лучше
15,1 Мб, webm,1280x1024, 5:34
Я ненавижу себя и свою жизнь
17,3 Мб, webm,1280x1024, 5:59
Я хочу умереть
.
19,8 Мб, webm,1280x1024, 8:36
Я ненавижу жить блять я блять ненавижу, хочу нахуй сдохнуть уже блять пожалуйста
>>716209
То ли мне показалось, что ли у тебя расхождение с тем, что ты пишешь и тем, как ты говоришь. У тебя вполне спокойный нормальный голос, не подавленный какой-то, рассказываешь интересно.
Ты это просто так пишешь, про сдохнуть, типа прикол такой?
То ли мне показалось, что ли у тебя расхождение с тем, что ты пишешь и тем, как ты говоришь. У тебя вполне спокойный нормальный голос, не подавленный какой-то, рассказываешь интересно.
Ты это просто так пишешь, про сдохнуть, типа прикол такой?
19,4 Мб, webm,1280x1024, 8:37
Ненавижу свою ебаную жизнь блять
17,4 Мб, webm,1280x1024, 7:44
Я уёбище блять
9,3 Мб, webm,1280x1024, 3:32
Я хочу куда-нибудь спрятаться блять я у меня руки чешутся что-нибудь разъебать и спрятаться и чтобы меня никто не нашёл я ненавижу свою ебаную жизнь, блять я не хочу так жить больше сука, я куплю участок земли с деревянным полусгнившим домом, поселюсь там и нахуй замёрзну насмерть или случайно спалю его вместе с собой. НИчего блять хорошего, всем блять что-то надо от меня идите нахуй, я хочу просто сидеть и сидеть в экран, я не хочуть блять ничего больше
9,6 Мб, mp4,640x360, 2:03
Я не могу делать то, что мне не хочется (то есть почти что всё), мне становится плохо и со временем я не привыкаю, а становится только хуже, у меня начинают чесаться руки, чтобы сломать что-то что попадётся под руку или ударить себя по башке. И в какой-то момент я просто физически не могу себя заставить вообще ни минуты больше делать то, что мне не хочется, мне физически плохо. Это примерно то же ощущение, когда берёшь нож с мыслями, ну вот ща всажу его поглубже, но как только доходит до дела, то всё внутри противится, потому что ну объективно нельзя такое делать, если ты нормальный человек, а не ебучая школьница
Я не могу учиться, я не могу работать, я ненавижу это всё, мои родители эффективно заставили меня пойти на работу, потому что я просто уже не вывозил морально их постоянное нытьё о том, что вот ты какая мразь бросил учиться. И всё, у меня подошла точка, когда меня так сильно выворачивает наизнанку, что я не могу ни на минуту сесть за комп и что-то начать делать, я слишком сильно ебал в рот этот говнокодинг какой-то хуйни, которую я ебал в рот, я ни минуты не хочу больше разбираться в этой куче хуйни
Проблема в том, что мне теперь жить спокойно не дадут, зная что я блять нихуя себе сижу дома давлю кнопки и мне за это платят какие-то обоссанные копейки, и будут ебать мне мозг точно так же, как ебали мне мозг с учёбой, только ещё сильнее, мол, давай иди, иди снова всирай свою жизнь на какую-то очередную долбоёбскую парашу
Я могу уехать от них месяца на 4 максимум, а потом, видимо, лечь на пол, сдохнуть от голода и мумифицироваться, потому что абсолютно все работы доступные человеку с низким айкью - это подобное дегроидное говно, от которого мне хочется залезть на потолок. Либо притворяться, что работаю, блять, подделывать скрины из бансковского приложения
Я не могу учиться, я не могу работать, я ненавижу это всё, мои родители эффективно заставили меня пойти на работу, потому что я просто уже не вывозил морально их постоянное нытьё о том, что вот ты какая мразь бросил учиться. И всё, у меня подошла точка, когда меня так сильно выворачивает наизнанку, что я не могу ни на минуту сесть за комп и что-то начать делать, я слишком сильно ебал в рот этот говнокодинг какой-то хуйни, которую я ебал в рот, я ни минуты не хочу больше разбираться в этой куче хуйни
Проблема в том, что мне теперь жить спокойно не дадут, зная что я блять нихуя себе сижу дома давлю кнопки и мне за это платят какие-то обоссанные копейки, и будут ебать мне мозг точно так же, как ебали мне мозг с учёбой, только ещё сильнее, мол, давай иди, иди снова всирай свою жизнь на какую-то очередную долбоёбскую парашу
Я могу уехать от них месяца на 4 максимум, а потом, видимо, лечь на пол, сдохнуть от голода и мумифицироваться, потому что абсолютно все работы доступные человеку с низким айкью - это подобное дегроидное говно, от которого мне хочется залезть на потолок. Либо притворяться, что работаю, блять, подделывать скрины из бансковского приложения
18,7 Мб, webm,1280x1024, 8:19
Мне хуёво блять
19,5 Мб, webm,1280x1024, 14:12
Я хочу нахуй сдохнуть блять
14,3 Мб, webm,1280x1024, 5:54
Ничего хорошего не будет, ничего хорошего не было, я блять уёбище я хочу чтобы всё закончилось, я хочу один раз удариться головой об стену и чтобы она раскололась как скорлупа у яйца и всё блять сука блять сука
Вот, видите. Именно такие мысли продуцирует неовим у каждого его пользователя.
18,5 Мб, webm,1280x1024, 9:40
Я блять не могу больше
19,6 Мб, webm,1280x1024, 13:35
Я уёбище
462 Кб, 2028x2048Я ненавижу свою ебучую жизнь блять, я тупорылое уёбище и это само по себе причиняет страдания и я не могу выдерживать того, что мне сверху испортили всю мою ебаную жизнь и впереди нихуя не будет абсолютно ничего хорошего никогда, потому что физически невозможно, чтобы что-то хорошее произошло это всё равно что мне ногу отрубили и я теперь всю оставшуюся жизнь вынужден вприпрыжку передвигаться на одной сука блять ноге блять сука и давай, привыкай, живи с одной ногой и вообще тебе повезло ещё или якобы и нет никакой проблемы, а вообще одни плюсы в том, чтобы с одной ногой жить, на что ты жалуешься, блять идите нахуй сука вы ненавижу я хочу, чтобы вы все умерли
15,5 Мб, webm,1920x1440, 0:31
Я не знаю, что мне делать, все мысли в моей голове - ебаное говно, я тупой долбоёб
2,5 Мб, 2383x2157Я эту ебаную зиму не переживу, ну почему так ебано то, блять, почему настолько безнадёжно, просто всё, всё, нихуя не будет всё
1,3 Мб, 4080x3072почему всё так
Я пять секунд попробовал гитхаб копилот, короче, он буквально сразу же нагенерил мне заведомо нерабочий мусор, причём выглядит правдоподобно, но всё равно бред. Короче, юзлесс, как и чатгпт
134 Кб, mp4,844x426, 0:02
Я сейчас на работе буквально ничего не делаю и каждый день придумываю оправдания, почему я что-то не сделал, создаю видимость, что я что-то делаю, кормлю завтраками и тд. Не могу себя заставить, потому что мне не хочется, мне не интересно, мне противно, нет никакого положительного стимула это делать.
Не могу даже делать минимум спустя рукава, чтобы меня не трогали. И на фоне этого ничем для себя я толком тоже не могу заниматься, из-за ощущения, что вот-вот произойдёт что-то неприятное, из-за того, что в это время мне якобы нужно делать что-то другое, из-за того, что вне зависимости ни от чего будет кто-то, кто будет постоянно трахать мне мозг какой-то хуйнёй для долбоёбов.
У тебя просто нет возможности в течение, например, недели делать только что-то одно, без переключения на другие вещи. А как-то пытаться совмещать - это бесполезно, я пытался, у меня не хватает сил ни физических, ни моральных. Получалось так, что я ничего не успевал, тот треугольник рисовал почти два месяца, например.
Я в итоге сейчас просто целыми днями сижу и ничего не делаю, в состоянии ступора какого-то, я не знаю. Я всегда хотел только одного - чтобы я мог проснуться, осознавая, что никому от меня ничего не надо, что я могу потратить своё время так, как мне вздумается. Но этого просто никогда не будет, потому что, видимо, абсолютное большинство людей всё устраивает, возможно, им даже нравится, когда им нон-стоп ебут мозг.
Не могу даже делать минимум спустя рукава, чтобы меня не трогали. И на фоне этого ничем для себя я толком тоже не могу заниматься, из-за ощущения, что вот-вот произойдёт что-то неприятное, из-за того, что в это время мне якобы нужно делать что-то другое, из-за того, что вне зависимости ни от чего будет кто-то, кто будет постоянно трахать мне мозг какой-то хуйнёй для долбоёбов.
У тебя просто нет возможности в течение, например, недели делать только что-то одно, без переключения на другие вещи. А как-то пытаться совмещать - это бесполезно, я пытался, у меня не хватает сил ни физических, ни моральных. Получалось так, что я ничего не успевал, тот треугольник рисовал почти два месяца, например.
Я в итоге сейчас просто целыми днями сижу и ничего не делаю, в состоянии ступора какого-то, я не знаю. Я всегда хотел только одного - чтобы я мог проснуться, осознавая, что никому от меня ничего не надо, что я могу потратить своё время так, как мне вздумается. Но этого просто никогда не будет, потому что, видимо, абсолютное большинство людей всё устраивает, возможно, им даже нравится, когда им нон-стоп ебут мозг.
697 Кб, 3090x4096>>721791
Если я так и не начну сегодня ничего делать, то возможно меня уволят, потому что я ничего не делаю уже достаточно времени, чтобы это вызвало недовольство. Но проблема в том, что мне как-то всё равно, я хочу, чтобы всё как-нибудь просто закончилось, но мне никто не поможет, просто проблема в том, что меня потом снова погонят в рабство в стойло, либо у меня просто деньги закончатся, если я съеду от них, чтобы они меня не трогали. А откуда брать деньги, не прикладывая никаких усилий, или как жить без потребности в деньгах, при этом пользуясь интернетом и электричеством и не имея своего дома, я не знаю, я слишком тупой и бесполезный для этого
Почему я просто не родился красивой женщиной, всё было бы настолько проще, вот вообще тупо всё, а так это просто бесполезно жить так нет смысла никакого, не на что надеяться, ничего из более-менее вероятного в теории не может произойти, что могло бы исправить моё положение, и я сам ничего сделать не могу, ничего хорошего не будет
Если я так и не начну сегодня ничего делать, то возможно меня уволят, потому что я ничего не делаю уже достаточно времени, чтобы это вызвало недовольство. Но проблема в том, что мне как-то всё равно, я хочу, чтобы всё как-нибудь просто закончилось, но мне никто не поможет, просто проблема в том, что меня потом снова погонят в рабство в стойло, либо у меня просто деньги закончатся, если я съеду от них, чтобы они меня не трогали. А откуда брать деньги, не прикладывая никаких усилий, или как жить без потребности в деньгах, при этом пользуясь интернетом и электричеством и не имея своего дома, я не знаю, я слишком тупой и бесполезный для этого
Почему я просто не родился красивой женщиной, всё было бы настолько проще, вот вообще тупо всё, а так это просто бесполезно жить так нет смысла никакого, не на что надеяться, ничего из более-менее вероятного в теории не может произойти, что могло бы исправить моё положение, и я сам ничего сделать не могу, ничего хорошего не будет
14,1 Мб, mp4,1280x1024, 0:46
cos(колво рукавов × угол + направление закручивания × 2π × (колво оборотов × расстояние от центра + время))
Я бы не додумался сам потому что я тупорылый долбоёб
Фликеринг жёсткий
Похуй
блять мне
Я бы не додумался сам потому что я тупорылый долбоёб
Фликеринг жёсткий
Похуй
блять мне
>>722169
Какая зп, какой потолок в конторе, скока получают топманагеры, главхуй, скока оборот, какая продукция производится, куда сбывается?
Сори за такие интимные вопросы, но ответь хоть на что-то, раз ты дневниковод.
Какая зп, какой потолок в конторе, скока получают топманагеры, главхуй, скока оборот, какая продукция производится, куда сбывается?
Сори за такие интимные вопросы, но ответь хоть на что-то, раз ты дневниковод.
29 Кб, 546x546>>722589
Недостаточно большая, чтобы можно было за год рабства ХОТЯ БЫ накопить на покупку своего участка с домом, то есть обоссанные копейки. Как и на большинстве работ: хватает только на то, чтобы покупать всякую потреблядскую парашу, но не на нормальные вещи.
Это всё не имеет значения. Если у тебя IQ <130, то тебе доступны только бесполезные бессмысленные говноработы, от которых течёт мозг и на которых ты деградируешь, просто впустую всираешь часы своей жизни, свои силы.
И мне похуй на то, что там другие люди считают "полезным" трудом, я, например, в рот ебал центральное водоснабжение. Наверняка дохуя сложно поддерживать в нормальном состоянии всю эту ебаную систему, наверняка нужны какие-то специальные знания и далеко ненулевой интеллект, наверняка большинство людей считают её даже не просто полезной, а жизненно необходимой, но в моих глазах она не нужна, потому что Я НЕ МОЮСЬ БЛЯТЬ.
И что ещё хуже, все эти говноработы порождают потребность только в ещё большем количестве говноработ. Мы построили большой город - теперь нам нужны магазины на каждом углу. Мы нахуярили магазинов на каждом углу - теперь нам нужно развозить в них свежую еду каждый день, теперь нам нужно нанять дохуя людей расставлять товары и разгружать грузовики, теперь нам нужно разрабатывать говнософт для касс самообслуживания, потому что кассиров не хватает. И так далее.
Я ебал всё в рот, мне похуй, ему похуй, похуй похуй похуй
>Какая зп
Недостаточно большая, чтобы можно было за год рабства ХОТЯ БЫ накопить на покупку своего участка с домом, то есть обоссанные копейки. Как и на большинстве работ: хватает только на то, чтобы покупать всякую потреблядскую парашу, но не на нормальные вещи.
>какая продукция производится, куда сбывается
Это всё не имеет значения. Если у тебя IQ <130, то тебе доступны только бесполезные бессмысленные говноработы, от которых течёт мозг и на которых ты деградируешь, просто впустую всираешь часы своей жизни, свои силы.
И мне похуй на то, что там другие люди считают "полезным" трудом, я, например, в рот ебал центральное водоснабжение. Наверняка дохуя сложно поддерживать в нормальном состоянии всю эту ебаную систему, наверняка нужны какие-то специальные знания и далеко ненулевой интеллект, наверняка большинство людей считают её даже не просто полезной, а жизненно необходимой, но в моих глазах она не нужна, потому что Я НЕ МОЮСЬ БЛЯТЬ.
И что ещё хуже, все эти говноработы порождают потребность только в ещё большем количестве говноработ. Мы построили большой город - теперь нам нужны магазины на каждом углу. Мы нахуярили магазинов на каждом углу - теперь нам нужно развозить в них свежую еду каждый день, теперь нам нужно нанять дохуя людей расставлять товары и разгружать грузовики, теперь нам нужно разрабатывать говнософт для касс самообслуживания, потому что кассиров не хватает. И так далее.
Я ебал всё в рот, мне похуй, ему похуй, похуй похуй похуй
171 Кб, 1000x1000Не, это вообще полностью бесполезно, у меня дни слились просто в один длинный, ещё и солнце не светит никогда и я не понимаю, что вокруг происходит и мне просто постоянно плохо, физически тоже постоянно ощущение сдавленности в грудной клетке, сижу ничего не делаю.
Я скорее всего, съеду от родителей в январе и тогда же стану безРАБотным с 90% вероятностью. И не знаю, что буду делать дальше, не знаю, на сколько месяцев хватит денег. Пытаться снова лезть в говнокодинг за деньги нет никакого желания, не хочу работать, работа - это рабство, мне внутри всё внутри грудной клетки прогрызли крысы
Я скорее всего, съеду от родителей в январе и тогда же стану безРАБотным с 90% вероятностью. И не знаю, что буду делать дальше, не знаю, на сколько месяцев хватит денег. Пытаться снова лезть в говнокодинг за деньги нет никакого желания, не хочу работать, работа - это рабство, мне внутри всё внутри грудной клетки прогрызли крысы
149 Кб, mp4,500x374, 0:01
Впереди нет ничего, просто чернота, я не могу ни на что повлиять, не могу ничего сделать. Неважно, например, даже если я себя сейчас убью, то это буквально тот же самый исход, как если я не сделаю этого. Ни в чём нет смысла
Короче эта тема с якобы двойной буферизацией через сделать два скринбуфера CreateConsoleScreenBuffer и потом их по очереди показывать через SetConsoleActiveScreenBuffer как будто всё же немного улучшает, но только на conhost.exe, в виндовс терминале - без разницы, в алакрити оно как будто вообще только хуже делает. К тому же когда перезапускаешь в той же консоли заново, то во варианте с двумя скринбуферами почему-то всё неправильного размера начинает рисоваться, короче, это бред пытаться это использовать
Мельтешение при ресайзе невозможно убрать неважно с двумя скринбуферами или без них в любом случае вроде, не знаю
Единственное, что стоило сделать - это заменить растовый print! на WriteConsoleW, потому что раст похоже делает какую-то буферизацию и непонятно как преобразовывает utf8 строки в utf16 для винды, а я использую юникодовые символы, мне лень разбираться, проще самому сделать, вроде немного лучше (ну точнее в conhost.exe print вообще адекватно не работал, а виндовс терминалу было болееменее нормально с самого начала), но тоже вырвиглазно, короче бесполезно
А я просто что-то подумл зачем нужны все эти графические апи, если есть консоль, в которой можно рисовать квадратики и к тому же ещё и рендеринг текста есть, но не знаю короче
Мельтешение при ресайзе невозможно убрать неважно с двумя скринбуферами или без них в любом случае вроде, не знаю
Единственное, что стоило сделать - это заменить растовый print! на WriteConsoleW, потому что раст похоже делает какую-то буферизацию и непонятно как преобразовывает utf8 строки в utf16 для винды, а я использую юникодовые символы, мне лень разбираться, проще самому сделать, вроде немного лучше (ну точнее в conhost.exe print вообще адекватно не работал, а виндовс терминалу было болееменее нормально с самого начала), но тоже вырвиглазно, короче бесполезно
А я просто что-то подумл зачем нужны все эти графические апи, если есть консоль, в которой можно рисовать квадратики и к тому же ещё и рендеринг текста есть, но не знаю короче
9,6 Мб, mp4,1280x1024, 0:27
Скрыть виндовый курсор, пока он находится над конолью, вроде как нельзя
296 Кб, 1378x2039Не хочется жить, не на что надеяться, почему всё настолько плохо, никто не поможет
Мне абсолютно ничего не интересно, кроме как сидеть дома и играть в игры
335 Кб, 1943x2048Всё бесполезно, никаких вариантов нет. Я не верю в то, что людей со временем начинается принятие смирение и бла бла бла, все люди пиздят, я их всех ненавижу, принятия не существует, существует, что какая-то хуйня случилась и ты со временем её забыл, а когда хуйня происходит каждый день, ты её не можешь забыть блять. Все живут и всем нормально живётся, всё устраивает, всё нравится, а кому не нравится - они спиваются, старчиваются и сдыхают. Я один страдаю, мне одному плохо
905 Кб, 1834x1021Подписался на тред
>>725548
Неплохо. Текстурки порельефнее сделать, (типо "запечь" но без запекания, а вручную всё отрисовав) как в старых играх типо варкрафта.
Неплохо. Текстурки порельефнее сделать, (типо "запечь" но без запекания, а вручную всё отрисовав) как в старых играх типо варкрафта.
>>644092 (OP)
вот бы поюлозить своим хреном у тебя между сисек
вот бы поюлозить своим хреном у тебя между сисек
>>730346
блина, такой голос милый..
блина, такой голос милый..
>>730346
хм, а разве в винде нет malloc? я мало под неё писал, вернее вообще не писал, так что не знаю
какое же winapi все таки странное, капетс
даже как-то сказать нечего, графика как была для меня темным лесом, так наверно и останется
>выделение памяти для структуры через VirtualAlloc
хм, а разве в винде нет malloc? я мало под неё писал, вернее вообще не писал, так что не знаю
>PeekMessage
какое же winapi все таки странное, капетс
даже как-то сказать нечего, графика как была для меня темным лесом, так наверно и останется
461 Кб, 1358x2048Ебучие родаки за каким-то хуем решили порыться в моём столе и нашли заявление на увольнение. Двух недель не прошло, эти пидарасы уже успели узнать
>>731147
В чём проблема? Тебе сколько годиков? Родители нашли заявление на увольнение... ХОСПАДЕ ИСУСИ
В чём проблема? Тебе сколько годиков? Родители нашли заявление на увольнение... ХОСПАДЕ ИСУСИ
476 Кб, 1378x2039>>731152
Проблема в том, что я не могу больше притворяться, что всё ещё работаю и эти хуесосы теперь снова будут трахать мне мозг тем, чтобы я снова шёл работать каким-нибудь долбоёбом
Проблема в том, что я не могу больше притворяться, что всё ещё работаю и эти хуесосы теперь снова будут трахать мне мозг тем, чтобы я снова шёл работать каким-нибудь долбоёбом
>>731157
Стань мужиком и выйди на работу делов-то, все хватит ныть возьми себя в руки !!!
Стань мужиком и выйди на работу делов-то, все хватит ныть возьми себя в руки !!!
504 Кб, 1665x1665>>731158
Работа - это рабство и деградация, если у тебя iq < 115, то не существует интересных работ, существует только унылое бессмысленное дерьмо, которым я не хочу заниматься и мне хуёво
Работа - это рабство и деградация, если у тебя iq < 115, то не существует интересных работ, существует только унылое бессмысленное дерьмо, которым я не хочу заниматься и мне хуёво
>>731162
Зачем ты привязываешь свой пессимизм к IQ? Боишься чего-то и пытаешься защититься?
Зачем ты привязываешь свой пессимизм к IQ? Боишься чего-то и пытаешься защититься?
>>731162
Братан ну еду готовить и мусор выносить так-то тоже уныло.
Братан ну еду готовить и мусор выносить так-то тоже уныло.
Вот это забавно https://github.com/rust-lang/rust/issues/25860
Я не сразу понял, в чём вообще проблема, вот в более понятной для меня форме https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0449b79fa65e5d294f220a4d58dfb95e
Если попробовать на 12 строке вызвать function, то это не скомпилируется, потому что в теле функции попытка вернуть ссылку с более маленьким лайфтаймом, чем 'static, очевидно.
Если попробовать на 12 строке вызвать f1, то тоже не сработает, потому что хоть f1 и указатель на функцию и мы не знаем, что там на самом деле конкретно внутри возвращается с каким лайфтаймом, но из того, что в самой сигнатуре есть параметр типа "&'a &'b ()", следует, что 'b должен пережить 'a. Но у нас 'a = 'static, а 'b - нет, поэтому тоже скомпилируется.
Проблемы начинаются на 9 строке из-за того, что контравариантность типов параметров функции позволяет переход от "&'a &'b" к "&'a &'static". Тут с самой контравариантностью всё в порядке: если в функцию можно передать ссылку с лайфтаймом 'b, то туда тем более можно передать ссылку со 'static лайфтаймом. Но проблема в том, что при этом теряется информация о том, что 'b должен пережить 'a.
Не знаю, почему ещё не поправили это всё, лень читать тред, там непонятно ничего и слишком сложно для понимания
Ещё такой пример есть https://github.com/rust-lang/rust/issues/25860#issuecomment-1680007800 там как будто используется ковариантность типов возвращаемых значений, но я вообще не понимаю этот пример, слишком запутанный
Я не сразу понял, в чём вообще проблема, вот в более понятной для меня форме https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0449b79fa65e5d294f220a4d58dfb95e
Если попробовать на 12 строке вызвать function, то это не скомпилируется, потому что в теле функции попытка вернуть ссылку с более маленьким лайфтаймом, чем 'static, очевидно.
Если попробовать на 12 строке вызвать f1, то тоже не сработает, потому что хоть f1 и указатель на функцию и мы не знаем, что там на самом деле конкретно внутри возвращается с каким лайфтаймом, но из того, что в самой сигнатуре есть параметр типа "&'a &'b ()", следует, что 'b должен пережить 'a. Но у нас 'a = 'static, а 'b - нет, поэтому тоже скомпилируется.
Проблемы начинаются на 9 строке из-за того, что контравариантность типов параметров функции позволяет переход от "&'a &'b" к "&'a &'static". Тут с самой контравариантностью всё в порядке: если в функцию можно передать ссылку с лайфтаймом 'b, то туда тем более можно передать ссылку со 'static лайфтаймом. Но проблема в том, что при этом теряется информация о том, что 'b должен пережить 'a.
Не знаю, почему ещё не поправили это всё, лень читать тред, там непонятно ничего и слишком сложно для понимания
Ещё такой пример есть https://github.com/rust-lang/rust/issues/25860#issuecomment-1680007800 там как будто используется ковариантность типов возвращаемых значений, но я вообще не понимаю этот пример, слишком запутанный
У меня с lazy.nvim (который менеджер плагинов) были две проблемы,
что не работали плагины, зависящие от триситтера (matchup, например), если грузить их лениво,
и что когда открываешь файл напрямую командой через консоль так `nvim file` (а не внутри самого нвима через :e), то почему-то все лениво загружаемые плагины (триситтер, лсп, например) не давали сразу вывести на экран содержимое файла до того, как они все полностью загрузятся. Видимо, это из-за того, что BufReadPost, который триггерит загрузку большинства моих плагинов, триггерится до загрузки UI, из-за чего ждёшь лишние десятки миллисекунд смотря на чёрный экран, пока грузятся плагины.
Только сейчас попробовал посмотреть подробнее код LazyVim (который готовый конфиг, который я сам по себе не использую, только частично смотрел в нём, как настроить некоторые плагины), в общем,
первая проблема решается тем, чтобы предварительно добавить плагин триситтера в runtimepath https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/plugins/treesitter.lua#L11 Чтобы для других плагинов стали по крайней мере видны все скомпилированные парсеры, и этого вроде достаточно, потому что триситтер частично встроен в нвим, но плагин всё равно нужен, чтобы делать через него подсветку кода, но этим другим плагинам, которые используют триситтер, сам плагин не очень нужен? Там вообще какая-то странная двухсторонняя зависимость между ними бывает.
вторая проблема решается тем, чтобы создать кастомный ивент, который при условии триггера BufReadPost триггерится уже только после загрузки UI https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/util/plugin.lua#L114 и грузить большинство плагинов по этому кастомному ивенту, а не по BufReadPost/BufNewFile/BufWritePre.
Из этого выводы, что
дерево зависимостей глубже одного уровня - это зло,
UI, построенный на колбэках/ивентах с непонятно каким порядком выполнения кода - это зло,
скриптовые языки - это зло, потому что люди неизбежно начинают с их помощью надстраивать что-то гигантское, сложное и непонятное,
единственный правильный способ поддержки расширений - это менять исходный код через гит патчи, добавляющие нужный функционал, и самому пересобирать программу?
Или что мне нужно начать пользоваться блокнотом вместо нвима?
что не работали плагины, зависящие от триситтера (matchup, например), если грузить их лениво,
и что когда открываешь файл напрямую командой через консоль так `nvim file` (а не внутри самого нвима через :e), то почему-то все лениво загружаемые плагины (триситтер, лсп, например) не давали сразу вывести на экран содержимое файла до того, как они все полностью загрузятся. Видимо, это из-за того, что BufReadPost, который триггерит загрузку большинства моих плагинов, триггерится до загрузки UI, из-за чего ждёшь лишние десятки миллисекунд смотря на чёрный экран, пока грузятся плагины.
Только сейчас попробовал посмотреть подробнее код LazyVim (который готовый конфиг, который я сам по себе не использую, только частично смотрел в нём, как настроить некоторые плагины), в общем,
первая проблема решается тем, чтобы предварительно добавить плагин триситтера в runtimepath https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/plugins/treesitter.lua#L11 Чтобы для других плагинов стали по крайней мере видны все скомпилированные парсеры, и этого вроде достаточно, потому что триситтер частично встроен в нвим, но плагин всё равно нужен, чтобы делать через него подсветку кода, но этим другим плагинам, которые используют триситтер, сам плагин не очень нужен? Там вообще какая-то странная двухсторонняя зависимость между ними бывает.
вторая проблема решается тем, чтобы создать кастомный ивент, который при условии триггера BufReadPost триггерится уже только после загрузки UI https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/util/plugin.lua#L114 и грузить большинство плагинов по этому кастомному ивенту, а не по BufReadPost/BufNewFile/BufWritePre.
Из этого выводы, что
дерево зависимостей глубже одного уровня - это зло,
UI, построенный на колбэках/ивентах с непонятно каким порядком выполнения кода - это зло,
скриптовые языки - это зло, потому что люди неизбежно начинают с их помощью надстраивать что-то гигантское, сложное и непонятное,
единственный правильный способ поддержки расширений - это менять исходный код через гит патчи, добавляющие нужный функционал, и самому пересобирать программу?
Или что мне нужно начать пользоваться блокнотом вместо нвима?
У меня с lazy.nvim (который менеджер плагинов) были две проблемы,
что не работали плагины, зависящие от триситтера (matchup, например), если грузить их лениво,
и что когда открываешь файл напрямую командой через консоль так `nvim file` (а не внутри самого нвима через :e), то почему-то все лениво загружаемые плагины (триситтер, лсп, например) не давали сразу вывести на экран содержимое файла до того, как они все полностью загрузятся. Видимо, это из-за того, что BufReadPost, который триггерит загрузку большинства моих плагинов, триггерится до загрузки UI, из-за чего ждёшь лишние десятки миллисекунд смотря на чёрный экран, пока грузятся плагины.
Только сейчас попробовал посмотреть подробнее код LazyVim (который готовый конфиг, который я сам по себе не использую, только частично смотрел в нём, как настроить некоторые плагины), в общем,
первая проблема решается тем, чтобы предварительно добавить плагин триситтера в runtimepath https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/plugins/treesitter.lua#L11 Чтобы для других плагинов стали по крайней мере видны все скомпилированные парсеры, и этого вроде достаточно, потому что триситтер частично встроен в нвим, но плагин всё равно нужен, чтобы делать через него подсветку кода, но этим другим плагинам, которые используют триситтер, сам плагин не очень нужен? Там вообще какая-то странная двухсторонняя зависимость между ними бывает.
вторая проблема решается тем, чтобы создать кастомный ивент, который при условии триггера BufReadPost триггерится уже только после загрузки UI https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/util/plugin.lua#L114 и грузить большинство плагинов по этому кастомному ивенту, а не по BufReadPost/BufNewFile/BufWritePre.
Из этого выводы, что
дерево зависимостей глубже одного уровня - это зло,
UI, построенный на колбэках/ивентах с непонятно каким порядком выполнения кода - это зло,
скриптовые языки - это зло, потому что люди неизбежно начинают с их помощью надстраивать что-то гигантское, сложное и непонятное,
единственный правильный способ поддержки расширений - это менять исходный код через гит патчи, добавляющие нужный функционал, и самому пересобирать программу?
Или что мне нужно начать пользоваться блокнотом вместо нвима?
что не работали плагины, зависящие от триситтера (matchup, например), если грузить их лениво,
и что когда открываешь файл напрямую командой через консоль так `nvim file` (а не внутри самого нвима через :e), то почему-то все лениво загружаемые плагины (триситтер, лсп, например) не давали сразу вывести на экран содержимое файла до того, как они все полностью загрузятся. Видимо, это из-за того, что BufReadPost, который триггерит загрузку большинства моих плагинов, триггерится до загрузки UI, из-за чего ждёшь лишние десятки миллисекунд смотря на чёрный экран, пока грузятся плагины.
Только сейчас попробовал посмотреть подробнее код LazyVim (который готовый конфиг, который я сам по себе не использую, только частично смотрел в нём, как настроить некоторые плагины), в общем,
первая проблема решается тем, чтобы предварительно добавить плагин триситтера в runtimepath https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/plugins/treesitter.lua#L11 Чтобы для других плагинов стали по крайней мере видны все скомпилированные парсеры, и этого вроде достаточно, потому что триситтер частично встроен в нвим, но плагин всё равно нужен, чтобы делать через него подсветку кода, но этим другим плагинам, которые используют триситтер, сам плагин не очень нужен? Там вообще какая-то странная двухсторонняя зависимость между ними бывает.
вторая проблема решается тем, чтобы создать кастомный ивент, который при условии триггера BufReadPost триггерится уже только после загрузки UI https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/util/plugin.lua#L114 и грузить большинство плагинов по этому кастомному ивенту, а не по BufReadPost/BufNewFile/BufWritePre.
Из этого выводы, что
дерево зависимостей глубже одного уровня - это зло,
UI, построенный на колбэках/ивентах с непонятно каким порядком выполнения кода - это зло,
скриптовые языки - это зло, потому что люди неизбежно начинают с их помощью надстраивать что-то гигантское, сложное и непонятное,
единственный правильный способ поддержки расширений - это менять исходный код через гит патчи, добавляющие нужный функционал, и самому пересобирать программу?
Или что мне нужно начать пользоваться блокнотом вместо нвима?
13,1 Мб, webm,960x1034, 9:33
Я в 10 раз бросил кофе но всё ещё не хочу ничего, нет смысла жить никакого
905 Кб, 1834x1021>>735071
Зачем бросил? Хуевит с него?
Зачем бросил? Хуевит с него?
Пытался читать это https://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf но в итоге не осилил полностью и тем более не понял большинство доказательств. Это просто реальность существования с низким IQ: сидишь, перечитываешь что-то один раз, второй и не понимаешь ничего, по отдельности вещи делают смысл, но не выстраиваются ни во что цельное.
Я вообще просто хотел понять, что такое машинный эпсилон, потому что когда увидел его случайно в std раста, то подумалось, что а вдруг это то самое, что нужно использовать когда сравниваешь флоаты, но, короче, нет, это вообще дебильное предположение. Он связан с относительной погрешностью, но я так и не понял, какой смысл у того, чтобы взять абсолютную погрешность (например, выраженную в ULP) и поделить её на "настоящее" значение. Видимо, для того, чтобы сделать результат независимым от экспоненты?
Допустим, есть "настоящее" значение 1.0 × 10^{-42} и "вычисленное" значение 1.1 × 10^{-42}. Абсолютная погрешность равна 0.1 × 10^{-42}, что, наверное, ни о чём не говорит, потому что ну типа погрешность выглядит маленькой, но проблема в том, что сами числа тоже маленькие. А относительная погрешность будет равна просто 0.1, наверное, это даёт лучшее представление о точности, не знаю. И если мы работаем с флоатами (β = 10, p = 2), то можно сказать, что ε = 0.05 и оценить количество потенциально неверных знаков с конца через log_β{относительная погрешность / ε}? (p - это размер мантиссы, причём он в том числе включает единицу, которая в IEEE 754 неявная.)
Как я понял, в целом связь машинного эпсилона и относительной погрешности в том, что вот абсолютная погрешность представления флоата максимум равна 1/2 ULP = ((β / 2) · β^{-p}) × β^{e} для какой-то экспоненты e. И эта погрешность верна для всех флоатов в промежутке [β^{e} .. β^{e + 1}) . Но относительная погрешность зависит от "настоящего" вещественного значения, поэтому на этом промежутке она находится где-то в промежутке ((1 / 2) · β^{-p} .. (β / 2) · β^{-p}] - от экспоненты, получается, не зависит. И типо вот как раз верхняя граница этой оценки относительной погрешности определяется как машинный эпсилон. Ну и типо тогда, видимо, имеет смысл измерять погрешность вычислений во флоатах как n × ε, потому что ε - это максимальная точность, которую можно достичь, представляя результат во флоате?
Непонятно, почему-то иногда машинный эпсилон определяется как расстояние от 1.0 до следующего флоата, а иногда как половина от этого расстояния, причём в википедии тоже написано, что это либо то, либо это. Не понимаю.
Ещё один момент, о котором не думал: что во флоатах так-то всякие базовые операции (плюс, минус, умножить, поделить и как минимум вроде ещё квадратный корень) выполняются с максимальной точностью: то есть как если бы флоаты перевели в вещественные числа, сделали вычисления, а потом округлили бы обратно к флоатам. И, как я понял, для этого во внутренней реализации для таких точных вычислений не хватает использования только лишь p цифр мантиссы, нужна хотя бы одна дополнительная цифра (guard digit), чтобы, например, выполнять вычитание двух флоатов с точностью < 2ε (теорема 2 из статьи).
Вроде как эта дополнительная цифра играет роль, когда, например, вычитаешь два числа с разными экспонентами и сдвигаешь мантиссу числа с меньшей экспонентой, чтобы их выровнять.
Допустим, вычисляем 1.01 × 10^{1} - 9.93 × 10^{0}, (β = 10, p = 3)
1.01 × 10^{1} - 0.99 × 10^{1} = 0.02 × 10^{1} = 0.2 × 10^{0}, если не использовать guard digit.
1.010 × 10^{1} - 0.993 × 10^{1} = 0.017 × 10^{1} = 0.17 × 10^{0}, если добавить guard digit.
Но вроде как только одной дополнительной цифры недостаточно для максимальной точности, нужна как минимум ещё вторая дополнительная цифра round digit (видимо, чтобы округление было всегда в правильную сторону, судя по названию? возможно, нужен, потому что когда складываешь или умножаешь нормализованные флоаты, то целая часть может перевалить за 2 цифры?) Sticky bit не знаю, как определяется для произвольного β, в случае с β = 2 вроде как это просто OR всех битов, которые не уместились при сдвиге мантиссы, видимо, чтобы их тоже хотя бы как-то учесть?. Немного более подробно про это я нашёл только тут https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/flpt.apprec.html не знаю, короче.
И, как я понял, этих трёх дополнительных битов должно быть достаточно как для сингловых флоатов, так и для даблов? По крайней мере во всех теоремах про точность вычислений в статье погрешность указывается в машинных эпсилонах, то есть оно не должно зависеть от того, насколько большой сам машинный эпсилон? Вот не знаю, это, наверное, самый непонятный момент для меня.
Я вообще просто хотел понять, что такое машинный эпсилон, потому что когда увидел его случайно в std раста, то подумалось, что а вдруг это то самое, что нужно использовать когда сравниваешь флоаты, но, короче, нет, это вообще дебильное предположение. Он связан с относительной погрешностью, но я так и не понял, какой смысл у того, чтобы взять абсолютную погрешность (например, выраженную в ULP) и поделить её на "настоящее" значение. Видимо, для того, чтобы сделать результат независимым от экспоненты?
Допустим, есть "настоящее" значение 1.0 × 10^{-42} и "вычисленное" значение 1.1 × 10^{-42}. Абсолютная погрешность равна 0.1 × 10^{-42}, что, наверное, ни о чём не говорит, потому что ну типа погрешность выглядит маленькой, но проблема в том, что сами числа тоже маленькие. А относительная погрешность будет равна просто 0.1, наверное, это даёт лучшее представление о точности, не знаю. И если мы работаем с флоатами (β = 10, p = 2), то можно сказать, что ε = 0.05 и оценить количество потенциально неверных знаков с конца через log_β{относительная погрешность / ε}? (p - это размер мантиссы, причём он в том числе включает единицу, которая в IEEE 754 неявная.)
Как я понял, в целом связь машинного эпсилона и относительной погрешности в том, что вот абсолютная погрешность представления флоата максимум равна 1/2 ULP = ((β / 2) · β^{-p}) × β^{e} для какой-то экспоненты e. И эта погрешность верна для всех флоатов в промежутке [β^{e} .. β^{e + 1}) . Но относительная погрешность зависит от "настоящего" вещественного значения, поэтому на этом промежутке она находится где-то в промежутке ((1 / 2) · β^{-p} .. (β / 2) · β^{-p}] - от экспоненты, получается, не зависит. И типо вот как раз верхняя граница этой оценки относительной погрешности определяется как машинный эпсилон. Ну и типо тогда, видимо, имеет смысл измерять погрешность вычислений во флоатах как n × ε, потому что ε - это максимальная точность, которую можно достичь, представляя результат во флоате?
Непонятно, почему-то иногда машинный эпсилон определяется как расстояние от 1.0 до следующего флоата, а иногда как половина от этого расстояния, причём в википедии тоже написано, что это либо то, либо это. Не понимаю.
Ещё один момент, о котором не думал: что во флоатах так-то всякие базовые операции (плюс, минус, умножить, поделить и как минимум вроде ещё квадратный корень) выполняются с максимальной точностью: то есть как если бы флоаты перевели в вещественные числа, сделали вычисления, а потом округлили бы обратно к флоатам. И, как я понял, для этого во внутренней реализации для таких точных вычислений не хватает использования только лишь p цифр мантиссы, нужна хотя бы одна дополнительная цифра (guard digit), чтобы, например, выполнять вычитание двух флоатов с точностью < 2ε (теорема 2 из статьи).
Вроде как эта дополнительная цифра играет роль, когда, например, вычитаешь два числа с разными экспонентами и сдвигаешь мантиссу числа с меньшей экспонентой, чтобы их выровнять.
Допустим, вычисляем 1.01 × 10^{1} - 9.93 × 10^{0}, (β = 10, p = 3)
1.01 × 10^{1} - 0.99 × 10^{1} = 0.02 × 10^{1} = 0.2 × 10^{0}, если не использовать guard digit.
1.010 × 10^{1} - 0.993 × 10^{1} = 0.017 × 10^{1} = 0.17 × 10^{0}, если добавить guard digit.
Но вроде как только одной дополнительной цифры недостаточно для максимальной точности, нужна как минимум ещё вторая дополнительная цифра round digit (видимо, чтобы округление было всегда в правильную сторону, судя по названию? возможно, нужен, потому что когда складываешь или умножаешь нормализованные флоаты, то целая часть может перевалить за 2 цифры?) Sticky bit не знаю, как определяется для произвольного β, в случае с β = 2 вроде как это просто OR всех битов, которые не уместились при сдвиге мантиссы, видимо, чтобы их тоже хотя бы как-то учесть?. Немного более подробно про это я нашёл только тут https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/flpt.apprec.html не знаю, короче.
И, как я понял, этих трёх дополнительных битов должно быть достаточно как для сингловых флоатов, так и для даблов? По крайней мере во всех теоремах про точность вычислений в статье погрешность указывается в машинных эпсилонах, то есть оно не должно зависеть от того, насколько большой сам машинный эпсилон? Вот не знаю, это, наверное, самый непонятный момент для меня.
Пытался читать это https://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf но в итоге не осилил полностью и тем более не понял большинство доказательств. Это просто реальность существования с низким IQ: сидишь, перечитываешь что-то один раз, второй и не понимаешь ничего, по отдельности вещи делают смысл, но не выстраиваются ни во что цельное.
Я вообще просто хотел понять, что такое машинный эпсилон, потому что когда увидел его случайно в std раста, то подумалось, что а вдруг это то самое, что нужно использовать когда сравниваешь флоаты, но, короче, нет, это вообще дебильное предположение. Он связан с относительной погрешностью, но я так и не понял, какой смысл у того, чтобы взять абсолютную погрешность (например, выраженную в ULP) и поделить её на "настоящее" значение. Видимо, для того, чтобы сделать результат независимым от экспоненты?
Допустим, есть "настоящее" значение 1.0 × 10^{-42} и "вычисленное" значение 1.1 × 10^{-42}. Абсолютная погрешность равна 0.1 × 10^{-42}, что, наверное, ни о чём не говорит, потому что ну типа погрешность выглядит маленькой, но проблема в том, что сами числа тоже маленькие. А относительная погрешность будет равна просто 0.1, наверное, это даёт лучшее представление о точности, не знаю. И если мы работаем с флоатами (β = 10, p = 2), то можно сказать, что ε = 0.05 и оценить количество потенциально неверных знаков с конца через log_β{относительная погрешность / ε}? (p - это размер мантиссы, причём он в том числе включает единицу, которая в IEEE 754 неявная.)
Как я понял, в целом связь машинного эпсилона и относительной погрешности в том, что вот абсолютная погрешность представления флоата максимум равна 1/2 ULP = ((β / 2) · β^{-p}) × β^{e} для какой-то экспоненты e. И эта погрешность верна для всех флоатов в промежутке [β^{e} .. β^{e + 1}) . Но относительная погрешность зависит от "настоящего" вещественного значения, поэтому на этом промежутке она находится где-то в промежутке ((1 / 2) · β^{-p} .. (β / 2) · β^{-p}] - от экспоненты, получается, не зависит. И типо вот как раз верхняя граница этой оценки относительной погрешности определяется как машинный эпсилон. Ну и типо тогда, видимо, имеет смысл измерять погрешность вычислений во флоатах как n × ε, потому что ε - это максимальная точность, которую можно достичь, представляя результат во флоате?
Непонятно, почему-то иногда машинный эпсилон определяется как расстояние от 1.0 до следующего флоата, а иногда как половина от этого расстояния, причём в википедии тоже написано, что это либо то, либо это. Не понимаю.
Ещё один момент, о котором не думал: что во флоатах так-то всякие базовые операции (плюс, минус, умножить, поделить и как минимум вроде ещё квадратный корень) выполняются с максимальной точностью: то есть как если бы флоаты перевели в вещественные числа, сделали вычисления, а потом округлили бы обратно к флоатам. И, как я понял, для этого во внутренней реализации для таких точных вычислений не хватает использования только лишь p цифр мантиссы, нужна хотя бы одна дополнительная цифра (guard digit), чтобы, например, выполнять вычитание двух флоатов с точностью < 2ε (теорема 2 из статьи).
Вроде как эта дополнительная цифра играет роль, когда, например, вычитаешь два числа с разными экспонентами и сдвигаешь мантиссу числа с меньшей экспонентой, чтобы их выровнять.
Допустим, вычисляем 1.01 × 10^{1} - 9.93 × 10^{0}, (β = 10, p = 3)
1.01 × 10^{1} - 0.99 × 10^{1} = 0.02 × 10^{1} = 0.2 × 10^{0}, если не использовать guard digit.
1.010 × 10^{1} - 0.993 × 10^{1} = 0.017 × 10^{1} = 0.17 × 10^{0}, если добавить guard digit.
Но вроде как только одной дополнительной цифры недостаточно для максимальной точности, нужна как минимум ещё вторая дополнительная цифра round digit (видимо, чтобы округление было всегда в правильную сторону, судя по названию? возможно, нужен, потому что когда складываешь или умножаешь нормализованные флоаты, то целая часть может перевалить за 2 цифры?) Sticky bit не знаю, как определяется для произвольного β, в случае с β = 2 вроде как это просто OR всех битов, которые не уместились при сдвиге мантиссы, видимо, чтобы их тоже хотя бы как-то учесть?. Немного более подробно про это я нашёл только тут https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/flpt.apprec.html не знаю, короче.
И, как я понял, этих трёх дополнительных битов должно быть достаточно как для сингловых флоатов, так и для даблов? По крайней мере во всех теоремах про точность вычислений в статье погрешность указывается в машинных эпсилонах, то есть оно не должно зависеть от того, насколько большой сам машинный эпсилон? Вот не знаю, это, наверное, самый непонятный момент для меня.
Я вообще просто хотел понять, что такое машинный эпсилон, потому что когда увидел его случайно в std раста, то подумалось, что а вдруг это то самое, что нужно использовать когда сравниваешь флоаты, но, короче, нет, это вообще дебильное предположение. Он связан с относительной погрешностью, но я так и не понял, какой смысл у того, чтобы взять абсолютную погрешность (например, выраженную в ULP) и поделить её на "настоящее" значение. Видимо, для того, чтобы сделать результат независимым от экспоненты?
Допустим, есть "настоящее" значение 1.0 × 10^{-42} и "вычисленное" значение 1.1 × 10^{-42}. Абсолютная погрешность равна 0.1 × 10^{-42}, что, наверное, ни о чём не говорит, потому что ну типа погрешность выглядит маленькой, но проблема в том, что сами числа тоже маленькие. А относительная погрешность будет равна просто 0.1, наверное, это даёт лучшее представление о точности, не знаю. И если мы работаем с флоатами (β = 10, p = 2), то можно сказать, что ε = 0.05 и оценить количество потенциально неверных знаков с конца через log_β{относительная погрешность / ε}? (p - это размер мантиссы, причём он в том числе включает единицу, которая в IEEE 754 неявная.)
Как я понял, в целом связь машинного эпсилона и относительной погрешности в том, что вот абсолютная погрешность представления флоата максимум равна 1/2 ULP = ((β / 2) · β^{-p}) × β^{e} для какой-то экспоненты e. И эта погрешность верна для всех флоатов в промежутке [β^{e} .. β^{e + 1}) . Но относительная погрешность зависит от "настоящего" вещественного значения, поэтому на этом промежутке она находится где-то в промежутке ((1 / 2) · β^{-p} .. (β / 2) · β^{-p}] - от экспоненты, получается, не зависит. И типо вот как раз верхняя граница этой оценки относительной погрешности определяется как машинный эпсилон. Ну и типо тогда, видимо, имеет смысл измерять погрешность вычислений во флоатах как n × ε, потому что ε - это максимальная точность, которую можно достичь, представляя результат во флоате?
Непонятно, почему-то иногда машинный эпсилон определяется как расстояние от 1.0 до следующего флоата, а иногда как половина от этого расстояния, причём в википедии тоже написано, что это либо то, либо это. Не понимаю.
Ещё один момент, о котором не думал: что во флоатах так-то всякие базовые операции (плюс, минус, умножить, поделить и как минимум вроде ещё квадратный корень) выполняются с максимальной точностью: то есть как если бы флоаты перевели в вещественные числа, сделали вычисления, а потом округлили бы обратно к флоатам. И, как я понял, для этого во внутренней реализации для таких точных вычислений не хватает использования только лишь p цифр мантиссы, нужна хотя бы одна дополнительная цифра (guard digit), чтобы, например, выполнять вычитание двух флоатов с точностью < 2ε (теорема 2 из статьи).
Вроде как эта дополнительная цифра играет роль, когда, например, вычитаешь два числа с разными экспонентами и сдвигаешь мантиссу числа с меньшей экспонентой, чтобы их выровнять.
Допустим, вычисляем 1.01 × 10^{1} - 9.93 × 10^{0}, (β = 10, p = 3)
1.01 × 10^{1} - 0.99 × 10^{1} = 0.02 × 10^{1} = 0.2 × 10^{0}, если не использовать guard digit.
1.010 × 10^{1} - 0.993 × 10^{1} = 0.017 × 10^{1} = 0.17 × 10^{0}, если добавить guard digit.
Но вроде как только одной дополнительной цифры недостаточно для максимальной точности, нужна как минимум ещё вторая дополнительная цифра round digit (видимо, чтобы округление было всегда в правильную сторону, судя по названию? возможно, нужен, потому что когда складываешь или умножаешь нормализованные флоаты, то целая часть может перевалить за 2 цифры?) Sticky bit не знаю, как определяется для произвольного β, в случае с β = 2 вроде как это просто OR всех битов, которые не уместились при сдвиге мантиссы, видимо, чтобы их тоже хотя бы как-то учесть?. Немного более подробно про это я нашёл только тут https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/flpt.apprec.html не знаю, короче.
И, как я понял, этих трёх дополнительных битов должно быть достаточно как для сингловых флоатов, так и для даблов? По крайней мере во всех теоремах про точность вычислений в статье погрешность указывается в машинных эпсилонах, то есть оно не должно зависеть от того, насколько большой сам машинный эпсилон? Вот не знаю, это, наверное, самый непонятный момент для меня.
Дальше там в статье обсуждаются разные примеры того, когда точность вычислений во флоатах может сильно пострадать. Если кратко, то
- Когда вычитаешь друг из друга два близких значения, вычисленных с погрешностью, то получаешь маленькое значение с потенциально очень большой погрешностью (что, наверное, верно не только для флоатов, а в целом в жизни, типо когда измеряешь что-то).
- Даже если финальный результат вычисления умещается во флоат, не факт, что уместятся промежуточные результаты вычислений, из-за чего можно получить вообще неправильный результат (что, наверное, верно не только для флоатов, но и для интов). И ещё, промежуточные результаты могут поместиться во флоат, но быть слишком большими, из-за чего слишком неточными. Чтобы предотвратить это при умножении, можно, например, сделать так (теорема 6): x · y = (x_h + x_l) · (y_h + y_l) = расписать как сумму из чётырёх чисел. В x_h - верхняя половина цифр из мантиссы, в x_l - нижняя. И типо после этого результат не сразу складывать, а попытаться что-нибудь ещё так разложить и сложить члены с одинаковыми экспонентами? Вроде что-то похожее можно сделать, чтобы эмулировать большие инты через маленькие?
- У флоатов нет ассоциативности. И деление не всегда обратимо даже для целых чисел, записанных во флоаты 1002.0F / 100.0F * 100.0F != 1002.0F. Но, что интересно, деление целого числа, записанного во флоате, например, на 10, вроде как почти всегда обратимо умножением на 10 (теорема 7, верно для деления на что угодно вида 2^{i} + 2^{j}, непонятно, правда, в чём смысл и как это хотя бы в теории можно использовать).
- Чем больше флоатовых операций делаешь, тем больше накапливается погрешность, из-за чего, например, вычислять (1 / x)^{n} лучше как 1 / x^{n} (потому что тогда в промежуточных вычислениях степени будет использоваться точный x, а не 1 / x, вычисленный с погрешностью). И эта проблема есть даже с вычислением суммы массива флоатов. Мне это немного ломает мозг с учётом предыдущего утверждения о том, что сумма двух флоатов вычисляется точно, но тут проблема в том, что суммируются не 2, а много флоатов, и на каждом шаге делается округление вместо того, чтобы сложить всё как вещественные числа и потом округлить к флоату. Вроде как есть такой алгоритм, который компенсирует эту погрешность https://en.wikipedia.org/wiki/Kahan_summation_algorithm я не сильно разбирался.
- Флоаты округляются к ближайшему чётному, типо смысл в том, что тогда в 50% случаев в спорной ситуации будет округление вниз, в остальных случаях - вверх. В статье есть вырожденный пример того, что может случиться, если вместо этого округлять всегда вверх (теорема 5), там итеративно прибавляется и вычитается флоат и в итоге результат постепенно смещается, а если округлять к чётным, то остаётся на месте. Интересно, можно ли подобрать такой же вырожденный пример, где бы округление к ближайшему чётному так фейлилось.
И ещё один момент, все эти разговоры о погрешностях имеют смысл только, если входные данные для вычислений - точные. Если они сами по себе вычислены с погрешностью, то не имеет смысла, например, переписывать x^{2} - y^{2} как (x - y) · (x + y), потому что сама разность x - y уже страдает от того, что в статье называется catastrophic cancellation (при условии близости x и y друг к другу), если x и y сами по себе вычислены с погрешностью.
Поэтому, наверное, все вот эти трюки имеют смысл только во всяких библиотечных функциях? В тригонометрических там, например.
Ещё там совсем немного о переводе флоатов в десятичный вид, но не даётся конкретного алгоритма. Только говорится о том, что типа 9 десятичных знаков для сингловых флоатов и 17 для даблов достаточно для того, чтобы перевести флоат в десятичный вид и обратно без потерь. Но это верхняя оценка, на практике может понадобится меньше знаков. Обоснование типо такое, что флоаты вида β = 10, p = 9 на одном и том же промежутке, что флоаты β = 2, p = 24 расположены плотнее, благодаря чему не будет ситуации, когда несколько бинарных флоатов отобразятся в один и тот же десятичный, но при этом может быть наоборот, что два разных десятичных флоата отображаются в один и тот же бинарный - отсюда потенциальная возможность выбрать более короткий вариант десятичного представления, чем 9 знаков.
А как, собственно, переводить флоат в десятичный вид я так особо и не понял. Я пытался читать эту статью https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf но я не осилил, я просто в какой-то момент перестаю понимать, что происходит, я слишком тупой. Ещё такой вариант https://blog.benoitblanchon.fr/lightweight-float-to-string но не знаю, насколько он точный. Там идея в том, чтобы отрубить у флоата экспоненту и потом дробную часть умножить на 10^{9}, привести к инту и привести к десятичному виду. А целая часть после обрубания экспоненты уже должна быть достаточно маленькой, чтобы поместиться в обычный инт. Вроде такая идея.
Тут https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 вроде бы описывается способ точно перевести флоат в десятичный. Там идея в том, чтобы представить флоат как гигантское число с фиксированной точкой (128 бит на целую часть, 149 бит на дробную), чтобы в него записать флоат (по сути достаточно на нужное в соответствии с экспонентой смещение скопировать мантиссу). И потом вроде целую часть итеративно делишь на 10, записывая остатки в целую часть результата. А дробную умножаешь на 10 с переполнением, записывая это переполнение. Типо вроде когда умножаешь в столбик, то обрубаешь всё, что вылезло слева за пределы 149 бит. Я, если честно, ни разу вроде не писал ни деление, ни умножение в столбик.
Ещё у этого же чела в комментариях нашёл про генерацию рандомных флоатов от 0 до 1 https://randomascii.wordpress.com/2012/01/11/tricks-with-the-floating-point-format/#comment-573 В общем, проблема в том, что между 0 и 0.5 флоатов больше, чем между 0.5 и 1 (только лишь между 0.25 и 0.5 их столько же, сколько между 0.5 и 1), из-за чего, если просто взять рандомный u32 и поделить его на u32_max, то на второй половине промежутка некоторые рандомные u32 будут отображаться в одни и те же флоаты, потому что там просто мантиссы не хватает, и это несимметрично с первой половиной промежутка, где флоатов больше. Ну и короче решение просто в том, чтобы обрезать u32 до 23 битов.
Я просто бы, наверное, просто изначально не подумал, что тут есть какая-то проблема, потому что я ебаный даун.
И последнее, вроде как IEEE 754 ничего не говорит о порядке байтов в записи флоатов. По крайней мере в википедии так написано https://en.wikipedia.org/wiki/Endianness#Floating_point Из-за чего в теории порядок байтов у флоатов и интов может отличаться и старший бит инта необязательно соответствует знаковому биту флоата, из-за чего мой abs может в теории не работать. Но, по-моему, всё же на большинстве компов у них порядок байтов совпадает.
- Когда вычитаешь друг из друга два близких значения, вычисленных с погрешностью, то получаешь маленькое значение с потенциально очень большой погрешностью (что, наверное, верно не только для флоатов, а в целом в жизни, типо когда измеряешь что-то).
- Даже если финальный результат вычисления умещается во флоат, не факт, что уместятся промежуточные результаты вычислений, из-за чего можно получить вообще неправильный результат (что, наверное, верно не только для флоатов, но и для интов). И ещё, промежуточные результаты могут поместиться во флоат, но быть слишком большими, из-за чего слишком неточными. Чтобы предотвратить это при умножении, можно, например, сделать так (теорема 6): x · y = (x_h + x_l) · (y_h + y_l) = расписать как сумму из чётырёх чисел. В x_h - верхняя половина цифр из мантиссы, в x_l - нижняя. И типо после этого результат не сразу складывать, а попытаться что-нибудь ещё так разложить и сложить члены с одинаковыми экспонентами? Вроде что-то похожее можно сделать, чтобы эмулировать большие инты через маленькие?
- У флоатов нет ассоциативности. И деление не всегда обратимо даже для целых чисел, записанных во флоаты 1002.0F / 100.0F * 100.0F != 1002.0F. Но, что интересно, деление целого числа, записанного во флоате, например, на 10, вроде как почти всегда обратимо умножением на 10 (теорема 7, верно для деления на что угодно вида 2^{i} + 2^{j}, непонятно, правда, в чём смысл и как это хотя бы в теории можно использовать).
- Чем больше флоатовых операций делаешь, тем больше накапливается погрешность, из-за чего, например, вычислять (1 / x)^{n} лучше как 1 / x^{n} (потому что тогда в промежуточных вычислениях степени будет использоваться точный x, а не 1 / x, вычисленный с погрешностью). И эта проблема есть даже с вычислением суммы массива флоатов. Мне это немного ломает мозг с учётом предыдущего утверждения о том, что сумма двух флоатов вычисляется точно, но тут проблема в том, что суммируются не 2, а много флоатов, и на каждом шаге делается округление вместо того, чтобы сложить всё как вещественные числа и потом округлить к флоату. Вроде как есть такой алгоритм, который компенсирует эту погрешность https://en.wikipedia.org/wiki/Kahan_summation_algorithm я не сильно разбирался.
- Флоаты округляются к ближайшему чётному, типо смысл в том, что тогда в 50% случаев в спорной ситуации будет округление вниз, в остальных случаях - вверх. В статье есть вырожденный пример того, что может случиться, если вместо этого округлять всегда вверх (теорема 5), там итеративно прибавляется и вычитается флоат и в итоге результат постепенно смещается, а если округлять к чётным, то остаётся на месте. Интересно, можно ли подобрать такой же вырожденный пример, где бы округление к ближайшему чётному так фейлилось.
И ещё один момент, все эти разговоры о погрешностях имеют смысл только, если входные данные для вычислений - точные. Если они сами по себе вычислены с погрешностью, то не имеет смысла, например, переписывать x^{2} - y^{2} как (x - y) · (x + y), потому что сама разность x - y уже страдает от того, что в статье называется catastrophic cancellation (при условии близости x и y друг к другу), если x и y сами по себе вычислены с погрешностью.
Поэтому, наверное, все вот эти трюки имеют смысл только во всяких библиотечных функциях? В тригонометрических там, например.
Ещё там совсем немного о переводе флоатов в десятичный вид, но не даётся конкретного алгоритма. Только говорится о том, что типа 9 десятичных знаков для сингловых флоатов и 17 для даблов достаточно для того, чтобы перевести флоат в десятичный вид и обратно без потерь. Но это верхняя оценка, на практике может понадобится меньше знаков. Обоснование типо такое, что флоаты вида β = 10, p = 9 на одном и том же промежутке, что флоаты β = 2, p = 24 расположены плотнее, благодаря чему не будет ситуации, когда несколько бинарных флоатов отобразятся в один и тот же десятичный, но при этом может быть наоборот, что два разных десятичных флоата отображаются в один и тот же бинарный - отсюда потенциальная возможность выбрать более короткий вариант десятичного представления, чем 9 знаков.
А как, собственно, переводить флоат в десятичный вид я так особо и не понял. Я пытался читать эту статью https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf но я не осилил, я просто в какой-то момент перестаю понимать, что происходит, я слишком тупой. Ещё такой вариант https://blog.benoitblanchon.fr/lightweight-float-to-string но не знаю, насколько он точный. Там идея в том, чтобы отрубить у флоата экспоненту и потом дробную часть умножить на 10^{9}, привести к инту и привести к десятичному виду. А целая часть после обрубания экспоненты уже должна быть достаточно маленькой, чтобы поместиться в обычный инт. Вроде такая идея.
Тут https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 вроде бы описывается способ точно перевести флоат в десятичный. Там идея в том, чтобы представить флоат как гигантское число с фиксированной точкой (128 бит на целую часть, 149 бит на дробную), чтобы в него записать флоат (по сути достаточно на нужное в соответствии с экспонентой смещение скопировать мантиссу). И потом вроде целую часть итеративно делишь на 10, записывая остатки в целую часть результата. А дробную умножаешь на 10 с переполнением, записывая это переполнение. Типо вроде когда умножаешь в столбик, то обрубаешь всё, что вылезло слева за пределы 149 бит. Я, если честно, ни разу вроде не писал ни деление, ни умножение в столбик.
Ещё у этого же чела в комментариях нашёл про генерацию рандомных флоатов от 0 до 1 https://randomascii.wordpress.com/2012/01/11/tricks-with-the-floating-point-format/#comment-573 В общем, проблема в том, что между 0 и 0.5 флоатов больше, чем между 0.5 и 1 (только лишь между 0.25 и 0.5 их столько же, сколько между 0.5 и 1), из-за чего, если просто взять рандомный u32 и поделить его на u32_max, то на второй половине промежутка некоторые рандомные u32 будут отображаться в одни и те же флоаты, потому что там просто мантиссы не хватает, и это несимметрично с первой половиной промежутка, где флоатов больше. Ну и короче решение просто в том, чтобы обрезать u32 до 23 битов.
Я просто бы, наверное, просто изначально не подумал, что тут есть какая-то проблема, потому что я ебаный даун.
И последнее, вроде как IEEE 754 ничего не говорит о порядке байтов в записи флоатов. По крайней мере в википедии так написано https://en.wikipedia.org/wiki/Endianness#Floating_point Из-за чего в теории порядок байтов у флоатов и интов может отличаться и старший бит инта необязательно соответствует знаковому биту флоата, из-за чего мой abs может в теории не работать. Но, по-моему, всё же на большинстве компов у них порядок байтов совпадает.
Дальше там в статье обсуждаются разные примеры того, когда точность вычислений во флоатах может сильно пострадать. Если кратко, то
- Когда вычитаешь друг из друга два близких значения, вычисленных с погрешностью, то получаешь маленькое значение с потенциально очень большой погрешностью (что, наверное, верно не только для флоатов, а в целом в жизни, типо когда измеряешь что-то).
- Даже если финальный результат вычисления умещается во флоат, не факт, что уместятся промежуточные результаты вычислений, из-за чего можно получить вообще неправильный результат (что, наверное, верно не только для флоатов, но и для интов). И ещё, промежуточные результаты могут поместиться во флоат, но быть слишком большими, из-за чего слишком неточными. Чтобы предотвратить это при умножении, можно, например, сделать так (теорема 6): x · y = (x_h + x_l) · (y_h + y_l) = расписать как сумму из чётырёх чисел. В x_h - верхняя половина цифр из мантиссы, в x_l - нижняя. И типо после этого результат не сразу складывать, а попытаться что-нибудь ещё так разложить и сложить члены с одинаковыми экспонентами? Вроде что-то похожее можно сделать, чтобы эмулировать большие инты через маленькие?
- У флоатов нет ассоциативности. И деление не всегда обратимо даже для целых чисел, записанных во флоаты 1002.0F / 100.0F * 100.0F != 1002.0F. Но, что интересно, деление целого числа, записанного во флоате, например, на 10, вроде как почти всегда обратимо умножением на 10 (теорема 7, верно для деления на что угодно вида 2^{i} + 2^{j}, непонятно, правда, в чём смысл и как это хотя бы в теории можно использовать).
- Чем больше флоатовых операций делаешь, тем больше накапливается погрешность, из-за чего, например, вычислять (1 / x)^{n} лучше как 1 / x^{n} (потому что тогда в промежуточных вычислениях степени будет использоваться точный x, а не 1 / x, вычисленный с погрешностью). И эта проблема есть даже с вычислением суммы массива флоатов. Мне это немного ломает мозг с учётом предыдущего утверждения о том, что сумма двух флоатов вычисляется точно, но тут проблема в том, что суммируются не 2, а много флоатов, и на каждом шаге делается округление вместо того, чтобы сложить всё как вещественные числа и потом округлить к флоату. Вроде как есть такой алгоритм, который компенсирует эту погрешность https://en.wikipedia.org/wiki/Kahan_summation_algorithm я не сильно разбирался.
- Флоаты округляются к ближайшему чётному, типо смысл в том, что тогда в 50% случаев в спорной ситуации будет округление вниз, в остальных случаях - вверх. В статье есть вырожденный пример того, что может случиться, если вместо этого округлять всегда вверх (теорема 5), там итеративно прибавляется и вычитается флоат и в итоге результат постепенно смещается, а если округлять к чётным, то остаётся на месте. Интересно, можно ли подобрать такой же вырожденный пример, где бы округление к ближайшему чётному так фейлилось.
И ещё один момент, все эти разговоры о погрешностях имеют смысл только, если входные данные для вычислений - точные. Если они сами по себе вычислены с погрешностью, то не имеет смысла, например, переписывать x^{2} - y^{2} как (x - y) · (x + y), потому что сама разность x - y уже страдает от того, что в статье называется catastrophic cancellation (при условии близости x и y друг к другу), если x и y сами по себе вычислены с погрешностью.
Поэтому, наверное, все вот эти трюки имеют смысл только во всяких библиотечных функциях? В тригонометрических там, например.
Ещё там совсем немного о переводе флоатов в десятичный вид, но не даётся конкретного алгоритма. Только говорится о том, что типа 9 десятичных знаков для сингловых флоатов и 17 для даблов достаточно для того, чтобы перевести флоат в десятичный вид и обратно без потерь. Но это верхняя оценка, на практике может понадобится меньше знаков. Обоснование типо такое, что флоаты вида β = 10, p = 9 на одном и том же промежутке, что флоаты β = 2, p = 24 расположены плотнее, благодаря чему не будет ситуации, когда несколько бинарных флоатов отобразятся в один и тот же десятичный, но при этом может быть наоборот, что два разных десятичных флоата отображаются в один и тот же бинарный - отсюда потенциальная возможность выбрать более короткий вариант десятичного представления, чем 9 знаков.
А как, собственно, переводить флоат в десятичный вид я так особо и не понял. Я пытался читать эту статью https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf но я не осилил, я просто в какой-то момент перестаю понимать, что происходит, я слишком тупой. Ещё такой вариант https://blog.benoitblanchon.fr/lightweight-float-to-string но не знаю, насколько он точный. Там идея в том, чтобы отрубить у флоата экспоненту и потом дробную часть умножить на 10^{9}, привести к инту и привести к десятичному виду. А целая часть после обрубания экспоненты уже должна быть достаточно маленькой, чтобы поместиться в обычный инт. Вроде такая идея.
Тут https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 вроде бы описывается способ точно перевести флоат в десятичный. Там идея в том, чтобы представить флоат как гигантское число с фиксированной точкой (128 бит на целую часть, 149 бит на дробную), чтобы в него записать флоат (по сути достаточно на нужное в соответствии с экспонентой смещение скопировать мантиссу). И потом вроде целую часть итеративно делишь на 10, записывая остатки в целую часть результата. А дробную умножаешь на 10 с переполнением, записывая это переполнение. Типо вроде когда умножаешь в столбик, то обрубаешь всё, что вылезло слева за пределы 149 бит. Я, если честно, ни разу вроде не писал ни деление, ни умножение в столбик.
Ещё у этого же чела в комментариях нашёл про генерацию рандомных флоатов от 0 до 1 https://randomascii.wordpress.com/2012/01/11/tricks-with-the-floating-point-format/#comment-573 В общем, проблема в том, что между 0 и 0.5 флоатов больше, чем между 0.5 и 1 (только лишь между 0.25 и 0.5 их столько же, сколько между 0.5 и 1), из-за чего, если просто взять рандомный u32 и поделить его на u32_max, то на второй половине промежутка некоторые рандомные u32 будут отображаться в одни и те же флоаты, потому что там просто мантиссы не хватает, и это несимметрично с первой половиной промежутка, где флоатов больше. Ну и короче решение просто в том, чтобы обрезать u32 до 23 битов.
Я просто бы, наверное, просто изначально не подумал, что тут есть какая-то проблема, потому что я ебаный даун.
И последнее, вроде как IEEE 754 ничего не говорит о порядке байтов в записи флоатов. По крайней мере в википедии так написано https://en.wikipedia.org/wiki/Endianness#Floating_point Из-за чего в теории порядок байтов у флоатов и интов может отличаться и старший бит инта необязательно соответствует знаковому биту флоата, из-за чего мой abs может в теории не работать. Но, по-моему, всё же на большинстве компов у них порядок байтов совпадает.
- Когда вычитаешь друг из друга два близких значения, вычисленных с погрешностью, то получаешь маленькое значение с потенциально очень большой погрешностью (что, наверное, верно не только для флоатов, а в целом в жизни, типо когда измеряешь что-то).
- Даже если финальный результат вычисления умещается во флоат, не факт, что уместятся промежуточные результаты вычислений, из-за чего можно получить вообще неправильный результат (что, наверное, верно не только для флоатов, но и для интов). И ещё, промежуточные результаты могут поместиться во флоат, но быть слишком большими, из-за чего слишком неточными. Чтобы предотвратить это при умножении, можно, например, сделать так (теорема 6): x · y = (x_h + x_l) · (y_h + y_l) = расписать как сумму из чётырёх чисел. В x_h - верхняя половина цифр из мантиссы, в x_l - нижняя. И типо после этого результат не сразу складывать, а попытаться что-нибудь ещё так разложить и сложить члены с одинаковыми экспонентами? Вроде что-то похожее можно сделать, чтобы эмулировать большие инты через маленькие?
- У флоатов нет ассоциативности. И деление не всегда обратимо даже для целых чисел, записанных во флоаты 1002.0F / 100.0F * 100.0F != 1002.0F. Но, что интересно, деление целого числа, записанного во флоате, например, на 10, вроде как почти всегда обратимо умножением на 10 (теорема 7, верно для деления на что угодно вида 2^{i} + 2^{j}, непонятно, правда, в чём смысл и как это хотя бы в теории можно использовать).
- Чем больше флоатовых операций делаешь, тем больше накапливается погрешность, из-за чего, например, вычислять (1 / x)^{n} лучше как 1 / x^{n} (потому что тогда в промежуточных вычислениях степени будет использоваться точный x, а не 1 / x, вычисленный с погрешностью). И эта проблема есть даже с вычислением суммы массива флоатов. Мне это немного ломает мозг с учётом предыдущего утверждения о том, что сумма двух флоатов вычисляется точно, но тут проблема в том, что суммируются не 2, а много флоатов, и на каждом шаге делается округление вместо того, чтобы сложить всё как вещественные числа и потом округлить к флоату. Вроде как есть такой алгоритм, который компенсирует эту погрешность https://en.wikipedia.org/wiki/Kahan_summation_algorithm я не сильно разбирался.
- Флоаты округляются к ближайшему чётному, типо смысл в том, что тогда в 50% случаев в спорной ситуации будет округление вниз, в остальных случаях - вверх. В статье есть вырожденный пример того, что может случиться, если вместо этого округлять всегда вверх (теорема 5), там итеративно прибавляется и вычитается флоат и в итоге результат постепенно смещается, а если округлять к чётным, то остаётся на месте. Интересно, можно ли подобрать такой же вырожденный пример, где бы округление к ближайшему чётному так фейлилось.
И ещё один момент, все эти разговоры о погрешностях имеют смысл только, если входные данные для вычислений - точные. Если они сами по себе вычислены с погрешностью, то не имеет смысла, например, переписывать x^{2} - y^{2} как (x - y) · (x + y), потому что сама разность x - y уже страдает от того, что в статье называется catastrophic cancellation (при условии близости x и y друг к другу), если x и y сами по себе вычислены с погрешностью.
Поэтому, наверное, все вот эти трюки имеют смысл только во всяких библиотечных функциях? В тригонометрических там, например.
Ещё там совсем немного о переводе флоатов в десятичный вид, но не даётся конкретного алгоритма. Только говорится о том, что типа 9 десятичных знаков для сингловых флоатов и 17 для даблов достаточно для того, чтобы перевести флоат в десятичный вид и обратно без потерь. Но это верхняя оценка, на практике может понадобится меньше знаков. Обоснование типо такое, что флоаты вида β = 10, p = 9 на одном и том же промежутке, что флоаты β = 2, p = 24 расположены плотнее, благодаря чему не будет ситуации, когда несколько бинарных флоатов отобразятся в один и тот же десятичный, но при этом может быть наоборот, что два разных десятичных флоата отображаются в один и тот же бинарный - отсюда потенциальная возможность выбрать более короткий вариант десятичного представления, чем 9 знаков.
А как, собственно, переводить флоат в десятичный вид я так особо и не понял. Я пытался читать эту статью https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf но я не осилил, я просто в какой-то момент перестаю понимать, что происходит, я слишком тупой. Ещё такой вариант https://blog.benoitblanchon.fr/lightweight-float-to-string но не знаю, насколько он точный. Там идея в том, чтобы отрубить у флоата экспоненту и потом дробную часть умножить на 10^{9}, привести к инту и привести к десятичному виду. А целая часть после обрубания экспоненты уже должна быть достаточно маленькой, чтобы поместиться в обычный инт. Вроде такая идея.
Тут https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 вроде бы описывается способ точно перевести флоат в десятичный. Там идея в том, чтобы представить флоат как гигантское число с фиксированной точкой (128 бит на целую часть, 149 бит на дробную), чтобы в него записать флоат (по сути достаточно на нужное в соответствии с экспонентой смещение скопировать мантиссу). И потом вроде целую часть итеративно делишь на 10, записывая остатки в целую часть результата. А дробную умножаешь на 10 с переполнением, записывая это переполнение. Типо вроде когда умножаешь в столбик, то обрубаешь всё, что вылезло слева за пределы 149 бит. Я, если честно, ни разу вроде не писал ни деление, ни умножение в столбик.
Ещё у этого же чела в комментариях нашёл про генерацию рандомных флоатов от 0 до 1 https://randomascii.wordpress.com/2012/01/11/tricks-with-the-floating-point-format/#comment-573 В общем, проблема в том, что между 0 и 0.5 флоатов больше, чем между 0.5 и 1 (только лишь между 0.25 и 0.5 их столько же, сколько между 0.5 и 1), из-за чего, если просто взять рандомный u32 и поделить его на u32_max, то на второй половине промежутка некоторые рандомные u32 будут отображаться в одни и те же флоаты, потому что там просто мантиссы не хватает, и это несимметрично с первой половиной промежутка, где флоатов больше. Ну и короче решение просто в том, чтобы обрезать u32 до 23 битов.
Я просто бы, наверное, просто изначально не подумал, что тут есть какая-то проблема, потому что я ебаный даун.
И последнее, вроде как IEEE 754 ничего не говорит о порядке байтов в записи флоатов. По крайней мере в википедии так написано https://en.wikipedia.org/wiki/Endianness#Floating_point Из-за чего в теории порядок байтов у флоатов и интов может отличаться и старший бит инта необязательно соответствует знаковому биту флоата, из-за чего мой abs может в теории не работать. Но, по-моему, всё же на большинстве компов у них порядок байтов совпадает.
Я чего-то заметил, что под виндой, если клангом компилировать напрямую без прокладки в виде симейка, то он выдаёт более крупные экзешники (на ~100 дополнительных килобайтов), чем те, что получаются с симейком. Короче, проблема в том, что по дефолту он тебе в экзешник добавляет кучу какого-то непонятного кода и реализации некоторых функций из стандартной библиотеки. Видимо, это всё часть сишного рантайма, ну как минимум для парсинга аргументов из командной строки что ли?
А симейк по дефолту линкует весь этот код динамически + использует ucrt через параметр `-Xclang --dependent-lib=msvcrt`. Тут по размеру получается совсем немного больше, чем с -nostdlib. Мне не то чтобы есть дело до того, что экзешник на 100 килобайтов больше или меньше, но типо я просто не понимал, почему у симейка получается меньше размер. Но, с другой стороны, такой экзешник, наверное, не будет работать на винде, где нету ucrt, плюс типичные дебильные ошибки с тем, что не найден vcruntime какой-то версии.
Я, наверное, разучился пользоваться гуглом, но я не понимаю, откуда я вообще должен узнать, что мне надо добавить этот магический параметр и что он означает. Особенно с учётом того, что как будто более очевидное решение передать в линкер `/defaultlib:ucrt.lib` тупо не работает и выдаёт какие-то стрёмные duplicate symbol ошибки.
Если полностью отказываться от линкования с сишной библиотекой на винде, то достаточно просто определить memcpy и memset и поменять main на mainCRTStartup (если subsystem console). Вызовы memset и memcpy компилятор (по крайней мере кланг точно) может сам вставлять в сгенерированный код, поэтому они нужны. Такое есть в том числе в расте, там есть даже отдельная библиотека со всеми подобными функциями https://github.com/rust-lang/compiler-builtins Для x86 ещё какие-то детали с выравниванием стека есть https://nullprogram.com/blog/2023/02/15/#stack-alignment-on-32-bit-x86
Ещё на винде может понадобиться функция chkstk https://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function но вроде кланг сам что-то делает с троганьем стека и не нужно её определять.
Меня ещё просто бесит симейк и я его использую только из-за того, что он генерирует compile_commands.json (там просто описание как компилировать все юниты), который использует clangd в основном, чтобы знать дефайны, где хедеры лежат и другие параметры компилятора. Может быть, можно его и вручную попробовать генерировать. А так я бы, может быть, просто одной командой все файлы каждый раз бы компилировал.
А симейк по дефолту линкует весь этот код динамически + использует ucrt через параметр `-Xclang --dependent-lib=msvcrt`. Тут по размеру получается совсем немного больше, чем с -nostdlib. Мне не то чтобы есть дело до того, что экзешник на 100 килобайтов больше или меньше, но типо я просто не понимал, почему у симейка получается меньше размер. Но, с другой стороны, такой экзешник, наверное, не будет работать на винде, где нету ucrt, плюс типичные дебильные ошибки с тем, что не найден vcruntime какой-то версии.
Я, наверное, разучился пользоваться гуглом, но я не понимаю, откуда я вообще должен узнать, что мне надо добавить этот магический параметр и что он означает. Особенно с учётом того, что как будто более очевидное решение передать в линкер `/defaultlib:ucrt.lib` тупо не работает и выдаёт какие-то стрёмные duplicate symbol ошибки.
Если полностью отказываться от линкования с сишной библиотекой на винде, то достаточно просто определить memcpy и memset и поменять main на mainCRTStartup (если subsystem console). Вызовы memset и memcpy компилятор (по крайней мере кланг точно) может сам вставлять в сгенерированный код, поэтому они нужны. Такое есть в том числе в расте, там есть даже отдельная библиотека со всеми подобными функциями https://github.com/rust-lang/compiler-builtins Для x86 ещё какие-то детали с выравниванием стека есть https://nullprogram.com/blog/2023/02/15/#stack-alignment-on-32-bit-x86
Ещё на винде может понадобиться функция chkstk https://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function но вроде кланг сам что-то делает с троганьем стека и не нужно её определять.
Меня ещё просто бесит симейк и я его использую только из-за того, что он генерирует compile_commands.json (там просто описание как компилировать все юниты), который использует clangd в основном, чтобы знать дефайны, где хедеры лежат и другие параметры компилятора. Может быть, можно его и вручную попробовать генерировать. А так я бы, может быть, просто одной командой все файлы каждый раз бы компилировал.
Я чего-то заметил, что под виндой, если клангом компилировать напрямую без прокладки в виде симейка, то он выдаёт более крупные экзешники (на ~100 дополнительных килобайтов), чем те, что получаются с симейком. Короче, проблема в том, что по дефолту он тебе в экзешник добавляет кучу какого-то непонятного кода и реализации некоторых функций из стандартной библиотеки. Видимо, это всё часть сишного рантайма, ну как минимум для парсинга аргументов из командной строки что ли?
А симейк по дефолту линкует весь этот код динамически + использует ucrt через параметр `-Xclang --dependent-lib=msvcrt`. Тут по размеру получается совсем немного больше, чем с -nostdlib. Мне не то чтобы есть дело до того, что экзешник на 100 килобайтов больше или меньше, но типо я просто не понимал, почему у симейка получается меньше размер. Но, с другой стороны, такой экзешник, наверное, не будет работать на винде, где нету ucrt, плюс типичные дебильные ошибки с тем, что не найден vcruntime какой-то версии.
Я, наверное, разучился пользоваться гуглом, но я не понимаю, откуда я вообще должен узнать, что мне надо добавить этот магический параметр и что он означает. Особенно с учётом того, что как будто более очевидное решение передать в линкер `/defaultlib:ucrt.lib` тупо не работает и выдаёт какие-то стрёмные duplicate symbol ошибки.
Если полностью отказываться от линкования с сишной библиотекой на винде, то достаточно просто определить memcpy и memset и поменять main на mainCRTStartup (если subsystem console). Вызовы memset и memcpy компилятор (по крайней мере кланг точно) может сам вставлять в сгенерированный код, поэтому они нужны. Такое есть в том числе в расте, там есть даже отдельная библиотека со всеми подобными функциями https://github.com/rust-lang/compiler-builtins Для x86 ещё какие-то детали с выравниванием стека есть https://nullprogram.com/blog/2023/02/15/#stack-alignment-on-32-bit-x86
Ещё на винде может понадобиться функция chkstk https://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function но вроде кланг сам что-то делает с троганьем стека и не нужно её определять.
Меня ещё просто бесит симейк и я его использую только из-за того, что он генерирует compile_commands.json (там просто описание как компилировать все юниты), который использует clangd в основном, чтобы знать дефайны, где хедеры лежат и другие параметры компилятора. Может быть, можно его и вручную попробовать генерировать. А так я бы, может быть, просто одной командой все файлы каждый раз бы компилировал.
А симейк по дефолту линкует весь этот код динамически + использует ucrt через параметр `-Xclang --dependent-lib=msvcrt`. Тут по размеру получается совсем немного больше, чем с -nostdlib. Мне не то чтобы есть дело до того, что экзешник на 100 килобайтов больше или меньше, но типо я просто не понимал, почему у симейка получается меньше размер. Но, с другой стороны, такой экзешник, наверное, не будет работать на винде, где нету ucrt, плюс типичные дебильные ошибки с тем, что не найден vcruntime какой-то версии.
Я, наверное, разучился пользоваться гуглом, но я не понимаю, откуда я вообще должен узнать, что мне надо добавить этот магический параметр и что он означает. Особенно с учётом того, что как будто более очевидное решение передать в линкер `/defaultlib:ucrt.lib` тупо не работает и выдаёт какие-то стрёмные duplicate symbol ошибки.
Если полностью отказываться от линкования с сишной библиотекой на винде, то достаточно просто определить memcpy и memset и поменять main на mainCRTStartup (если subsystem console). Вызовы memset и memcpy компилятор (по крайней мере кланг точно) может сам вставлять в сгенерированный код, поэтому они нужны. Такое есть в том числе в расте, там есть даже отдельная библиотека со всеми подобными функциями https://github.com/rust-lang/compiler-builtins Для x86 ещё какие-то детали с выравниванием стека есть https://nullprogram.com/blog/2023/02/15/#stack-alignment-on-32-bit-x86
Ещё на винде может понадобиться функция chkstk https://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function но вроде кланг сам что-то делает с троганьем стека и не нужно её определять.
Меня ещё просто бесит симейк и я его использую только из-за того, что он генерирует compile_commands.json (там просто описание как компилировать все юниты), который использует clangd в основном, чтобы знать дефайны, где хедеры лежат и другие параметры компилятора. Может быть, можно его и вручную попробовать генерировать. А так я бы, может быть, просто одной командой все файлы каждый раз бы компилировал.
158 Кб, 828x892Земленика
Но там всего лишь штук 10 ягод на пакет в 100 граммов и у ароматизатора слишком приторный запах какой-то. У меня изначально сложилось неоправданно положительное впечатление от ароматизированных чаёв из-за того, что первым попался очень вкусно пахнущий. А все последующие, что пробовал, были в лучшем случае терпимыми. Может быть, лучше пить без ароматизаторов и купить каких-нибудь сублимированных ягод. Не знаю, будут ли они сами по себе хотя бы запах давать в чае, не пробовал ни разу.
Но там всего лишь штук 10 ягод на пакет в 100 граммов и у ароматизатора слишком приторный запах какой-то. У меня изначально сложилось неоправданно положительное впечатление от ароматизированных чаёв из-за того, что первым попался очень вкусно пахнущий. А все последующие, что пробовал, были в лучшем случае терпимыми. Может быть, лучше пить без ароматизаторов и купить каких-нибудь сублимированных ягод. Не знаю, будут ли они сами по себе хотя бы запах давать в чае, не пробовал ни разу.
6,4 Мб, webm,960x1034, 1:37
https://zingl.github.io/bresenham.html#line он такой компактный и элегантный, он выбирает пиксель с самым маленьким |f(x, y)|, но там ещё по-умному раскрываются модули. Слишком мало iq, чтобы понять остальные
Недостаточно просто после клиппинга нарисовать с нуля линию между клипнутыми точками, нужно сохранить наклон старой линии + инициализировать брезенхама в состояние такое, как будто он сам дошёл до пикселя, с которого начинаешь рисовать. Иначе клипнутая линия не будет совпадать с оригинальной
https://en.wikipedia.org/wiki/Cohen–Sutherland_algorithm это типа самый тупой вариант, вроде можно умнее, но я не смотрел и сам не придумаю потому что я ебаный даун
https://git.musl-libc.org/cgit/musl/tree/src/math/floorf.c избегают того, чтобы просто взять и сделать каст к инту и обратно, вместо этого находят, где запятая и вручную делают -1 для отрицательных нецелых, вручную зануляют биты мантиссы
Я не знаю, как должен выглядеть ui код, пока что бред какой-то получается
Я как-то не задумывался, что можно сделать round просто через целочисленное деление, если просто (делимое + делитель / 2) / делитель, но если учитывать отрицательные числа, то получится слишком громоздко, тогда неинтересно
Из CMAKE_C_FLAGS_DEBUG и CMAKE_C_FLAGS_RELEASE убрать все дефолтные флаги и прописывать все флаги вручную. Для мультиконфиг билдов нужно это https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html потому что на момент конфигурации ты не знаешь, билдишь релиз или дебаг и не можешь просто сделать if(CMAKE_BUILD_TYPE ...). add_compile_options и add_link_options зачем-то выпиливают дубликаты флагов. Нужно делать, например, add_compile_options("SHELL:-Xlinker ..." "SHELL:-Xlinker ..."), иначе он выпилит второй -Xlinker.
Пытаться настроить симейк - ещё более бесполезное занятие, чем сидеть писать конфиги к текстовому редактору
Недостаточно просто после клиппинга нарисовать с нуля линию между клипнутыми точками, нужно сохранить наклон старой линии + инициализировать брезенхама в состояние такое, как будто он сам дошёл до пикселя, с которого начинаешь рисовать. Иначе клипнутая линия не будет совпадать с оригинальной
https://en.wikipedia.org/wiki/Cohen–Sutherland_algorithm это типа самый тупой вариант, вроде можно умнее, но я не смотрел и сам не придумаю потому что я ебаный даун
https://git.musl-libc.org/cgit/musl/tree/src/math/floorf.c избегают того, чтобы просто взять и сделать каст к инту и обратно, вместо этого находят, где запятая и вручную делают -1 для отрицательных нецелых, вручную зануляют биты мантиссы
Я не знаю, как должен выглядеть ui код, пока что бред какой-то получается
Я как-то не задумывался, что можно сделать round просто через целочисленное деление, если просто (делимое + делитель / 2) / делитель, но если учитывать отрицательные числа, то получится слишком громоздко, тогда неинтересно
Из CMAKE_C_FLAGS_DEBUG и CMAKE_C_FLAGS_RELEASE убрать все дефолтные флаги и прописывать все флаги вручную. Для мультиконфиг билдов нужно это https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html потому что на момент конфигурации ты не знаешь, билдишь релиз или дебаг и не можешь просто сделать if(CMAKE_BUILD_TYPE ...). add_compile_options и add_link_options зачем-то выпиливают дубликаты флагов. Нужно делать, например, add_compile_options("SHELL:-Xlinker ..." "SHELL:-Xlinker ..."), иначе он выпилит второй -Xlinker.
Пытаться настроить симейк - ещё более бесполезное занятие, чем сидеть писать конфиги к текстовому редактору
11 Кб, 400x300Я пробовал добавлять сублимированную клубнику и смородину в чай, но они не дают ни вкуса, ни запаха, а просто размокают, но есть их интереснее сухими. Ещё в морозилке валяются какие-то замороженные ягоды, но, я думаю, проще просто умереть
1,1 Мб, webm,960x1034, 0:08
Купил эрл грей, потому что просто слышал название, оказалось, что он с какими-то цитрусовыми кожурками и пахнет омерзительно, теперь мне его пить непонятно сколько времени, пока не закончится
Ничего не понимаю, что я делаю. Типа совсем, я не понимал, почему mov из памяти в регистр не работает (нету версии mov из 8-байтового immediate адреса и, видимо, нужно либо относительный адрес делать, либо в регистр абсолютный адрес класть).
И что некоторые операции над младшими кусками регистров зануляют верхние, в том числе у xmm. Но только некоторые, mov al, например, остальные байты не трогает. Поэтому, видимо, если функция, возвращает bool, то проверять нужно именно al, а не rax целиком
И что на винде перед вызовом функций нужно на стеке выделить как минимум 32 байта, но я не понял, зачем. И что стек должен быть выровнен на 16 байт перед вызовом функций, но в начале функции он сдвинут на 8 байт из-за того, что call запушил адрес, куда возвращаться
Квадраты рисую не я, и даже нахождение внутри квадрата не я проверяю, это вот это https://www.raylib.com/cheatsheet/cheatsheet.html Виндовое ABI вроде более-менее простое
Ничего не понимаю, что я делаю. Типа совсем, я не понимал, почему mov из памяти в регистр не работает (нету версии mov из 8-байтового immediate адреса и, видимо, нужно либо относительный адрес делать, либо в регистр абсолютный адрес класть).
И что некоторые операции над младшими кусками регистров зануляют верхние, в том числе у xmm. Но только некоторые, mov al, например, остальные байты не трогает. Поэтому, видимо, если функция, возвращает bool, то проверять нужно именно al, а не rax целиком
И что на винде перед вызовом функций нужно на стеке выделить как минимум 32 байта, но я не понял, зачем. И что стек должен быть выровнен на 16 байт перед вызовом функций, но в начале функции он сдвинут на 8 байт из-за того, что call запушил адрес, куда возвращаться
Квадраты рисую не я, и даже нахождение внутри квадрата не я проверяю, это вот это https://www.raylib.com/cheatsheet/cheatsheet.html Виндовое ABI вроде более-менее простое
1,7 Мб, mp4,824x574, 0:06
Я ничего не делал ни вчера, ни сегодня, ни в чём не вижу смысла, нету смысла жить, ничего хорошего никогда не будет
285 Кб, 1080x1350https://youtu.be/JtgQJT08J1g?t=2003 прикольное видео, короче там примерно те же идеи используются, что и тут для прямых >>737395 когда раскрываются модули в неравенстве, когда выбирается, какая следующая точка ближе к линии, которую рисуешь. Я это имел в виду тогда, но в контексте прямых
И прикольная идея с тем, что можно несколько раз применить DDA. Типо, что если вычисляем функцию f(x, y) для последовательных точек, прибавляя постепенно D(x, y) = f(x + 1, y) - f(x, y), то эту D(x, y) можно тоже вычислять так последовательно что-нибудь прибавляя.
Я не знаю, как сделать клиппинг для окружностей. Я нагуглил только это https://theswissbay.ch/pdf/Gentoomen%20Library/Game%20Development/Programming/Graphics%20Gems%203.pdf (IV.3 A fast circle clipping algorithm), но это как будто бред какой-то бессодержательный, арккосинусы ещё зачем-то
Типо просто наивно найти точки пересечения прямоугольника и окружности, наверное, и нарисовать видимые куски. Для нахождения точек пересечения с точностью до пикселя нужен квадратный корень с округлением к ближайшему целому. Тут https://en.wikipedia.org/wiki/Integer_square_root#Algorithm_using_Newton's_method пишут, что для округления вниз метод Ньютона для квадратного корня достаточно остановить в момент, когда |x_{k+1} - x_k| < 1 и вернуть floor(x_{k+1}) как результат.
Для округления до ближайшего целого вроде как достаточно остановиться в момент |x_{k+1} - x_k| < 0.5 и вернуть round(x_{k+1}), но я не понимаю, как это формально доказать. Я не понимаю, как с погрешностью связана эта разность предыдущего и следующего приближений
У меня чувство, что по крайней мере залитые одним цветом круги проще рисовать просто проходясь по всем пикселям внутри квадрата
И прикольная идея с тем, что можно несколько раз применить DDA. Типо, что если вычисляем функцию f(x, y) для последовательных точек, прибавляя постепенно D(x, y) = f(x + 1, y) - f(x, y), то эту D(x, y) можно тоже вычислять так последовательно что-нибудь прибавляя.
Я не знаю, как сделать клиппинг для окружностей. Я нагуглил только это https://theswissbay.ch/pdf/Gentoomen%20Library/Game%20Development/Programming/Graphics%20Gems%203.pdf (IV.3 A fast circle clipping algorithm), но это как будто бред какой-то бессодержательный, арккосинусы ещё зачем-то
Типо просто наивно найти точки пересечения прямоугольника и окружности, наверное, и нарисовать видимые куски. Для нахождения точек пересечения с точностью до пикселя нужен квадратный корень с округлением к ближайшему целому. Тут https://en.wikipedia.org/wiki/Integer_square_root#Algorithm_using_Newton's_method пишут, что для округления вниз метод Ньютона для квадратного корня достаточно остановить в момент, когда |x_{k+1} - x_k| < 1 и вернуть floor(x_{k+1}) как результат.
Для округления до ближайшего целого вроде как достаточно остановиться в момент |x_{k+1} - x_k| < 0.5 и вернуть round(x_{k+1}), но я не понимаю, как это формально доказать. Я не понимаю, как с погрешностью связана эта разность предыдущего и следующего приближений
У меня чувство, что по крайней мере залитые одним цветом круги проще рисовать просто проходясь по всем пикселям внутри квадрата
1,3 Мб, mp4,960x1032, 0:09
Я хотел типо нарисовать крестик через triangle fan и чтобы можно было независимо менять ширину и длину палок, чтобы типа можно было сделать анимацию появления. Нарисовать анимированный нолик будет проще, потому что есть просто это https://www.raylib.com/examples/shapes/loader.html?name=shapes_draw_ring Но я не знаю, буду ли я дальше делать, мне слишком тяжело чего-то
Но в самом triangle fan в контексте рейлиба смысла мало, потому что DrawTriangleFan на самом деле в любом случае там куда-то внутри себя собирает вершины треугольников, чтобы когда-то потом в одном батче их все нарисовать. И там внутри нигде не используется GL_TRIANGLE_FAN, не делается ничего через рестарт индекс.
Я не ожидал, что в xmm похоже вообще нельзя загружать immediate значения, только из памяти или из других регистров. То есть приходится придумывать названия для каждой константы. И что пользоваться fpu сложнее, чем другими инструкциями: там какой-то свой отдельный стек, в который ты пушишь аргументы, делаешь операции и потом достаёшь результат. И похоже, что доставать/класть аргументы можно только промежуточно положив их в память, нельзя из обычного регистра положить что-то на fpu стек или наоборот перенести из fpu стека в регистр.
И я всё ещё не понимаю, как прочитать в регистр что-то по абсолютному 64-битному адресу, nasm обрезает адрес до 32 бит и sign экстендит эту половину до 64 бит, когда я пишу "mov r, [abs qword label]". При этом как будто бы оно существует "Move r/m64 to r64" https://www.felixcloutier.com/x86/mov но почему у меня ничего не получается. И не получается даже через lea положить в регистр абсолютный адрес, там то же самое.
И адресовать массив, расположенный в data секции, я тоже не понимаю как (ну типа label + регистр умножить на размер элемента), у меня тоже ничего не работает
Но в самом triangle fan в контексте рейлиба смысла мало, потому что DrawTriangleFan на самом деле в любом случае там куда-то внутри себя собирает вершины треугольников, чтобы когда-то потом в одном батче их все нарисовать. И там внутри нигде не используется GL_TRIANGLE_FAN, не делается ничего через рестарт индекс.
Я не ожидал, что в xmm похоже вообще нельзя загружать immediate значения, только из памяти или из других регистров. То есть приходится придумывать названия для каждой константы. И что пользоваться fpu сложнее, чем другими инструкциями: там какой-то свой отдельный стек, в который ты пушишь аргументы, делаешь операции и потом достаёшь результат. И похоже, что доставать/класть аргументы можно только промежуточно положив их в память, нельзя из обычного регистра положить что-то на fpu стек или наоборот перенести из fpu стека в регистр.
И я всё ещё не понимаю, как прочитать в регистр что-то по абсолютному 64-битному адресу, nasm обрезает адрес до 32 бит и sign экстендит эту половину до 64 бит, когда я пишу "mov r, [abs qword label]". При этом как будто бы оно существует "Move r/m64 to r64" https://www.felixcloutier.com/x86/mov но почему у меня ничего не получается. И не получается даже через lea положить в регистр абсолютный адрес, там то же самое.
И адресовать массив, расположенный в data секции, я тоже не понимаю как (ну типа label + регистр умножить на размер элемента), у меня тоже ничего не работает
738 Кб, 909x1400>>738389
Не нужно читать по абсолютным 64-битным адресам, доступ к глобальным переменным в x64 почти всегда (когда их меньше 2 Гб; PE EXE в Windows >2 Гб принципиально не поддерживает, и нормально) делается как RIP-relative. Если нужно больше 2 Гб (не нужно, такое нужно динамически выделять и из внешнего файла загружать), есть модели с «абсолютными» адресами: https://wiki.osdev.org/X86-64#Text_Segment_Types, https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models, я не знаю, как они работают, но по логике ты кладёшь адреса в регистр через mov r64, imm64, И — это важно — добавляешь эту инструкцию в relocations, чтобы загрузчик в условиях ASLR и прочего поменял адрес в этой инструкции на настоящий. В “FPC-flavored GNU assembler” это каким-то таким заклинанием делается: https://gitlab.com/freepascal.org/fpc/source/-/blob/139f2dfe84cf07d03e461e50097a426cd88a0797/rtl/x86_64/x86_64.inc#L341 (помещаем адрес переменной fast_large_repmovstosb: boolean в r9 через mov r64, imm64 с добавлением этой инструкции в список релокаций, затем работаем по адресу в r9), в NASM тоже гуглится что-то на тему got / gotpcrel. Короче говоря, лучше не вскрывать эту тему, смысл RIP-relative как раз в том, что фишка напрямую поддерживается набором инструкций, позиционно-независимый код без необходимости вписывать правильные адреса получается автоматически, а 2 (4?) Гб хватит всем.
Чтобы «адресовать массив, расположенный в data-секции», ты сначала помещаешь его адрес в регистр соответствующим способом (RIP-relative — lea reg, [rel arr]; это отдельный способ адресации, несовместимый с base + index × scale в рамках одной и той же инструкции, размечтался), и уже потом используешь его как base в base + index × scale.
Не нужно читать по абсолютным 64-битным адресам, доступ к глобальным переменным в x64 почти всегда (когда их меньше 2 Гб; PE EXE в Windows >2 Гб принципиально не поддерживает, и нормально) делается как RIP-relative. Если нужно больше 2 Гб (не нужно, такое нужно динамически выделять и из внешнего файла загружать), есть модели с «абсолютными» адресами: https://wiki.osdev.org/X86-64#Text_Segment_Types, https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models, я не знаю, как они работают, но по логике ты кладёшь адреса в регистр через mov r64, imm64, И — это важно — добавляешь эту инструкцию в relocations, чтобы загрузчик в условиях ASLR и прочего поменял адрес в этой инструкции на настоящий. В “FPC-flavored GNU assembler” это каким-то таким заклинанием делается: https://gitlab.com/freepascal.org/fpc/source/-/blob/139f2dfe84cf07d03e461e50097a426cd88a0797/rtl/x86_64/x86_64.inc#L341 (помещаем адрес переменной fast_large_repmovstosb: boolean в r9 через mov r64, imm64 с добавлением этой инструкции в список релокаций, затем работаем по адресу в r9), в NASM тоже гуглится что-то на тему got / gotpcrel. Короче говоря, лучше не вскрывать эту тему, смысл RIP-relative как раз в том, что фишка напрямую поддерживается набором инструкций, позиционно-независимый код без необходимости вписывать правильные адреса получается автоматически, а 2 (4?) Гб хватит всем.
Чтобы «адресовать массив, расположенный в data-секции», ты сначала помещаешь его адрес в регистр соответствующим способом (RIP-relative — lea reg, [rel arr]; это отдельный способ адресации, несовместимый с base + index × scale в рамках одной и той же инструкции, размечтался), и уже потом используешь его как base в base + index × scale.
305 Кб, 638x765Дизайн украл
807 Кб, 1564x2048>>738399
Ну да, понятно вообщем спасибо, у меня как-то не зарегистрировалось в голове, что абсолютные адреса же ещё будут на каждом запуске разными и непредопределёнными (несмотря на то, что, запуская код в дебаггере, видел, что адреса каждый раз разные)
Ну да, я догадался сделать так и до того, что оно не будет работать с относительными адресами, поэтому снова вспомнил, что у меня не получалось mov использовать с абсолютными в более простом варианте адресации
Ну да, понятно вообщем спасибо, у меня как-то не зарегистрировалось в голове, что абсолютные адреса же ещё будут на каждом запуске разными и непредопределёнными (несмотря на то, что, запуская код в дебаггере, видел, что адреса каждый раз разные)
>сначала помещаешь его адрес в регистр соответствующим способом (RIP-relative — lea reg, [rel arr]; это отдельный способ адресации, несовместимый с base + index × scale в рамках одной и той же инструкции
Ну да, я догадался сделать так и до того, что оно не будет работать с относительными адресами, поэтому снова вспомнил, что у меня не получалось mov использовать с абсолютными в более простом варианте адресации
281 Кб, 1411x1852Похоже, что на винде нету нормального способа сделать экзешник, который при открытии из эксплорера создаёт гуишное окно, а при запуске из консоли тоже создаёт гуишное окно, но также умеет писать в консоль (из которого он был запущен).
Если делаешь subsystem windows, то приложение сразу же отсоединяется от консоли и шелл уже показывает промпт для ввода следующей команды, не дожидаясь закрытия гуишного окна. AttachConsole(ATTACH_PARENT_PROCESS) позволяет что-то писать в оторванную консоль из приложения, но это всё ещё конфликтует с шеллом, который рисует следующий промпт, затирает то, что пишет приложение, и обрабатывает инпут из консоли.
Если делаешь subsystem console, то вместе с гуишным окном неизбежно создастся консольное окно, когда запускаешь экзешник из эксплорера. Можно закрыть через FreeConsole, но оно всё равно на мгновение появится. Нужно понять, запустили ли тебя из эксплорера или консоли, чтобы делать FreeConsole только в первом случае. Я видел, люди предлагают смотреть на возвращаемые значения GetConsoleTitle, GetConsoleScreenBufferInfo, AttachConsole(ATTACH_PARENT_PROCESS), но для меня они все не работают вместе с subsystem console. Это https://devblogs.microsoft.com/oldnewthing/20160125-00/?p=92922 вроде работает.
Как это обходят другие люди - делают два экзешника: один - гуишное приложение, второй - консольный враппер. Например, у mpv есть "mpv.com" для консоли - он запускает основное приложение "mpv.exe", передавая информацию о том, что юзер запустил приложение из консоли через переменную среды https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/win32-console-wrapper.c#L95
"mpv.exe" - полностью отдельный экзешник со своей отдельной точкой входа https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/main-fn-win.c#L60
"mpv.exe" по дефолту запускается в гуишном режиме, но, если задана та переменная среды внутри консольного враппера, то он аттачит консоль родительского процесса "mpv.com" и использует его хэндлы на stdout, stdin, stderr. И тут избегается проблема subsystem windows с тем, что шелл не дожидается закрытия гуишного окна, потому что "mpv.com" висит и ждёт завершения дочернего процесса.
И ещё "mpv.com" почему-то имеет больший приоритет, чем "mpv.exe", когда пишешь "mpv" что в павершелле, что в cmd (алфавитный порядок?) А когда в поиске пишешь mpv, то приоритет у "mpv.exe". То есть оно работает бесшовно, если ты везде пишешь "mpv" без расширения.
Вообще я не знаю, что такое COM, https://devblogs.microsoft.com/oldnewthing/20080324-00/?p=23033 вроде какой-то старый формат экзешников, который просто содержит машинный код с первого же байта. Но в случае с mpv всё же "mpv.com" - это не COM, а PE экзешник с переименованным расширением, но винда умеет такое корректно такое загружать, поэтому всё в порядке, кроме того, что мне очень хочется уже умереть
Если делаешь subsystem windows, то приложение сразу же отсоединяется от консоли и шелл уже показывает промпт для ввода следующей команды, не дожидаясь закрытия гуишного окна. AttachConsole(ATTACH_PARENT_PROCESS) позволяет что-то писать в оторванную консоль из приложения, но это всё ещё конфликтует с шеллом, который рисует следующий промпт, затирает то, что пишет приложение, и обрабатывает инпут из консоли.
Если делаешь subsystem console, то вместе с гуишным окном неизбежно создастся консольное окно, когда запускаешь экзешник из эксплорера. Можно закрыть через FreeConsole, но оно всё равно на мгновение появится. Нужно понять, запустили ли тебя из эксплорера или консоли, чтобы делать FreeConsole только в первом случае. Я видел, люди предлагают смотреть на возвращаемые значения GetConsoleTitle, GetConsoleScreenBufferInfo, AttachConsole(ATTACH_PARENT_PROCESS), но для меня они все не работают вместе с subsystem console. Это https://devblogs.microsoft.com/oldnewthing/20160125-00/?p=92922 вроде работает.
Как это обходят другие люди - делают два экзешника: один - гуишное приложение, второй - консольный враппер. Например, у mpv есть "mpv.com" для консоли - он запускает основное приложение "mpv.exe", передавая информацию о том, что юзер запустил приложение из консоли через переменную среды https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/win32-console-wrapper.c#L95
"mpv.exe" - полностью отдельный экзешник со своей отдельной точкой входа https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/main-fn-win.c#L60
"mpv.exe" по дефолту запускается в гуишном режиме, но, если задана та переменная среды внутри консольного враппера, то он аттачит консоль родительского процесса "mpv.com" и использует его хэндлы на stdout, stdin, stderr. И тут избегается проблема subsystem windows с тем, что шелл не дожидается закрытия гуишного окна, потому что "mpv.com" висит и ждёт завершения дочернего процесса.
И ещё "mpv.com" почему-то имеет больший приоритет, чем "mpv.exe", когда пишешь "mpv" что в павершелле, что в cmd (алфавитный порядок?) А когда в поиске пишешь mpv, то приоритет у "mpv.exe". То есть оно работает бесшовно, если ты везде пишешь "mpv" без расширения.
Вообще я не знаю, что такое COM, https://devblogs.microsoft.com/oldnewthing/20080324-00/?p=23033 вроде какой-то старый формат экзешников, который просто содержит машинный код с первого же байта. Но в случае с mpv всё же "mpv.com" - это не COM, а PE экзешник с переименованным расширением, но винда умеет такое корректно такое загружать, поэтому всё в порядке, кроме того, что мне очень хочется уже умереть
281 Кб, 1411x1852Похоже, что на винде нету нормального способа сделать экзешник, который при открытии из эксплорера создаёт гуишное окно, а при запуске из консоли тоже создаёт гуишное окно, но также умеет писать в консоль (из которого он был запущен).
Если делаешь subsystem windows, то приложение сразу же отсоединяется от консоли и шелл уже показывает промпт для ввода следующей команды, не дожидаясь закрытия гуишного окна. AttachConsole(ATTACH_PARENT_PROCESS) позволяет что-то писать в оторванную консоль из приложения, но это всё ещё конфликтует с шеллом, который рисует следующий промпт, затирает то, что пишет приложение, и обрабатывает инпут из консоли.
Если делаешь subsystem console, то вместе с гуишным окном неизбежно создастся консольное окно, когда запускаешь экзешник из эксплорера. Можно закрыть через FreeConsole, но оно всё равно на мгновение появится. Нужно понять, запустили ли тебя из эксплорера или консоли, чтобы делать FreeConsole только в первом случае. Я видел, люди предлагают смотреть на возвращаемые значения GetConsoleTitle, GetConsoleScreenBufferInfo, AttachConsole(ATTACH_PARENT_PROCESS), но для меня они все не работают вместе с subsystem console. Это https://devblogs.microsoft.com/oldnewthing/20160125-00/?p=92922 вроде работает.
Как это обходят другие люди - делают два экзешника: один - гуишное приложение, второй - консольный враппер. Например, у mpv есть "mpv.com" для консоли - он запускает основное приложение "mpv.exe", передавая информацию о том, что юзер запустил приложение из консоли через переменную среды https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/win32-console-wrapper.c#L95
"mpv.exe" - полностью отдельный экзешник со своей отдельной точкой входа https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/main-fn-win.c#L60
"mpv.exe" по дефолту запускается в гуишном режиме, но, если задана та переменная среды внутри консольного враппера, то он аттачит консоль родительского процесса "mpv.com" и использует его хэндлы на stdout, stdin, stderr. И тут избегается проблема subsystem windows с тем, что шелл не дожидается закрытия гуишного окна, потому что "mpv.com" висит и ждёт завершения дочернего процесса.
И ещё "mpv.com" почему-то имеет больший приоритет, чем "mpv.exe", когда пишешь "mpv" что в павершелле, что в cmd (алфавитный порядок?) А когда в поиске пишешь mpv, то приоритет у "mpv.exe". То есть оно работает бесшовно, если ты везде пишешь "mpv" без расширения.
Вообще я не знаю, что такое COM, https://devblogs.microsoft.com/oldnewthing/20080324-00/?p=23033 вроде какой-то старый формат экзешников, который просто содержит машинный код с первого же байта. Но в случае с mpv всё же "mpv.com" - это не COM, а PE экзешник с переименованным расширением, но винда умеет такое корректно такое загружать, поэтому всё в порядке, кроме того, что мне очень хочется уже умереть
Если делаешь subsystem windows, то приложение сразу же отсоединяется от консоли и шелл уже показывает промпт для ввода следующей команды, не дожидаясь закрытия гуишного окна. AttachConsole(ATTACH_PARENT_PROCESS) позволяет что-то писать в оторванную консоль из приложения, но это всё ещё конфликтует с шеллом, который рисует следующий промпт, затирает то, что пишет приложение, и обрабатывает инпут из консоли.
Если делаешь subsystem console, то вместе с гуишным окном неизбежно создастся консольное окно, когда запускаешь экзешник из эксплорера. Можно закрыть через FreeConsole, но оно всё равно на мгновение появится. Нужно понять, запустили ли тебя из эксплорера или консоли, чтобы делать FreeConsole только в первом случае. Я видел, люди предлагают смотреть на возвращаемые значения GetConsoleTitle, GetConsoleScreenBufferInfo, AttachConsole(ATTACH_PARENT_PROCESS), но для меня они все не работают вместе с subsystem console. Это https://devblogs.microsoft.com/oldnewthing/20160125-00/?p=92922 вроде работает.
Как это обходят другие люди - делают два экзешника: один - гуишное приложение, второй - консольный враппер. Например, у mpv есть "mpv.com" для консоли - он запускает основное приложение "mpv.exe", передавая информацию о том, что юзер запустил приложение из консоли через переменную среды https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/win32-console-wrapper.c#L95
"mpv.exe" - полностью отдельный экзешник со своей отдельной точкой входа https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/main-fn-win.c#L60
"mpv.exe" по дефолту запускается в гуишном режиме, но, если задана та переменная среды внутри консольного враппера, то он аттачит консоль родительского процесса "mpv.com" и использует его хэндлы на stdout, stdin, stderr. И тут избегается проблема subsystem windows с тем, что шелл не дожидается закрытия гуишного окна, потому что "mpv.com" висит и ждёт завершения дочернего процесса.
И ещё "mpv.com" почему-то имеет больший приоритет, чем "mpv.exe", когда пишешь "mpv" что в павершелле, что в cmd (алфавитный порядок?) А когда в поиске пишешь mpv, то приоритет у "mpv.exe". То есть оно работает бесшовно, если ты везде пишешь "mpv" без расширения.
Вообще я не знаю, что такое COM, https://devblogs.microsoft.com/oldnewthing/20080324-00/?p=23033 вроде какой-то старый формат экзешников, который просто содержит машинный код с первого же байта. Но в случае с mpv всё же "mpv.com" - это не COM, а PE экзешник с переименованным расширением, но винда умеет такое корректно такое загружать, поэтому всё в порядке, кроме того, что мне очень хочется уже умереть
Шизофрения
Типа контекст - структура со всякой ерундой, которую обычно через глобальные переменные делают, например, аллокатор, логгер и прочее такое
Я не придумал, как через такое обобщённое апи сделать так, чтобы динамический массив с линейным аллокатором не тратил впустую память. Добавить функцию реаллок и сделать, чтобы линейный аллокатор мог по возможности расширить последнюю аллокацию, а не выделять новый кусок?
Я хотел бы попробовать написать решение этого https://adventofcode.com/2023/day/1 на саммсебреле, но я слишком тупой и мне страшно. Я так понимаю, когда я буду искать цифры, после сравнения, чтобы достать первую или последнюю цифру в строке, мне нужно будет перевести маску в более удобный вид https://www.felixcloutier.com/x86/pmovmskb и понять, какой по счёту байт мне нужен (через инструкции LZCNT или TZCNT)? Я думал, может быть, есть инструкция, которая бы позволила по маске извлечь один байт из SIMD регистра и положить этот один единственный байт куда-то в память, но не могу найти такое. Самое близкое это https://www.felixcloutier.com/x86/maskmovdqu но это вроде не то, оно сохранит замаскированные байты сохраняя смещения. Shuffle инструкции вроде работают только с immediate, blend - тоже что-то не то, наверное, нет такого, не знаю.
Не хочется жить
Типа контекст - структура со всякой ерундой, которую обычно через глобальные переменные делают, например, аллокатор, логгер и прочее такое
Я не придумал, как через такое обобщённое апи сделать так, чтобы динамический массив с линейным аллокатором не тратил впустую память. Добавить функцию реаллок и сделать, чтобы линейный аллокатор мог по возможности расширить последнюю аллокацию, а не выделять новый кусок?
Я хотел бы попробовать написать решение этого https://adventofcode.com/2023/day/1 на саммсебреле, но я слишком тупой и мне страшно. Я так понимаю, когда я буду искать цифры, после сравнения, чтобы достать первую или последнюю цифру в строке, мне нужно будет перевести маску в более удобный вид https://www.felixcloutier.com/x86/pmovmskb и понять, какой по счёту байт мне нужен (через инструкции LZCNT или TZCNT)? Я думал, может быть, есть инструкция, которая бы позволила по маске извлечь один байт из SIMD регистра и положить этот один единственный байт куда-то в память, но не могу найти такое. Самое близкое это https://www.felixcloutier.com/x86/maskmovdqu но это вроде не то, оно сохранит замаскированные байты сохраняя смещения. Shuffle инструкции вроде работают только с immediate, blend - тоже что-то не то, наверное, нет такого, не знаю.
Не хочется жить
>>738389
А, ссылкиhttps://play.rust-lang.org/?version=stable&mode=debug&edition=&gist=e спойлерземля тебе пухом, кста а в каком моменте он был во втором сезоне? я просто дропнул сезон с первом серии мне не в катила эта тема с рабами bdebafbfaedacaadだ。.
А, ссылкиhttps://play.rust-lang.org/?version=stable&mode=debug&edition=&gist=e спойлерземля тебе пухом, кста а в каком моменте он был во втором сезоне? я просто дропнул сезон с первом серии мне не в катила эта тема с рабами bdebafbfaedacaadだ。.
1,1 Мб, 1000x1414>>739489
Если ты прочитал вектор по адресу A, что-то насравнивал, и из результата сравнения получил смещение через pmovmskb + bsf/tzcnt (положим i), то для извлечения значения по этому смещению ты перечитываешь его с адреса A + i. :) Я так делал в CompareByte (memcmp), вот здесь https://gitlab.com/freepascal.org/fpc/source/-/blob/b3c1f294ba4b69f2d3bee53730c86af204e456b9/rtl/x86_64/x86_64.inc#L856 перечитываются и вычитаются два байта по смещению, полученному из pmovmskb + bsf.
Если ты прочитал вектор по адресу A, что-то насравнивал, и из результата сравнения получил смещение через pmovmskb + bsf/tzcnt (положим i), то для извлечения значения по этому смещению ты перечитываешь его с адреса A + i. :) Я так делал в CompareByte (memcmp), вот здесь https://gitlab.com/freepascal.org/fpc/source/-/blob/b3c1f294ba4b69f2d3bee53730c86af204e456b9/rtl/x86_64/x86_64.inc#L856 перечитываются и вычитаются два байта по смещению, полученному из pmovmskb + bsf.
288 Кб, 1377x2048Я не могу, я пытался что-то начинать делать, но мне слишком паршиво, постоянно какая-то тяжесть в груди и я тупой, всё из рук валится, и зачем уже так жить, нету никакого смысла жить, если ты тупой, всратый и не свалилось на голову никаких богатств, я уже устал ждать смерти
67 Кб, 1171x840Я почти допил эрл грей, который на вкус и запах так и остался для меня омерзительным. Я теперь ещё меньше верю в то, что можно так насильно изменить свои вкусовые предпочтения.
Теперь попробовал это:
Он просто невкусный. Меня от него не передёргивает, как от эрл грея после каждого глотка, но он просто пахнет как будто грязной половой тряпкой, а на вкус почти никакой, как будто его и нет почти.
Где-то две недели назад сломал очередные проводные наушники (случайно погнул штекер, я не осилю заменить его: единственный раз, когда пробовал чинить наушники - очень быстро снова их сломал, я слишком тупой для этого). Подумал, может быть, стоит купить беспроводные, короче, теперь кринжовая реальность - что иногда нужно снять наушники, чтобы их зарядить + ощутимая небольшая задержка, когда играешь в игры. А из плюсов от того, что они беспроводные - только, что я теперь не могу сломать провод.
Единственный сценарий, когда они удобнее проводных - когда делаешь что-то на кухне руками, ходишь туда-сюда, и одновременно что-то смотришь на телефоне. Можно телефон в одно место положить, не быть привязанным к нему наушниками и иметь возможность поглядывать на экран.
Про всякие дополнительные вещи, которые обычно пихают в беспроводные наушники, вроде микрофона, шумодава, режима прозрачности, жестов для управления, с моей стороны было бы говорить нечестно с учётом того, что я купил дешёвые наушники. Может быть, в каких-нибудь более дорогих есть, например, волшебный шумодав, который реально все звуки извне блокирует, а не просто давит шипением на барабанные перепонки, как мой китайский кусок мусора хуавей 5i. Но я тут и не рассчитывал ни на что с самого начала.
Короче, беспроводные устройства - это похоже просто очередной гиммик
Теперь попробовал это:
>An aromatic blend of premium Ceylon black tea, raisins and soursop infused with the fruity flavour of white grape wine. With Nuwara Eliya tea, you are offered a fruity taste of grape and soursop with a hint of floral taste. Enjoy every sip.
Он просто невкусный. Меня от него не передёргивает, как от эрл грея после каждого глотка, но он просто пахнет как будто грязной половой тряпкой, а на вкус почти никакой, как будто его и нет почти.
Где-то две недели назад сломал очередные проводные наушники (случайно погнул штекер, я не осилю заменить его: единственный раз, когда пробовал чинить наушники - очень быстро снова их сломал, я слишком тупой для этого). Подумал, может быть, стоит купить беспроводные, короче, теперь кринжовая реальность - что иногда нужно снять наушники, чтобы их зарядить + ощутимая небольшая задержка, когда играешь в игры. А из плюсов от того, что они беспроводные - только, что я теперь не могу сломать провод.
Единственный сценарий, когда они удобнее проводных - когда делаешь что-то на кухне руками, ходишь туда-сюда, и одновременно что-то смотришь на телефоне. Можно телефон в одно место положить, не быть привязанным к нему наушниками и иметь возможность поглядывать на экран.
Про всякие дополнительные вещи, которые обычно пихают в беспроводные наушники, вроде микрофона, шумодава, режима прозрачности, жестов для управления, с моей стороны было бы говорить нечестно с учётом того, что я купил дешёвые наушники. Может быть, в каких-нибудь более дорогих есть, например, волшебный шумодав, который реально все звуки извне блокирует, а не просто давит шипением на барабанные перепонки, как мой китайский кусок мусора хуавей 5i. Но я тут и не рассчитывал ни на что с самого начала.
Короче, беспроводные устройства - это похоже просто очередной гиммик
Мне на глаза снова попалось обсуждение того, что кто-то там в коде своей игры сделал длинный свитч кейс на тысячу значений, и я на этот раз всё же решил посмотреть, во что это может компилироваться, потому что мне стало немного менее страшно читать асемблер
В общем, если кейсов мало, то if-else.
Если кейсов много, но значения в них последовательные, то генерируется массив из адресов кейсов, куда прыгать, который индексируется значением, по которому делается свитч. Если есть небольшие дыры, то их можно заделать вставкой адреса, куда переходить, если значение не подошло ни под один кейс.
Если кейсов много и между значениями слишком большие дыры, то делается бинарный поиск с захардкоженными всеми возможными ветками и сравнениями. И это может комбинироваться с таблицей адресов для прыжков, если в какой-то ветке бинарного поиска остаётся кусок значений, которые (почти) последовательные внутри этого куска. Вроде бы он ещё умеет видеть кластеры близких друг к другу значений кейсов и делать под каждый из них отдельную таблицу, то есть не просто пополам делить бинарным поиском.
Не знаю, есть ли какой-то предел по количеству кейсов, после которого компиляторы перестают генерировать таблицу прыжков, как будто бы не должно быть, потому что если каждому кейсу соответствует какой-то отдельный уникальный немного осмысленный кусок кода, то эта таблица вроде не должна слишком уж сильно раздуть экзешник по сравнению с вариантом с if-else.
Вроде как кланг в случае со свитчем на 100к кейсов генерирует (очень долго, я не замерял, но минут 5-10) табличку (в коде на 4 картинке видно, что он что-то читает из памяти, там адрес из .rdata секции, и там дальше ниже уже идут разные кейсы почему-то в рандомном порядке). Кстати, сейчас подумал, что может быть, тут можно было бы обойтись и без таблички с учётом того, что размер кода во всех кейсах одинаковый и кейсы идут от 0 до 100к без дырок? Может быть, можно было бы вычислять нужный адрес напрямую, а не индексировать сначала таблицу.
Макросы в виме с навешанными на него плагинами как-то совсем дико медленно работают (я ими генерировал файл со свитчем на много кейсов) и я не уверен, какой конкретно плагин является причиной, было лень разбираться, просто все отключил, когда это делал.
Странно слышать после этого, что вим с плагинами какой-то по-особенному крутой по сравнению с другими редакторами, когда плагины убивают одну из самых прикольных фич вима. Я сомневаюсь даже, что за счёт отсутствия нормального GUI он работает быстрее других редакторов, которые зачастую внутри используют те же самые лсп, что и вим. То есть это уже даже не вим по своей сути, а очередной унылый редактор, у которого единственная отличительная бесполезная особенность - что его внутри терминала можно запустить.
Я какое-то время назад добавил в вим команду, чтобы переключаться между разными шеллами (cmd, pwsh, msys2, wsl) и заметил, что почему-то в как будто рандомные моменты меня начало переключать в wsl-ный шелл. До меня очень не сразу дошло, что я иногда случайно пишу :W вместо :w для сохранения файла, и эта :W выполняет мою кастомную команду :WSL. Потому что виме, если ты пишешь неполное уникальное начало команды, то он её без вопросов выполняет, и так получилось, что единственная команда, начинающаяся на W - это моя кастомная для переключения шелла на wsl-левский.
Короче, я решил это так, что просто назначил на :W тоже сохранение файла
В общем, если кейсов мало, то if-else.
Если кейсов много, но значения в них последовательные, то генерируется массив из адресов кейсов, куда прыгать, который индексируется значением, по которому делается свитч. Если есть небольшие дыры, то их можно заделать вставкой адреса, куда переходить, если значение не подошло ни под один кейс.
Если кейсов много и между значениями слишком большие дыры, то делается бинарный поиск с захардкоженными всеми возможными ветками и сравнениями. И это может комбинироваться с таблицей адресов для прыжков, если в какой-то ветке бинарного поиска остаётся кусок значений, которые (почти) последовательные внутри этого куска. Вроде бы он ещё умеет видеть кластеры близких друг к другу значений кейсов и делать под каждый из них отдельную таблицу, то есть не просто пополам делить бинарным поиском.
Не знаю, есть ли какой-то предел по количеству кейсов, после которого компиляторы перестают генерировать таблицу прыжков, как будто бы не должно быть, потому что если каждому кейсу соответствует какой-то отдельный уникальный немного осмысленный кусок кода, то эта таблица вроде не должна слишком уж сильно раздуть экзешник по сравнению с вариантом с if-else.
Вроде как кланг в случае со свитчем на 100к кейсов генерирует (очень долго, я не замерял, но минут 5-10) табличку (в коде на 4 картинке видно, что он что-то читает из памяти, там адрес из .rdata секции, и там дальше ниже уже идут разные кейсы почему-то в рандомном порядке). Кстати, сейчас подумал, что может быть, тут можно было бы обойтись и без таблички с учётом того, что размер кода во всех кейсах одинаковый и кейсы идут от 0 до 100к без дырок? Может быть, можно было бы вычислять нужный адрес напрямую, а не индексировать сначала таблицу.
Макросы в виме с навешанными на него плагинами как-то совсем дико медленно работают (я ими генерировал файл со свитчем на много кейсов) и я не уверен, какой конкретно плагин является причиной, было лень разбираться, просто все отключил, когда это делал.
Странно слышать после этого, что вим с плагинами какой-то по-особенному крутой по сравнению с другими редакторами, когда плагины убивают одну из самых прикольных фич вима. Я сомневаюсь даже, что за счёт отсутствия нормального GUI он работает быстрее других редакторов, которые зачастую внутри используют те же самые лсп, что и вим. То есть это уже даже не вим по своей сути, а очередной унылый редактор, у которого единственная отличительная бесполезная особенность - что его внутри терминала можно запустить.
Я какое-то время назад добавил в вим команду, чтобы переключаться между разными шеллами (cmd, pwsh, msys2, wsl) и заметил, что почему-то в как будто рандомные моменты меня начало переключать в wsl-ный шелл. До меня очень не сразу дошло, что я иногда случайно пишу :W вместо :w для сохранения файла, и эта :W выполняет мою кастомную команду :WSL. Потому что виме, если ты пишешь неполное уникальное начало команды, то он её без вопросов выполняет, и так получилось, что единственная команда, начинающаяся на W - это моя кастомная для переключения шелла на wsl-левский.
Короче, я решил это так, что просто назначил на :W тоже сохранение файла
Мне на глаза снова попалось обсуждение того, что кто-то там в коде своей игры сделал длинный свитч кейс на тысячу значений, и я на этот раз всё же решил посмотреть, во что это может компилироваться, потому что мне стало немного менее страшно читать асемблер
В общем, если кейсов мало, то if-else.
Если кейсов много, но значения в них последовательные, то генерируется массив из адресов кейсов, куда прыгать, который индексируется значением, по которому делается свитч. Если есть небольшие дыры, то их можно заделать вставкой адреса, куда переходить, если значение не подошло ни под один кейс.
Если кейсов много и между значениями слишком большие дыры, то делается бинарный поиск с захардкоженными всеми возможными ветками и сравнениями. И это может комбинироваться с таблицей адресов для прыжков, если в какой-то ветке бинарного поиска остаётся кусок значений, которые (почти) последовательные внутри этого куска. Вроде бы он ещё умеет видеть кластеры близких друг к другу значений кейсов и делать под каждый из них отдельную таблицу, то есть не просто пополам делить бинарным поиском.
Не знаю, есть ли какой-то предел по количеству кейсов, после которого компиляторы перестают генерировать таблицу прыжков, как будто бы не должно быть, потому что если каждому кейсу соответствует какой-то отдельный уникальный немного осмысленный кусок кода, то эта таблица вроде не должна слишком уж сильно раздуть экзешник по сравнению с вариантом с if-else.
Вроде как кланг в случае со свитчем на 100к кейсов генерирует (очень долго, я не замерял, но минут 5-10) табличку (в коде на 4 картинке видно, что он что-то читает из памяти, там адрес из .rdata секции, и там дальше ниже уже идут разные кейсы почему-то в рандомном порядке). Кстати, сейчас подумал, что может быть, тут можно было бы обойтись и без таблички с учётом того, что размер кода во всех кейсах одинаковый и кейсы идут от 0 до 100к без дырок? Может быть, можно было бы вычислять нужный адрес напрямую, а не индексировать сначала таблицу.
Макросы в виме с навешанными на него плагинами как-то совсем дико медленно работают (я ими генерировал файл со свитчем на много кейсов) и я не уверен, какой конкретно плагин является причиной, было лень разбираться, просто все отключил, когда это делал.
Странно слышать после этого, что вим с плагинами какой-то по-особенному крутой по сравнению с другими редакторами, когда плагины убивают одну из самых прикольных фич вима. Я сомневаюсь даже, что за счёт отсутствия нормального GUI он работает быстрее других редакторов, которые зачастую внутри используют те же самые лсп, что и вим. То есть это уже даже не вим по своей сути, а очередной унылый редактор, у которого единственная отличительная бесполезная особенность - что его внутри терминала можно запустить.
Я какое-то время назад добавил в вим команду, чтобы переключаться между разными шеллами (cmd, pwsh, msys2, wsl) и заметил, что почему-то в как будто рандомные моменты меня начало переключать в wsl-ный шелл. До меня очень не сразу дошло, что я иногда случайно пишу :W вместо :w для сохранения файла, и эта :W выполняет мою кастомную команду :WSL. Потому что виме, если ты пишешь неполное уникальное начало команды, то он её без вопросов выполняет, и так получилось, что единственная команда, начинающаяся на W - это моя кастомная для переключения шелла на wsl-левский.
Короче, я решил это так, что просто назначил на :W тоже сохранение файла
В общем, если кейсов мало, то if-else.
Если кейсов много, но значения в них последовательные, то генерируется массив из адресов кейсов, куда прыгать, который индексируется значением, по которому делается свитч. Если есть небольшие дыры, то их можно заделать вставкой адреса, куда переходить, если значение не подошло ни под один кейс.
Если кейсов много и между значениями слишком большие дыры, то делается бинарный поиск с захардкоженными всеми возможными ветками и сравнениями. И это может комбинироваться с таблицей адресов для прыжков, если в какой-то ветке бинарного поиска остаётся кусок значений, которые (почти) последовательные внутри этого куска. Вроде бы он ещё умеет видеть кластеры близких друг к другу значений кейсов и делать под каждый из них отдельную таблицу, то есть не просто пополам делить бинарным поиском.
Не знаю, есть ли какой-то предел по количеству кейсов, после которого компиляторы перестают генерировать таблицу прыжков, как будто бы не должно быть, потому что если каждому кейсу соответствует какой-то отдельный уникальный немного осмысленный кусок кода, то эта таблица вроде не должна слишком уж сильно раздуть экзешник по сравнению с вариантом с if-else.
Вроде как кланг в случае со свитчем на 100к кейсов генерирует (очень долго, я не замерял, но минут 5-10) табличку (в коде на 4 картинке видно, что он что-то читает из памяти, там адрес из .rdata секции, и там дальше ниже уже идут разные кейсы почему-то в рандомном порядке). Кстати, сейчас подумал, что может быть, тут можно было бы обойтись и без таблички с учётом того, что размер кода во всех кейсах одинаковый и кейсы идут от 0 до 100к без дырок? Может быть, можно было бы вычислять нужный адрес напрямую, а не индексировать сначала таблицу.
Макросы в виме с навешанными на него плагинами как-то совсем дико медленно работают (я ими генерировал файл со свитчем на много кейсов) и я не уверен, какой конкретно плагин является причиной, было лень разбираться, просто все отключил, когда это делал.
Странно слышать после этого, что вим с плагинами какой-то по-особенному крутой по сравнению с другими редакторами, когда плагины убивают одну из самых прикольных фич вима. Я сомневаюсь даже, что за счёт отсутствия нормального GUI он работает быстрее других редакторов, которые зачастую внутри используют те же самые лсп, что и вим. То есть это уже даже не вим по своей сути, а очередной унылый редактор, у которого единственная отличительная бесполезная особенность - что его внутри терминала можно запустить.
Я какое-то время назад добавил в вим команду, чтобы переключаться между разными шеллами (cmd, pwsh, msys2, wsl) и заметил, что почему-то в как будто рандомные моменты меня начало переключать в wsl-ный шелл. До меня очень не сразу дошло, что я иногда случайно пишу :W вместо :w для сохранения файла, и эта :W выполняет мою кастомную команду :WSL. Потому что виме, если ты пишешь неполное уникальное начало команды, то он её без вопросов выполняет, и так получилось, что единственная команда, начинающаяся на W - это моя кастомная для переключения шелла на wsl-левский.
Короче, я решил это так, что просто назначил на :W тоже сохранение файла
15,4 Мб, webm,960x1032, 10:31
иди нахуй
421 Кб, 1884x388https://www.shadertoy.com/view/Ws3GRs
Как я понял, на чёрных клетках рисуешь рандомные вертикальные, на белых - рандомные горизонтальные, потом дорисовываешь недостающие
Как я понял, на чёрных клетках рисуешь рандомные вертикальные, на белых - рандомные горизонтальные, потом дорисовываешь недостающие
30 Кб, 818x312Спасибо, очень круто
Как я понял, это так ни в какой стандарт и не приняли
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2083.htm
А в плюсах их вроде по-хорошему вообще не существует как таковых
Понятно, что существующим компиляторам наверняка всё равно на такие моменты в стандартах и они съедят многое, но всё равно как-то неприятно. Неприятно не из-за того, что ой, а вдруг код сломается в новой версии компилятора из-за того, что я использую что-то нестандартизированное - это не проблема, просто можно продолжить использовать конкретную старую версию компилятора, в которой всё нормально было.
А из-за того, что кто-то, реализовав компилятор следуя только стандарту, не сможет компилировать код со всякими упоротыми расширениями (вроде такого https://clang.llvm.org/docs/BlockLanguageSpec.html - это похоже кложуры в си?) И ему придётся повторять путь существующих или существовавших компиляторов (когда весь код перепишут на раст и си и плюсы будут не нужны), чтобы что?
Как я понял, это так ни в какой стандарт и не приняли
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2083.htm
А в плюсах их вроде по-хорошему вообще не существует как таковых
Понятно, что существующим компиляторам наверняка всё равно на такие моменты в стандартах и они съедят многое, но всё равно как-то неприятно. Неприятно не из-за того, что ой, а вдруг код сломается в новой версии компилятора из-за того, что я использую что-то нестандартизированное - это не проблема, просто можно продолжить использовать конкретную старую версию компилятора, в которой всё нормально было.
А из-за того, что кто-то, реализовав компилятор следуя только стандарту, не сможет компилировать код со всякими упоротыми расширениями (вроде такого https://clang.llvm.org/docs/BlockLanguageSpec.html - это похоже кложуры в си?) И ему придётся повторять путь существующих или существовавших компиляторов (когда весь код перепишут на раст и си и плюсы будут не нужны), чтобы что?
19,6 Мб, webm,1280x720, 1:35
Мыльный пэрри кринж мпч
Я так до сих пор и не прошёл элдер ринг ни разу из-за своей шизы с удалением сейвов. Айзека, кстати, только относительно недавно прошёл спустя почти 3 года после выхода репы, и первый раз все ачивки закрыты с 2014. Там как будто новое обновление будет когда-то, а у меня закрытого сейва своего уже нету, ну тут не по моей вине, его каким-то образом скорраптила стим помойка
Я так до сих пор и не прошёл элдер ринг ни разу из-за своей шизы с удалением сейвов. Айзека, кстати, только относительно недавно прошёл спустя почти 3 года после выхода репы, и первый раз все ачивки закрыты с 2014. Там как будто новое обновление будет когда-то, а у меня закрытого сейва своего уже нету, ну тут не по моей вине, его каким-то образом скорраптила стим помойка
19,6 Мб, webm,1280x720, 1:14
Куки кликер тир гейминг
19,7 Мб, webm,1280x720, 1:10
Нет, вот куки кликер
Днём пробовал ходить ногами немного больше 20 километров, короче, это просто дикое уныние и бессмысленная трата времени и я теперь хочу умереть только ещё сильнее
Днём пробовал ходить ногами немного больше 20 километров, короче, это просто дикое уныние и бессмысленная трата времени и я теперь хочу умереть только ещё сильнее
19,7 Мб, webm,1280x720, 1:13
У ножей слишком большая задержка перед окном парирования, нужно прямо совсем заранее прожимать, неудобно и тяжело. У другого оружия, кроме щитов, всё ещё хуже: задержка такая же, а окно в два раза меньше
19,6 Мб, webm,1280x720, 1:28
Почему-то периодически, когда прожимаю скилл на быстрые выстрелы, то либо скилл не срабатывает, либо он вообще не стреляет как будто, особенно в режиме прицеливания. Буквально проблемы с навыком
19,7 Мб, webm,1280x720, 1:42
Я не хочу ничего, нахуя я живу
19,8 Мб, webm,1280x720, 0:54
Тот, у которого шипастые шары на палке, не парируется, к сожалению, нельзя его сбить и по-нормальному убить. Все боссы на конях - мусор, да вообще все боссы пока что мусор унылый. Особенно дебильная птица с миллионом хп сверху, которая ещё и ваншотает любым своим ударом
18,9 Мб, webm,1280x720, 0:26
Такая тупость, ему можно спокойно за спину зайти. Ещё у его вот этого выпада двумя руками сразу более-менее простые тайминги, можно парировать. Больше не понимаю, что с ним можно сделать. Ему, наверное, специально так мало хп сделали, чтобы его можно было просто в лоб танковать, но это совсем дебилизм
19,7 Мб, webm,1280x720, 1:17
Ненавижу этих медведей, они тупо в любой момент могут решить дешнуться тебе в лицо и если ты в этот же момент уже замахнулся оружием, то у тебя околонулевые шансы увернуться. И с них даже ничего не падает полезного и денег тоже почти не дают, я не понимаю, зачем их понатыкали на карте везде, просто чтобы закрыть пустое пространство хотя бы немного, видимо
19,7 Мб, webm,1280x720, 1:17
Какая-то читерская катана, он даже в свою дебильную вторую фазу с молниями не успел перейти
19,9 Мб, webm,1280x720, 0:55
Почему я ещё не умер
Ясно, макаба окончательно разучилась генерировать обложки к видео
Парные боссы - это рнг бред. Это, понятно, что даже не босс по сути, но они будут позже и я, скорее всего, не вывезу их, если не начну прокачивать лвл. Меня с моим хп скоро будет вообще любой бомж ваншотать. Но, с другой стороны, я ненавижу прокачку в играх, какое-то дикое уныние для любителей сидеть и высчитывать, как бы заминмаксить статы
Лучше бы начальный класс полностью определял траекторию прокачки, а прокачка была бы линейной, например, по ходу прогресса тебе бы давали предметы, которые увеличивают статы. По-моему, в секире примерно так и было сделано для прокачки хп и урона, но зато было дебильное дерево прокачки протеза
Парные боссы - это рнг бред. Это, понятно, что даже не босс по сути, но они будут позже и я, скорее всего, не вывезу их, если не начну прокачивать лвл. Меня с моим хп скоро будет вообще любой бомж ваншотать. Но, с другой стороны, я ненавижу прокачку в играх, какое-то дикое уныние для любителей сидеть и высчитывать, как бы заминмаксить статы
Лучше бы начальный класс полностью определял траекторию прокачки, а прокачка была бы линейной, например, по ходу прогресса тебе бы давали предметы, которые увеличивают статы. По-моему, в секире примерно так и было сделано для прокачки хп и урона, но зато было дебильное дерево прокачки протеза
О, это же толпа врагов, рандомно понатыканных в токсичном болоте без какого-либо предполагаемого порядка их убийства. И теперь они будут мне мешать убить нпц фантома
С врагами на конях зачастую бывает так, что вроде бы в нужное время прожал парирование, но оно не сработало как будто из-за того, что ты был не той стороной к врагу повёрнут. Либо всё же действительно в тайминг не попал, не знаю
Это магическое парирование, оказывается, к сожалению, не может столько прожектайлов за один раз отразить. В конце забавно получилось, что они всё же решили скоординироваться и начать меня по очереди бить обычными атаками, а не магией, огнём или аое кринжем
Мне снова каждый день ебут мозг и я хочу умереть
Мне снова каждый день ебут мозг и я хочу умереть
Нахуя продолжать жить, если всё будет только хуже и хуже
Этот вертикальный удар на катане так быстро всех из равновесия выбивает
Я не знаю, зачем ты это делаешь, но я смотрю. Выглядит как танец. Сам я игры от этой студии не тяну, душно
Самый худший босс пока что: начиная с арены с кучей препятствий, которые мешаются под ногами, заканчивая тупыми атаками, которые непонятно как доджить, кроме как делать паник роллы в надежде, что тебя не заденет один из десятка ваншотающих прожектайлов
Как же мощно амдшный хардварный ав1 энкодер периодически не вывозит: просто в рандомные моменты начинает лагать, причём это с speed пресетом
Как же мощно амдшный хардварный ав1 энкодер периодически не вывозит: просто в рандомные моменты начинает лагать, причём это с speed пресетом
Эту атаку в конце просто не мог задоджить ни разу, слишком анскилл, абсолютно не могу увидеть, нужно ли мне перекатиться в сторону от огня или нет, и оно вроде в рандомных направлениях стреляет
Компилятор не смог осилить свэг чата джипити
Я два дня не могу сесть и доделать это, там нужно сделать ещё хотя бы объединение чанков с соседними при освобождении и отдельные списки свободных чанков для заранее определённых мелких размеров, но я не знаю, мне не хочется, мне хочется нахуй повеситься уже, зачем жить
Я два дня не могу сесть и доделать это, там нужно сделать ещё хотя бы объединение чанков с соседними при освобождении и отдельные списки свободных чанков для заранее определённых мелких размеров, но я не знаю, мне не хочется, мне хочется нахуй повеситься уже, зачем жить
Хочется повеситься от такого гейминга
Моей видеокарте тоже как-то нехорошо стало, почему-то запись ещё сильнее лагать стала
Моей видеокарте тоже как-то нехорошо стало, почему-то запись ещё сильнее лагать стала
>>692316
Никогда больше не буду покупать этот мусор
>если у меня будет новая видеокарта, то это будет амд
Никогда больше не буду покупать этот мусор
Наверно, спасибо на том, что он своим рыком не ваншотает меня на расстоянии, а всего лишь сносит 90% хп, и что этот рык можно заблокировать щитом
H.265 тоже точно так же в рандомные моменты начинает лагать, непонятно, в среднем меньше, чем ав1, или так же. А амдшный H.264 вообще выдаёт слишком мусорное качество, чтобы им можно было пользоваться. Я не знаю, может быть, она перегревается, но почему тогда перегревается только энкодер, а всей остальной видеокарте нормально
Может быть, она просто уже подыхает, потому что вроде же недавно эта проблема не была так сильно выражена, ну, реже случалось. Либо ничего не изменилось и мне просто сейчас не повезло, что это произошло в неудачный момент, не знаю, короче. Мне просто от любой такой даже мелкой вещи сейчас хочется умереть только ещё сильнее, завтра ещё что-нибудь случится, ну типо чай пролью, и, наверное, повешусь нахуй блять
H.265 тоже точно так же в рандомные моменты начинает лагать, непонятно, в среднем меньше, чем ав1, или так же. А амдшный H.264 вообще выдаёт слишком мусорное качество, чтобы им можно было пользоваться. Я не знаю, может быть, она перегревается, но почему тогда перегревается только энкодер, а всей остальной видеокарте нормально
Может быть, она просто уже подыхает, потому что вроде же недавно эта проблема не была так сильно выражена, ну, реже случалось. Либо ничего не изменилось и мне просто сейчас не повезло, что это произошло в неудачный момент, не знаю, короче. Мне просто от любой такой даже мелкой вещи сейчас хочется умереть только ещё сильнее, завтра ещё что-нибудь случится, ну типо чай пролью, и, наверное, повешусь нахуй блять
А, так можно было что ли. Даже не знаю, что хуже: играть за мага или подобные крысиные страты
1,3 Мб, 1893x1734Это реальность или элдер ринг? Из него крафтится что-нибудь полезное? Или это просто закуска? Хочу жить в лесу и питаться жуками и болотной тиной, а потом ближе к зиме умереть от голода и холода
Могли бы хотя бы сделать так, что в конце, после убийства всех мелких драконов вокруг, можно было бы подойти к большому и отрубить ему голову или внутренность какую-нибудь вырезать и вырвать, но нет, он просто испаряется, уныние, какой тогда смысл его вообще убивать "правильным" способом
>>745958
Ещё один неоправданно жирный моб с миллионом хп и пойза, с которого не падает ничего уникального
Ещё один неоправданно жирный моб с миллионом хп и пойза, с которого не падает ничего уникального
Не могу более агрессивно, слишком анскилл, кринж
Не могу найти нормальную одежду, в этой игре вся одежда какая-то уродская
Я так и не понял, почему он сдыхает после того, как впустить его в академию, он изучал какие-то не те кристаллы или что. Я, короче, не буду больше в это играть, наверное, так много сейчас. Я вроде бы прошёл всё, что мог, до перехода в мидгеймовые локации на севере, кроме ренналы и радана. Но проблема в том, что их прохождение - это, скорее всего, будет очень много депрессии на миллион траев из-за того, что у меня ноль хп на базовом лвле бандита. И я не уверен, что я готов к такому геймингу и не повешусь ли я от него случайно. А лвл тут качать уже не хочется, потому что как будто тогда неинтересно уже будет. И как будто пока что всё было более-менее терпимо даже так, но, скорее всего, мидгейм меня точно сломает, если я до него доберусь, я слишком анскилл для подобного
Я решил немного попробовать его и в итоге случайно убил его, и это, естественно, оказался самый идиотский трай, где я по-дебильному получил по лицу и где я тупо его блидом затыкал, а он даже не успел свои метеориты в меня запустить, нахуя я вообще, блять всё ещё живу, я не могу даже нормально играть в ебаную игру сука блять блять вообще никаких ничего зачем жить
Шизовые хитбоксы
Очень сильно хочется уже умереть, ничего хорошего не было и не будет и я буквально не могу ничего сделать, чтобы была нормальная жизнь, в любом случае, что бы я ни делал, я буду всегда страдать и всегда будет плохо и нету смысла никакого жить, просто полная безнадёжность примерно как в аду
>>746966
Тебе сколько, ОП? Сам живу в таком же состоянии, ни жив ни мёртв.
Тебе сколько, ОП? Сам живу в таком же состоянии, ни жив ни мёртв.
А, эти двое, оказывается уже сдохли просто автоматом, типичный дарк солс момент: сделал что-то не в том порядке и заруинил квест
>>746282
Всё же нашёл более-менее нормальную одежду
Всё же нашёл более-менее нормальную одежду
Не понимаю, что на экране происходит
Бить его по голове в основном. Во время того, как он кастует облака смерти, есть возможность в прыжке ударить. Когда он просто идёт на тебя, то пытаться стоять напротив него немного поодаль, чтобы успевать выкатываться из аое, и ждать опенинги, чтобы 1-2 раза ударить по голове.
Опенинги обычно бывают после того, как он две каких-то атаки сделал: два раза укусил, махнул лапой и ударил в землю, укусил и махнул лапой и тд, но во второй фазе это не всегда работает: у него появляются более длинные комбо. Перекатываться от его атак назад, два раза подряд, но, если видишь, что случайно сблизился с ним, то наоборот: вперёд под него, потому что иначе не успеваешь выкатиться из-под аое
В остальных случаях просто доджить все остальные атаки и ждать, из-за чего всё растягивается на минуты 4. Можно пытаться бегать у него под ногами и бить по ним, но он постоянно будет на тебя вешать электрический заряд, из-за чего не получится даже два раза нормально ударить подряд, будешь как мышь туда-сюда бегать, тяжело, хоть и будет быстрее, я думаю
Круговая атака во второй фазе доджится перекатом влево вроде довольно стабильно. Сквозь волны на земле можно перекатываться.
Текстовый туториал на босса, потому что ну правда неочевидно, что с ним делать, особенно, когда он почти всеми своими атаками меня ваншотит
Опенинги обычно бывают после того, как он две каких-то атаки сделал: два раза укусил, махнул лапой и ударил в землю, укусил и махнул лапой и тд, но во второй фазе это не всегда работает: у него появляются более длинные комбо. Перекатываться от его атак назад, два раза подряд, но, если видишь, что случайно сблизился с ним, то наоборот: вперёд под него, потому что иначе не успеваешь выкатиться из-под аое
В остальных случаях просто доджить все остальные атаки и ждать, из-за чего всё растягивается на минуты 4. Можно пытаться бегать у него под ногами и бить по ним, но он постоянно будет на тебя вешать электрический заряд, из-за чего не получится даже два раза нормально ударить подряд, будешь как мышь туда-сюда бегать, тяжело, хоть и будет быстрее, я думаю
Круговая атака во второй фазе доджится перекатом влево вроде довольно стабильно. Сквозь волны на земле можно перекатываться.
Текстовый туториал на босса, потому что ну правда неочевидно, что с ним делать, особенно, когда он почти всеми своими атаками меня ваншотит
>>746294
Ладно, она легко проходится на моём низком лвле и даже без оверлвл оружия, просто это долго
Ладно, она легко проходится на моём низком лвле и даже без оверлвл оружия, просто это долго
Короче, я увидел видрил 1 https://x.com/tsoding/status/1801321187730960501 (и ещё раньше видел типо квайны, которые печатают не сами себя, а другие проги, иногда на других яп) и подумал, что было бы прикольно сделать что-то похожее, но чтобы сам код программы изменялся со временем, и под эту идею плохо подходят часы, потому что их состояние не зависит от кода программы, больше подходит таймер. Типо получилось вот на скрине: код таймера, который отсчитывает 12 минут 34 секунды 567 миллисекунд. И, пока он отсчитывает время, то он выводит код программы и таймер, в него встроенный. И в любой момент, пока он отсчитывает время, можно скопировать это всё и получить код другого таймера, который будет отсчитывать время от момента, когда ты скопировал код. Или можно вручную цифры поменять, но это нужно заранее знать шрифт.
Проблема в том, что получилось говно и я ебаный отсталый даун, потому что
Во-первых, в консоли нет дабл буферинга, из-за чего в миллисекундах будет выводиться мусор с большой вероятностью, плюс я зачем-то трачу время на перерисовку вообще всего кода, хотя меняются только цифры, но это ладно, оно толерантно к мусору в цифрах.
Во-вторых, оно просто адово жирное и даже не убирается нормально на экран. Много места занимает шрифт, закодированный в инты, может быть, стоило бы кодировать в base64, сам блоб был бы компактнее, но тогда бы пришлось ещё впихнуть base64 декодер в код, неясно, было ли бы лучше. И/или добавить сжатие одинаковых подряд идущих символов с теми же издержками.
Плюс ещё аргументы принтфов раздувают код а их нужно использовать по той причине, что ты не можешь ни в каком виде в строковые литералы с кодом программы включить символы из набора: " % \. Эскейпить не выйдет, потому что тогда придётся эскейпить символы, КОТОРЫМИ ты эскейпишь, и в итоге тебе нужно бесконечно эскейпов. По этой же причине нельзя использовать \n. Поэтому нужно либо использовать %c + аски код символа в аргументах, либо нормальный вариант - это писать свой принтф, который будет автоматом эскейпить всё сам при выводе (это то, как сделал этот чел с первого видео, как я понял). Ну и всё нужно было делать более широким, чтобы уменьшить высоту.
В-третьих, я пытался код сделать выровненным, но вот в середине кусок строкового литерала обрывается в начале строки. Я бы мог забить оставшееся место просто ;;;;;;;;;; но проблема в том, что тогда эти точки с запятой нужно также добавить внутрь строкового литерала с кодом программы, то есть на самом деле нужно добавить количество символов равное половине оставшегося места, НО оно не делится на 2 и всё равно не будет выровнено. То есть придётся внизу менять код, чтобы добавить один символ где-то, но тогда сам код внизу съедет. И я не понимаю, как это всё выровнять, видимо, наоборот, пытаться сжать код, но как будто те же проблемы вылезут.
Кроме того, куча кринжа связанного с тем, чтобы выровнять код: опять же, бесполезные точки с запятой и кудрявые скобки, неоправданно длинные идентификаторы, шестнадцатеричные и восьмеричные интовые литералы, интовые литералы, переписанные как сумма маленького и большого, забивание комментов и строк бесполезными символами (надпись "time's up" в конце даже не успевает вывестись на экран, она моментально затирается, она там чисто для выравнивания). Единственное правило, которое пытался соблюдать - отсутствие лишних пробелов, но мог что-то пропустить случайно. Можно было бы эксплоитить всякую си шизу с тем, что, например, у переменных по дефолту тип инт и тп, но я в ней не особо разбираюсь и я не хочу. Плюс инклюд можно было бы добавить как аргумент компилятора, но тогда придётся добавлять в коммент инструкции по компиляции, а я хотел, чтобы оно компилилось просто как "cc quimer.c", по этой же причине использую какую-то непонятную c11 timespec_get ерунду: потому что она доступна на всех компиляторах и платформах вроде.
В-четвёртых, САМОЕ ГЛАВНОЕ ЭТО БЛЯТЬ ДАЖЕ НЕ КВАЙН, Я ДАУН И НЕ ОСИЛИЛ, я слишком поздно понял, что то, как я отформатировал литералы с кодом прораммы - это никак не отразится на том, что напечатается на экране. По этой причине на видео видно, что литералы печатаются просто в одну строку. У чела в видео - настоящий квайн, то есть его прога сама себя печатает (он чёто не показал дифф), у меня печатает только в лучшем случае наполовину такую же программу.
Как исправить, оставив выравнивание - я не знаю. С принтф это точно невозможно, потому что ты обязан переносить литерал именно только там, где есть перенос в коде, и вставлять туда %c для новой строки. И код в строковом литерале будет длиннее самого кода, то есть по крайней мере они не могут быть выровнены на одну ширину. У чела в видео с кастомным принтфом тоже так, если посмотреть: каждый кусок литерала заканчивается на \n и он вручную при выводе после переносов строк добавляет двойные кавычки (код в конце p('\\');p('n');p('"');p('\n');p('"')).
Решается это, скорее всего, тем, что опять же, делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы. Плюс иметь удачу или большой мозг, чтобы в итоге всё красиво вручную выровнять, либо ещё более большой мозг, чтобы написать прогу, которая выравнивает всё сама, применяя всякие ухищрения. И эта прога - это всё ещё, к сожалению, не чат джипити инб4 ты неправильно объясняешь, что нужно сделать, к тому же слепить всё в одну строку, убрав пробелы даже там, где нельзя - это тоже валидный вариант выровнять код, ты ведь не указал максимальную длину строки А я же реально жду, когда смогу попросить его сгенерировать аски арт и получить в ответ что-то отличное от рандомного набора символов, ну и в целом, момента, когда оно будет способно на что-то реально интересное само по себе, и искренне надеюсь, что это когда-нибудь случится, но пока что это просто сплошное разочарование какое-то.
Ну и ещё одна причина, по которой это даже в теории не может быть квайном - это то, что это более-менее честный таймер и "запускается" он как можно быстрее после запуска программы, после чего перед выводом цифр тратится немного времени по крайней мере на то, чтобы распарсить шрифт из массива интов, из-за чего на момент вывода цифр в консоль там уже останется меньше времени, чем написано в коде программы.
Единственный более-менее прикольный момент этой проги - это то, что вот эти большие цифры посередине - это именно то, что определяет, на сколько минут/секунд запустится таймер, и типо видно на видео, что пока таймер крутится, то кроме самих цифр в коде ничего больше не меняется, ну и я вручную именно цифры поменял и тем самым задал время. (Если честно, я настолько блять тупой, что только когда начал это всё делать, понял, что я же могу просто в коде переменным присвоить количество минут, секунд и миллисекунд, и вся эта идея имеет ОЧЕНЬ МАЛО СМЫСЛА.) Чтобы это реализовать, я считаю что-то типо хэша: взвешенную сумму всех символов, составляющих глиф. Веса зависят от типов символов (ну, пробел, вертикальная черта, нижнее подчёркивание, иначе сумма всех символов одинакова у всех глифов, потому что шрифт моноширинный) + от игрек координаты (потому что иначе у 6 и 9 и у 5 и 2 получаются всегда попарно одинаковые хэши). Ну и дальше просто типо очень упрощённая хэш таблица без коллизий, но кринжовая, потому что на 12 элементов требуется целых 35 ячеек. И все неактивные ячейки забиты нулями и это то, благодаря чему оно не особо сходит с ума от мусорных символов, но, наверное, всё ещё может сделать что-то странное, если хэш попадёт в ячейку с точкой или точкой с запятой. Ну и ещё неприятно то, что вероятно даже мелкие изменения в символах, визуально ничего не меняющие, возможно, будут кардинально менять то, как они интерпретируются.
Короче, это моя вторая попытка сделать квайн, в первый раз получился вообще полный мусор, но то был хотя бы действительно квайн (я там просто код программы внутри строки закодировал в base64, типа чтобы было не совсем очевидно, что это квайн, и тоже просто принтф использовал). А тут я не осилил даже квайн сделать в итоге.
Проблема в том, что получилось говно и я ебаный отсталый даун, потому что
Во-первых, в консоли нет дабл буферинга, из-за чего в миллисекундах будет выводиться мусор с большой вероятностью, плюс я зачем-то трачу время на перерисовку вообще всего кода, хотя меняются только цифры, но это ладно, оно толерантно к мусору в цифрах.
Во-вторых, оно просто адово жирное и даже не убирается нормально на экран. Много места занимает шрифт, закодированный в инты, может быть, стоило бы кодировать в base64, сам блоб был бы компактнее, но тогда бы пришлось ещё впихнуть base64 декодер в код, неясно, было ли бы лучше. И/или добавить сжатие одинаковых подряд идущих символов с теми же издержками.
Плюс ещё аргументы принтфов раздувают код а их нужно использовать по той причине, что ты не можешь ни в каком виде в строковые литералы с кодом программы включить символы из набора: " % \. Эскейпить не выйдет, потому что тогда придётся эскейпить символы, КОТОРЫМИ ты эскейпишь, и в итоге тебе нужно бесконечно эскейпов. По этой же причине нельзя использовать \n. Поэтому нужно либо использовать %c + аски код символа в аргументах, либо нормальный вариант - это писать свой принтф, который будет автоматом эскейпить всё сам при выводе (это то, как сделал этот чел с первого видео, как я понял). Ну и всё нужно было делать более широким, чтобы уменьшить высоту.
В-третьих, я пытался код сделать выровненным, но вот в середине кусок строкового литерала обрывается в начале строки. Я бы мог забить оставшееся место просто ;;;;;;;;;; но проблема в том, что тогда эти точки с запятой нужно также добавить внутрь строкового литерала с кодом программы, то есть на самом деле нужно добавить количество символов равное половине оставшегося места, НО оно не делится на 2 и всё равно не будет выровнено. То есть придётся внизу менять код, чтобы добавить один символ где-то, но тогда сам код внизу съедет. И я не понимаю, как это всё выровнять, видимо, наоборот, пытаться сжать код, но как будто те же проблемы вылезут.
Кроме того, куча кринжа связанного с тем, чтобы выровнять код: опять же, бесполезные точки с запятой и кудрявые скобки, неоправданно длинные идентификаторы, шестнадцатеричные и восьмеричные интовые литералы, интовые литералы, переписанные как сумма маленького и большого, забивание комментов и строк бесполезными символами (надпись "time's up" в конце даже не успевает вывестись на экран, она моментально затирается, она там чисто для выравнивания). Единственное правило, которое пытался соблюдать - отсутствие лишних пробелов, но мог что-то пропустить случайно. Можно было бы эксплоитить всякую си шизу с тем, что, например, у переменных по дефолту тип инт и тп, но я в ней не особо разбираюсь и я не хочу. Плюс инклюд можно было бы добавить как аргумент компилятора, но тогда придётся добавлять в коммент инструкции по компиляции, а я хотел, чтобы оно компилилось просто как "cc quimer.c", по этой же причине использую какую-то непонятную c11 timespec_get ерунду: потому что она доступна на всех компиляторах и платформах вроде.
В-четвёртых, САМОЕ ГЛАВНОЕ ЭТО БЛЯТЬ ДАЖЕ НЕ КВАЙН, Я ДАУН И НЕ ОСИЛИЛ, я слишком поздно понял, что то, как я отформатировал литералы с кодом прораммы - это никак не отразится на том, что напечатается на экране. По этой причине на видео видно, что литералы печатаются просто в одну строку. У чела в видео - настоящий квайн, то есть его прога сама себя печатает (он чёто не показал дифф), у меня печатает только в лучшем случае наполовину такую же программу.
Как исправить, оставив выравнивание - я не знаю. С принтф это точно невозможно, потому что ты обязан переносить литерал именно только там, где есть перенос в коде, и вставлять туда %c для новой строки. И код в строковом литерале будет длиннее самого кода, то есть по крайней мере они не могут быть выровнены на одну ширину. У чела в видео с кастомным принтфом тоже так, если посмотреть: каждый кусок литерала заканчивается на \n и он вручную при выводе после переносов строк добавляет двойные кавычки (код в конце p('\\');p('n');p('"');p('\n');p('"')).
Решается это, скорее всего, тем, что опять же, делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы. Плюс иметь удачу или большой мозг, чтобы в итоге всё красиво вручную выровнять, либо ещё более большой мозг, чтобы написать прогу, которая выравнивает всё сама, применяя всякие ухищрения. И эта прога - это всё ещё, к сожалению, не чат джипити инб4 ты неправильно объясняешь, что нужно сделать, к тому же слепить всё в одну строку, убрав пробелы даже там, где нельзя - это тоже валидный вариант выровнять код, ты ведь не указал максимальную длину строки А я же реально жду, когда смогу попросить его сгенерировать аски арт и получить в ответ что-то отличное от рандомного набора символов, ну и в целом, момента, когда оно будет способно на что-то реально интересное само по себе, и искренне надеюсь, что это когда-нибудь случится, но пока что это просто сплошное разочарование какое-то.
Ну и ещё одна причина, по которой это даже в теории не может быть квайном - это то, что это более-менее честный таймер и "запускается" он как можно быстрее после запуска программы, после чего перед выводом цифр тратится немного времени по крайней мере на то, чтобы распарсить шрифт из массива интов, из-за чего на момент вывода цифр в консоль там уже останется меньше времени, чем написано в коде программы.
Единственный более-менее прикольный момент этой проги - это то, что вот эти большие цифры посередине - это именно то, что определяет, на сколько минут/секунд запустится таймер, и типо видно на видео, что пока таймер крутится, то кроме самих цифр в коде ничего больше не меняется, ну и я вручную именно цифры поменял и тем самым задал время. (Если честно, я настолько блять тупой, что только когда начал это всё делать, понял, что я же могу просто в коде переменным присвоить количество минут, секунд и миллисекунд, и вся эта идея имеет ОЧЕНЬ МАЛО СМЫСЛА.) Чтобы это реализовать, я считаю что-то типо хэша: взвешенную сумму всех символов, составляющих глиф. Веса зависят от типов символов (ну, пробел, вертикальная черта, нижнее подчёркивание, иначе сумма всех символов одинакова у всех глифов, потому что шрифт моноширинный) + от игрек координаты (потому что иначе у 6 и 9 и у 5 и 2 получаются всегда попарно одинаковые хэши). Ну и дальше просто типо очень упрощённая хэш таблица без коллизий, но кринжовая, потому что на 12 элементов требуется целых 35 ячеек. И все неактивные ячейки забиты нулями и это то, благодаря чему оно не особо сходит с ума от мусорных символов, но, наверное, всё ещё может сделать что-то странное, если хэш попадёт в ячейку с точкой или точкой с запятой. Ну и ещё неприятно то, что вероятно даже мелкие изменения в символах, визуально ничего не меняющие, возможно, будут кардинально менять то, как они интерпретируются.
Короче, это моя вторая попытка сделать квайн, в первый раз получился вообще полный мусор, но то был хотя бы действительно квайн (я там просто код программы внутри строки закодировал в base64, типа чтобы было не совсем очевидно, что это квайн, и тоже просто принтф использовал). А тут я не осилил даже квайн сделать в итоге.
Короче, я увидел видрил 1 https://x.com/tsoding/status/1801321187730960501 (и ещё раньше видел типо квайны, которые печатают не сами себя, а другие проги, иногда на других яп) и подумал, что было бы прикольно сделать что-то похожее, но чтобы сам код программы изменялся со временем, и под эту идею плохо подходят часы, потому что их состояние не зависит от кода программы, больше подходит таймер. Типо получилось вот на скрине: код таймера, который отсчитывает 12 минут 34 секунды 567 миллисекунд. И, пока он отсчитывает время, то он выводит код программы и таймер, в него встроенный. И в любой момент, пока он отсчитывает время, можно скопировать это всё и получить код другого таймера, который будет отсчитывать время от момента, когда ты скопировал код. Или можно вручную цифры поменять, но это нужно заранее знать шрифт.
Проблема в том, что получилось говно и я ебаный отсталый даун, потому что
Во-первых, в консоли нет дабл буферинга, из-за чего в миллисекундах будет выводиться мусор с большой вероятностью, плюс я зачем-то трачу время на перерисовку вообще всего кода, хотя меняются только цифры, но это ладно, оно толерантно к мусору в цифрах.
Во-вторых, оно просто адово жирное и даже не убирается нормально на экран. Много места занимает шрифт, закодированный в инты, может быть, стоило бы кодировать в base64, сам блоб был бы компактнее, но тогда бы пришлось ещё впихнуть base64 декодер в код, неясно, было ли бы лучше. И/или добавить сжатие одинаковых подряд идущих символов с теми же издержками.
Плюс ещё аргументы принтфов раздувают код а их нужно использовать по той причине, что ты не можешь ни в каком виде в строковые литералы с кодом программы включить символы из набора: " % \. Эскейпить не выйдет, потому что тогда придётся эскейпить символы, КОТОРЫМИ ты эскейпишь, и в итоге тебе нужно бесконечно эскейпов. По этой же причине нельзя использовать \n. Поэтому нужно либо использовать %c + аски код символа в аргументах, либо нормальный вариант - это писать свой принтф, который будет автоматом эскейпить всё сам при выводе (это то, как сделал этот чел с первого видео, как я понял). Ну и всё нужно было делать более широким, чтобы уменьшить высоту.
В-третьих, я пытался код сделать выровненным, но вот в середине кусок строкового литерала обрывается в начале строки. Я бы мог забить оставшееся место просто ;;;;;;;;;; но проблема в том, что тогда эти точки с запятой нужно также добавить внутрь строкового литерала с кодом программы, то есть на самом деле нужно добавить количество символов равное половине оставшегося места, НО оно не делится на 2 и всё равно не будет выровнено. То есть придётся внизу менять код, чтобы добавить один символ где-то, но тогда сам код внизу съедет. И я не понимаю, как это всё выровнять, видимо, наоборот, пытаться сжать код, но как будто те же проблемы вылезут.
Кроме того, куча кринжа связанного с тем, чтобы выровнять код: опять же, бесполезные точки с запятой и кудрявые скобки, неоправданно длинные идентификаторы, шестнадцатеричные и восьмеричные интовые литералы, интовые литералы, переписанные как сумма маленького и большого, забивание комментов и строк бесполезными символами (надпись "time's up" в конце даже не успевает вывестись на экран, она моментально затирается, она там чисто для выравнивания). Единственное правило, которое пытался соблюдать - отсутствие лишних пробелов, но мог что-то пропустить случайно. Можно было бы эксплоитить всякую си шизу с тем, что, например, у переменных по дефолту тип инт и тп, но я в ней не особо разбираюсь и я не хочу. Плюс инклюд можно было бы добавить как аргумент компилятора, но тогда придётся добавлять в коммент инструкции по компиляции, а я хотел, чтобы оно компилилось просто как "cc quimer.c", по этой же причине использую какую-то непонятную c11 timespec_get ерунду: потому что она доступна на всех компиляторах и платформах вроде.
В-четвёртых, САМОЕ ГЛАВНОЕ ЭТО БЛЯТЬ ДАЖЕ НЕ КВАЙН, Я ДАУН И НЕ ОСИЛИЛ, я слишком поздно понял, что то, как я отформатировал литералы с кодом прораммы - это никак не отразится на том, что напечатается на экране. По этой причине на видео видно, что литералы печатаются просто в одну строку. У чела в видео - настоящий квайн, то есть его прога сама себя печатает (он чёто не показал дифф), у меня печатает только в лучшем случае наполовину такую же программу.
Как исправить, оставив выравнивание - я не знаю. С принтф это точно невозможно, потому что ты обязан переносить литерал именно только там, где есть перенос в коде, и вставлять туда %c для новой строки. И код в строковом литерале будет длиннее самого кода, то есть по крайней мере они не могут быть выровнены на одну ширину. У чела в видео с кастомным принтфом тоже так, если посмотреть: каждый кусок литерала заканчивается на \n и он вручную при выводе после переносов строк добавляет двойные кавычки (код в конце p('\\');p('n');p('"');p('\n');p('"')).
Решается это, скорее всего, тем, что опять же, делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы. Плюс иметь удачу или большой мозг, чтобы в итоге всё красиво вручную выровнять, либо ещё более большой мозг, чтобы написать прогу, которая выравнивает всё сама, применяя всякие ухищрения. И эта прога - это всё ещё, к сожалению, не чат джипити инб4 ты неправильно объясняешь, что нужно сделать, к тому же слепить всё в одну строку, убрав пробелы даже там, где нельзя - это тоже валидный вариант выровнять код, ты ведь не указал максимальную длину строки А я же реально жду, когда смогу попросить его сгенерировать аски арт и получить в ответ что-то отличное от рандомного набора символов, ну и в целом, момента, когда оно будет способно на что-то реально интересное само по себе, и искренне надеюсь, что это когда-нибудь случится, но пока что это просто сплошное разочарование какое-то.
Ну и ещё одна причина, по которой это даже в теории не может быть квайном - это то, что это более-менее честный таймер и "запускается" он как можно быстрее после запуска программы, после чего перед выводом цифр тратится немного времени по крайней мере на то, чтобы распарсить шрифт из массива интов, из-за чего на момент вывода цифр в консоль там уже останется меньше времени, чем написано в коде программы.
Единственный более-менее прикольный момент этой проги - это то, что вот эти большие цифры посередине - это именно то, что определяет, на сколько минут/секунд запустится таймер, и типо видно на видео, что пока таймер крутится, то кроме самих цифр в коде ничего больше не меняется, ну и я вручную именно цифры поменял и тем самым задал время. (Если честно, я настолько блять тупой, что только когда начал это всё делать, понял, что я же могу просто в коде переменным присвоить количество минут, секунд и миллисекунд, и вся эта идея имеет ОЧЕНЬ МАЛО СМЫСЛА.) Чтобы это реализовать, я считаю что-то типо хэша: взвешенную сумму всех символов, составляющих глиф. Веса зависят от типов символов (ну, пробел, вертикальная черта, нижнее подчёркивание, иначе сумма всех символов одинакова у всех глифов, потому что шрифт моноширинный) + от игрек координаты (потому что иначе у 6 и 9 и у 5 и 2 получаются всегда попарно одинаковые хэши). Ну и дальше просто типо очень упрощённая хэш таблица без коллизий, но кринжовая, потому что на 12 элементов требуется целых 35 ячеек. И все неактивные ячейки забиты нулями и это то, благодаря чему оно не особо сходит с ума от мусорных символов, но, наверное, всё ещё может сделать что-то странное, если хэш попадёт в ячейку с точкой или точкой с запятой. Ну и ещё неприятно то, что вероятно даже мелкие изменения в символах, визуально ничего не меняющие, возможно, будут кардинально менять то, как они интерпретируются.
Короче, это моя вторая попытка сделать квайн, в первый раз получился вообще полный мусор, но то был хотя бы действительно квайн (я там просто код программы внутри строки закодировал в base64, типа чтобы было не совсем очевидно, что это квайн, и тоже просто принтф использовал). А тут я не осилил даже квайн сделать в итоге.
Проблема в том, что получилось говно и я ебаный отсталый даун, потому что
Во-первых, в консоли нет дабл буферинга, из-за чего в миллисекундах будет выводиться мусор с большой вероятностью, плюс я зачем-то трачу время на перерисовку вообще всего кода, хотя меняются только цифры, но это ладно, оно толерантно к мусору в цифрах.
Во-вторых, оно просто адово жирное и даже не убирается нормально на экран. Много места занимает шрифт, закодированный в инты, может быть, стоило бы кодировать в base64, сам блоб был бы компактнее, но тогда бы пришлось ещё впихнуть base64 декодер в код, неясно, было ли бы лучше. И/или добавить сжатие одинаковых подряд идущих символов с теми же издержками.
Плюс ещё аргументы принтфов раздувают код а их нужно использовать по той причине, что ты не можешь ни в каком виде в строковые литералы с кодом программы включить символы из набора: " % \. Эскейпить не выйдет, потому что тогда придётся эскейпить символы, КОТОРЫМИ ты эскейпишь, и в итоге тебе нужно бесконечно эскейпов. По этой же причине нельзя использовать \n. Поэтому нужно либо использовать %c + аски код символа в аргументах, либо нормальный вариант - это писать свой принтф, который будет автоматом эскейпить всё сам при выводе (это то, как сделал этот чел с первого видео, как я понял). Ну и всё нужно было делать более широким, чтобы уменьшить высоту.
В-третьих, я пытался код сделать выровненным, но вот в середине кусок строкового литерала обрывается в начале строки. Я бы мог забить оставшееся место просто ;;;;;;;;;; но проблема в том, что тогда эти точки с запятой нужно также добавить внутрь строкового литерала с кодом программы, то есть на самом деле нужно добавить количество символов равное половине оставшегося места, НО оно не делится на 2 и всё равно не будет выровнено. То есть придётся внизу менять код, чтобы добавить один символ где-то, но тогда сам код внизу съедет. И я не понимаю, как это всё выровнять, видимо, наоборот, пытаться сжать код, но как будто те же проблемы вылезут.
Кроме того, куча кринжа связанного с тем, чтобы выровнять код: опять же, бесполезные точки с запятой и кудрявые скобки, неоправданно длинные идентификаторы, шестнадцатеричные и восьмеричные интовые литералы, интовые литералы, переписанные как сумма маленького и большого, забивание комментов и строк бесполезными символами (надпись "time's up" в конце даже не успевает вывестись на экран, она моментально затирается, она там чисто для выравнивания). Единственное правило, которое пытался соблюдать - отсутствие лишних пробелов, но мог что-то пропустить случайно. Можно было бы эксплоитить всякую си шизу с тем, что, например, у переменных по дефолту тип инт и тп, но я в ней не особо разбираюсь и я не хочу. Плюс инклюд можно было бы добавить как аргумент компилятора, но тогда придётся добавлять в коммент инструкции по компиляции, а я хотел, чтобы оно компилилось просто как "cc quimer.c", по этой же причине использую какую-то непонятную c11 timespec_get ерунду: потому что она доступна на всех компиляторах и платформах вроде.
В-четвёртых, САМОЕ ГЛАВНОЕ ЭТО БЛЯТЬ ДАЖЕ НЕ КВАЙН, Я ДАУН И НЕ ОСИЛИЛ, я слишком поздно понял, что то, как я отформатировал литералы с кодом прораммы - это никак не отразится на том, что напечатается на экране. По этой причине на видео видно, что литералы печатаются просто в одну строку. У чела в видео - настоящий квайн, то есть его прога сама себя печатает (он чёто не показал дифф), у меня печатает только в лучшем случае наполовину такую же программу.
Как исправить, оставив выравнивание - я не знаю. С принтф это точно невозможно, потому что ты обязан переносить литерал именно только там, где есть перенос в коде, и вставлять туда %c для новой строки. И код в строковом литерале будет длиннее самого кода, то есть по крайней мере они не могут быть выровнены на одну ширину. У чела в видео с кастомным принтфом тоже так, если посмотреть: каждый кусок литерала заканчивается на \n и он вручную при выводе после переносов строк добавляет двойные кавычки (код в конце p('\\');p('n');p('"');p('\n');p('"')).
Решается это, скорее всего, тем, что опять же, делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы. Плюс иметь удачу или большой мозг, чтобы в итоге всё красиво вручную выровнять, либо ещё более большой мозг, чтобы написать прогу, которая выравнивает всё сама, применяя всякие ухищрения. И эта прога - это всё ещё, к сожалению, не чат джипити инб4 ты неправильно объясняешь, что нужно сделать, к тому же слепить всё в одну строку, убрав пробелы даже там, где нельзя - это тоже валидный вариант выровнять код, ты ведь не указал максимальную длину строки А я же реально жду, когда смогу попросить его сгенерировать аски арт и получить в ответ что-то отличное от рандомного набора символов, ну и в целом, момента, когда оно будет способно на что-то реально интересное само по себе, и искренне надеюсь, что это когда-нибудь случится, но пока что это просто сплошное разочарование какое-то.
Ну и ещё одна причина, по которой это даже в теории не может быть квайном - это то, что это более-менее честный таймер и "запускается" он как можно быстрее после запуска программы, после чего перед выводом цифр тратится немного времени по крайней мере на то, чтобы распарсить шрифт из массива интов, из-за чего на момент вывода цифр в консоль там уже останется меньше времени, чем написано в коде программы.
Единственный более-менее прикольный момент этой проги - это то, что вот эти большие цифры посередине - это именно то, что определяет, на сколько минут/секунд запустится таймер, и типо видно на видео, что пока таймер крутится, то кроме самих цифр в коде ничего больше не меняется, ну и я вручную именно цифры поменял и тем самым задал время. (Если честно, я настолько блять тупой, что только когда начал это всё делать, понял, что я же могу просто в коде переменным присвоить количество минут, секунд и миллисекунд, и вся эта идея имеет ОЧЕНЬ МАЛО СМЫСЛА.) Чтобы это реализовать, я считаю что-то типо хэша: взвешенную сумму всех символов, составляющих глиф. Веса зависят от типов символов (ну, пробел, вертикальная черта, нижнее подчёркивание, иначе сумма всех символов одинакова у всех глифов, потому что шрифт моноширинный) + от игрек координаты (потому что иначе у 6 и 9 и у 5 и 2 получаются всегда попарно одинаковые хэши). Ну и дальше просто типо очень упрощённая хэш таблица без коллизий, но кринжовая, потому что на 12 элементов требуется целых 35 ячеек. И все неактивные ячейки забиты нулями и это то, благодаря чему оно не особо сходит с ума от мусорных символов, но, наверное, всё ещё может сделать что-то странное, если хэш попадёт в ячейку с точкой или точкой с запятой. Ну и ещё неприятно то, что вероятно даже мелкие изменения в символах, визуально ничего не меняющие, возможно, будут кардинально менять то, как они интерпретируются.
Короче, это моя вторая попытка сделать квайн, в первый раз получился вообще полный мусор, но то был хотя бы действительно квайн (я там просто код программы внутри строки закодировал в base64, типа чтобы было не совсем очевидно, что это квайн, и тоже просто принтф использовал). А тут я не осилил даже квайн сделать в итоге.
Короче, я увидел пикрил 1 (https://x.com/tsoding/status/1433170025796472836) и подумал, что, может быть, эта идея сработала бы для квайна: сделать таблицу используемых символов в программе, а сам текст программы закодировать как последовательность индексов из этой таблицы. И я заодно ещё попробовал эту свою идею:
>>747408
Получился пикрил 2 он просто печатает сам себя если что https://godbolt.org/z/odWGK7K13 и даже, после некоторых мучений в попытках скукожить код "23 умножить на 3" вместо 69 - это попытка скукожить, а не раздуть, потому что это сокращает таблицу символов, случайно получился ровный прямоугольник.
Индексы, идущие в таблицу символов (переменная t), записал в строку (переменная s) через печатаемые аски символы, получается, тут есть оверхед в записи кода программы из-за того, что индексы 6-битные, но каждый записан символом, который кодирует 8 бит, и я не знаю, как можно эффективно в код впихнуть последовательность 6-битных чисел. То есть я тупой еблан и буквально ничего не выигрываю этим и только раздуваю код необходимостью хранить таблицу.
>>747408
>делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы
Получился пикрил 2 он просто печатает сам себя если что https://godbolt.org/z/odWGK7K13 и даже, после некоторых мучений в попытках скукожить код "23 умножить на 3" вместо 69 - это попытка скукожить, а не раздуть, потому что это сокращает таблицу символов, случайно получился ровный прямоугольник.
Индексы, идущие в таблицу символов (переменная t), записал в строку (переменная s) через печатаемые аски символы, получается, тут есть оверхед в записи кода программы из-за того, что индексы 6-битные, но каждый записан символом, который кодирует 8 бит, и я не знаю, как можно эффективно в код впихнуть последовательность 6-битных чисел. То есть я тупой еблан и буквально ничего не выигрываю этим и только раздуваю код необходимостью хранить таблицу.
>>739489
Эта шиза снова прогрессирует, добавил в типо контекст в дополнение к основному аллокатору дополнительный для всякого временного мусора, который бы не замусоривал основной и который можно было бы периодически чистить полностью. И проблема в том, что это именно должен быть отдельный второй аллокатор, потому что иногда функция может одновременно захотеть и выделить что-то с долгим лайфтаймом, и выделить что-то для использования чисто внутри неё самой (например, utf-16 строку, чтобы передать в виндовое апи). Из-за чего приходится раздваивать некоторые функции на обычную версию, которая создаёт что-то, используя основной аллокатор, и "временную", которая использует временный аллокатор и не мусорит в основной. Переделал динамические массивы на отдельные функции вместо макросов, которые инлайнят реализации функций на месте. Не знаю, зачем, потому что теперь невозможно использовать sizeof, чтобы узнать размер элемента, и нельзя пушить литералы, потому что тут, оказывается, нельзя брать указатели на rvalue, которые являются литералами? В итоге бред какой-то получается и сам массив какой-то жирный теперь. В итоге не уверен, что мне это всё нравится, но, неважно, я слишком тупой в любом случае ничего неважно
Я думал ещё про то, хочу ли я какие-нибудь шизоидные проверки на переполнение интов, когда выделяю память, но первая проблема в том, что это скользкая дорожка к тому, чтобы делать бесполезные проверки вообще любой степени шизовости вообще везде, а вторая - а какой вообще реалистичный сценарий того, что кто-то захочет выделить что-то вроде, например, 20000 элементов каждый из которых размером 1000 терабайтов? Или даже что-то отдалённо близкое к этому, где не было бы переполнения при перемножении. Если это происходит при чтении какого-то пользовательского ввода, например, читаешь в память битмаповый шрифт из файла и типо, допустим, там прописано, что размер какого-то глифа = миллиард миллиардов пикселей, то все эти проверки, наверное, должны быть именно там, где ты парсишь этот файл, и там у этих проверок к тому же есть шанс быть более разумными. Например, сделать лимит на размер одного глифа условно 100x100 пикселей. Если это какой-то алгоритм, которому нужна дополнительная память, то он вряд ли сразу захочет так много памяти выделить, скорее постепенно будет съедать больше и больше, и более вероятно отвалится на моменте, когда попытается выделить даже пару десятков гигабайт, гораздо раньше, чем там что-то переполнится. Короче, наверное, в этом нет смысла.
>>747408
Кстати, вроде можно было бы немного сократить строку, если заменить в ней длинные числа из массива с шрифтом (переменная ef) на %llu и в принтф аргументы передать через ef[0], ef[1] и тд, хотя, скорее всего, в итоге в лучшем случае никакой разницы не будет из-за того, что эти ef[0], ef[1] придётся в строку тоже добавить. Вообще, наверное, лучше в строку кодировать шрифт
Эта шиза снова прогрессирует, добавил в типо контекст в дополнение к основному аллокатору дополнительный для всякого временного мусора, который бы не замусоривал основной и который можно было бы периодически чистить полностью. И проблема в том, что это именно должен быть отдельный второй аллокатор, потому что иногда функция может одновременно захотеть и выделить что-то с долгим лайфтаймом, и выделить что-то для использования чисто внутри неё самой (например, utf-16 строку, чтобы передать в виндовое апи). Из-за чего приходится раздваивать некоторые функции на обычную версию, которая создаёт что-то, используя основной аллокатор, и "временную", которая использует временный аллокатор и не мусорит в основной. Переделал динамические массивы на отдельные функции вместо макросов, которые инлайнят реализации функций на месте. Не знаю, зачем, потому что теперь невозможно использовать sizeof, чтобы узнать размер элемента, и нельзя пушить литералы, потому что тут, оказывается, нельзя брать указатели на rvalue, которые являются литералами? В итоге бред какой-то получается и сам массив какой-то жирный теперь. В итоге не уверен, что мне это всё нравится, но, неважно, я слишком тупой в любом случае ничего неважно
Я думал ещё про то, хочу ли я какие-нибудь шизоидные проверки на переполнение интов, когда выделяю память, но первая проблема в том, что это скользкая дорожка к тому, чтобы делать бесполезные проверки вообще любой степени шизовости вообще везде, а вторая - а какой вообще реалистичный сценарий того, что кто-то захочет выделить что-то вроде, например, 20000 элементов каждый из которых размером 1000 терабайтов? Или даже что-то отдалённо близкое к этому, где не было бы переполнения при перемножении. Если это происходит при чтении какого-то пользовательского ввода, например, читаешь в память битмаповый шрифт из файла и типо, допустим, там прописано, что размер какого-то глифа = миллиард миллиардов пикселей, то все эти проверки, наверное, должны быть именно там, где ты парсишь этот файл, и там у этих проверок к тому же есть шанс быть более разумными. Например, сделать лимит на размер одного глифа условно 100x100 пикселей. Если это какой-то алгоритм, которому нужна дополнительная память, то он вряд ли сразу захочет так много памяти выделить, скорее постепенно будет съедать больше и больше, и более вероятно отвалится на моменте, когда попытается выделить даже пару десятков гигабайт, гораздо раньше, чем там что-то переполнится. Короче, наверное, в этом нет смысла.
>>747408
Кстати, вроде можно было бы немного сократить строку, если заменить в ней длинные числа из массива с шрифтом (переменная ef) на %llu и в принтф аргументы передать через ef[0], ef[1] и тд, хотя, скорее всего, в итоге в лучшем случае никакой разницы не будет из-за того, что эти ef[0], ef[1] придётся в строку тоже добавить. Вообще, наверное, лучше в строку кодировать шрифт
>>739489
Эта шиза снова прогрессирует, добавил в типо контекст в дополнение к основному аллокатору дополнительный для всякого временного мусора, который бы не замусоривал основной и который можно было бы периодически чистить полностью. И проблема в том, что это именно должен быть отдельный второй аллокатор, потому что иногда функция может одновременно захотеть и выделить что-то с долгим лайфтаймом, и выделить что-то для использования чисто внутри неё самой (например, utf-16 строку, чтобы передать в виндовое апи). Из-за чего приходится раздваивать некоторые функции на обычную версию, которая создаёт что-то, используя основной аллокатор, и "временную", которая использует временный аллокатор и не мусорит в основной. Переделал динамические массивы на отдельные функции вместо макросов, которые инлайнят реализации функций на месте. Не знаю, зачем, потому что теперь невозможно использовать sizeof, чтобы узнать размер элемента, и нельзя пушить литералы, потому что тут, оказывается, нельзя брать указатели на rvalue, которые являются литералами? В итоге бред какой-то получается и сам массив какой-то жирный теперь. В итоге не уверен, что мне это всё нравится, но, неважно, я слишком тупой в любом случае ничего неважно
Я думал ещё про то, хочу ли я какие-нибудь шизоидные проверки на переполнение интов, когда выделяю память, но первая проблема в том, что это скользкая дорожка к тому, чтобы делать бесполезные проверки вообще любой степени шизовости вообще везде, а вторая - а какой вообще реалистичный сценарий того, что кто-то захочет выделить что-то вроде, например, 20000 элементов каждый из которых размером 1000 терабайтов? Или даже что-то отдалённо близкое к этому, где не было бы переполнения при перемножении. Если это происходит при чтении какого-то пользовательского ввода, например, читаешь в память битмаповый шрифт из файла и типо, допустим, там прописано, что размер какого-то глифа = миллиард миллиардов пикселей, то все эти проверки, наверное, должны быть именно там, где ты парсишь этот файл, и там у этих проверок к тому же есть шанс быть более разумными. Например, сделать лимит на размер одного глифа условно 100x100 пикселей. Если это какой-то алгоритм, которому нужна дополнительная память, то он вряд ли сразу захочет так много памяти выделить, скорее постепенно будет съедать больше и больше, и более вероятно отвалится на моменте, когда попытается выделить даже пару десятков гигабайт, гораздо раньше, чем там что-то переполнится. Короче, наверное, в этом нет смысла.
>>747408
Кстати, вроде можно было бы немного сократить строку, если заменить в ней длинные числа из массива с шрифтом (переменная ef) на %llu и в принтф аргументы передать через ef[0], ef[1] и тд, хотя, скорее всего, в итоге в лучшем случае никакой разницы не будет из-за того, что эти ef[0], ef[1] придётся в строку тоже добавить. Вообще, наверное, лучше в строку кодировать шрифт
Эта шиза снова прогрессирует, добавил в типо контекст в дополнение к основному аллокатору дополнительный для всякого временного мусора, который бы не замусоривал основной и который можно было бы периодически чистить полностью. И проблема в том, что это именно должен быть отдельный второй аллокатор, потому что иногда функция может одновременно захотеть и выделить что-то с долгим лайфтаймом, и выделить что-то для использования чисто внутри неё самой (например, utf-16 строку, чтобы передать в виндовое апи). Из-за чего приходится раздваивать некоторые функции на обычную версию, которая создаёт что-то, используя основной аллокатор, и "временную", которая использует временный аллокатор и не мусорит в основной. Переделал динамические массивы на отдельные функции вместо макросов, которые инлайнят реализации функций на месте. Не знаю, зачем, потому что теперь невозможно использовать sizeof, чтобы узнать размер элемента, и нельзя пушить литералы, потому что тут, оказывается, нельзя брать указатели на rvalue, которые являются литералами? В итоге бред какой-то получается и сам массив какой-то жирный теперь. В итоге не уверен, что мне это всё нравится, но, неважно, я слишком тупой в любом случае ничего неважно
Я думал ещё про то, хочу ли я какие-нибудь шизоидные проверки на переполнение интов, когда выделяю память, но первая проблема в том, что это скользкая дорожка к тому, чтобы делать бесполезные проверки вообще любой степени шизовости вообще везде, а вторая - а какой вообще реалистичный сценарий того, что кто-то захочет выделить что-то вроде, например, 20000 элементов каждый из которых размером 1000 терабайтов? Или даже что-то отдалённо близкое к этому, где не было бы переполнения при перемножении. Если это происходит при чтении какого-то пользовательского ввода, например, читаешь в память битмаповый шрифт из файла и типо, допустим, там прописано, что размер какого-то глифа = миллиард миллиардов пикселей, то все эти проверки, наверное, должны быть именно там, где ты парсишь этот файл, и там у этих проверок к тому же есть шанс быть более разумными. Например, сделать лимит на размер одного глифа условно 100x100 пикселей. Если это какой-то алгоритм, которому нужна дополнительная память, то он вряд ли сразу захочет так много памяти выделить, скорее постепенно будет съедать больше и больше, и более вероятно отвалится на моменте, когда попытается выделить даже пару десятков гигабайт, гораздо раньше, чем там что-то переполнится. Короче, наверное, в этом нет смысла.
>>747408
Кстати, вроде можно было бы немного сократить строку, если заменить в ней длинные числа из массива с шрифтом (переменная ef) на %llu и в принтф аргументы передать через ef[0], ef[1] и тд, хотя, скорее всего, в итоге в лучшем случае никакой разницы не будет из-за того, что эти ef[0], ef[1] придётся в строку тоже добавить. Вообще, наверное, лучше в строку кодировать шрифт
О, это же буквально я, тоже ломаю вещи и потом начинаю кричать и носиться по своей комнате из стороны в сторону
Не пускает меня поиграть в длц. Бить его +6 оружием на протяжении пяти минут довольно депрессивно, но я за сегодня просто не успел найти камень на +7 на новом сейве. Хорошо, что к нему хотя бы можно попасть более-менее рано через квест
Я вроде никогда не пытался разобраться в том, даже как выглядит матрица перспективного преобразования, но, я сначала вспомнил, что мне Рируру рассказывал, как он с умом генерировал вершины куба, но я тогда вроде не понял ничего без картинок. Наверное, этим можно генерировать любой правильный многогранник, но сами нормали и ориентации направо тоже неплохо было бы генерировать тоже, не знаю. Потом мне почему-то показалось, что левая/правая система координат может как-то влиять на определение векторного произведения, но нет, в координатах же то же самое, очевидно, остаётся. Чтобы вывести формулу векторного произведения способом, нужно сначала доказать дистрибутивность, а она какая-то неочевидная даже геометрически, что она существует, если ты заранее не знаешь. А по-другому непонятно вообще откуда формула берётся, я видел альтернативную запись в виде определителя матрицы, но она ещё более магическая
https://www.songho.ca/opengl/gl_projectionmatrix.html такое нашёл, но в итоге, наверное, можно было бы здравым смыслом вывести её без учёта того, что фрустум может быть зачем-то несимметричным. Кроме момента с тем, что почему Z нелинейная? Я понимаю, что если пытаешься впихнуть перспективное преобразование в матрицу, то оно по-другому быть не может, но вообще в целом, зачем? http://www.humus.name/index.php?ID=255 на эту тему нашёл только это, он говорит, что типо Z, оказывается, линеен на экране, я типо верю, но интуитивно не понимаю совсем, попытался найти производную dZ/dX для чего-то типо похожего на перспективное преобразование (X/Z, Y/Z, 1/Z), как будто действительно выходит константа, но не знаю, я мог написать бред. Пытался проверить, что оно прямые в прямые переводит, ну как будто да, вот очередная вещь, которая наверняка очевидна людям с высоким iq, а я реально не вижу, из чего следует сохранение прямых. Идея того, чтобы использовать повороты на 360 градусов вместо радиан, в том числе внутри тригонометрических функций, показалось забавной? 0.25 вместо π/2, например, выглядит красивее или нет, не знаю
https://www.songho.ca/opengl/gl_projectionmatrix.html такое нашёл, но в итоге, наверное, можно было бы здравым смыслом вывести её без учёта того, что фрустум может быть зачем-то несимметричным. Кроме момента с тем, что почему Z нелинейная? Я понимаю, что если пытаешься впихнуть перспективное преобразование в матрицу, то оно по-другому быть не может, но вообще в целом, зачем? http://www.humus.name/index.php?ID=255 на эту тему нашёл только это, он говорит, что типо Z, оказывается, линеен на экране, я типо верю, но интуитивно не понимаю совсем, попытался найти производную dZ/dX для чего-то типо похожего на перспективное преобразование (X/Z, Y/Z, 1/Z), как будто действительно выходит константа, но не знаю, я мог написать бред. Пытался проверить, что оно прямые в прямые переводит, ну как будто да, вот очередная вещь, которая наверняка очевидна людям с высоким iq, а я реально не вижу, из чего следует сохранение прямых. Идея того, чтобы использовать повороты на 360 градусов вместо радиан, в том числе внутри тригонометрических функций, показалось забавной? 0.25 вместо π/2, например, выглядит красивее или нет, не знаю
Я вроде никогда не пытался разобраться в том, даже как выглядит матрица перспективного преобразования, но, я сначала вспомнил, что мне Рируру рассказывал, как он с умом генерировал вершины куба, но я тогда вроде не понял ничего без картинок. Наверное, этим можно генерировать любой правильный многогранник, но сами нормали и ориентации направо тоже неплохо было бы генерировать тоже, не знаю. Потом мне почему-то показалось, что левая/правая система координат может как-то влиять на определение векторного произведения, но нет, в координатах же то же самое, очевидно, остаётся. Чтобы вывести формулу векторного произведения способом, нужно сначала доказать дистрибутивность, а она какая-то неочевидная даже геометрически, что она существует, если ты заранее не знаешь. А по-другому непонятно вообще откуда формула берётся, я видел альтернативную запись в виде определителя матрицы, но она ещё более магическая
https://www.songho.ca/opengl/gl_projectionmatrix.html такое нашёл, но в итоге, наверное, можно было бы здравым смыслом вывести её без учёта того, что фрустум может быть зачем-то несимметричным. Кроме момента с тем, что почему Z нелинейная? Я понимаю, что если пытаешься впихнуть перспективное преобразование в матрицу, то оно по-другому быть не может, но вообще в целом, зачем? http://www.humus.name/index.php?ID=255 на эту тему нашёл только это, он говорит, что типо Z, оказывается, линеен на экране, я типо верю, но интуитивно не понимаю совсем, попытался найти производную dZ/dX для чего-то типо похожего на перспективное преобразование (X/Z, Y/Z, 1/Z), как будто действительно выходит константа, но не знаю, я мог написать бред. Пытался проверить, что оно прямые в прямые переводит, ну как будто да, вот очередная вещь, которая наверняка очевидна людям с высоким iq, а я реально не вижу, из чего следует сохранение прямых. Идея того, чтобы использовать повороты на 360 градусов вместо радиан, в том числе внутри тригонометрических функций, показалось забавной? 0.25 вместо π/2, например, выглядит красивее или нет, не знаю
https://www.songho.ca/opengl/gl_projectionmatrix.html такое нашёл, но в итоге, наверное, можно было бы здравым смыслом вывести её без учёта того, что фрустум может быть зачем-то несимметричным. Кроме момента с тем, что почему Z нелинейная? Я понимаю, что если пытаешься впихнуть перспективное преобразование в матрицу, то оно по-другому быть не может, но вообще в целом, зачем? http://www.humus.name/index.php?ID=255 на эту тему нашёл только это, он говорит, что типо Z, оказывается, линеен на экране, я типо верю, но интуитивно не понимаю совсем, попытался найти производную dZ/dX для чего-то типо похожего на перспективное преобразование (X/Z, Y/Z, 1/Z), как будто действительно выходит константа, но не знаю, я мог написать бред. Пытался проверить, что оно прямые в прямые переводит, ну как будто да, вот очередная вещь, которая наверняка очевидна людям с высоким iq, а я реально не вижу, из чего следует сохранение прямых. Идея того, чтобы использовать повороты на 360 градусов вместо радиан, в том числе внутри тригонометрических функций, показалось забавной? 0.25 вместо π/2, например, выглядит красивее или нет, не знаю
>>748320
Не хочется в это играть, там с самого начала первая локация - какой-то очередной гигантский пустырь и непонятно куда идти, мне гораздо больше нравился коридорный левел дизайн дарк солсов, где чётко понятно, куда идти, а бегать по пустырям и выискивать данжи, мини боссов и нпс мне приносит только уныние. И первый встретившийся мини босс - дракон скелет с душными атаками, которые нельзя задоджить, пока ты сидишь на коне, но если слезешь с коня, то он может поймать тебя своей аое, от которой не убежишь на ногах. Вместо того, чтобы сделать хотя бы один нормальный файт с драконом в этой игре, они похоже решили наоборот сделать самый худший из всех. В итоге забил в тот же день, что длц вышло.
Да и в основную игру не хочется играть, короче, я никогда не пройду эту игру. Играть на сейве, где у меня базовый RL5 бандит, стало слишком депрессивно: боссы начали слишком часто ваншотать, нужно прямо очень осторожно играть и бить только в безопасные окна, а это не очень весело. Играть в основную игру на сейве, где я по-быстрому добирался до длц, тоже не хочется, я там уже слишком оверлвл для основной игры, ну, можно перераспределить статы во что-то бесполезное, но уже нету настроения.
Короче, в итоге я забил на игру и, раз уж у меня есть стим версия игры, решил побегать немного в пвп на RL1+0 и это было довольно забавно: вторгаться в начальных локациях и мешать людям играть в коопе, в худшем случае людям, которые полчаса назад игру в первый раз запустили и даже играть толком не умеют, короче, как раз уровень моего скилла. Веселее всего офк убивать людей, прикрываясь за спинами толпы мобов или за наземным боссом. Но особо нет ощущения, что ты серьёзно руинишь кому-то игру, они по сути теряют только немного времени и аналог человечности, как в дс1, но тут он имеет нулевую ценность, потому что растёт на земле. Самый максимум неудобств, что можно принести, это вторгнуться около полудохлого дракона с гигантским хп баром, к которому некоторые люди приходят в начале игры, чтобы получить много рун забесплатно, и по-быстрому убить хоста, обнулив его прогресс по убийству дракона. Или когда вторгаешься посреди того, как кто-то кому-то передаёт предметы, и крадёшь их с пола, но это редко случается и мне ни разу не везло подобрать что-то интересное: только консервы и какие-то мусорные талисманы.
Проблема в том, что, оказывается, чуть ли не половина людей, играющих в коопе, играют вместе с высокоуровневыми фантомами, призванными по паролю. По всей видимости, это челы, которые уже прошли игру, играют с друзьями, которые только начали играть, не знаю. И, хоть вроде как их дамаг по мне скейлится вниз, я слишком анскилл, чтобы доджить их спам какими-то непонятными вепон артами и заклинаниями, которые в первый раз вижу, и продираться через их пойз и гигантскую полоску здоровья. Иногда получается их убить или быстро прикончить хоста, но зачастую нет.
Не знаю, могу ли я сам получить доступ хотя бы к каким-нибудь опшным оружиям или вепон артам, чтобы ещё более эффективно убивать людей, запустивших игру в первый раз. По-честному это придётся играть пве на RL1+0, а это раз в 10 сложнее обычного RL1. Ну, в начале убить годрика, чтобы получить реюзабельный палец для вторжений, было не очень сложно, а вот даже файт с раданом уже занял три с половиной минуты душения меня, и дальше только хуже. Чем дольше файт, тем более вероятно, что ты ошибёшься и тебя ваншотнут, либо ошибёшься достаточно раз, что у тебя закончатся фляги с хп.
А кооп в игре прямо дико унылый, даже вдвоём боссы по кд выбиваются из равновесия и в целом просто уничтожаются. В коопе весело, наверное, только стоять где-нибудь, ждать вторжений и втроём ганкать красных фантомов, особенно, если призвать кого-нибудь высоколвльного по паролю. А в пве играть с какими-то рандомами - не знаю.
Не хочется в это играть, там с самого начала первая локация - какой-то очередной гигантский пустырь и непонятно куда идти, мне гораздо больше нравился коридорный левел дизайн дарк солсов, где чётко понятно, куда идти, а бегать по пустырям и выискивать данжи, мини боссов и нпс мне приносит только уныние. И первый встретившийся мини босс - дракон скелет с душными атаками, которые нельзя задоджить, пока ты сидишь на коне, но если слезешь с коня, то он может поймать тебя своей аое, от которой не убежишь на ногах. Вместо того, чтобы сделать хотя бы один нормальный файт с драконом в этой игре, они похоже решили наоборот сделать самый худший из всех. В итоге забил в тот же день, что длц вышло.
Да и в основную игру не хочется играть, короче, я никогда не пройду эту игру. Играть на сейве, где у меня базовый RL5 бандит, стало слишком депрессивно: боссы начали слишком часто ваншотать, нужно прямо очень осторожно играть и бить только в безопасные окна, а это не очень весело. Играть в основную игру на сейве, где я по-быстрому добирался до длц, тоже не хочется, я там уже слишком оверлвл для основной игры, ну, можно перераспределить статы во что-то бесполезное, но уже нету настроения.
Короче, в итоге я забил на игру и, раз уж у меня есть стим версия игры, решил побегать немного в пвп на RL1+0 и это было довольно забавно: вторгаться в начальных локациях и мешать людям играть в коопе, в худшем случае людям, которые полчаса назад игру в первый раз запустили и даже играть толком не умеют, короче, как раз уровень моего скилла. Веселее всего офк убивать людей, прикрываясь за спинами толпы мобов или за наземным боссом. Но особо нет ощущения, что ты серьёзно руинишь кому-то игру, они по сути теряют только немного времени и аналог человечности, как в дс1, но тут он имеет нулевую ценность, потому что растёт на земле. Самый максимум неудобств, что можно принести, это вторгнуться около полудохлого дракона с гигантским хп баром, к которому некоторые люди приходят в начале игры, чтобы получить много рун забесплатно, и по-быстрому убить хоста, обнулив его прогресс по убийству дракона. Или когда вторгаешься посреди того, как кто-то кому-то передаёт предметы, и крадёшь их с пола, но это редко случается и мне ни разу не везло подобрать что-то интересное: только консервы и какие-то мусорные талисманы.
Проблема в том, что, оказывается, чуть ли не половина людей, играющих в коопе, играют вместе с высокоуровневыми фантомами, призванными по паролю. По всей видимости, это челы, которые уже прошли игру, играют с друзьями, которые только начали играть, не знаю. И, хоть вроде как их дамаг по мне скейлится вниз, я слишком анскилл, чтобы доджить их спам какими-то непонятными вепон артами и заклинаниями, которые в первый раз вижу, и продираться через их пойз и гигантскую полоску здоровья. Иногда получается их убить или быстро прикончить хоста, но зачастую нет.
Не знаю, могу ли я сам получить доступ хотя бы к каким-нибудь опшным оружиям или вепон артам, чтобы ещё более эффективно убивать людей, запустивших игру в первый раз. По-честному это придётся играть пве на RL1+0, а это раз в 10 сложнее обычного RL1. Ну, в начале убить годрика, чтобы получить реюзабельный палец для вторжений, было не очень сложно, а вот даже файт с раданом уже занял три с половиной минуты душения меня, и дальше только хуже. Чем дольше файт, тем более вероятно, что ты ошибёшься и тебя ваншотнут, либо ошибёшься достаточно раз, что у тебя закончатся фляги с хп.
А кооп в игре прямо дико унылый, даже вдвоём боссы по кд выбиваются из равновесия и в целом просто уничтожаются. В коопе весело, наверное, только стоять где-нибудь, ждать вторжений и втроём ганкать красных фантомов, особенно, если призвать кого-нибудь высоколвльного по паролю. А в пве играть с какими-то рандомами - не знаю.
>>748320
Не хочется в это играть, там с самого начала первая локация - какой-то очередной гигантский пустырь и непонятно куда идти, мне гораздо больше нравился коридорный левел дизайн дарк солсов, где чётко понятно, куда идти, а бегать по пустырям и выискивать данжи, мини боссов и нпс мне приносит только уныние. И первый встретившийся мини босс - дракон скелет с душными атаками, которые нельзя задоджить, пока ты сидишь на коне, но если слезешь с коня, то он может поймать тебя своей аое, от которой не убежишь на ногах. Вместо того, чтобы сделать хотя бы один нормальный файт с драконом в этой игре, они похоже решили наоборот сделать самый худший из всех. В итоге забил в тот же день, что длц вышло.
Да и в основную игру не хочется играть, короче, я никогда не пройду эту игру. Играть на сейве, где у меня базовый RL5 бандит, стало слишком депрессивно: боссы начали слишком часто ваншотать, нужно прямо очень осторожно играть и бить только в безопасные окна, а это не очень весело. Играть в основную игру на сейве, где я по-быстрому добирался до длц, тоже не хочется, я там уже слишком оверлвл для основной игры, ну, можно перераспределить статы во что-то бесполезное, но уже нету настроения.
Короче, в итоге я забил на игру и, раз уж у меня есть стим версия игры, решил побегать немного в пвп на RL1+0 и это было довольно забавно: вторгаться в начальных локациях и мешать людям играть в коопе, в худшем случае людям, которые полчаса назад игру в первый раз запустили и даже играть толком не умеют, короче, как раз уровень моего скилла. Веселее всего офк убивать людей, прикрываясь за спинами толпы мобов или за наземным боссом. Но особо нет ощущения, что ты серьёзно руинишь кому-то игру, они по сути теряют только немного времени и аналог человечности, как в дс1, но тут он имеет нулевую ценность, потому что растёт на земле. Самый максимум неудобств, что можно принести, это вторгнуться около полудохлого дракона с гигантским хп баром, к которому некоторые люди приходят в начале игры, чтобы получить много рун забесплатно, и по-быстрому убить хоста, обнулив его прогресс по убийству дракона. Или когда вторгаешься посреди того, как кто-то кому-то передаёт предметы, и крадёшь их с пола, но это редко случается и мне ни разу не везло подобрать что-то интересное: только консервы и какие-то мусорные талисманы.
Проблема в том, что, оказывается, чуть ли не половина людей, играющих в коопе, играют вместе с высокоуровневыми фантомами, призванными по паролю. По всей видимости, это челы, которые уже прошли игру, играют с друзьями, которые только начали играть, не знаю. И, хоть вроде как их дамаг по мне скейлится вниз, я слишком анскилл, чтобы доджить их спам какими-то непонятными вепон артами и заклинаниями, которые в первый раз вижу, и продираться через их пойз и гигантскую полоску здоровья. Иногда получается их убить или быстро прикончить хоста, но зачастую нет.
Не знаю, могу ли я сам получить доступ хотя бы к каким-нибудь опшным оружиям или вепон артам, чтобы ещё более эффективно убивать людей, запустивших игру в первый раз. По-честному это придётся играть пве на RL1+0, а это раз в 10 сложнее обычного RL1. Ну, в начале убить годрика, чтобы получить реюзабельный палец для вторжений, было не очень сложно, а вот даже файт с раданом уже занял три с половиной минуты душения меня, и дальше только хуже. Чем дольше файт, тем более вероятно, что ты ошибёшься и тебя ваншотнут, либо ошибёшься достаточно раз, что у тебя закончатся фляги с хп.
А кооп в игре прямо дико унылый, даже вдвоём боссы по кд выбиваются из равновесия и в целом просто уничтожаются. В коопе весело, наверное, только стоять где-нибудь, ждать вторжений и втроём ганкать красных фантомов, особенно, если призвать кого-нибудь высоколвльного по паролю. А в пве играть с какими-то рандомами - не знаю.
Не хочется в это играть, там с самого начала первая локация - какой-то очередной гигантский пустырь и непонятно куда идти, мне гораздо больше нравился коридорный левел дизайн дарк солсов, где чётко понятно, куда идти, а бегать по пустырям и выискивать данжи, мини боссов и нпс мне приносит только уныние. И первый встретившийся мини босс - дракон скелет с душными атаками, которые нельзя задоджить, пока ты сидишь на коне, но если слезешь с коня, то он может поймать тебя своей аое, от которой не убежишь на ногах. Вместо того, чтобы сделать хотя бы один нормальный файт с драконом в этой игре, они похоже решили наоборот сделать самый худший из всех. В итоге забил в тот же день, что длц вышло.
Да и в основную игру не хочется играть, короче, я никогда не пройду эту игру. Играть на сейве, где у меня базовый RL5 бандит, стало слишком депрессивно: боссы начали слишком часто ваншотать, нужно прямо очень осторожно играть и бить только в безопасные окна, а это не очень весело. Играть в основную игру на сейве, где я по-быстрому добирался до длц, тоже не хочется, я там уже слишком оверлвл для основной игры, ну, можно перераспределить статы во что-то бесполезное, но уже нету настроения.
Короче, в итоге я забил на игру и, раз уж у меня есть стим версия игры, решил побегать немного в пвп на RL1+0 и это было довольно забавно: вторгаться в начальных локациях и мешать людям играть в коопе, в худшем случае людям, которые полчаса назад игру в первый раз запустили и даже играть толком не умеют, короче, как раз уровень моего скилла. Веселее всего офк убивать людей, прикрываясь за спинами толпы мобов или за наземным боссом. Но особо нет ощущения, что ты серьёзно руинишь кому-то игру, они по сути теряют только немного времени и аналог человечности, как в дс1, но тут он имеет нулевую ценность, потому что растёт на земле. Самый максимум неудобств, что можно принести, это вторгнуться около полудохлого дракона с гигантским хп баром, к которому некоторые люди приходят в начале игры, чтобы получить много рун забесплатно, и по-быстрому убить хоста, обнулив его прогресс по убийству дракона. Или когда вторгаешься посреди того, как кто-то кому-то передаёт предметы, и крадёшь их с пола, но это редко случается и мне ни разу не везло подобрать что-то интересное: только консервы и какие-то мусорные талисманы.
Проблема в том, что, оказывается, чуть ли не половина людей, играющих в коопе, играют вместе с высокоуровневыми фантомами, призванными по паролю. По всей видимости, это челы, которые уже прошли игру, играют с друзьями, которые только начали играть, не знаю. И, хоть вроде как их дамаг по мне скейлится вниз, я слишком анскилл, чтобы доджить их спам какими-то непонятными вепон артами и заклинаниями, которые в первый раз вижу, и продираться через их пойз и гигантскую полоску здоровья. Иногда получается их убить или быстро прикончить хоста, но зачастую нет.
Не знаю, могу ли я сам получить доступ хотя бы к каким-нибудь опшным оружиям или вепон артам, чтобы ещё более эффективно убивать людей, запустивших игру в первый раз. По-честному это придётся играть пве на RL1+0, а это раз в 10 сложнее обычного RL1. Ну, в начале убить годрика, чтобы получить реюзабельный палец для вторжений, было не очень сложно, а вот даже файт с раданом уже занял три с половиной минуты душения меня, и дальше только хуже. Чем дольше файт, тем более вероятно, что ты ошибёшься и тебя ваншотнут, либо ошибёшься достаточно раз, что у тебя закончатся фляги с хп.
А кооп в игре прямо дико унылый, даже вдвоём боссы по кд выбиваются из равновесия и в целом просто уничтожаются. В коопе весело, наверное, только стоять где-нибудь, ждать вторжений и втроём ганкать красных фантомов, особенно, если призвать кого-нибудь высоколвльного по паролю. А в пве играть с какими-то рандомами - не знаю.
Но, на самом деле, спам морозным твинблейдом или что угодно подобное не работает, если даже два человека попадаются, которые играют оборонительно, доджат мои атаки без попыток их наказывать, и периодически с двух сторон подходят, бьют почти одновременно по одному разу, отбегают, и так снова и снова. Даже необязательно чем-то тяжёлым, а просто прямыми мечами, в этой игре как будто не существует пойза. Пытаешься подбежать к одному - он убегает, а второй нападает со спины, и наоборот. В таком случае я не знаю, что этому противопоставить + я слишком анскилл, чтобы такое доджить достаточно долго, ну и в целом анскилл. Ну или, если один человек что-то кастует нон-стоп, а другой его защищает и атакует меня, но тут хотя бы бывают окна, когда у мага фп заканчиваются и тогда он становится беззащитным на несколько секунд.
В общем, если вторгаться где-нибудь подальше от начальных локаций, где конкретно сейчас много людей, которые в первый раз запустили игру из-за хайпа по длц, то меня самого зачастую начинают довольно эффективно давить как таракана, которым я и являюсь. И я перепробовал много разного оружия: когда меня убивали чем-то, то пробовал его сам использовать, и ничего не менялось, когда встречались люди, немного умеющие играть. А всякое дно вроде меня можно чем угодно забить.
В общем, если вторгаться где-нибудь подальше от начальных локаций, где конкретно сейчас много людей, которые в первый раз запустили игру из-за хайпа по длц, то меня самого зачастую начинают довольно эффективно давить как таракана, которым я и являюсь. И я перепробовал много разного оружия: когда меня убивали чем-то, то пробовал его сам использовать, и ничего не менялось, когда встречались люди, немного умеющие играть. А всякое дно вроде меня можно чем угодно забить.
171 Кб, 279x388Ну и чего ты ноешь? Не нравицца - не играй, если анскилл в pvp тоже не суйся, эти посты - какая-то невнятная рефлексия непойми зачем
Пробовал немного ещё играть в пвп, всё так же на RL1+0, но в итоге всё же немного надоело, что либо я быстро всех убиваю, либо наоборот быстро убивают меня, обычно оверлвл фантомы и иногда попадаются скилловые люди, которые умеют в тимворк. И всё так же остался анскиллом, но единственное, что понял, что я могу не бросаться вперёд, напарываясь на всякие безумные aow, а играть дефенсивно, и тогда есть шанс, что я хотя бы что-то смогу сделать.
Плюс прикольно можно менять на ходу оружие в зависимости от ситуации, типо сменить по-быстрому на оружие, где повешен пробивающий щит выпад, или на оружие с более быстрым мувсетом, ну и в целом прикольно так делать, даже если практической пользы немного. Но в идеале это нужно запоминать расположение всего, чтобы не глядя менять.
А играть на мета пвп лвле на арене не очень хочется даже пробовать, там всё как-то совсем всё выглядит сложно со стороны, там файты выглядят так, что два чела сначала минуту бегают друг перед другом, а потом один резко стрейфит атаку другого и убивает бэкстабом
Пробовал на RL1+0 продолжить убивать боссов, конкретно тощего попробовал https://youtu.be/yNnJOCg9WwI но для такого, мне кажется, я уже не только анскилл, но ещё и мозг слишком дерьмовый, типо, например, я физически не могу отпарировать его атаку острым концом слева и когда пытаюсь, каждый раз опаздываю из-за того, что мозг не успевает распознать конкретно эту атаку и решить вместо переката прожать парирование. Из-за плохого мозга хочется умереть, это не только плохая реакция, но и плохая память, плохо и медленно соображаешь, иногда когда в чём-то разбираешься, то чувствуешь, что мозг плавится и всё
Плюс прикольно можно менять на ходу оружие в зависимости от ситуации, типо сменить по-быстрому на оружие, где повешен пробивающий щит выпад, или на оружие с более быстрым мувсетом, ну и в целом прикольно так делать, даже если практической пользы немного. Но в идеале это нужно запоминать расположение всего, чтобы не глядя менять.
А играть на мета пвп лвле на арене не очень хочется даже пробовать, там всё как-то совсем всё выглядит сложно со стороны, там файты выглядят так, что два чела сначала минуту бегают друг перед другом, а потом один резко стрейфит атаку другого и убивает бэкстабом
Пробовал на RL1+0 продолжить убивать боссов, конкретно тощего попробовал https://youtu.be/yNnJOCg9WwI но для такого, мне кажется, я уже не только анскилл, но ещё и мозг слишком дерьмовый, типо, например, я физически не могу отпарировать его атаку острым концом слева и когда пытаюсь, каждый раз опаздываю из-за того, что мозг не успевает распознать конкретно эту атаку и решить вместо переката прожать парирование. Из-за плохого мозга хочется умереть, это не только плохая реакция, но и плохая память, плохо и медленно соображаешь, иногда когда в чём-то разбираешься, то чувствуешь, что мозг плавится и всё
Ну я короче подумал, что, может быть, тогда просто по-нормальному пройти с прокачкой, чтобы хотя бы ачивки были, ну вот я короче снова новый сейв начал играть, это вот так оно происходит, это причина, почему я не могу проходить игры
В новом сейве я просто почти мимо всех данжей пробегаю мимо в отличие от RL5 сейва, где я всё подряд проходил, все итемы скупал и пылесосил лут в локациях, тут только квесты делаю и всё.
Я более-менее далеко прошёл, дальше, чем в первом сейве, но не до конца
Его, на самом деле, парировать тяжелее, чем по-нормальному убивать, хотя выглядит наоборот. Но просто забавно так
В новом сейве я просто почти мимо всех данжей пробегаю мимо в отличие от RL5 сейва, где я всё подряд проходил, все итемы скупал и пылесосил лут в локациях, тут только квесты делаю и всё.
Я более-менее далеко прошёл, дальше, чем в первом сейве, но не до конца
Его, на самом деле, парировать тяжелее, чем по-нормальному убивать, хотя выглядит наоборот. Но просто забавно так
А с гниющей женщиной https://youtu.be/RtiFd1vVJQM как-то совсем тяжко, у неё есть атака, когда вот она много быстро махает мечом, и первую её часть вроде как можно задоджить двумя перекатами, но у меня ни разу не получалось и там вроде действительно очень сложно в тайминг попасть, и проблема в том, что она смертельно опасная. И вместо этого вроде как все обычно подбегают к ней вплотную перед этой атакой и бегают вокруг, чтобы она в сторону первую атаку сделала https://youtu.be/jvmTnrQjb94, но для такого я тоже слишком анскилл. Я постоянно оказываюсь в ситуации, где я стою недостаточно близко, чтобы успеть подойти и покрутить её, и недостаточно далеко, чтобы успеть убежать. Когда убегаешь, то вроде как немного помогает прыжок, не знаю, можно ли им избежать урон (который бы ты возможно получил, если бы просто бежал), но, если она тебя немного задевает, то с прыжком она тебя хотя бы не станнит, и ты можешь продолжить бежать
В итоге просто кринж файт получился, где я постояно стою как можно дальше от неё и постоянно отбегаю, чтобы успеть потенциально убежать от этой атаки. И парирую ровно один вид атаки, другие не научился, слишком плохой мозг, слишком анскилл
Для этой атаки её клонами я тоже слишком анскилл, каждый раз я просто стою и не понимаю, что происходит. Вроде как можно отбежать подальше и задоджить только последнего клона, который атакует выпадом в тебя слева, и потом её саму, но не знаю, насколько это стабильно работает, я только один раз так сделал в успешном трае
Она ещё бьёт как-то совсем очень больно, хотя у меня 60 уровней в хп и это вроде кап, ну, с другой стороны, я просто в одном платье бегаю без нормальной брони, но, с третьей стороны, сомневаюсь, что это сыграло бы особую роль.
В итоге просто кринж файт получился, где я постояно стою как можно дальше от неё и постоянно отбегаю, чтобы успеть потенциально убежать от этой атаки. И парирую ровно один вид атаки, другие не научился, слишком плохой мозг, слишком анскилл
Для этой атаки её клонами я тоже слишком анскилл, каждый раз я просто стою и не понимаю, что происходит. Вроде как можно отбежать подальше и задоджить только последнего клона, который атакует выпадом в тебя слева, и потом её саму, но не знаю, насколько это стабильно работает, я только один раз так сделал в успешном трае
Она ещё бьёт как-то совсем очень больно, хотя у меня 60 уровней в хп и это вроде кап, ну, с другой стороны, я просто в одном платье бегаю без нормальной брони, но, с третьей стороны, сомневаюсь, что это сыграло бы особую роль.
Ничего не делаю, сижу играю в игры, хочу нахуй повеситься, ничего не хочу, вообще ни в чём нет смысла, когда ты тупой всратый даун. Низкий iq -> ничего не хочется и даже, если заставляешь себя что-то делать, то всё валится из рук и слишком тупой, чтобы что-то делать в любом случае, потом ещё случайно увидел себя в зеркале - всё, день окончательно испорчен, нет смысла жить
Пытался смотреть кватернионы
Я сначала смотрел это видео 3b1b https://youtu.be/d4EgbgTm0Bg и это https://eater.net/quaternions но, по-моему, это просто бред какой-то: ну я вижу, что да, стереографическая проекция кусков 4д сферы в трёхмерное пространство, да, умножение на кватернион растягивает и крутит проекцию, да, если умножить слева на единичный кватернион и справа на сопряжённый, то растягивания типа компенсируют друг друга и проекция крутится, ну и чё дальше, это что-то на уровне того мультика про выворачивание сферы наизнанку, вот тоже сидишь смотришь и киваешь пустой башкой.
По-моему, в плане геометрических преобразований комплексные числа и кватернионы слишком разные, несмотря на то, что одно является расширением другого. Умножение на комплексное число делает произвольный поворот + скейлинг 2д векторов, а умножение на кватернион вроде бы не может сделать даже произвольный поворот 4д вектора: слишком мало компонентов, нужно хотя бы 6. Короче, я не вижу пользы в том, чтобы проводить параллели между ними.
Я не особо понимаю, сколько нужно чисел для представления произвольного поворота в N-мерном пространстве. Вроде бы один вариант, как об этом можно думать, это, что мы хотим выбрать все различные пары осей координат, которые будут представлять плоскости поворота, и это количество равно числу сочетаний из N по 2, то есть N! / ((N-2)! 2!) = N (N - 1) / 2. В 3д обычно говорят об осях вращения, но просто можно взять нормали к плоскостям в качестве осей. В 2д вообще плоскость только одна, поэтому и поворот представляется только одним числом.
Другой вариант - это представить, что у нас есть куб с рёбрами, выровненными по осям координат, и мы хотим его повернуть в какую-то ориентацию. Сначала хватаемся за ребро, смотрящее в направлении оси X, и у нас есть N - 1 степеней свободы (по количеству оставшихся осей координат), чтобы ориентировать его, как нам надо. После хватаемся за ось Y, тоже ставим её в нужное положение, но только у нас осталось уже N - 2 степеней свободы, так как X мы зафиксировали. (N - 1) + (N - 2) + ... + 1 = N (N - 1) / 2.
Ещё из попыток объяснить кватернионы такое есть https://marctenbosch.com/quaternions что-то что-то бивекторы, внешнее произведение, роторы, ничего не понял особо в итоге и сложилось впечатление, что магические формулы кватернионов просто подменили на другие магические формулы.
Короче, в итоге, если ты тупой, то похоже нет смысла пытаться понять, что было в голове у того чела, который придумал кватернионы, почему 4д кватернионы используются для 3д поворотов и какой глубинный смысл формулы p' = qpq∗. И просто последовательно всё вывести из формулы i2 = j2 = k2 = ijk = -1, которую, допустим, я увидел, проходя мимо моста.
https://www.youtube.com/playlist?list=PLpzmRsG7u_gr0FO12cBWj-15_e0yqQQ1U вот эти видео нормальные, ну вот только представление операции умножения на кватернион в виде матрицы оказалось каким-то бесполезным. Я думал его можно было бы использовать для вывода матричной формы p' = qpq∗, но не вижу, как. Ну просто интересно получается, что матрицы эти, выходит изоморфны кватернионам? И тут реально наделяется смысл тому, что значит, например, возвести i в квадрат и получить -1.
Представление кватерниона в виде скаляра + вектора очень удобное и вроде как раз исторически именно отсюда пошли векторное и скалярное произведения векторов: они вылезают в формуле умножения кватернионов. Отсюда становится понятно, почему они выглядят такими искусственными и взявшимися из ниоткуда (ну у них есть геометрический смысл, но, по-моему, не самый очевидный, чтобы взять просто на ровном месте придумать эти операции для векторов).
Формулу поворота он сначала выводит через векторное и скалярное произведения, а потом показывает, как переписать её через кватернионы, используя типа аналог формулы эйлера для кватернионов, выходит так: v' = eθn/2 v e-θn/2. Почему половинный угол? Я не знаю, да и какая разница, ну просто получилось так. И я видел все эти картинки с книжками, к которым прицеплена ленточка, и там она перекручивается, если перевернуть книжку на 360 градусов, но если перевернуть на 720, то её можно размотать без переворачивания книжки и бла-бла-бла, это не имеет никакого смысла в моих глазах.
По-моему, это просто означает, что ну ок, получается, при повороте через кватернионы, можно выбрать то, по какой дуге делать поворот: по короткой или по длинной. Ну, типо, например, поворот от 120 градусов либо к 240 градусам, либо к -120 градусам. Финальная ориентация одна и та же, но поворот сделан либо против, либо по часовой стрелке.
Матричную запись поворота через кватернионы можно вывести так http://www.songho.ca/opengl/gl_quaternion.html но это какое-то безумие, нашёл вариант попроще https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Quaternion-derived_rotation_matrix немного подробнее расписал.
Я так понял, что между кватернионами можно просто брать и делать линейную интерполяцию и в отличие от матриц, с которыми если так сделать, то объект будет искажаться и вроде может быть shearing? Я не уверен, есть ли искажения в случае с кватернионами, сам не пробовал ещё, а, ну, наверное, их нужно будет нормализовывать после лерпа, потому что он величину вектора не сохраняет. Но, если просто лерпать, то в любом случае оно крутиться будет как минимум с неравномерной скоростью, для постоянной скорости нужен слерп. Вывод формулы слерпа отсюда http://allenchou.net/2018/05/game-math-deriving-the-slerp-formula
Но, в итоге, если честно, я не особо понимаю, почему слерп кватернионов как 4д векторов результирует именно в плавный поворот вроде как по кратчайшей дуге в 3д, что означает угол между кватернионами как 4д векторами в этом контексте... Это, наверное, можно проверить, если взять два произвольных кватерниона p и q, подставить их в формулу слерпа, чтобы получить промежуточный кватернион slerp(p, q, t). Потом взять произвольный вектор v и проверить, что промежуточно повёрнутый "slerp(p, q, t) v slerp(p, q, t)∗" лежит в плоскости, которую образуют qvq∗ и pvp∗, и что он повёрнут на правильный угол относительно них? Я это всё сойду с ума считать, у меня нет сейчас сил на такое. В общем, я просто не вижу интуицию, почему это работает, я слишком тупой, я реально отсталый.
Про дуальные кватернионы (именно дуальные, октонионы - это что-то другое, хотя и у тех, и у других по 8 компонентов) немного посмотрел, в основном отсюда https://cs.gmu.edu/~jmlien/teaching/cs451/uploads/Main/dual-quaternion.pdf но там много опечаток и мало информации. Это видео https://youtu.be/ichOiuBoBoQ выглядело многообещающим, но там пошла какая-то проективная геометрия? и я ничего не понял.
Ну, короче, если кратко, то идея такая, что в два кватерниона определённым образом записываются поворот + смещение, а сами два кватерниона объединяются в один "дуальный". И определяются операции над этими дуальными кватернионами, которые основаны на дуальных числах (что-то вроде комплексных), где компонентами выбрали кватернионы. И так выходит, что если вписать обычный 3д вектор в дуальный кватернион (единица в вещественной части и сам вектор в дуальной https://en.wikipedia.org/wiki/Dual_quaternion#Dual_quaternions_and_4%C3%974_homogeneous_transforms), и домножить его слева на дуальный кватернион, а справа на его сопряжённое (как в смысле дуальных чисел, так и в смысле кватернионов), то типо получается сначала повёрнутый, а потом смещённый вектор. И вроде как смысл в том, что эти дуальные кватернионы тоже можно интерполировать, как обычные кватернионы. Вроде ещё для чего-то используются в анимации этот чел рассказывал https://youtu.be/en2QcehKJd8 про какой-то candy-wrapper эффект, но я его презентацию аболютно не понял от начала и до конца.
Гораздо больше магических формул, взявшихся из ниоткуда, я максимум просто проверил, что формула действительно делает с вектором поворот + смещение. Я не стал пытаться самостоятельно пройти аналогичный путь, как с обычными кватернионами: от формулы, записанной в форме векторов, к формуле через дуальные кватернионы p' = qpq∗, я не вывезу и запутаюсь.
В конце немного про отражения, выраженные через кватернионы. Я не задумывался о том, что два последовательных отражения - это поворот (или задумывался, я забыл), но с формулами отражения/поворота через кватернионы это легко выводится. Это всё немного перекликается с той статьёй про роторы, только там вроде наоборот: сначала шли отражения, а потом повороты через них выражались. Ну и формулы выглядят там визуально похоже.
Я сначала смотрел это видео 3b1b https://youtu.be/d4EgbgTm0Bg и это https://eater.net/quaternions но, по-моему, это просто бред какой-то: ну я вижу, что да, стереографическая проекция кусков 4д сферы в трёхмерное пространство, да, умножение на кватернион растягивает и крутит проекцию, да, если умножить слева на единичный кватернион и справа на сопряжённый, то растягивания типа компенсируют друг друга и проекция крутится, ну и чё дальше, это что-то на уровне того мультика про выворачивание сферы наизнанку, вот тоже сидишь смотришь и киваешь пустой башкой.
По-моему, в плане геометрических преобразований комплексные числа и кватернионы слишком разные, несмотря на то, что одно является расширением другого. Умножение на комплексное число делает произвольный поворот + скейлинг 2д векторов, а умножение на кватернион вроде бы не может сделать даже произвольный поворот 4д вектора: слишком мало компонентов, нужно хотя бы 6. Короче, я не вижу пользы в том, чтобы проводить параллели между ними.
Я не особо понимаю, сколько нужно чисел для представления произвольного поворота в N-мерном пространстве. Вроде бы один вариант, как об этом можно думать, это, что мы хотим выбрать все различные пары осей координат, которые будут представлять плоскости поворота, и это количество равно числу сочетаний из N по 2, то есть N! / ((N-2)! 2!) = N (N - 1) / 2. В 3д обычно говорят об осях вращения, но просто можно взять нормали к плоскостям в качестве осей. В 2д вообще плоскость только одна, поэтому и поворот представляется только одним числом.
Другой вариант - это представить, что у нас есть куб с рёбрами, выровненными по осям координат, и мы хотим его повернуть в какую-то ориентацию. Сначала хватаемся за ребро, смотрящее в направлении оси X, и у нас есть N - 1 степеней свободы (по количеству оставшихся осей координат), чтобы ориентировать его, как нам надо. После хватаемся за ось Y, тоже ставим её в нужное положение, но только у нас осталось уже N - 2 степеней свободы, так как X мы зафиксировали. (N - 1) + (N - 2) + ... + 1 = N (N - 1) / 2.
Ещё из попыток объяснить кватернионы такое есть https://marctenbosch.com/quaternions что-то что-то бивекторы, внешнее произведение, роторы, ничего не понял особо в итоге и сложилось впечатление, что магические формулы кватернионов просто подменили на другие магические формулы.
Короче, в итоге, если ты тупой, то похоже нет смысла пытаться понять, что было в голове у того чела, который придумал кватернионы, почему 4д кватернионы используются для 3д поворотов и какой глубинный смысл формулы p' = qpq∗. И просто последовательно всё вывести из формулы i2 = j2 = k2 = ijk = -1, которую, допустим, я увидел, проходя мимо моста.
https://www.youtube.com/playlist?list=PLpzmRsG7u_gr0FO12cBWj-15_e0yqQQ1U вот эти видео нормальные, ну вот только представление операции умножения на кватернион в виде матрицы оказалось каким-то бесполезным. Я думал его можно было бы использовать для вывода матричной формы p' = qpq∗, но не вижу, как. Ну просто интересно получается, что матрицы эти, выходит изоморфны кватернионам? И тут реально наделяется смысл тому, что значит, например, возвести i в квадрат и получить -1.
Представление кватерниона в виде скаляра + вектора очень удобное и вроде как раз исторически именно отсюда пошли векторное и скалярное произведения векторов: они вылезают в формуле умножения кватернионов. Отсюда становится понятно, почему они выглядят такими искусственными и взявшимися из ниоткуда (ну у них есть геометрический смысл, но, по-моему, не самый очевидный, чтобы взять просто на ровном месте придумать эти операции для векторов).
Формулу поворота он сначала выводит через векторное и скалярное произведения, а потом показывает, как переписать её через кватернионы, используя типа аналог формулы эйлера для кватернионов, выходит так: v' = eθn/2 v e-θn/2. Почему половинный угол? Я не знаю, да и какая разница, ну просто получилось так. И я видел все эти картинки с книжками, к которым прицеплена ленточка, и там она перекручивается, если перевернуть книжку на 360 градусов, но если перевернуть на 720, то её можно размотать без переворачивания книжки и бла-бла-бла, это не имеет никакого смысла в моих глазах.
По-моему, это просто означает, что ну ок, получается, при повороте через кватернионы, можно выбрать то, по какой дуге делать поворот: по короткой или по длинной. Ну, типо, например, поворот от 120 градусов либо к 240 градусам, либо к -120 градусам. Финальная ориентация одна и та же, но поворот сделан либо против, либо по часовой стрелке.
Матричную запись поворота через кватернионы можно вывести так http://www.songho.ca/opengl/gl_quaternion.html но это какое-то безумие, нашёл вариант попроще https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Quaternion-derived_rotation_matrix немного подробнее расписал.
Я так понял, что между кватернионами можно просто брать и делать линейную интерполяцию и в отличие от матриц, с которыми если так сделать, то объект будет искажаться и вроде может быть shearing? Я не уверен, есть ли искажения в случае с кватернионами, сам не пробовал ещё, а, ну, наверное, их нужно будет нормализовывать после лерпа, потому что он величину вектора не сохраняет. Но, если просто лерпать, то в любом случае оно крутиться будет как минимум с неравномерной скоростью, для постоянной скорости нужен слерп. Вывод формулы слерпа отсюда http://allenchou.net/2018/05/game-math-deriving-the-slerp-formula
Но, в итоге, если честно, я не особо понимаю, почему слерп кватернионов как 4д векторов результирует именно в плавный поворот вроде как по кратчайшей дуге в 3д, что означает угол между кватернионами как 4д векторами в этом контексте... Это, наверное, можно проверить, если взять два произвольных кватерниона p и q, подставить их в формулу слерпа, чтобы получить промежуточный кватернион slerp(p, q, t). Потом взять произвольный вектор v и проверить, что промежуточно повёрнутый "slerp(p, q, t) v slerp(p, q, t)∗" лежит в плоскости, которую образуют qvq∗ и pvp∗, и что он повёрнут на правильный угол относительно них? Я это всё сойду с ума считать, у меня нет сейчас сил на такое. В общем, я просто не вижу интуицию, почему это работает, я слишком тупой, я реально отсталый.
Про дуальные кватернионы (именно дуальные, октонионы - это что-то другое, хотя и у тех, и у других по 8 компонентов) немного посмотрел, в основном отсюда https://cs.gmu.edu/~jmlien/teaching/cs451/uploads/Main/dual-quaternion.pdf но там много опечаток и мало информации. Это видео https://youtu.be/ichOiuBoBoQ выглядело многообещающим, но там пошла какая-то проективная геометрия? и я ничего не понял.
Ну, короче, если кратко, то идея такая, что в два кватерниона определённым образом записываются поворот + смещение, а сами два кватерниона объединяются в один "дуальный". И определяются операции над этими дуальными кватернионами, которые основаны на дуальных числах (что-то вроде комплексных), где компонентами выбрали кватернионы. И так выходит, что если вписать обычный 3д вектор в дуальный кватернион (единица в вещественной части и сам вектор в дуальной https://en.wikipedia.org/wiki/Dual_quaternion#Dual_quaternions_and_4%C3%974_homogeneous_transforms), и домножить его слева на дуальный кватернион, а справа на его сопряжённое (как в смысле дуальных чисел, так и в смысле кватернионов), то типо получается сначала повёрнутый, а потом смещённый вектор. И вроде как смысл в том, что эти дуальные кватернионы тоже можно интерполировать, как обычные кватернионы. Вроде ещё для чего-то используются в анимации этот чел рассказывал https://youtu.be/en2QcehKJd8 про какой-то candy-wrapper эффект, но я его презентацию аболютно не понял от начала и до конца.
Гораздо больше магических формул, взявшихся из ниоткуда, я максимум просто проверил, что формула действительно делает с вектором поворот + смещение. Я не стал пытаться самостоятельно пройти аналогичный путь, как с обычными кватернионами: от формулы, записанной в форме векторов, к формуле через дуальные кватернионы p' = qpq∗, я не вывезу и запутаюсь.
В конце немного про отражения, выраженные через кватернионы. Я не задумывался о том, что два последовательных отражения - это поворот (или задумывался, я забыл), но с формулами отражения/поворота через кватернионы это легко выводится. Это всё немного перекликается с той статьёй про роторы, только там вроде наоборот: сначала шли отражения, а потом повороты через них выражались. Ну и формулы выглядят там визуально похоже.
Пытался смотреть кватернионы
Я сначала смотрел это видео 3b1b https://youtu.be/d4EgbgTm0Bg и это https://eater.net/quaternions но, по-моему, это просто бред какой-то: ну я вижу, что да, стереографическая проекция кусков 4д сферы в трёхмерное пространство, да, умножение на кватернион растягивает и крутит проекцию, да, если умножить слева на единичный кватернион и справа на сопряжённый, то растягивания типа компенсируют друг друга и проекция крутится, ну и чё дальше, это что-то на уровне того мультика про выворачивание сферы наизнанку, вот тоже сидишь смотришь и киваешь пустой башкой.
По-моему, в плане геометрических преобразований комплексные числа и кватернионы слишком разные, несмотря на то, что одно является расширением другого. Умножение на комплексное число делает произвольный поворот + скейлинг 2д векторов, а умножение на кватернион вроде бы не может сделать даже произвольный поворот 4д вектора: слишком мало компонентов, нужно хотя бы 6. Короче, я не вижу пользы в том, чтобы проводить параллели между ними.
Я не особо понимаю, сколько нужно чисел для представления произвольного поворота в N-мерном пространстве. Вроде бы один вариант, как об этом можно думать, это, что мы хотим выбрать все различные пары осей координат, которые будут представлять плоскости поворота, и это количество равно числу сочетаний из N по 2, то есть N! / ((N-2)! 2!) = N (N - 1) / 2. В 3д обычно говорят об осях вращения, но просто можно взять нормали к плоскостям в качестве осей. В 2д вообще плоскость только одна, поэтому и поворот представляется только одним числом.
Другой вариант - это представить, что у нас есть куб с рёбрами, выровненными по осям координат, и мы хотим его повернуть в какую-то ориентацию. Сначала хватаемся за ребро, смотрящее в направлении оси X, и у нас есть N - 1 степеней свободы (по количеству оставшихся осей координат), чтобы ориентировать его, как нам надо. После хватаемся за ось Y, тоже ставим её в нужное положение, но только у нас осталось уже N - 2 степеней свободы, так как X мы зафиксировали. (N - 1) + (N - 2) + ... + 1 = N (N - 1) / 2.
Ещё из попыток объяснить кватернионы такое есть https://marctenbosch.com/quaternions что-то что-то бивекторы, внешнее произведение, роторы, ничего не понял особо в итоге и сложилось впечатление, что магические формулы кватернионов просто подменили на другие магические формулы.
Короче, в итоге, если ты тупой, то похоже нет смысла пытаться понять, что было в голове у того чела, который придумал кватернионы, почему 4д кватернионы используются для 3д поворотов и какой глубинный смысл формулы p' = qpq∗. И просто последовательно всё вывести из формулы i2 = j2 = k2 = ijk = -1, которую, допустим, я увидел, проходя мимо моста.
https://www.youtube.com/playlist?list=PLpzmRsG7u_gr0FO12cBWj-15_e0yqQQ1U вот эти видео нормальные, ну вот только представление операции умножения на кватернион в виде матрицы оказалось каким-то бесполезным. Я думал его можно было бы использовать для вывода матричной формы p' = qpq∗, но не вижу, как. Ну просто интересно получается, что матрицы эти, выходит изоморфны кватернионам? И тут реально наделяется смысл тому, что значит, например, возвести i в квадрат и получить -1.
Представление кватерниона в виде скаляра + вектора очень удобное и вроде как раз исторически именно отсюда пошли векторное и скалярное произведения векторов: они вылезают в формуле умножения кватернионов. Отсюда становится понятно, почему они выглядят такими искусственными и взявшимися из ниоткуда (ну у них есть геометрический смысл, но, по-моему, не самый очевидный, чтобы взять просто на ровном месте придумать эти операции для векторов).
Формулу поворота он сначала выводит через векторное и скалярное произведения, а потом показывает, как переписать её через кватернионы, используя типа аналог формулы эйлера для кватернионов, выходит так: v' = eθn/2 v e-θn/2. Почему половинный угол? Я не знаю, да и какая разница, ну просто получилось так. И я видел все эти картинки с книжками, к которым прицеплена ленточка, и там она перекручивается, если перевернуть книжку на 360 градусов, но если перевернуть на 720, то её можно размотать без переворачивания книжки и бла-бла-бла, это не имеет никакого смысла в моих глазах.
По-моему, это просто означает, что ну ок, получается, при повороте через кватернионы, можно выбрать то, по какой дуге делать поворот: по короткой или по длинной. Ну, типо, например, поворот от 120 градусов либо к 240 градусам, либо к -120 градусам. Финальная ориентация одна и та же, но поворот сделан либо против, либо по часовой стрелке.
Матричную запись поворота через кватернионы можно вывести так http://www.songho.ca/opengl/gl_quaternion.html но это какое-то безумие, нашёл вариант попроще https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Quaternion-derived_rotation_matrix немного подробнее расписал.
Я так понял, что между кватернионами можно просто брать и делать линейную интерполяцию и в отличие от матриц, с которыми если так сделать, то объект будет искажаться и вроде может быть shearing? Я не уверен, есть ли искажения в случае с кватернионами, сам не пробовал ещё, а, ну, наверное, их нужно будет нормализовывать после лерпа, потому что он величину вектора не сохраняет. Но, если просто лерпать, то в любом случае оно крутиться будет как минимум с неравномерной скоростью, для постоянной скорости нужен слерп. Вывод формулы слерпа отсюда http://allenchou.net/2018/05/game-math-deriving-the-slerp-formula
Но, в итоге, если честно, я не особо понимаю, почему слерп кватернионов как 4д векторов результирует именно в плавный поворот вроде как по кратчайшей дуге в 3д, что означает угол между кватернионами как 4д векторами в этом контексте... Это, наверное, можно проверить, если взять два произвольных кватерниона p и q, подставить их в формулу слерпа, чтобы получить промежуточный кватернион slerp(p, q, t). Потом взять произвольный вектор v и проверить, что промежуточно повёрнутый "slerp(p, q, t) v slerp(p, q, t)∗" лежит в плоскости, которую образуют qvq∗ и pvp∗, и что он повёрнут на правильный угол относительно них? Я это всё сойду с ума считать, у меня нет сейчас сил на такое. В общем, я просто не вижу интуицию, почему это работает, я слишком тупой, я реально отсталый.
Про дуальные кватернионы (именно дуальные, октонионы - это что-то другое, хотя и у тех, и у других по 8 компонентов) немного посмотрел, в основном отсюда https://cs.gmu.edu/~jmlien/teaching/cs451/uploads/Main/dual-quaternion.pdf но там много опечаток и мало информации. Это видео https://youtu.be/ichOiuBoBoQ выглядело многообещающим, но там пошла какая-то проективная геометрия? и я ничего не понял.
Ну, короче, если кратко, то идея такая, что в два кватерниона определённым образом записываются поворот + смещение, а сами два кватерниона объединяются в один "дуальный". И определяются операции над этими дуальными кватернионами, которые основаны на дуальных числах (что-то вроде комплексных), где компонентами выбрали кватернионы. И так выходит, что если вписать обычный 3д вектор в дуальный кватернион (единица в вещественной части и сам вектор в дуальной https://en.wikipedia.org/wiki/Dual_quaternion#Dual_quaternions_and_4%C3%974_homogeneous_transforms), и домножить его слева на дуальный кватернион, а справа на его сопряжённое (как в смысле дуальных чисел, так и в смысле кватернионов), то типо получается сначала повёрнутый, а потом смещённый вектор. И вроде как смысл в том, что эти дуальные кватернионы тоже можно интерполировать, как обычные кватернионы. Вроде ещё для чего-то используются в анимации этот чел рассказывал https://youtu.be/en2QcehKJd8 про какой-то candy-wrapper эффект, но я его презентацию аболютно не понял от начала и до конца.
Гораздо больше магических формул, взявшихся из ниоткуда, я максимум просто проверил, что формула действительно делает с вектором поворот + смещение. Я не стал пытаться самостоятельно пройти аналогичный путь, как с обычными кватернионами: от формулы, записанной в форме векторов, к формуле через дуальные кватернионы p' = qpq∗, я не вывезу и запутаюсь.
В конце немного про отражения, выраженные через кватернионы. Я не задумывался о том, что два последовательных отражения - это поворот (или задумывался, я забыл), но с формулами отражения/поворота через кватернионы это легко выводится. Это всё немного перекликается с той статьёй про роторы, только там вроде наоборот: сначала шли отражения, а потом повороты через них выражались. Ну и формулы выглядят там визуально похоже.
Я сначала смотрел это видео 3b1b https://youtu.be/d4EgbgTm0Bg и это https://eater.net/quaternions но, по-моему, это просто бред какой-то: ну я вижу, что да, стереографическая проекция кусков 4д сферы в трёхмерное пространство, да, умножение на кватернион растягивает и крутит проекцию, да, если умножить слева на единичный кватернион и справа на сопряжённый, то растягивания типа компенсируют друг друга и проекция крутится, ну и чё дальше, это что-то на уровне того мультика про выворачивание сферы наизнанку, вот тоже сидишь смотришь и киваешь пустой башкой.
По-моему, в плане геометрических преобразований комплексные числа и кватернионы слишком разные, несмотря на то, что одно является расширением другого. Умножение на комплексное число делает произвольный поворот + скейлинг 2д векторов, а умножение на кватернион вроде бы не может сделать даже произвольный поворот 4д вектора: слишком мало компонентов, нужно хотя бы 6. Короче, я не вижу пользы в том, чтобы проводить параллели между ними.
Я не особо понимаю, сколько нужно чисел для представления произвольного поворота в N-мерном пространстве. Вроде бы один вариант, как об этом можно думать, это, что мы хотим выбрать все различные пары осей координат, которые будут представлять плоскости поворота, и это количество равно числу сочетаний из N по 2, то есть N! / ((N-2)! 2!) = N (N - 1) / 2. В 3д обычно говорят об осях вращения, но просто можно взять нормали к плоскостям в качестве осей. В 2д вообще плоскость только одна, поэтому и поворот представляется только одним числом.
Другой вариант - это представить, что у нас есть куб с рёбрами, выровненными по осям координат, и мы хотим его повернуть в какую-то ориентацию. Сначала хватаемся за ребро, смотрящее в направлении оси X, и у нас есть N - 1 степеней свободы (по количеству оставшихся осей координат), чтобы ориентировать его, как нам надо. После хватаемся за ось Y, тоже ставим её в нужное положение, но только у нас осталось уже N - 2 степеней свободы, так как X мы зафиксировали. (N - 1) + (N - 2) + ... + 1 = N (N - 1) / 2.
Ещё из попыток объяснить кватернионы такое есть https://marctenbosch.com/quaternions что-то что-то бивекторы, внешнее произведение, роторы, ничего не понял особо в итоге и сложилось впечатление, что магические формулы кватернионов просто подменили на другие магические формулы.
Короче, в итоге, если ты тупой, то похоже нет смысла пытаться понять, что было в голове у того чела, который придумал кватернионы, почему 4д кватернионы используются для 3д поворотов и какой глубинный смысл формулы p' = qpq∗. И просто последовательно всё вывести из формулы i2 = j2 = k2 = ijk = -1, которую, допустим, я увидел, проходя мимо моста.
https://www.youtube.com/playlist?list=PLpzmRsG7u_gr0FO12cBWj-15_e0yqQQ1U вот эти видео нормальные, ну вот только представление операции умножения на кватернион в виде матрицы оказалось каким-то бесполезным. Я думал его можно было бы использовать для вывода матричной формы p' = qpq∗, но не вижу, как. Ну просто интересно получается, что матрицы эти, выходит изоморфны кватернионам? И тут реально наделяется смысл тому, что значит, например, возвести i в квадрат и получить -1.
Представление кватерниона в виде скаляра + вектора очень удобное и вроде как раз исторически именно отсюда пошли векторное и скалярное произведения векторов: они вылезают в формуле умножения кватернионов. Отсюда становится понятно, почему они выглядят такими искусственными и взявшимися из ниоткуда (ну у них есть геометрический смысл, но, по-моему, не самый очевидный, чтобы взять просто на ровном месте придумать эти операции для векторов).
Формулу поворота он сначала выводит через векторное и скалярное произведения, а потом показывает, как переписать её через кватернионы, используя типа аналог формулы эйлера для кватернионов, выходит так: v' = eθn/2 v e-θn/2. Почему половинный угол? Я не знаю, да и какая разница, ну просто получилось так. И я видел все эти картинки с книжками, к которым прицеплена ленточка, и там она перекручивается, если перевернуть книжку на 360 градусов, но если перевернуть на 720, то её можно размотать без переворачивания книжки и бла-бла-бла, это не имеет никакого смысла в моих глазах.
По-моему, это просто означает, что ну ок, получается, при повороте через кватернионы, можно выбрать то, по какой дуге делать поворот: по короткой или по длинной. Ну, типо, например, поворот от 120 градусов либо к 240 градусам, либо к -120 градусам. Финальная ориентация одна и та же, но поворот сделан либо против, либо по часовой стрелке.
Матричную запись поворота через кватернионы можно вывести так http://www.songho.ca/opengl/gl_quaternion.html но это какое-то безумие, нашёл вариант попроще https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Quaternion-derived_rotation_matrix немного подробнее расписал.
Я так понял, что между кватернионами можно просто брать и делать линейную интерполяцию и в отличие от матриц, с которыми если так сделать, то объект будет искажаться и вроде может быть shearing? Я не уверен, есть ли искажения в случае с кватернионами, сам не пробовал ещё, а, ну, наверное, их нужно будет нормализовывать после лерпа, потому что он величину вектора не сохраняет. Но, если просто лерпать, то в любом случае оно крутиться будет как минимум с неравномерной скоростью, для постоянной скорости нужен слерп. Вывод формулы слерпа отсюда http://allenchou.net/2018/05/game-math-deriving-the-slerp-formula
Но, в итоге, если честно, я не особо понимаю, почему слерп кватернионов как 4д векторов результирует именно в плавный поворот вроде как по кратчайшей дуге в 3д, что означает угол между кватернионами как 4д векторами в этом контексте... Это, наверное, можно проверить, если взять два произвольных кватерниона p и q, подставить их в формулу слерпа, чтобы получить промежуточный кватернион slerp(p, q, t). Потом взять произвольный вектор v и проверить, что промежуточно повёрнутый "slerp(p, q, t) v slerp(p, q, t)∗" лежит в плоскости, которую образуют qvq∗ и pvp∗, и что он повёрнут на правильный угол относительно них? Я это всё сойду с ума считать, у меня нет сейчас сил на такое. В общем, я просто не вижу интуицию, почему это работает, я слишком тупой, я реально отсталый.
Про дуальные кватернионы (именно дуальные, октонионы - это что-то другое, хотя и у тех, и у других по 8 компонентов) немного посмотрел, в основном отсюда https://cs.gmu.edu/~jmlien/teaching/cs451/uploads/Main/dual-quaternion.pdf но там много опечаток и мало информации. Это видео https://youtu.be/ichOiuBoBoQ выглядело многообещающим, но там пошла какая-то проективная геометрия? и я ничего не понял.
Ну, короче, если кратко, то идея такая, что в два кватерниона определённым образом записываются поворот + смещение, а сами два кватерниона объединяются в один "дуальный". И определяются операции над этими дуальными кватернионами, которые основаны на дуальных числах (что-то вроде комплексных), где компонентами выбрали кватернионы. И так выходит, что если вписать обычный 3д вектор в дуальный кватернион (единица в вещественной части и сам вектор в дуальной https://en.wikipedia.org/wiki/Dual_quaternion#Dual_quaternions_and_4%C3%974_homogeneous_transforms), и домножить его слева на дуальный кватернион, а справа на его сопряжённое (как в смысле дуальных чисел, так и в смысле кватернионов), то типо получается сначала повёрнутый, а потом смещённый вектор. И вроде как смысл в том, что эти дуальные кватернионы тоже можно интерполировать, как обычные кватернионы. Вроде ещё для чего-то используются в анимации этот чел рассказывал https://youtu.be/en2QcehKJd8 про какой-то candy-wrapper эффект, но я его презентацию аболютно не понял от начала и до конца.
Гораздо больше магических формул, взявшихся из ниоткуда, я максимум просто проверил, что формула действительно делает с вектором поворот + смещение. Я не стал пытаться самостоятельно пройти аналогичный путь, как с обычными кватернионами: от формулы, записанной в форме векторов, к формуле через дуальные кватернионы p' = qpq∗, я не вывезу и запутаюсь.
В конце немного про отражения, выраженные через кватернионы. Я не задумывался о том, что два последовательных отражения - это поворот (или задумывался, я забыл), но с формулами отражения/поворота через кватернионы это легко выводится. Это всё немного перекликается с той статьёй про роторы, только там вроде наоборот: сначала шли отражения, а потом повороты через них выражались. Ну и формулы выглядят там визуально похоже.
725 Кб, 1448x2048Попытался сделать свою функцию для парсинга (сингловых) флоатов из строки, но получилось какое-то длинное шизоидное тормознутое полотно https://godbolt.org/z/1YKzf87sY
Основная идея в том, чтобы распаковать флоат в бинарное число с фиксированной точкой с гигантской точностью, чтобы в него уместился любой флоат без потери точности, а потом скопировать биты после первой старшей единицы в мантиссу + посчитать экспоненту так, чтобы она сдвигала точку в нужное место. Примерно то же самое, что описывал тот чел https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 для обратной операции (перевод из флоата в строку с десятичной дробью), но нет заморочек с тем, чтобы вывести самое короткое представление в десятичном виде, потому что тут результат фиксированного размера.
Проблема в том, что десятичную дробь в бинарную не всегда можно записать конечным количеством цифр, поэтому придётся округлять. Я сделал вроде примерно, как в той >>735955 статье рассказывалось: что беру дополнительно два следующих бита (guard и round) после того, как заканчивается точность мантиссы, и ещё третий бит равный OR-у всех оставшихся битов (sticky). Ну и типо, если биты равны 0xx, то округляешь вниз, если 100, то к чётному, иначе вверх. Округление делается просто через +1 к почти готовому флоату, проинтерпретированному как u32.
Непонятно, сколько нужно вперёд битов брать, чтобы вычислить sticky бит. У меня на целую часть выделено 5 u32-ых (типо самый длинный флоат 2^127 + ещё сверху нужно хотя бы 2 бита на guard и round), и на дробную тоже 5 u32-ых (самый маленький положительный флоат 2^-149 + тоже биты для округления). Ну и как будто хватает.
Чтобы перевести десятичную целую часть в бинарную, можно просто взять это число, состоящее из 5 u32-ых, изначально равное нулю, и последовательно умножать его на 10 и прибавлять следующую и следующую цифру из входной строки слева от точки. Умножение столбиком (long multiplication) и о нём тут можно думать как об умножении числа из 5 цифр на число из одной цифры в 2^32-ричной системе счисления, то есть просто напрямую перемножаешь два u32, прибавляешь перенос, записываешь результат в u64, после чего одна половина идёт в результат произведения, а вторая - в перенос к умножению на следующий разряд. Со сложением в столбик примерно то же самое.
А дробную часть не знаю, как нормально переводить в бинарный вид. Я думал, можно обойтись так же, как с целой, и что-нибудь с экспонентой сделать, но проблема в том, что в изначальной форме число десятичное, а приводится к двоичному и непонятно, как сконвертировать умножение на 10^n в умножение на 2^n. Я в итоге сделал через последовательное умножение десятичной дробной части на 2, ну то есть буквально записываешь все цифры из входной строки после точки в массив, оставив в начале один ноль для целой части, и столбиком умножаешь их на 2. Умножил один раз, если в целой части вылезла единица, то значит в числе есть одна 1/2-ая, иначе ноль, единицу зануляешь, и потом умножаешь ещё раз на 2 - получил количество 1/4-ых в числе, ещё раз - количество 1/8-ых, и так далее, по ходу записываешь результат в бинарном виде.
И к этому ещё нужно было как-то прикрутить парсинг такой записи 1e-2, и тут та же проблема, короче, я просто как-то криво сделал, что при переводе целой/дробной части в бинарную я, в зависимости от десятичной экспоненты, например, читаю цифры из целой десятичной части в дробную бинарную, если экспонента отрицательная, либо читаю из дробной десятичной в целую бинарную, если положительная, либо забиваю нулями, короче, такой бред.
Для парсинга десятичной экспоненты нужен парсинг интов + понимать, умещается ли последовательность цифр в инт, и я почему-то написал какой-то бред, что для этого я просто сравниваю входную строку лексикографически с максимальным / минимальным интом, записанным в строку. Другой вариант был бы, наверное, попробовать упихнуть последовательность цифр в инт и на каждой следующей цифре проверять сложение / умножение на переполнение, не знаю, что хуже.
А с денормализованными как будто всё легко получилось, потому что просто, когда целая часть нулевая и идёшь по бинарной дробной в поисках первой единицы, постепенно уменьшая бинарную экспоненту, то останавливаешься в момент, когда бинарная экспонента андерфловится, и дальше уже пишешь все следующие биты в мантиссу, какими бы они ни были.
И вот весь этот бред он вроде работает, но как-то медленно, по крайней мере достаточно, чтобы мне лень ждать, чтобы проверить его хотя бы на всех сингловых флоатах, отформатированных через sprintf, и то это не будет избыточной проверкой, потому что это будут только некоторые из возможных входных десятичных дробей.
Скорее всего, основная проблема в том, что я делаю всякий побитовый бред вручную вместо того, чтобы использовать интринсики, ну которые там количество единиц считают или находят бит со старшей единицей. Ну и сам подход в корне какой-то дебильный: что мне приходится сначала всё разворачивать в гигантский десимал, а потом сворачивать в крошечный флоат.
Основная идея в том, чтобы распаковать флоат в бинарное число с фиксированной точкой с гигантской точностью, чтобы в него уместился любой флоат без потери точности, а потом скопировать биты после первой старшей единицы в мантиссу + посчитать экспоненту так, чтобы она сдвигала точку в нужное место. Примерно то же самое, что описывал тот чел https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 для обратной операции (перевод из флоата в строку с десятичной дробью), но нет заморочек с тем, чтобы вывести самое короткое представление в десятичном виде, потому что тут результат фиксированного размера.
Проблема в том, что десятичную дробь в бинарную не всегда можно записать конечным количеством цифр, поэтому придётся округлять. Я сделал вроде примерно, как в той >>735955 статье рассказывалось: что беру дополнительно два следующих бита (guard и round) после того, как заканчивается точность мантиссы, и ещё третий бит равный OR-у всех оставшихся битов (sticky). Ну и типо, если биты равны 0xx, то округляешь вниз, если 100, то к чётному, иначе вверх. Округление делается просто через +1 к почти готовому флоату, проинтерпретированному как u32.
Непонятно, сколько нужно вперёд битов брать, чтобы вычислить sticky бит. У меня на целую часть выделено 5 u32-ых (типо самый длинный флоат 2^127 + ещё сверху нужно хотя бы 2 бита на guard и round), и на дробную тоже 5 u32-ых (самый маленький положительный флоат 2^-149 + тоже биты для округления). Ну и как будто хватает.
Чтобы перевести десятичную целую часть в бинарную, можно просто взять это число, состоящее из 5 u32-ых, изначально равное нулю, и последовательно умножать его на 10 и прибавлять следующую и следующую цифру из входной строки слева от точки. Умножение столбиком (long multiplication) и о нём тут можно думать как об умножении числа из 5 цифр на число из одной цифры в 2^32-ричной системе счисления, то есть просто напрямую перемножаешь два u32, прибавляешь перенос, записываешь результат в u64, после чего одна половина идёт в результат произведения, а вторая - в перенос к умножению на следующий разряд. Со сложением в столбик примерно то же самое.
А дробную часть не знаю, как нормально переводить в бинарный вид. Я думал, можно обойтись так же, как с целой, и что-нибудь с экспонентой сделать, но проблема в том, что в изначальной форме число десятичное, а приводится к двоичному и непонятно, как сконвертировать умножение на 10^n в умножение на 2^n. Я в итоге сделал через последовательное умножение десятичной дробной части на 2, ну то есть буквально записываешь все цифры из входной строки после точки в массив, оставив в начале один ноль для целой части, и столбиком умножаешь их на 2. Умножил один раз, если в целой части вылезла единица, то значит в числе есть одна 1/2-ая, иначе ноль, единицу зануляешь, и потом умножаешь ещё раз на 2 - получил количество 1/4-ых в числе, ещё раз - количество 1/8-ых, и так далее, по ходу записываешь результат в бинарном виде.
И к этому ещё нужно было как-то прикрутить парсинг такой записи 1e-2, и тут та же проблема, короче, я просто как-то криво сделал, что при переводе целой/дробной части в бинарную я, в зависимости от десятичной экспоненты, например, читаю цифры из целой десятичной части в дробную бинарную, если экспонента отрицательная, либо читаю из дробной десятичной в целую бинарную, если положительная, либо забиваю нулями, короче, такой бред.
Для парсинга десятичной экспоненты нужен парсинг интов + понимать, умещается ли последовательность цифр в инт, и я почему-то написал какой-то бред, что для этого я просто сравниваю входную строку лексикографически с максимальным / минимальным интом, записанным в строку. Другой вариант был бы, наверное, попробовать упихнуть последовательность цифр в инт и на каждой следующей цифре проверять сложение / умножение на переполнение, не знаю, что хуже.
А с денормализованными как будто всё легко получилось, потому что просто, когда целая часть нулевая и идёшь по бинарной дробной в поисках первой единицы, постепенно уменьшая бинарную экспоненту, то останавливаешься в момент, когда бинарная экспонента андерфловится, и дальше уже пишешь все следующие биты в мантиссу, какими бы они ни были.
И вот весь этот бред он вроде работает, но как-то медленно, по крайней мере достаточно, чтобы мне лень ждать, чтобы проверить его хотя бы на всех сингловых флоатах, отформатированных через sprintf, и то это не будет избыточной проверкой, потому что это будут только некоторые из возможных входных десятичных дробей.
Скорее всего, основная проблема в том, что я делаю всякий побитовый бред вручную вместо того, чтобы использовать интринсики, ну которые там количество единиц считают или находят бит со старшей единицей. Ну и сам подход в корне какой-то дебильный: что мне приходится сначала всё разворачивать в гигантский десимал, а потом сворачивать в крошечный флоат.
725 Кб, 1448x2048Попытался сделать свою функцию для парсинга (сингловых) флоатов из строки, но получилось какое-то длинное шизоидное тормознутое полотно https://godbolt.org/z/1YKzf87sY
Основная идея в том, чтобы распаковать флоат в бинарное число с фиксированной точкой с гигантской точностью, чтобы в него уместился любой флоат без потери точности, а потом скопировать биты после первой старшей единицы в мантиссу + посчитать экспоненту так, чтобы она сдвигала точку в нужное место. Примерно то же самое, что описывал тот чел https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 для обратной операции (перевод из флоата в строку с десятичной дробью), но нет заморочек с тем, чтобы вывести самое короткое представление в десятичном виде, потому что тут результат фиксированного размера.
Проблема в том, что десятичную дробь в бинарную не всегда можно записать конечным количеством цифр, поэтому придётся округлять. Я сделал вроде примерно, как в той >>735955 статье рассказывалось: что беру дополнительно два следующих бита (guard и round) после того, как заканчивается точность мантиссы, и ещё третий бит равный OR-у всех оставшихся битов (sticky). Ну и типо, если биты равны 0xx, то округляешь вниз, если 100, то к чётному, иначе вверх. Округление делается просто через +1 к почти готовому флоату, проинтерпретированному как u32.
Непонятно, сколько нужно вперёд битов брать, чтобы вычислить sticky бит. У меня на целую часть выделено 5 u32-ых (типо самый длинный флоат 2^127 + ещё сверху нужно хотя бы 2 бита на guard и round), и на дробную тоже 5 u32-ых (самый маленький положительный флоат 2^-149 + тоже биты для округления). Ну и как будто хватает.
Чтобы перевести десятичную целую часть в бинарную, можно просто взять это число, состоящее из 5 u32-ых, изначально равное нулю, и последовательно умножать его на 10 и прибавлять следующую и следующую цифру из входной строки слева от точки. Умножение столбиком (long multiplication) и о нём тут можно думать как об умножении числа из 5 цифр на число из одной цифры в 2^32-ричной системе счисления, то есть просто напрямую перемножаешь два u32, прибавляешь перенос, записываешь результат в u64, после чего одна половина идёт в результат произведения, а вторая - в перенос к умножению на следующий разряд. Со сложением в столбик примерно то же самое.
А дробную часть не знаю, как нормально переводить в бинарный вид. Я думал, можно обойтись так же, как с целой, и что-нибудь с экспонентой сделать, но проблема в том, что в изначальной форме число десятичное, а приводится к двоичному и непонятно, как сконвертировать умножение на 10^n в умножение на 2^n. Я в итоге сделал через последовательное умножение десятичной дробной части на 2, ну то есть буквально записываешь все цифры из входной строки после точки в массив, оставив в начале один ноль для целой части, и столбиком умножаешь их на 2. Умножил один раз, если в целой части вылезла единица, то значит в числе есть одна 1/2-ая, иначе ноль, единицу зануляешь, и потом умножаешь ещё раз на 2 - получил количество 1/4-ых в числе, ещё раз - количество 1/8-ых, и так далее, по ходу записываешь результат в бинарном виде.
И к этому ещё нужно было как-то прикрутить парсинг такой записи 1e-2, и тут та же проблема, короче, я просто как-то криво сделал, что при переводе целой/дробной части в бинарную я, в зависимости от десятичной экспоненты, например, читаю цифры из целой десятичной части в дробную бинарную, если экспонента отрицательная, либо читаю из дробной десятичной в целую бинарную, если положительная, либо забиваю нулями, короче, такой бред.
Для парсинга десятичной экспоненты нужен парсинг интов + понимать, умещается ли последовательность цифр в инт, и я почему-то написал какой-то бред, что для этого я просто сравниваю входную строку лексикографически с максимальным / минимальным интом, записанным в строку. Другой вариант был бы, наверное, попробовать упихнуть последовательность цифр в инт и на каждой следующей цифре проверять сложение / умножение на переполнение, не знаю, что хуже.
А с денормализованными как будто всё легко получилось, потому что просто, когда целая часть нулевая и идёшь по бинарной дробной в поисках первой единицы, постепенно уменьшая бинарную экспоненту, то останавливаешься в момент, когда бинарная экспонента андерфловится, и дальше уже пишешь все следующие биты в мантиссу, какими бы они ни были.
И вот весь этот бред он вроде работает, но как-то медленно, по крайней мере достаточно, чтобы мне лень ждать, чтобы проверить его хотя бы на всех сингловых флоатах, отформатированных через sprintf, и то это не будет избыточной проверкой, потому что это будут только некоторые из возможных входных десятичных дробей.
Скорее всего, основная проблема в том, что я делаю всякий побитовый бред вручную вместо того, чтобы использовать интринсики, ну которые там количество единиц считают или находят бит со старшей единицей. Ну и сам подход в корне какой-то дебильный: что мне приходится сначала всё разворачивать в гигантский десимал, а потом сворачивать в крошечный флоат.
Основная идея в том, чтобы распаковать флоат в бинарное число с фиксированной точкой с гигантской точностью, чтобы в него уместился любой флоат без потери точности, а потом скопировать биты после первой старшей единицы в мантиссу + посчитать экспоненту так, чтобы она сдвигала точку в нужное место. Примерно то же самое, что описывал тот чел https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 для обратной операции (перевод из флоата в строку с десятичной дробью), но нет заморочек с тем, чтобы вывести самое короткое представление в десятичном виде, потому что тут результат фиксированного размера.
Проблема в том, что десятичную дробь в бинарную не всегда можно записать конечным количеством цифр, поэтому придётся округлять. Я сделал вроде примерно, как в той >>735955 статье рассказывалось: что беру дополнительно два следующих бита (guard и round) после того, как заканчивается точность мантиссы, и ещё третий бит равный OR-у всех оставшихся битов (sticky). Ну и типо, если биты равны 0xx, то округляешь вниз, если 100, то к чётному, иначе вверх. Округление делается просто через +1 к почти готовому флоату, проинтерпретированному как u32.
Непонятно, сколько нужно вперёд битов брать, чтобы вычислить sticky бит. У меня на целую часть выделено 5 u32-ых (типо самый длинный флоат 2^127 + ещё сверху нужно хотя бы 2 бита на guard и round), и на дробную тоже 5 u32-ых (самый маленький положительный флоат 2^-149 + тоже биты для округления). Ну и как будто хватает.
Чтобы перевести десятичную целую часть в бинарную, можно просто взять это число, состоящее из 5 u32-ых, изначально равное нулю, и последовательно умножать его на 10 и прибавлять следующую и следующую цифру из входной строки слева от точки. Умножение столбиком (long multiplication) и о нём тут можно думать как об умножении числа из 5 цифр на число из одной цифры в 2^32-ричной системе счисления, то есть просто напрямую перемножаешь два u32, прибавляешь перенос, записываешь результат в u64, после чего одна половина идёт в результат произведения, а вторая - в перенос к умножению на следующий разряд. Со сложением в столбик примерно то же самое.
А дробную часть не знаю, как нормально переводить в бинарный вид. Я думал, можно обойтись так же, как с целой, и что-нибудь с экспонентой сделать, но проблема в том, что в изначальной форме число десятичное, а приводится к двоичному и непонятно, как сконвертировать умножение на 10^n в умножение на 2^n. Я в итоге сделал через последовательное умножение десятичной дробной части на 2, ну то есть буквально записываешь все цифры из входной строки после точки в массив, оставив в начале один ноль для целой части, и столбиком умножаешь их на 2. Умножил один раз, если в целой части вылезла единица, то значит в числе есть одна 1/2-ая, иначе ноль, единицу зануляешь, и потом умножаешь ещё раз на 2 - получил количество 1/4-ых в числе, ещё раз - количество 1/8-ых, и так далее, по ходу записываешь результат в бинарном виде.
И к этому ещё нужно было как-то прикрутить парсинг такой записи 1e-2, и тут та же проблема, короче, я просто как-то криво сделал, что при переводе целой/дробной части в бинарную я, в зависимости от десятичной экспоненты, например, читаю цифры из целой десятичной части в дробную бинарную, если экспонента отрицательная, либо читаю из дробной десятичной в целую бинарную, если положительная, либо забиваю нулями, короче, такой бред.
Для парсинга десятичной экспоненты нужен парсинг интов + понимать, умещается ли последовательность цифр в инт, и я почему-то написал какой-то бред, что для этого я просто сравниваю входную строку лексикографически с максимальным / минимальным интом, записанным в строку. Другой вариант был бы, наверное, попробовать упихнуть последовательность цифр в инт и на каждой следующей цифре проверять сложение / умножение на переполнение, не знаю, что хуже.
А с денормализованными как будто всё легко получилось, потому что просто, когда целая часть нулевая и идёшь по бинарной дробной в поисках первой единицы, постепенно уменьшая бинарную экспоненту, то останавливаешься в момент, когда бинарная экспонента андерфловится, и дальше уже пишешь все следующие биты в мантиссу, какими бы они ни были.
И вот весь этот бред он вроде работает, но как-то медленно, по крайней мере достаточно, чтобы мне лень ждать, чтобы проверить его хотя бы на всех сингловых флоатах, отформатированных через sprintf, и то это не будет избыточной проверкой, потому что это будут только некоторые из возможных входных десятичных дробей.
Скорее всего, основная проблема в том, что я делаю всякий побитовый бред вручную вместо того, чтобы использовать интринсики, ну которые там количество единиц считают или находят бит со старшей единицей. Ну и сам подход в корне какой-то дебильный: что мне приходится сначала всё разворачивать в гигантский десимал, а потом сворачивать в крошечный флоат.
Попробовал сейчас пользовать ффмпег программно, но не через libav∗ либы (так уже пробовал и это слишком больно), а напрямую запускать экзешник ффмпега. Один вариант - это сначала отрендерить все кадры в пронумерованные файлы и потом ффмпегом объединить их в видео, другой вариант - кормить процессу с ффмпегом кадры через stdin.
Идею для видео украл откуда-то (гифку увидел в интернете), круги, расположенные по сетке, на точках пересечения цвет меняется на противоположный, радиус меняют по синусоиде со сдвигом в зависимости от расстояния от центра. Каждый раз не могу понять, правильно ли я сделал закольцовывание или нет.
Через сохранение в файлы не пробовал, там основная сложность, в каком формате сохранять файлы, ну, наверное, лучше всего в пнг, но ффмпег также понимает это https://netpbm.sourceforge.net/doc/ppm.html (никакого сжатия) и это https://qoiformat.org (какое-то сжатие, вроде несложно написать свой энкодер). Плюс в том, что промежуточные результаты рендера сохраняются на диск: в теории можно поставить на паузу и продолжить позже или сохранить видео в нескольких форматах без траты времени на то, чтобы перерендеривать кадры. Минус в том, что наверное, много место занимает, даже с учётом сжатия?
Я сам сделал через stdin, ффмпег запускается примерно такой командой:
И просто в него скармливаешь подряд байты в формате, какой указал в -pix_fmt, в конце закрываешь stdin и ждёшь завершения работы процесса.
Под виндой это делается через то, чтобы создать пайп, один его конец (read) прицепить к дочернему процессу с ффмпегом при его создании, а во второй (write) писать из родительского, который потом в конце закрыть просто как обычный файл через CloseHandle. https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output
CreateProcess - какая-то странная функция, куча параметров и я не понимаю, что передавать в параметры application name и что в command line. Если в application name положить путь до экзешника ffmpeg, а в command line команду полностью, включая "ffmpeg" в начале, то работает. Другие комбинации по типу "NULL в application name, полностью команду в command line" или "путь до ффмпега в application name, пропустить ffmpeg в command line" либо работают как-то странно, либо падают с ошибкой.
Под линуксом, вроде я слышал, это делается через fork+exec и что-то ещё для пайпов, но я не пробовал, у меня сейчас нет линукса и не очень хочется.
С линуксом я недавно мучился, когда пытался установить его на qemu виртуалку с UEFI, потому что я хотел попробовать установить так, чтобы оно грузилось без бутлодера (efistub). И я, во-первых, не сразу понял, что если ты редактируешь efivars, то недостаточно просто делать -bios OVMF.fd, нужно отдельно подключать драйв с кодом UEFI и драйв, где хранятся efivars
А, во-вторых, начались проблемы с qemu под виндой, что ускоритель whpx не дружит с тем, чтобы вот так отдельно code и vars подключать. Обходится через то, чтобы один раз запуститься без whpx, отредактировать efivars, склеить vars и code в один файл и потом подключать его через -bios одновременно уже с whpx.
И я как-то очень поздно нагуглил ридми https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-qemu/msys2.readme.txt где решения всех этих проблем описываются прямым текстом.
UEFI биос, кстати, отсюда можно скачать https://retrage.github.io/edk2-nightly и я помню, что когда делал хелловорлд на уефи и тестил его в виртуалке, то я его сам собирал этот биос из-за того, что тупо не мог нагуглить, где скачать готовый билд. Мне кажется, у меня упал iq ещё сильнее и я перестал уметь пользоваться гуглом.
Ну и, на самом деле, под виндой во всех этих заморочках с qemu не особо есть смысл, потому что тут, оказывается, есть hyper-v manager - что-то похожее на virt-manager из линукса, и в нём также есть какая-то своя встроенная реализация UEFI.
Идею для видео украл откуда-то (гифку увидел в интернете), круги, расположенные по сетке, на точках пересечения цвет меняется на противоположный, радиус меняют по синусоиде со сдвигом в зависимости от расстояния от центра. Каждый раз не могу понять, правильно ли я сделал закольцовывание или нет.
Через сохранение в файлы не пробовал, там основная сложность, в каком формате сохранять файлы, ну, наверное, лучше всего в пнг, но ффмпег также понимает это https://netpbm.sourceforge.net/doc/ppm.html (никакого сжатия) и это https://qoiformat.org (какое-то сжатие, вроде несложно написать свой энкодер). Плюс в том, что промежуточные результаты рендера сохраняются на диск: в теории можно поставить на паузу и продолжить позже или сохранить видео в нескольких форматах без траты времени на то, чтобы перерендеривать кадры. Минус в том, что наверное, много место занимает, даже с учётом сжатия?
Я сам сделал через stdin, ффмпег запускается примерно такой командой:
> ffmpeg -y -f rawvideo -pix_fmt argb -s 1920x1080 -r 60 -i - -an out.mp4
И просто в него скармливаешь подряд байты в формате, какой указал в -pix_fmt, в конце закрываешь stdin и ждёшь завершения работы процесса.
Под виндой это делается через то, чтобы создать пайп, один его конец (read) прицепить к дочернему процессу с ффмпегом при его создании, а во второй (write) писать из родительского, который потом в конце закрыть просто как обычный файл через CloseHandle. https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output
CreateProcess - какая-то странная функция, куча параметров и я не понимаю, что передавать в параметры application name и что в command line. Если в application name положить путь до экзешника ffmpeg, а в command line команду полностью, включая "ffmpeg" в начале, то работает. Другие комбинации по типу "NULL в application name, полностью команду в command line" или "путь до ффмпега в application name, пропустить ffmpeg в command line" либо работают как-то странно, либо падают с ошибкой.
Под линуксом, вроде я слышал, это делается через fork+exec и что-то ещё для пайпов, но я не пробовал, у меня сейчас нет линукса и не очень хочется.
С линуксом я недавно мучился, когда пытался установить его на qemu виртуалку с UEFI, потому что я хотел попробовать установить так, чтобы оно грузилось без бутлодера (efistub). И я, во-первых, не сразу понял, что если ты редактируешь efivars, то недостаточно просто делать -bios OVMF.fd, нужно отдельно подключать драйв с кодом UEFI и драйв, где хранятся efivars
> -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd
А, во-вторых, начались проблемы с qemu под виндой, что ускоритель whpx не дружит с тем, чтобы вот так отдельно code и vars подключать. Обходится через то, чтобы один раз запуститься без whpx, отредактировать efivars, склеить vars и code в один файл и потом подключать его через -bios одновременно уже с whpx.
И я как-то очень поздно нагуглил ридми https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-qemu/msys2.readme.txt где решения всех этих проблем описываются прямым текстом.
UEFI биос, кстати, отсюда можно скачать https://retrage.github.io/edk2-nightly и я помню, что когда делал хелловорлд на уефи и тестил его в виртуалке, то я его сам собирал этот биос из-за того, что тупо не мог нагуглить, где скачать готовый билд. Мне кажется, у меня упал iq ещё сильнее и я перестал уметь пользоваться гуглом.
Ну и, на самом деле, под виндой во всех этих заморочках с qemu не особо есть смысл, потому что тут, оказывается, есть hyper-v manager - что-то похожее на virt-manager из линукса, и в нём также есть какая-то своя встроенная реализация UEFI.
Попробовал сейчас пользовать ффмпег программно, но не через libav∗ либы (так уже пробовал и это слишком больно), а напрямую запускать экзешник ффмпега. Один вариант - это сначала отрендерить все кадры в пронумерованные файлы и потом ффмпегом объединить их в видео, другой вариант - кормить процессу с ффмпегом кадры через stdin.
Идею для видео украл откуда-то (гифку увидел в интернете), круги, расположенные по сетке, на точках пересечения цвет меняется на противоположный, радиус меняют по синусоиде со сдвигом в зависимости от расстояния от центра. Каждый раз не могу понять, правильно ли я сделал закольцовывание или нет.
Через сохранение в файлы не пробовал, там основная сложность, в каком формате сохранять файлы, ну, наверное, лучше всего в пнг, но ффмпег также понимает это https://netpbm.sourceforge.net/doc/ppm.html (никакого сжатия) и это https://qoiformat.org (какое-то сжатие, вроде несложно написать свой энкодер). Плюс в том, что промежуточные результаты рендера сохраняются на диск: в теории можно поставить на паузу и продолжить позже или сохранить видео в нескольких форматах без траты времени на то, чтобы перерендеривать кадры. Минус в том, что наверное, много место занимает, даже с учётом сжатия?
Я сам сделал через stdin, ффмпег запускается примерно такой командой:
И просто в него скармливаешь подряд байты в формате, какой указал в -pix_fmt, в конце закрываешь stdin и ждёшь завершения работы процесса.
Под виндой это делается через то, чтобы создать пайп, один его конец (read) прицепить к дочернему процессу с ффмпегом при его создании, а во второй (write) писать из родительского, который потом в конце закрыть просто как обычный файл через CloseHandle. https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output
CreateProcess - какая-то странная функция, куча параметров и я не понимаю, что передавать в параметры application name и что в command line. Если в application name положить путь до экзешника ffmpeg, а в command line команду полностью, включая "ffmpeg" в начале, то работает. Другие комбинации по типу "NULL в application name, полностью команду в command line" или "путь до ффмпега в application name, пропустить ffmpeg в command line" либо работают как-то странно, либо падают с ошибкой.
Под линуксом, вроде я слышал, это делается через fork+exec и что-то ещё для пайпов, но я не пробовал, у меня сейчас нет линукса и не очень хочется.
С линуксом я недавно мучился, когда пытался установить его на qemu виртуалку с UEFI, потому что я хотел попробовать установить так, чтобы оно грузилось без бутлодера (efistub). И я, во-первых, не сразу понял, что если ты редактируешь efivars, то недостаточно просто делать -bios OVMF.fd, нужно отдельно подключать драйв с кодом UEFI и драйв, где хранятся efivars
А, во-вторых, начались проблемы с qemu под виндой, что ускоритель whpx не дружит с тем, чтобы вот так отдельно code и vars подключать. Обходится через то, чтобы один раз запуститься без whpx, отредактировать efivars, склеить vars и code в один файл и потом подключать его через -bios одновременно уже с whpx.
И я как-то очень поздно нагуглил ридми https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-qemu/msys2.readme.txt где решения всех этих проблем описываются прямым текстом.
UEFI биос, кстати, отсюда можно скачать https://retrage.github.io/edk2-nightly и я помню, что когда делал хелловорлд на уефи и тестил его в виртуалке, то я его сам собирал этот биос из-за того, что тупо не мог нагуглить, где скачать готовый билд. Мне кажется, у меня упал iq ещё сильнее и я перестал уметь пользоваться гуглом.
Ну и, на самом деле, под виндой во всех этих заморочках с qemu не особо есть смысл, потому что тут, оказывается, есть hyper-v manager - что-то похожее на virt-manager из линукса, и в нём также есть какая-то своя встроенная реализация UEFI.
Идею для видео украл откуда-то (гифку увидел в интернете), круги, расположенные по сетке, на точках пересечения цвет меняется на противоположный, радиус меняют по синусоиде со сдвигом в зависимости от расстояния от центра. Каждый раз не могу понять, правильно ли я сделал закольцовывание или нет.
Через сохранение в файлы не пробовал, там основная сложность, в каком формате сохранять файлы, ну, наверное, лучше всего в пнг, но ффмпег также понимает это https://netpbm.sourceforge.net/doc/ppm.html (никакого сжатия) и это https://qoiformat.org (какое-то сжатие, вроде несложно написать свой энкодер). Плюс в том, что промежуточные результаты рендера сохраняются на диск: в теории можно поставить на паузу и продолжить позже или сохранить видео в нескольких форматах без траты времени на то, чтобы перерендеривать кадры. Минус в том, что наверное, много место занимает, даже с учётом сжатия?
Я сам сделал через stdin, ффмпег запускается примерно такой командой:
> ffmpeg -y -f rawvideo -pix_fmt argb -s 1920x1080 -r 60 -i - -an out.mp4
И просто в него скармливаешь подряд байты в формате, какой указал в -pix_fmt, в конце закрываешь stdin и ждёшь завершения работы процесса.
Под виндой это делается через то, чтобы создать пайп, один его конец (read) прицепить к дочернему процессу с ффмпегом при его создании, а во второй (write) писать из родительского, который потом в конце закрыть просто как обычный файл через CloseHandle. https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output
CreateProcess - какая-то странная функция, куча параметров и я не понимаю, что передавать в параметры application name и что в command line. Если в application name положить путь до экзешника ffmpeg, а в command line команду полностью, включая "ffmpeg" в начале, то работает. Другие комбинации по типу "NULL в application name, полностью команду в command line" или "путь до ффмпега в application name, пропустить ffmpeg в command line" либо работают как-то странно, либо падают с ошибкой.
Под линуксом, вроде я слышал, это делается через fork+exec и что-то ещё для пайпов, но я не пробовал, у меня сейчас нет линукса и не очень хочется.
С линуксом я недавно мучился, когда пытался установить его на qemu виртуалку с UEFI, потому что я хотел попробовать установить так, чтобы оно грузилось без бутлодера (efistub). И я, во-первых, не сразу понял, что если ты редактируешь efivars, то недостаточно просто делать -bios OVMF.fd, нужно отдельно подключать драйв с кодом UEFI и драйв, где хранятся efivars
> -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd
А, во-вторых, начались проблемы с qemu под виндой, что ускоритель whpx не дружит с тем, чтобы вот так отдельно code и vars подключать. Обходится через то, чтобы один раз запуститься без whpx, отредактировать efivars, склеить vars и code в один файл и потом подключать его через -bios одновременно уже с whpx.
И я как-то очень поздно нагуглил ридми https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-qemu/msys2.readme.txt где решения всех этих проблем описываются прямым текстом.
UEFI биос, кстати, отсюда можно скачать https://retrage.github.io/edk2-nightly и я помню, что когда делал хелловорлд на уефи и тестил его в виртуалке, то я его сам собирал этот биос из-за того, что тупо не мог нагуглить, где скачать готовый билд. Мне кажется, у меня упал iq ещё сильнее и я перестал уметь пользоваться гуглом.
Ну и, на самом деле, под виндой во всех этих заморочках с qemu не особо есть смысл, потому что тут, оказывается, есть hyper-v manager - что-то похожее на virt-manager из линукса, и в нём также есть какая-то своя встроенная реализация UEFI.
Попробовал сегодня сделать преобразование флоатов в строки минимальной длины https://godbolt.org/z/efvoM1a8b
Изначально я хотел сделать алгоритм FPP из этой древней статьи https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf но я интуитивно не особо понимаю смысла алгоритмов оттуда и постоянно путаюсь в однобуквенных переменных. Ну, типа, я понимаю, что вроде как там сначала флоат представляется в виде рациональной дроби R / S. Потом процедура simple-fixup, видимо, определяет то, начиная с какого разряда в десятичном представлении мы начнём генерировать цифры (через умножение числителя / знаменателя на 10, пока не нормализуем дробь). Плюс там что-то делается, чтобы учесть потенциально неравные расстояния между текущим флоатом и следующим / предыдущим. После чего генерируем цифры для десятичного представления с каким-то непонятным условием выхода из цикла. Но это всё равно всё дико запутанно.
Ещё есть такая статья https://arxiv.org/pdf/1310.8121 с очень привлекательно коротким алгоритмом на джаве, но я его тоже не понял, к тому же проблема в том, что он требует реализации полноценного длинного деления одного многоциферного числа на другое многоциферное, а я слишком тупой для этого, я не понимаю, как в делении в столбик угадывать цифры из частного без того, чтобы итеративно вычитать делитель из куска делимого (что, наверное, не вариант, когда "цифры" - это 4-байтовые инты).
Что я имею в виду, вот, допустим, делим 3142 на 53, как понять, что первая цифра частного - это 5 без того, чтобы долго и нудно вычитать 314 - 53 - 53 - 53 - 53 - 53 = 49? Ну, короче, оказывается, что есть способ почти точно оценить значение следующей цифры из частного, про это у кнута есть (вторая книжка, глава 4.3.1, алгоритм D) и в хакерс делайт глава с реализацией на си, но я особо не разбирался.
В итоге я взял алгоритм из вступления к этой статье https://dl.acm.org/doi/pdf/10.1145/3192366.3192369 Там в начале описывается медленный алгоритм, как преобразовывать флоаты в строку, а потом показывается, как его можно ускорить, но я дальше не читал. Основная идея медленного алгоритма в том, что берём флоат, а также два числа, которые находятся посередине между входным флоатом и предыдущим и следующим флоатами. Преобразовываем все три числа в десятичную форму с максимальной точностью и отбрасываем у них десятичные цифры в мантиссах до тех пор, пока не выполнятся какие-то там магические условия выхода из цикла.
Перед преобразованием в десятичную форму смещаем бинарную экспоненту так, чтобы бинарная мантисса стала интом, дальше работаем только с интами. После, хотим в этом уравнении:
узнать dec_mantissa и dec_exp, при этом мы вольны выбирать любую десятичную экспоненту, какая нам была бы удобна, но чтобы dec_mantissa был интом.
Если бинарная экспонента положительная, то можно взять dec_exp = 0 и вычислить десятичную интовую мантиссу, перемножив bin_mantissa · 2^bin_exp.
Если бинарная экспонента отрицательная, то берём dec_exp = bin_exp, сокращаем 2^bin_exp с обеих сторон, переносим 5^bin_exp влево и получаем dec_mantissa = bin_mantissa · 5^(-bin_exp). Вот это умножение на степень 5 было и в том алгоритме на джаве выше, но я всё равно не понял тот алгоритм.
Алгоритм очень простой в реализации, я тупо переписал псевдокод в обычный код + сделал несколько несложных бигинтовых операций: умножение бигинтов, сравнение бигинтов, деление бигинта на u32, прибавление u32 к бигинту, вычитание u32 из бигинта, возведение 5 в большую степень. По итогу выполнения алгоритма получаешь десятичную интовую мантиссу и экспоненту к ней. Чтобы напечатать это в виде дроби, я написал 50 строк какой-то кринжовой хуеты, лишь бы как-то работало, по-любому там где-то есть ошибка. Не складываются слова в предложения, потому что я нахуй хочу умереть
Изначально я хотел сделать алгоритм FPP из этой древней статьи https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf но я интуитивно не особо понимаю смысла алгоритмов оттуда и постоянно путаюсь в однобуквенных переменных. Ну, типа, я понимаю, что вроде как там сначала флоат представляется в виде рациональной дроби R / S. Потом процедура simple-fixup, видимо, определяет то, начиная с какого разряда в десятичном представлении мы начнём генерировать цифры (через умножение числителя / знаменателя на 10, пока не нормализуем дробь). Плюс там что-то делается, чтобы учесть потенциально неравные расстояния между текущим флоатом и следующим / предыдущим. После чего генерируем цифры для десятичного представления с каким-то непонятным условием выхода из цикла. Но это всё равно всё дико запутанно.
Ещё есть такая статья https://arxiv.org/pdf/1310.8121 с очень привлекательно коротким алгоритмом на джаве, но я его тоже не понял, к тому же проблема в том, что он требует реализации полноценного длинного деления одного многоциферного числа на другое многоциферное, а я слишком тупой для этого, я не понимаю, как в делении в столбик угадывать цифры из частного без того, чтобы итеративно вычитать делитель из куска делимого (что, наверное, не вариант, когда "цифры" - это 4-байтовые инты).
Что я имею в виду, вот, допустим, делим 3142 на 53, как понять, что первая цифра частного - это 5 без того, чтобы долго и нудно вычитать 314 - 53 - 53 - 53 - 53 - 53 = 49? Ну, короче, оказывается, что есть способ почти точно оценить значение следующей цифры из частного, про это у кнута есть (вторая книжка, глава 4.3.1, алгоритм D) и в хакерс делайт глава с реализацией на си, но я особо не разбирался.
В итоге я взял алгоритм из вступления к этой статье https://dl.acm.org/doi/pdf/10.1145/3192366.3192369 Там в начале описывается медленный алгоритм, как преобразовывать флоаты в строку, а потом показывается, как его можно ускорить, но я дальше не читал. Основная идея медленного алгоритма в том, что берём флоат, а также два числа, которые находятся посередине между входным флоатом и предыдущим и следующим флоатами. Преобразовываем все три числа в десятичную форму с максимальной точностью и отбрасываем у них десятичные цифры в мантиссах до тех пор, пока не выполнятся какие-то там магические условия выхода из цикла.
Перед преобразованием в десятичную форму смещаем бинарную экспоненту так, чтобы бинарная мантисса стала интом, дальше работаем только с интами. После, хотим в этом уравнении:
> bin_mantissa · 2^bin_exp = dec_mantissa · 10^dec_exp
узнать dec_mantissa и dec_exp, при этом мы вольны выбирать любую десятичную экспоненту, какая нам была бы удобна, но чтобы dec_mantissa был интом.
Если бинарная экспонента положительная, то можно взять dec_exp = 0 и вычислить десятичную интовую мантиссу, перемножив bin_mantissa · 2^bin_exp.
Если бинарная экспонента отрицательная, то берём dec_exp = bin_exp, сокращаем 2^bin_exp с обеих сторон, переносим 5^bin_exp влево и получаем dec_mantissa = bin_mantissa · 5^(-bin_exp). Вот это умножение на степень 5 было и в том алгоритме на джаве выше, но я всё равно не понял тот алгоритм.
Алгоритм очень простой в реализации, я тупо переписал псевдокод в обычный код + сделал несколько несложных бигинтовых операций: умножение бигинтов, сравнение бигинтов, деление бигинта на u32, прибавление u32 к бигинту, вычитание u32 из бигинта, возведение 5 в большую степень. По итогу выполнения алгоритма получаешь десятичную интовую мантиссу и экспоненту к ней. Чтобы напечатать это в виде дроби, я написал 50 строк какой-то кринжовой хуеты, лишь бы как-то работало, по-любому там где-то есть ошибка. Не складываются слова в предложения, потому что я нахуй хочу умереть
Попробовал сегодня сделать преобразование флоатов в строки минимальной длины https://godbolt.org/z/efvoM1a8b
Изначально я хотел сделать алгоритм FPP из этой древней статьи https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf но я интуитивно не особо понимаю смысла алгоритмов оттуда и постоянно путаюсь в однобуквенных переменных. Ну, типа, я понимаю, что вроде как там сначала флоат представляется в виде рациональной дроби R / S. Потом процедура simple-fixup, видимо, определяет то, начиная с какого разряда в десятичном представлении мы начнём генерировать цифры (через умножение числителя / знаменателя на 10, пока не нормализуем дробь). Плюс там что-то делается, чтобы учесть потенциально неравные расстояния между текущим флоатом и следующим / предыдущим. После чего генерируем цифры для десятичного представления с каким-то непонятным условием выхода из цикла. Но это всё равно всё дико запутанно.
Ещё есть такая статья https://arxiv.org/pdf/1310.8121 с очень привлекательно коротким алгоритмом на джаве, но я его тоже не понял, к тому же проблема в том, что он требует реализации полноценного длинного деления одного многоциферного числа на другое многоциферное, а я слишком тупой для этого, я не понимаю, как в делении в столбик угадывать цифры из частного без того, чтобы итеративно вычитать делитель из куска делимого (что, наверное, не вариант, когда "цифры" - это 4-байтовые инты).
Что я имею в виду, вот, допустим, делим 3142 на 53, как понять, что первая цифра частного - это 5 без того, чтобы долго и нудно вычитать 314 - 53 - 53 - 53 - 53 - 53 = 49? Ну, короче, оказывается, что есть способ почти точно оценить значение следующей цифры из частного, про это у кнута есть (вторая книжка, глава 4.3.1, алгоритм D) и в хакерс делайт глава с реализацией на си, но я особо не разбирался.
В итоге я взял алгоритм из вступления к этой статье https://dl.acm.org/doi/pdf/10.1145/3192366.3192369 Там в начале описывается медленный алгоритм, как преобразовывать флоаты в строку, а потом показывается, как его можно ускорить, но я дальше не читал. Основная идея медленного алгоритма в том, что берём флоат, а также два числа, которые находятся посередине между входным флоатом и предыдущим и следующим флоатами. Преобразовываем все три числа в десятичную форму с максимальной точностью и отбрасываем у них десятичные цифры в мантиссах до тех пор, пока не выполнятся какие-то там магические условия выхода из цикла.
Перед преобразованием в десятичную форму смещаем бинарную экспоненту так, чтобы бинарная мантисса стала интом, дальше работаем только с интами. После, хотим в этом уравнении:
узнать dec_mantissa и dec_exp, при этом мы вольны выбирать любую десятичную экспоненту, какая нам была бы удобна, но чтобы dec_mantissa был интом.
Если бинарная экспонента положительная, то можно взять dec_exp = 0 и вычислить десятичную интовую мантиссу, перемножив bin_mantissa · 2^bin_exp.
Если бинарная экспонента отрицательная, то берём dec_exp = bin_exp, сокращаем 2^bin_exp с обеих сторон, переносим 5^bin_exp влево и получаем dec_mantissa = bin_mantissa · 5^(-bin_exp). Вот это умножение на степень 5 было и в том алгоритме на джаве выше, но я всё равно не понял тот алгоритм.
Алгоритм очень простой в реализации, я тупо переписал псевдокод в обычный код + сделал несколько несложных бигинтовых операций: умножение бигинтов, сравнение бигинтов, деление бигинта на u32, прибавление u32 к бигинту, вычитание u32 из бигинта, возведение 5 в большую степень. По итогу выполнения алгоритма получаешь десятичную интовую мантиссу и экспоненту к ней. Чтобы напечатать это в виде дроби, я написал 50 строк какой-то кринжовой хуеты, лишь бы как-то работало, по-любому там где-то есть ошибка. Не складываются слова в предложения, потому что я нахуй хочу умереть
Изначально я хотел сделать алгоритм FPP из этой древней статьи https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf но я интуитивно не особо понимаю смысла алгоритмов оттуда и постоянно путаюсь в однобуквенных переменных. Ну, типа, я понимаю, что вроде как там сначала флоат представляется в виде рациональной дроби R / S. Потом процедура simple-fixup, видимо, определяет то, начиная с какого разряда в десятичном представлении мы начнём генерировать цифры (через умножение числителя / знаменателя на 10, пока не нормализуем дробь). Плюс там что-то делается, чтобы учесть потенциально неравные расстояния между текущим флоатом и следующим / предыдущим. После чего генерируем цифры для десятичного представления с каким-то непонятным условием выхода из цикла. Но это всё равно всё дико запутанно.
Ещё есть такая статья https://arxiv.org/pdf/1310.8121 с очень привлекательно коротким алгоритмом на джаве, но я его тоже не понял, к тому же проблема в том, что он требует реализации полноценного длинного деления одного многоциферного числа на другое многоциферное, а я слишком тупой для этого, я не понимаю, как в делении в столбик угадывать цифры из частного без того, чтобы итеративно вычитать делитель из куска делимого (что, наверное, не вариант, когда "цифры" - это 4-байтовые инты).
Что я имею в виду, вот, допустим, делим 3142 на 53, как понять, что первая цифра частного - это 5 без того, чтобы долго и нудно вычитать 314 - 53 - 53 - 53 - 53 - 53 = 49? Ну, короче, оказывается, что есть способ почти точно оценить значение следующей цифры из частного, про это у кнута есть (вторая книжка, глава 4.3.1, алгоритм D) и в хакерс делайт глава с реализацией на си, но я особо не разбирался.
В итоге я взял алгоритм из вступления к этой статье https://dl.acm.org/doi/pdf/10.1145/3192366.3192369 Там в начале описывается медленный алгоритм, как преобразовывать флоаты в строку, а потом показывается, как его можно ускорить, но я дальше не читал. Основная идея медленного алгоритма в том, что берём флоат, а также два числа, которые находятся посередине между входным флоатом и предыдущим и следующим флоатами. Преобразовываем все три числа в десятичную форму с максимальной точностью и отбрасываем у них десятичные цифры в мантиссах до тех пор, пока не выполнятся какие-то там магические условия выхода из цикла.
Перед преобразованием в десятичную форму смещаем бинарную экспоненту так, чтобы бинарная мантисса стала интом, дальше работаем только с интами. После, хотим в этом уравнении:
> bin_mantissa · 2^bin_exp = dec_mantissa · 10^dec_exp
узнать dec_mantissa и dec_exp, при этом мы вольны выбирать любую десятичную экспоненту, какая нам была бы удобна, но чтобы dec_mantissa был интом.
Если бинарная экспонента положительная, то можно взять dec_exp = 0 и вычислить десятичную интовую мантиссу, перемножив bin_mantissa · 2^bin_exp.
Если бинарная экспонента отрицательная, то берём dec_exp = bin_exp, сокращаем 2^bin_exp с обеих сторон, переносим 5^bin_exp влево и получаем dec_mantissa = bin_mantissa · 5^(-bin_exp). Вот это умножение на степень 5 было и в том алгоритме на джаве выше, но я всё равно не понял тот алгоритм.
Алгоритм очень простой в реализации, я тупо переписал псевдокод в обычный код + сделал несколько несложных бигинтовых операций: умножение бигинтов, сравнение бигинтов, деление бигинта на u32, прибавление u32 к бигинту, вычитание u32 из бигинта, возведение 5 в большую степень. По итогу выполнения алгоритма получаешь десятичную интовую мантиссу и экспоненту к ней. Чтобы напечатать это в виде дроби, я написал 50 строк какой-то кринжовой хуеты, лишь бы как-то работало, по-любому там где-то есть ошибка. Не складываются слова в предложения, потому что я нахуй хочу умереть
>>713297
Твой конфиг для Neovim выглядит неплохо. Плагины, которые ты используешь, действительно полезны. Однако, если ты чувствуешь, что твой конфиг слишком сложный, ты можешь попробовать использовать более минималистичный подход. Это может помочь тебе сосредоточиться на написании кода, а не на настройке редактора
Твой конфиг для Neovim выглядит неплохо. Плагины, которые ты используешь, действительно полезны. Однако, если ты чувствуешь, что твой конфиг слишком сложный, ты можешь попробовать использовать более минималистичный подход. Это может помочь тебе сосредоточиться на написании кода, а не на настройке редактора
413 Кб, 1080x1350Я хотел типа выделить память так, чтобы адрес был выровнен на N мегабайт, потому что это в теории может быть удобно, чтобы по указателю на что-то внутри куска памяти можно было восстановить указатель на начало, просто занулив младшие биты
https://godbolt.org/z/fTa4W15cM
Там два способа, один через какой-то VirtualAlloc2, который в 10 винде появился, и там в него просто можно параметром выравнивание передать. Другой - зарезервировать достаточно большой кусок памяти, чтобы в нём точно нашёлся выровненный адрес, и коммитнуть кусочек памяти по выровненному адресу. В худшем случае резервируются 2N мегабайтов и коммитится N. Как я понял, через VirtualFree нельзя частично освободить зарезервированный интервал адресов (в документации прямо написано), частично можно только декоммитнуть память. Что интересно, оба способа зачастую один и тот же адрес возвращают, если их последовательно запустить.
Ещё есть третий шизоидный вариант - перебирать выровненные адреса, подсовывая их как параметр в VirtualAlloc, пока не найдётся доступный, но, как будто это совсем бред.
Заметил, что даже если коммитишь много памяти, но на деле используешь её только частично, то как будто таск менеджер пишет, что процесс использует только ту память, которую ты реально потрогал, а не столько, сколько закоммитил. И что можно вообще коммитить больше памяти, чем у тебя есть физически. И показалось, что может быть, нет смысла резервировать и коммитить отдельно, но всё же нет https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-virtual-memory#committed-memory и суммарно закоммиченная память там в отдельной вкладке отображается.
Оно следит за тем, чтобы в теории была возможность одновременно всю коммитнутую память где-то держать: будь то в оперативке или в файле подкачки, поэтому есть предел, даже если ты эту память никак не используешь. И ещё по мере приближения к этому пределу VirtualAlloc работает всё медленнее и медленнее, пока не сдыхает, у меня - ближе к 128 гигабайтам закоммиченной памяти (ну вот, видимо, 32Гб физической + какой-то там большой файл подкачки).
А если в цикле кусками резервировать адреса, то те же 128 гигабайтов гораздо быстрее резервируются и полностью, и вроде всё в порядке. Виртуальные адреса тоже вроде не совсем бесконечные https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces написано, что доступны только адреса от 0 до 128 терабайтов.
Не особо понятно, что под линуксом, там в mmap как будто нет разделения на reserve и commit. Вроде бы достаточно указать PROT_NONE (pages may not be accessed) в mmap и потом сделать mprotect для нужного диапазона адресов. И у munmap как будто нет ограничения, что мол нужно передавать туда только то, что mmap вернул, поэтому, видимо, можно даже виртуальные адреса ненужные обратно отдать? Я не проверял ничего из этого
https://godbolt.org/z/fTa4W15cM
Там два способа, один через какой-то VirtualAlloc2, который в 10 винде появился, и там в него просто можно параметром выравнивание передать. Другой - зарезервировать достаточно большой кусок памяти, чтобы в нём точно нашёлся выровненный адрес, и коммитнуть кусочек памяти по выровненному адресу. В худшем случае резервируются 2N мегабайтов и коммитится N. Как я понял, через VirtualFree нельзя частично освободить зарезервированный интервал адресов (в документации прямо написано), частично можно только декоммитнуть память. Что интересно, оба способа зачастую один и тот же адрес возвращают, если их последовательно запустить.
Ещё есть третий шизоидный вариант - перебирать выровненные адреса, подсовывая их как параметр в VirtualAlloc, пока не найдётся доступный, но, как будто это совсем бред.
Заметил, что даже если коммитишь много памяти, но на деле используешь её только частично, то как будто таск менеджер пишет, что процесс использует только ту память, которую ты реально потрогал, а не столько, сколько закоммитил. И что можно вообще коммитить больше памяти, чем у тебя есть физически. И показалось, что может быть, нет смысла резервировать и коммитить отдельно, но всё же нет https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-virtual-memory#committed-memory и суммарно закоммиченная память там в отдельной вкладке отображается.
Оно следит за тем, чтобы в теории была возможность одновременно всю коммитнутую память где-то держать: будь то в оперативке или в файле подкачки, поэтому есть предел, даже если ты эту память никак не используешь. И ещё по мере приближения к этому пределу VirtualAlloc работает всё медленнее и медленнее, пока не сдыхает, у меня - ближе к 128 гигабайтам закоммиченной памяти (ну вот, видимо, 32Гб физической + какой-то там большой файл подкачки).
А если в цикле кусками резервировать адреса, то те же 128 гигабайтов гораздо быстрее резервируются и полностью, и вроде всё в порядке. Виртуальные адреса тоже вроде не совсем бесконечные https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces написано, что доступны только адреса от 0 до 128 терабайтов.
Не особо понятно, что под линуксом, там в mmap как будто нет разделения на reserve и commit. Вроде бы достаточно указать PROT_NONE (pages may not be accessed) в mmap и потом сделать mprotect для нужного диапазона адресов. И у munmap как будто нет ограничения, что мол нужно передавать туда только то, что mmap вернул, поэтому, видимо, можно даже виртуальные адреса ненужные обратно отдать? Я не проверял ничего из этого
413 Кб, 1080x1350Я хотел типа выделить память так, чтобы адрес был выровнен на N мегабайт, потому что это в теории может быть удобно, чтобы по указателю на что-то внутри куска памяти можно было восстановить указатель на начало, просто занулив младшие биты
https://godbolt.org/z/fTa4W15cM
Там два способа, один через какой-то VirtualAlloc2, который в 10 винде появился, и там в него просто можно параметром выравнивание передать. Другой - зарезервировать достаточно большой кусок памяти, чтобы в нём точно нашёлся выровненный адрес, и коммитнуть кусочек памяти по выровненному адресу. В худшем случае резервируются 2N мегабайтов и коммитится N. Как я понял, через VirtualFree нельзя частично освободить зарезервированный интервал адресов (в документации прямо написано), частично можно только декоммитнуть память. Что интересно, оба способа зачастую один и тот же адрес возвращают, если их последовательно запустить.
Ещё есть третий шизоидный вариант - перебирать выровненные адреса, подсовывая их как параметр в VirtualAlloc, пока не найдётся доступный, но, как будто это совсем бред.
Заметил, что даже если коммитишь много памяти, но на деле используешь её только частично, то как будто таск менеджер пишет, что процесс использует только ту память, которую ты реально потрогал, а не столько, сколько закоммитил. И что можно вообще коммитить больше памяти, чем у тебя есть физически. И показалось, что может быть, нет смысла резервировать и коммитить отдельно, но всё же нет https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-virtual-memory#committed-memory и суммарно закоммиченная память там в отдельной вкладке отображается.
Оно следит за тем, чтобы в теории была возможность одновременно всю коммитнутую память где-то держать: будь то в оперативке или в файле подкачки, поэтому есть предел, даже если ты эту память никак не используешь. И ещё по мере приближения к этому пределу VirtualAlloc работает всё медленнее и медленнее, пока не сдыхает, у меня - ближе к 128 гигабайтам закоммиченной памяти (ну вот, видимо, 32Гб физической + какой-то там большой файл подкачки).
А если в цикле кусками резервировать адреса, то те же 128 гигабайтов гораздо быстрее резервируются и полностью, и вроде всё в порядке. Виртуальные адреса тоже вроде не совсем бесконечные https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces написано, что доступны только адреса от 0 до 128 терабайтов.
Не особо понятно, что под линуксом, там в mmap как будто нет разделения на reserve и commit. Вроде бы достаточно указать PROT_NONE (pages may not be accessed) в mmap и потом сделать mprotect для нужного диапазона адресов. И у munmap как будто нет ограничения, что мол нужно передавать туда только то, что mmap вернул, поэтому, видимо, можно даже виртуальные адреса ненужные обратно отдать? Я не проверял ничего из этого
https://godbolt.org/z/fTa4W15cM
Там два способа, один через какой-то VirtualAlloc2, который в 10 винде появился, и там в него просто можно параметром выравнивание передать. Другой - зарезервировать достаточно большой кусок памяти, чтобы в нём точно нашёлся выровненный адрес, и коммитнуть кусочек памяти по выровненному адресу. В худшем случае резервируются 2N мегабайтов и коммитится N. Как я понял, через VirtualFree нельзя частично освободить зарезервированный интервал адресов (в документации прямо написано), частично можно только декоммитнуть память. Что интересно, оба способа зачастую один и тот же адрес возвращают, если их последовательно запустить.
Ещё есть третий шизоидный вариант - перебирать выровненные адреса, подсовывая их как параметр в VirtualAlloc, пока не найдётся доступный, но, как будто это совсем бред.
Заметил, что даже если коммитишь много памяти, но на деле используешь её только частично, то как будто таск менеджер пишет, что процесс использует только ту память, которую ты реально потрогал, а не столько, сколько закоммитил. И что можно вообще коммитить больше памяти, чем у тебя есть физически. И показалось, что может быть, нет смысла резервировать и коммитить отдельно, но всё же нет https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-virtual-memory#committed-memory и суммарно закоммиченная память там в отдельной вкладке отображается.
Оно следит за тем, чтобы в теории была возможность одновременно всю коммитнутую память где-то держать: будь то в оперативке или в файле подкачки, поэтому есть предел, даже если ты эту память никак не используешь. И ещё по мере приближения к этому пределу VirtualAlloc работает всё медленнее и медленнее, пока не сдыхает, у меня - ближе к 128 гигабайтам закоммиченной памяти (ну вот, видимо, 32Гб физической + какой-то там большой файл подкачки).
А если в цикле кусками резервировать адреса, то те же 128 гигабайтов гораздо быстрее резервируются и полностью, и вроде всё в порядке. Виртуальные адреса тоже вроде не совсем бесконечные https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces написано, что доступны только адреса от 0 до 128 терабайтов.
Не особо понятно, что под линуксом, там в mmap как будто нет разделения на reserve и commit. Вроде бы достаточно указать PROT_NONE (pages may not be accessed) в mmap и потом сделать mprotect для нужного диапазона адресов. И у munmap как будто нет ограничения, что мол нужно передавать туда только то, что mmap вернул, поэтому, видимо, можно даже виртуальные адреса ненужные обратно отдать? Я не проверял ничего из этого
>>754243
Можно перебирать диапазоны адресов функцией VirtualQuery. Красиво? Красиво??? :3
Ещё для сценариев, похожих на твой вариант 2, есть плейсхолдеры (https://devblogs.microsoft.com/oldnewthing/20240201-00/?p=109346), но они, видимо, поддерживаются (только) той же этой твоей VirtualAlloc2, что и прямое задание выравнивания. Выделяешь один плейсхолдер, делишь его на два в нужном месте, одну часть материализуешь, другую освобождаешь.
В принципе, можно то же самое делать без плейсхолдеров, просто в таком же цикле на случай гонки, что в статье. То есть, чтобы выделить кусок памяти, выровненный на 1 Мб, делаешь
Честно говоря, с учётом всегда существовавшей возможности сделать вот так и доли случаев, когда это нужно, все эти явные плейсхолдеры и выравнивания выглядят решениями никогда ни у кого не стоявших проблем. Аллокации и так всегда выровнены МИНИМУМ на 64 Кб, НУ КУДА ЕЩЁ БОЛЬШЕ. Опуская городские легенды про волшебные менеджеры памяти, использующие это вместо заголовков (идея на первый взгляд понятна, но чем больше об этом думаю, тем больше вопросов...), худшее, про что я слышал — это выравнивание буферов для асинхронного I/O (https://learn.microsoft.com/en-us/windows/win32/fileio/file-buffering) на размер физического сектора диска (https://en.wikipedia.org/wiki/Disk_sector), но, э-э, см. числа.
>перебирать выровненные адреса
Можно перебирать диапазоны адресов функцией VirtualQuery. Красиво? Красиво??? :3
Ещё для сценариев, похожих на твой вариант 2, есть плейсхолдеры (https://devblogs.microsoft.com/oldnewthing/20240201-00/?p=109346), но они, видимо, поддерживаются (только) той же этой твоей VirtualAlloc2, что и прямое задание выравнивания. Выделяешь один плейсхолдер, делишь его на два в нужном месте, одну часть материализуешь, другую освобождаешь.
В принципе, можно то же самое делать без плейсхолдеров, просто в таком же цикле на случай гонки, что в статье. То есть, чтобы выделить кусок памяти, выровненный на 1 Мб, делаешь
>do {
>— p = VirtualAlloc(null, 2 Мб, ...)
>— if (!p) throw;
>— p_aligned = (p + 1 Мб − 1) & −1 Мб
>— VirtualFree(p)
>— p = VirtualAlloc(p_aligned, 1 Мб, ...)
>} while (!p)
Честно говоря, с учётом всегда существовавшей возможности сделать вот так и доли случаев, когда это нужно, все эти явные плейсхолдеры и выравнивания выглядят решениями никогда ни у кого не стоявших проблем. Аллокации и так всегда выровнены МИНИМУМ на 64 Кб, НУ КУДА ЕЩЁ БОЛЬШЕ. Опуская городские легенды про волшебные менеджеры памяти, использующие это вместо заголовков (идея на первый взгляд понятна, но чем больше об этом думаю, тем больше вопросов...), худшее, про что я слышал — это выравнивание буферов для асинхронного I/O (https://learn.microsoft.com/en-us/windows/win32/fileio/file-buffering) на размер физического сектора диска (https://en.wikipedia.org/wiki/Disk_sector), но, э-э, см. числа.
Запретный сковородочный маслянистый полусырой хлеб
У меня в голове крутится шизоидная идея проги, которая берёт репозиторий с кодом и конвертирует его в картинку, на которой содержимое всех файлов выводится текстом с мелким пиксельным шрифтом, текст каждого файла пишется внутри отдельного прямоугольника вместе с названием файла и, возможно, другими метаданными. Может быть, даже конвертирует в гифку и в прямоугольниках с текстами файлов содержимое скроллится, а не сразу целиком выводится, чтобы удобнее было читать и потому что просмоторщикам картинок может стать плохо от картинок большого размера (в ширину и высоту). А также нужно, чтобы была возможность в обратную сторону прокрутить - из такой картинки воссоздать всю структуру папок и файлов и их содержимое. Короче, такой формат для архивирования репозитория в один файл, но при этом визуально читаемый.
Также можно добавить возможность делать патчи и точно так же их запаковывать в картинки, чтобы можно было запостить, например, на имиджборду, картинку с начальным состоянием репозитория, а потом самому себе реплаить по цепочке картинками-патчами с изменениями. Не знаю, как быть с мердж реквестами. Отдельную ветку в чужом картиночном репозитории создать легко, просто начинаешь сам реплаить по цепочке на какой-нибудь пост оригинального автора, но как потом объединить две параллельные цепочки: свою и авторскую - непонятно. Самый простой вариант, наверное, это чтобы автор для слияния вместо очередного патча запостил бы полноценный снапшот репозитория, в котором аккумулированы все авторские патчи и все патчи из мердж реквестовой ветки с вручную разрешёнными возможными конфликтами. Либо другой вариант, автор может вручную перепостить все твои картинки себе в цепочку, типа такой ребейз, не надо постить полноценный снапшот репозитория целиком, но это как-то муторно
У меня в голове крутится шизоидная идея проги, которая берёт репозиторий с кодом и конвертирует его в картинку, на которой содержимое всех файлов выводится текстом с мелким пиксельным шрифтом, текст каждого файла пишется внутри отдельного прямоугольника вместе с названием файла и, возможно, другими метаданными. Может быть, даже конвертирует в гифку и в прямоугольниках с текстами файлов содержимое скроллится, а не сразу целиком выводится, чтобы удобнее было читать и потому что просмоторщикам картинок может стать плохо от картинок большого размера (в ширину и высоту). А также нужно, чтобы была возможность в обратную сторону прокрутить - из такой картинки воссоздать всю структуру папок и файлов и их содержимое. Короче, такой формат для архивирования репозитория в один файл, но при этом визуально читаемый.
Также можно добавить возможность делать патчи и точно так же их запаковывать в картинки, чтобы можно было запостить, например, на имиджборду, картинку с начальным состоянием репозитория, а потом самому себе реплаить по цепочке картинками-патчами с изменениями. Не знаю, как быть с мердж реквестами. Отдельную ветку в чужом картиночном репозитории создать легко, просто начинаешь сам реплаить по цепочке на какой-нибудь пост оригинального автора, но как потом объединить две параллельные цепочки: свою и авторскую - непонятно. Самый простой вариант, наверное, это чтобы автор для слияния вместо очередного патча запостил бы полноценный снапшот репозитория, в котором аккумулированы все авторские патчи и все патчи из мердж реквестовой ветки с вручную разрешёнными возможными конфликтами. Либо другой вариант, автор может вручную перепостить все твои картинки себе в цепочку, типа такой ребейз, не надо постить полноценный снапшот репозитория целиком, но это как-то муторно
228 Кб, 1075x1442Нашёл такой сайт с объяснением, как читать сишные объявления http://unixwiz.net/techtips/reading-cdecl.html. Я до сих пор очень плохо понимал, как это делать, если честно.
Возьмём объявление переменной, идея в том, что у неё есть один "базовый" тип и к нему по очереди, наслаиваясь друг на друга, применяются типа "операторы", которые модифицируют его. Конкретно это:
- оператор "указатель на ..." (записывается звёздочкой)
- оператор "массив из ..." (записывается парой квадратных скобок с размерностью внутри)
- оператор "функция, возвращающая ..." (записывается парой круглых скобок со списком параметров внутри)
Если бы в си был нормальный синтаксис, то объявление переменной типа "массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char" могло бы выглядеть как-то так:
Здесь "базовый" тип - это char и к нему по очереди применяются операторы-модификаторы через обёртывание в "ptr<...>", "array<N, ...>" или "fn() -> ...", а название переменной просто в сторонке стоит.
Можно пройтись от базового типа до финального, постепенно применяя к нему операторы. Изначально есть просто char, а на название переменной вообще всё равно, просто потом можно дописать в конец:
Указатель на char:
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char:
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char:
А как провести теперь параллель с сишным синтаксисом я даже не знаю, он просто не делает никакого смысла. Отличия такие:
- "базовый" тип стоит всегда слева в сторонке
- "операторы" выглядят так, как будто применяются к названию переменной, потому что стоят вокруг неё, хотя по логике они всё так же применяются к базовому типу
- но при этом операторы, которые находятся дальше от названия переменной, применяются первее, чем те, что ближе к ней
- и да, они стоят именно вокруг переменной, а не по порядку перед ней или после неё (то есть это и не префиксная форма записи, и не постфиксная): оператор "указатель на ..." всегда стоит слева, а остальные два - всегда справа, из-за чего возникает необходимость вводить приоритет для них (у "указателя на ..." он меньше), а также использовать скобки, чтобы при необходимости применить оператор с меньшим приоритетом в первую очередь
Можно попытаться пройтись точно так же, от базового типа к финальному производному, но уже в упоротом сишном синтаксисе. Изначально есть char, название переменной тоже придётся добавить, потому что наворачивать операторы мы будет именно вокруг него, причём, из-за дебильного обратного порядка на каждом шаге мы будем впихивать операторы прямо РЯДОМ с названием переменной:
Указатель на char:
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
На русском звучит просто как обычное объявление функции, но почему код так странно выглядит (кстати, он спокойно компилируется)? Эти лишние скобки можно убрать, потому что оператор "(int, int)" всё равно по приоритету применится первее звёздочки, и тогда получится привычное объявление функции:
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char. Здесь ставим звёдочку рядом с названием переменной и заключаем её в скобки, потому что у рядом стоящего "(int, int)" больше приоритет, но нам нужно, чтобы только что добавленная звёздочка применилась первее, потому что у нас наркоманский обратный порядок:
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char, тут снова скобки лишние, потому что у "[8]" более высокий приоритет, чем у звёдочки:
Это полный бред, но это походу вот реально то, как оно работает, даже можно напихать лишних скобок и оно будет компилироваться и означать ровно то же самое:
Независимо я какое-то время назад, ещё летом вроде, смотрел стрим одного чела и он случайно обнаружил, что названия функций можно оборачивать в бессмысленные скобки, я тогда не задумывался особо глубоко, зачем так и почему, просто можно и ладно, но, получается, это отсюда ноги растут.
В статье также расписан алгоритм, как читать такие объявления, ну, что от названия переменной ты идёшь сначала до упора направо, потом налево, раскрываешь скобки, когда больше не можешь продвинуться ни туда, ни туда. Одновременно с этим строишь предложение на естественном языке от начала и до конца, в прямом порядке. Это более-менее очевидный подход, который следует из того, что звёздочки пишутся слева и имеют меньший приоритет. Ещё видел алгоритм чтения по спирали вместо "иди направо, потом налево" https://c-faq.com/decl/spiral.anderson.html. Если честно, я уже слышал про эти алгоритмы, но тогда тупо не понял их, из-за того, что не видел никакой логики в сишных объявлениях.
Но если реализовывать парсинг этих объявлений программно, то, как мне кажется, проще было бы идти не изнутри наружу, а наоборот, снаружи вовнутрь, постепенно отбрасывая внешние слои, но тогда звёздочки бы имели наоборот больший приоритет в порядке раскрывания:
...
... char
... указатель на char
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
... указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char
... массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
variable - это массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
К тому же этот способ не страдает от того, что при парсинге такого "int ∗(∗)())()" способом из статьи, непонятно, откуда изнутри начать разворачивать этот абстрактный декларатор (в статье пишет, что они встречаются в двух местах: в кастах и внутри sizeof, но так-то ещё в форвард-объявлениях функций, там же можно опустить названия параметров).
Можно типа сказать, что синтаксис с треугольными скобками ещё хуже и вообще он уродливый, ну ладно, но почему бы просто было не сделать так, например:
Здесь не нужны дополнительные скобки, потому что все операторы пишутся с одной стороны от названия переменной. Если посмотреть на конец объявления, то сразу понятно, ЧТО ЭТО ВООБЩЕ, в отличие от сишного синтаксиса, например, тут сразу видно, что это массив из восьми каких-то элементов. Чтобы понять, из каких, просто читаешь операторы справа-налево. Да, оно тоже выглядит уродливо, очень непривычно, возможно, на практике там вылезает миллион проблем в духе https://en.wikipedia.org/wiki/Most_vexing_parse, но, блин, а нахуй я живу, блять, кстати. Я думал сделать парсер сишных хедеров, начал писать токенизатор, а потом почти сразу забил, потому что, а зачем он мне нужен. Кстати, в шланге вроде бы есть опция, чтобы он выплюнул AST входного файла, больше имело бы смысл брать это готовое и делать что-то с ним.
А тайпдефы это, кстати, просто объявления переменных, к которым дописали слева typedef, и тогда название переменной становится названием алиаса для типа, который был типом переменной.
Ещё из странных вещей, я случайно обнаружил, что строковые и символьные литералы поддерживают восьмеричные коды для записи байтов, а синтаксис у них - "обратный слеш + от 1 до 3 цифр". Ну, то есть, например, 'J' == '\112' == 74. И, получается, в нуль-терминаторе '\0' - это не какой-то отдельный эскейп для нуля, как я думал, а восьмеричный код. Ну, понятно, что это не играет роли для нуля, но просто забавно
Возьмём объявление переменной, идея в том, что у неё есть один "базовый" тип и к нему по очереди, наслаиваясь друг на друга, применяются типа "операторы", которые модифицируют его. Конкретно это:
- оператор "указатель на ..." (записывается звёздочкой)
- оператор "массив из ..." (записывается парой квадратных скобок с размерностью внутри)
- оператор "функция, возвращающая ..." (записывается парой круглых скобок со списком параметров внутри)
Если бы в си был нормальный синтаксис, то объявление переменной типа "массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char" могло бы выглядеть как-то так:
> array<8, ptr<fn(int, int) -> ptr<char>>> variable;
Здесь "базовый" тип - это char и к нему по очереди применяются операторы-модификаторы через обёртывание в "ptr<...>", "array<N, ...>" или "fn() -> ...", а название переменной просто в сторонке стоит.
Можно пройтись от базового типа до финального, постепенно применяя к нему операторы. Изначально есть просто char, а на название переменной вообще всё равно, просто потом можно дописать в конец:
> char
Указатель на char:
> ptr<char>
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
> fn(int, int) -> ptr<char>
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char:
> ptr<fn(int, int) -> ptr<char>>
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char:
> array<8, ptr<fn(int, int) -> ptr<char>>>
А как провести теперь параллель с сишным синтаксисом я даже не знаю, он просто не делает никакого смысла. Отличия такие:
- "базовый" тип стоит всегда слева в сторонке
- "операторы" выглядят так, как будто применяются к названию переменной, потому что стоят вокруг неё, хотя по логике они всё так же применяются к базовому типу
- но при этом операторы, которые находятся дальше от названия переменной, применяются первее, чем те, что ближе к ней
- и да, они стоят именно вокруг переменной, а не по порядку перед ней или после неё (то есть это и не префиксная форма записи, и не постфиксная): оператор "указатель на ..." всегда стоит слева, а остальные два - всегда справа, из-за чего возникает необходимость вводить приоритет для них (у "указателя на ..." он меньше), а также использовать скобки, чтобы при необходимости применить оператор с меньшим приоритетом в первую очередь
Можно попытаться пройтись точно так же, от базового типа к финальному производному, но уже в упоротом сишном синтаксисе. Изначально есть char, название переменной тоже придётся добавить, потому что наворачивать операторы мы будет именно вокруг него, причём, из-за дебильного обратного порядка на каждом шаге мы будем впихивать операторы прямо РЯДОМ с названием переменной:
> char variable
Указатель на char:
> char ∗variable
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
> char ∗(variable(int, int))
На русском звучит просто как обычное объявление функции, но почему код так странно выглядит (кстати, он спокойно компилируется)? Эти лишние скобки можно убрать, потому что оператор "(int, int)" всё равно по приоритету применится первее звёздочки, и тогда получится привычное объявление функции:
> char ∗variable(int, int)
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char. Здесь ставим звёдочку рядом с названием переменной и заключаем её в скобки, потому что у рядом стоящего "(int, int)" больше приоритет, но нам нужно, чтобы только что добавленная звёздочка применилась первее, потому что у нас наркоманский обратный порядок:
> char ∗(∗variable)(int, int)
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char, тут снова скобки лишние, потому что у "[8]" более высокий приоритет, чем у звёдочки:
> char ∗(∗variable[8])(int, int)
Это полный бред, но это походу вот реально то, как оно работает, даже можно напихать лишних скобок и оно будет компилироваться и означать ровно то же самое:
> char (∗((∗((variable)[8]))(int, int)))
Независимо я какое-то время назад, ещё летом вроде, смотрел стрим одного чела и он случайно обнаружил, что названия функций можно оборачивать в бессмысленные скобки, я тогда не задумывался особо глубоко, зачем так и почему, просто можно и ладно, но, получается, это отсюда ноги растут.
В статье также расписан алгоритм, как читать такие объявления, ну, что от названия переменной ты идёшь сначала до упора направо, потом налево, раскрываешь скобки, когда больше не можешь продвинуться ни туда, ни туда. Одновременно с этим строишь предложение на естественном языке от начала и до конца, в прямом порядке. Это более-менее очевидный подход, который следует из того, что звёздочки пишутся слева и имеют меньший приоритет. Ещё видел алгоритм чтения по спирали вместо "иди направо, потом налево" https://c-faq.com/decl/spiral.anderson.html. Если честно, я уже слышал про эти алгоритмы, но тогда тупо не понял их, из-за того, что не видел никакой логики в сишных объявлениях.
Но если реализовывать парсинг этих объявлений программно, то, как мне кажется, проще было бы идти не изнутри наружу, а наоборот, снаружи вовнутрь, постепенно отбрасывая внешние слои, но тогда звёздочки бы имели наоборот больший приоритет в порядке раскрывания:
...
> char ∗(∗variable[8])(int, int)
... char
> ∗(∗variable[8])(int, int)
... указатель на char
> (∗variable[8])(int, int)
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
> (∗variable[8])
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
> ∗variable[8]
... указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char
> variable[8]
... массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
> variable
variable - это массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
>
К тому же этот способ не страдает от того, что при парсинге такого "int ∗(∗)())()" способом из статьи, непонятно, откуда изнутри начать разворачивать этот абстрактный декларатор (в статье пишет, что они встречаются в двух местах: в кастах и внутри sizeof, но так-то ещё в форвард-объявлениях функций, там же можно опустить названия параметров).
Можно типа сказать, что синтаксис с треугольными скобками ещё хуже и вообще он уродливый, ну ладно, но почему бы просто было не сделать так, например:
> char variable∗(int, int)∗[8]
Здесь не нужны дополнительные скобки, потому что все операторы пишутся с одной стороны от названия переменной. Если посмотреть на конец объявления, то сразу понятно, ЧТО ЭТО ВООБЩЕ, в отличие от сишного синтаксиса, например, тут сразу видно, что это массив из восьми каких-то элементов. Чтобы понять, из каких, просто читаешь операторы справа-налево. Да, оно тоже выглядит уродливо, очень непривычно, возможно, на практике там вылезает миллион проблем в духе https://en.wikipedia.org/wiki/Most_vexing_parse, но, блин, а нахуй я живу, блять, кстати. Я думал сделать парсер сишных хедеров, начал писать токенизатор, а потом почти сразу забил, потому что, а зачем он мне нужен. Кстати, в шланге вроде бы есть опция, чтобы он выплюнул AST входного файла, больше имело бы смысл брать это готовое и делать что-то с ним.
А тайпдефы это, кстати, просто объявления переменных, к которым дописали слева typedef, и тогда название переменной становится названием алиаса для типа, который был типом переменной.
Ещё из странных вещей, я случайно обнаружил, что строковые и символьные литералы поддерживают восьмеричные коды для записи байтов, а синтаксис у них - "обратный слеш + от 1 до 3 цифр". Ну, то есть, например, 'J' == '\112' == 74. И, получается, в нуль-терминаторе '\0' - это не какой-то отдельный эскейп для нуля, как я думал, а восьмеричный код. Ну, понятно, что это не играет роли для нуля, но просто забавно
228 Кб, 1075x1442Нашёл такой сайт с объяснением, как читать сишные объявления http://unixwiz.net/techtips/reading-cdecl.html. Я до сих пор очень плохо понимал, как это делать, если честно.
Возьмём объявление переменной, идея в том, что у неё есть один "базовый" тип и к нему по очереди, наслаиваясь друг на друга, применяются типа "операторы", которые модифицируют его. Конкретно это:
- оператор "указатель на ..." (записывается звёздочкой)
- оператор "массив из ..." (записывается парой квадратных скобок с размерностью внутри)
- оператор "функция, возвращающая ..." (записывается парой круглых скобок со списком параметров внутри)
Если бы в си был нормальный синтаксис, то объявление переменной типа "массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char" могло бы выглядеть как-то так:
Здесь "базовый" тип - это char и к нему по очереди применяются операторы-модификаторы через обёртывание в "ptr<...>", "array<N, ...>" или "fn() -> ...", а название переменной просто в сторонке стоит.
Можно пройтись от базового типа до финального, постепенно применяя к нему операторы. Изначально есть просто char, а на название переменной вообще всё равно, просто потом можно дописать в конец:
Указатель на char:
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char:
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char:
А как провести теперь параллель с сишным синтаксисом я даже не знаю, он просто не делает никакого смысла. Отличия такие:
- "базовый" тип стоит всегда слева в сторонке
- "операторы" выглядят так, как будто применяются к названию переменной, потому что стоят вокруг неё, хотя по логике они всё так же применяются к базовому типу
- но при этом операторы, которые находятся дальше от названия переменной, применяются первее, чем те, что ближе к ней
- и да, они стоят именно вокруг переменной, а не по порядку перед ней или после неё (то есть это и не префиксная форма записи, и не постфиксная): оператор "указатель на ..." всегда стоит слева, а остальные два - всегда справа, из-за чего возникает необходимость вводить приоритет для них (у "указателя на ..." он меньше), а также использовать скобки, чтобы при необходимости применить оператор с меньшим приоритетом в первую очередь
Можно попытаться пройтись точно так же, от базового типа к финальному производному, но уже в упоротом сишном синтаксисе. Изначально есть char, название переменной тоже придётся добавить, потому что наворачивать операторы мы будет именно вокруг него, причём, из-за дебильного обратного порядка на каждом шаге мы будем впихивать операторы прямо РЯДОМ с названием переменной:
Указатель на char:
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
На русском звучит просто как обычное объявление функции, но почему код так странно выглядит (кстати, он спокойно компилируется)? Эти лишние скобки можно убрать, потому что оператор "(int, int)" всё равно по приоритету применится первее звёздочки, и тогда получится привычное объявление функции:
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char. Здесь ставим звёдочку рядом с названием переменной и заключаем её в скобки, потому что у рядом стоящего "(int, int)" больше приоритет, но нам нужно, чтобы только что добавленная звёздочка применилась первее, потому что у нас наркоманский обратный порядок:
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char, тут снова скобки лишние, потому что у "[8]" более высокий приоритет, чем у звёдочки:
Это полный бред, но это походу вот реально то, как оно работает, даже можно напихать лишних скобок и оно будет компилироваться и означать ровно то же самое:
Независимо я какое-то время назад, ещё летом вроде, смотрел стрим одного чела и он случайно обнаружил, что названия функций можно оборачивать в бессмысленные скобки, я тогда не задумывался особо глубоко, зачем так и почему, просто можно и ладно, но, получается, это отсюда ноги растут.
В статье также расписан алгоритм, как читать такие объявления, ну, что от названия переменной ты идёшь сначала до упора направо, потом налево, раскрываешь скобки, когда больше не можешь продвинуться ни туда, ни туда. Одновременно с этим строишь предложение на естественном языке от начала и до конца, в прямом порядке. Это более-менее очевидный подход, который следует из того, что звёздочки пишутся слева и имеют меньший приоритет. Ещё видел алгоритм чтения по спирали вместо "иди направо, потом налево" https://c-faq.com/decl/spiral.anderson.html. Если честно, я уже слышал про эти алгоритмы, но тогда тупо не понял их, из-за того, что не видел никакой логики в сишных объявлениях.
Но если реализовывать парсинг этих объявлений программно, то, как мне кажется, проще было бы идти не изнутри наружу, а наоборот, снаружи вовнутрь, постепенно отбрасывая внешние слои, но тогда звёздочки бы имели наоборот больший приоритет в порядке раскрывания:
...
... char
... указатель на char
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
... указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char
... массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
variable - это массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
К тому же этот способ не страдает от того, что при парсинге такого "int ∗(∗)())()" способом из статьи, непонятно, откуда изнутри начать разворачивать этот абстрактный декларатор (в статье пишет, что они встречаются в двух местах: в кастах и внутри sizeof, но так-то ещё в форвард-объявлениях функций, там же можно опустить названия параметров).
Можно типа сказать, что синтаксис с треугольными скобками ещё хуже и вообще он уродливый, ну ладно, но почему бы просто было не сделать так, например:
Здесь не нужны дополнительные скобки, потому что все операторы пишутся с одной стороны от названия переменной. Если посмотреть на конец объявления, то сразу понятно, ЧТО ЭТО ВООБЩЕ, в отличие от сишного синтаксиса, например, тут сразу видно, что это массив из восьми каких-то элементов. Чтобы понять, из каких, просто читаешь операторы справа-налево. Да, оно тоже выглядит уродливо, очень непривычно, возможно, на практике там вылезает миллион проблем в духе https://en.wikipedia.org/wiki/Most_vexing_parse, но, блин, а нахуй я живу, блять, кстати. Я думал сделать парсер сишных хедеров, начал писать токенизатор, а потом почти сразу забил, потому что, а зачем он мне нужен. Кстати, в шланге вроде бы есть опция, чтобы он выплюнул AST входного файла, больше имело бы смысл брать это готовое и делать что-то с ним.
А тайпдефы это, кстати, просто объявления переменных, к которым дописали слева typedef, и тогда название переменной становится названием алиаса для типа, который был типом переменной.
Ещё из странных вещей, я случайно обнаружил, что строковые и символьные литералы поддерживают восьмеричные коды для записи байтов, а синтаксис у них - "обратный слеш + от 1 до 3 цифр". Ну, то есть, например, 'J' == '\112' == 74. И, получается, в нуль-терминаторе '\0' - это не какой-то отдельный эскейп для нуля, как я думал, а восьмеричный код. Ну, понятно, что это не играет роли для нуля, но просто забавно
Возьмём объявление переменной, идея в том, что у неё есть один "базовый" тип и к нему по очереди, наслаиваясь друг на друга, применяются типа "операторы", которые модифицируют его. Конкретно это:
- оператор "указатель на ..." (записывается звёздочкой)
- оператор "массив из ..." (записывается парой квадратных скобок с размерностью внутри)
- оператор "функция, возвращающая ..." (записывается парой круглых скобок со списком параметров внутри)
Если бы в си был нормальный синтаксис, то объявление переменной типа "массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char" могло бы выглядеть как-то так:
> array<8, ptr<fn(int, int) -> ptr<char>>> variable;
Здесь "базовый" тип - это char и к нему по очереди применяются операторы-модификаторы через обёртывание в "ptr<...>", "array<N, ...>" или "fn() -> ...", а название переменной просто в сторонке стоит.
Можно пройтись от базового типа до финального, постепенно применяя к нему операторы. Изначально есть просто char, а на название переменной вообще всё равно, просто потом можно дописать в конец:
> char
Указатель на char:
> ptr<char>
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
> fn(int, int) -> ptr<char>
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char:
> ptr<fn(int, int) -> ptr<char>>
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char:
> array<8, ptr<fn(int, int) -> ptr<char>>>
А как провести теперь параллель с сишным синтаксисом я даже не знаю, он просто не делает никакого смысла. Отличия такие:
- "базовый" тип стоит всегда слева в сторонке
- "операторы" выглядят так, как будто применяются к названию переменной, потому что стоят вокруг неё, хотя по логике они всё так же применяются к базовому типу
- но при этом операторы, которые находятся дальше от названия переменной, применяются первее, чем те, что ближе к ней
- и да, они стоят именно вокруг переменной, а не по порядку перед ней или после неё (то есть это и не префиксная форма записи, и не постфиксная): оператор "указатель на ..." всегда стоит слева, а остальные два - всегда справа, из-за чего возникает необходимость вводить приоритет для них (у "указателя на ..." он меньше), а также использовать скобки, чтобы при необходимости применить оператор с меньшим приоритетом в первую очередь
Можно попытаться пройтись точно так же, от базового типа к финальному производному, но уже в упоротом сишном синтаксисе. Изначально есть char, название переменной тоже придётся добавить, потому что наворачивать операторы мы будет именно вокруг него, причём, из-за дебильного обратного порядка на каждом шаге мы будем впихивать операторы прямо РЯДОМ с названием переменной:
> char variable
Указатель на char:
> char ∗variable
Функция, которая принимает два инта в качестве параметров и возвращает указатель на char:
> char ∗(variable(int, int))
На русском звучит просто как обычное объявление функции, но почему код так странно выглядит (кстати, он спокойно компилируется)? Эти лишние скобки можно убрать, потому что оператор "(int, int)" всё равно по приоритету применится первее звёздочки, и тогда получится привычное объявление функции:
> char ∗variable(int, int)
Указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char. Здесь ставим звёдочку рядом с названием переменной и заключаем её в скобки, потому что у рядом стоящего "(int, int)" больше приоритет, но нам нужно, чтобы только что добавленная звёздочка применилась первее, потому что у нас наркоманский обратный порядок:
> char ∗(∗variable)(int, int)
Массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char, тут снова скобки лишние, потому что у "[8]" более высокий приоритет, чем у звёдочки:
> char ∗(∗variable[8])(int, int)
Это полный бред, но это походу вот реально то, как оно работает, даже можно напихать лишних скобок и оно будет компилироваться и означать ровно то же самое:
> char (∗((∗((variable)[8]))(int, int)))
Независимо я какое-то время назад, ещё летом вроде, смотрел стрим одного чела и он случайно обнаружил, что названия функций можно оборачивать в бессмысленные скобки, я тогда не задумывался особо глубоко, зачем так и почему, просто можно и ладно, но, получается, это отсюда ноги растут.
В статье также расписан алгоритм, как читать такие объявления, ну, что от названия переменной ты идёшь сначала до упора направо, потом налево, раскрываешь скобки, когда больше не можешь продвинуться ни туда, ни туда. Одновременно с этим строишь предложение на естественном языке от начала и до конца, в прямом порядке. Это более-менее очевидный подход, который следует из того, что звёздочки пишутся слева и имеют меньший приоритет. Ещё видел алгоритм чтения по спирали вместо "иди направо, потом налево" https://c-faq.com/decl/spiral.anderson.html. Если честно, я уже слышал про эти алгоритмы, но тогда тупо не понял их, из-за того, что не видел никакой логики в сишных объявлениях.
Но если реализовывать парсинг этих объявлений программно, то, как мне кажется, проще было бы идти не изнутри наружу, а наоборот, снаружи вовнутрь, постепенно отбрасывая внешние слои, но тогда звёздочки бы имели наоборот больший приоритет в порядке раскрывания:
...
> char ∗(∗variable[8])(int, int)
... char
> ∗(∗variable[8])(int, int)
... указатель на char
> (∗variable[8])(int, int)
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
> (∗variable[8])
... функция, которая принимает два инта в качестве параметров и возвращает указатель на char
> ∗variable[8]
... указатель на функцию, которая принимает два инта в качестве параметров и возвращает указатель на char
> variable[8]
... массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
> variable
variable - это массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на char
>
К тому же этот способ не страдает от того, что при парсинге такого "int ∗(∗)())()" способом из статьи, непонятно, откуда изнутри начать разворачивать этот абстрактный декларатор (в статье пишет, что они встречаются в двух местах: в кастах и внутри sizeof, но так-то ещё в форвард-объявлениях функций, там же можно опустить названия параметров).
Можно типа сказать, что синтаксис с треугольными скобками ещё хуже и вообще он уродливый, ну ладно, но почему бы просто было не сделать так, например:
> char variable∗(int, int)∗[8]
Здесь не нужны дополнительные скобки, потому что все операторы пишутся с одной стороны от названия переменной. Если посмотреть на конец объявления, то сразу понятно, ЧТО ЭТО ВООБЩЕ, в отличие от сишного синтаксиса, например, тут сразу видно, что это массив из восьми каких-то элементов. Чтобы понять, из каких, просто читаешь операторы справа-налево. Да, оно тоже выглядит уродливо, очень непривычно, возможно, на практике там вылезает миллион проблем в духе https://en.wikipedia.org/wiki/Most_vexing_parse, но, блин, а нахуй я живу, блять, кстати. Я думал сделать парсер сишных хедеров, начал писать токенизатор, а потом почти сразу забил, потому что, а зачем он мне нужен. Кстати, в шланге вроде бы есть опция, чтобы он выплюнул AST входного файла, больше имело бы смысл брать это готовое и делать что-то с ним.
А тайпдефы это, кстати, просто объявления переменных, к которым дописали слева typedef, и тогда название переменной становится названием алиаса для типа, который был типом переменной.
Ещё из странных вещей, я случайно обнаружил, что строковые и символьные литералы поддерживают восьмеричные коды для записи байтов, а синтаксис у них - "обратный слеш + от 1 до 3 цифр". Ну, то есть, например, 'J' == '\112' == 74. И, получается, в нуль-терминаторе '\0' - это не какой-то отдельный эскейп для нуля, как я думал, а восьмеричный код. Ну, понятно, что это не играет роли для нуля, но просто забавно