Я вообще не знаю, чего я хочу, не понимаю.
Да что не так-то.
Откуда диаграмма с блоками?
Я забыл вычесть координаты точки до смещения.
Блендор.
Что зочнаил
Хуже нет
Мб на этомм писать а мб нет, не знаю он слишком располагает к тому чтобы писать шизу типа https://paste.ee/p/FIZkH И ансейф немного сложно, например я очень не сразу понял почему https://paste.ee/p/dpYPe эта прога на скрине крашится
Более лимение жсон парсер https://godbolt.org/z/6PWhTT8r6 на самом деле мне он не нужен, а нужен хмл парсер, просто я ничего никогда не парсил, поэтому попробовал сначала что-то попроще. Получилось ужасно если честно
Вообще в идеале твой парсер должен уметь работать, не имея всю строку в памяти, а читая куски по мере необходимости. Я себе сделал гибридный вариант:
— У парсера есть поля 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 полагаются больше никого не интересующими и разрешёнными для отбрасывания.
Я купил это и мне вообще всё равно, мне вообще всё равно
Ещё не очень понял, в чём конкретно проблема. То ли в том, что невозможно нормально реализовать автозакрытие кавычек, то ли в том, что невозможно реализовать нормальный редактор текста с фичами сложнее подстветки синтаксиса.
Я не знаю, у меня проблемы с мозгом. Ну точнее знаю. Что они есть.
Я не знаю, у меня проблемы с мозгом. Ну точнее знаю. Что они есть.
Я вообще не понимаю, неужели нет никакого нормального способа без макросов достать из дженерик параметра какие-то компайл-тайм данные. Как вот это, например, https://paste.ee/p/acGQ1 переписать так, чтобы не приходилось вручную повторять всё. Я максимум додумался так сделать https://paste.ee/p/ChBMj, но тут проблема в том, что мне нужна эта константа при определении метода в трейте.
Я вообще не понима, неужели нет никакого нормального способа перестать быть лоу айкью дауном.
Я вообще не понима, неужели нет никакого нормального способа перестать быть лоу айкью дауном.
Самый лучший формат картинок, потому что он единственный, который мой лоу айкью мозг может реализовать https://netpbm.sourceforge.net/doc/ppm.html. Настолько самый лучший, что его 20 лет назад выпилили из фаерфокса https://bugzilla.mozilla.org/show_bug.cgi?id=197530. Хочу умереть.
Это то, как отображаются жсоны в фаерфоксе, абсолютно бесполезный визуальный мусор двоеточие в конце каждого ключа, которое выглядит как часть самого ключа, потому что оно даже цветом не отличается. Особенно плохо выглядит когда сам ключ может содержать на конце что-то вроде двоеточия.
Я не знаю, я постоянно на подобное напарываюсь, и можно было бы списать на то, что софт слишком сложный, чтобы избегать даже таких очевидных проблем, что это и не проблемы вовсе, а я просто придираюсь, но я сейчас задумался, что я так-то сам часть проблемы, потому что я в жизни своей никогда не создавал никаких баг репортов после того, как напарывался на подобные вещи. Ну я на английском просто плохо говорю ещё, умереть хочется, короче.
Я не знаю, я постоянно на подобное напарываюсь, и можно было бы списать на то, что софт слишком сложный, чтобы избегать даже таких очевидных проблем, что это и не проблемы вовсе, а я просто придираюсь, но я сейчас задумался, что я так-то сам часть проблемы, потому что я в жизни своей никогда не создавал никаких баг репортов после того, как напарывался на подобные вещи. Ну я на английском просто плохо говорю ещё, умереть хочется, короче.
Я не могу, у меня болит голова от раста, я хочу выпилиться как минимум из-за того, что там это, например, не реализовано 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 мувает внутрь себя источник, откуда он читает, что вообще происходит.
Что вот мне делать, переписать, чтобы он не сам читал, а у него спрашивали, что он хочет сделать: скипнуть байты, прочесть сколько-то байтов, и потом пушили в него байты что ли, но это же бред, а может лучше просто выпилиться, потому что жить с таким маленьким айкью это просто уже невозможно.
Ну так и не пиши на расте, зачем так мучиться?
Если прописать 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
Проблема не столько в расте, сколько в слишком низком айкью, который ещё и продолжает уменьшаться.
У меня появилось в мыслях, что можно было бы маркерами сделать два отдельных типа и в них сделать две отдельных реализации одного и того же метода. Но там всё равно без макросов в итоге не обойтись для реализации остальных методов, которые не зависят от того, какие трейты реализованы, но хотят вызывать методы, которые от реализованных трейтов зависят 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 и я даже не знаю, что из этого хуже.
Но это даже не решение проблемы, что два отдельных типа приходится делать — это так-то бред.
Вообще ещё одна шизо-идея — это заставить самого пользователя реализовывать трейт Skippable. Сделать просто два макроса с двумя реализациями. Ну как, просто, там нужно будет как минимум заморочиться, если у структуры, для которой трейт реализуется, есть дженерик параметры, например. И вроде как вместе с min_specialization, которая вроде как по крайней мере не unsound, можно сделать одну дефолтную реализацию и пользователь может через макрос уточнить её https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b878b49b9ef2210b03a6163e1c887f27. То есть в худшем случае используется дефолтная реализация.
>переписать, чтобы он не сам читал
Ну в смысле, что он не будет вызывать read, не будет владеть буфером, куда читает, а будет только по указателю, который ему дают. Наверное, это лучше, не знаю, потому что более гранулярное апи получится, которое проще переиспользовать и бла-бла-бла https://youtu.be/ZQ5_u8Lgvyk, но важнее, что мне тогда не приходится использовать трейты.
Ещё в предыдущем варианте у меня в голове была какая-то стрёмная идея, что токенизатор должен по очереди пытаться распарсить токены, про которые он знает, и, наверное, я думал, что это сделает реализацию довольно прямолинейной и будет легко добавлять новые типы токенов, но по факту получился довольно нечитабельный код.
Во-первых, жсон токенизатор всё не должен беспокоится о валидности строк, чисел и ключевых слов по типу 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, потому что всё же, например, не любые три байта вида
> 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[].
Нет, короче, это бред, в этом 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[].
Нет, короче, это бред, в этом JsonTokenizerMode нет никакого смысла, усложнение кода ради ничего, в итоге получается одна жирная функция, которая обрабатывает все ситуации, вместо нескольких небольших на каждую отдельную ситуацию, да, очень ГРАНУЛЯРНО, какой же я тупорылый даун. Так, всё, я перепишу нормально, как было с самого начала, только, возможно, без шизомакросов и всё же с фиксированным буфером, куда читается входная строка.
Я пытался https://youtu.be/Si8QRtdjrUA
Всегда казалось, что нет лучше чувства, чем когда осознанно отлыниваешь от каких-то навязанных тебе "обязанностей", не делаешь того, что ты якобы должен делать. Но, на самом деле, это просто обычное состояние, когда тебя не ничего беспокоит, а во все остальные моменты в мыслях крутится постоянно, что а вот завтра придётся что-то делать или что кто-то от меня что-то ожидает, это портит жизнь, это портит моё настроение. Я не могу спокойно жить с осознанием, что моё время мне не принадлежит мне целиком и полностью, что кому-то от меня что-то надо, что кто-то претендует на то, чтобы отнимать у меня жизнь. Всё, чего я когда-либо действительно хотел — это проснуться с осознанием, что я свободен от выдуманных какими-то идиотами обязанностей, никому от меня ничего не надо и у меня в голове не скребутся посторонние мысли на фоне. Да-да, никому и так от меня ничего не надо, если бы я лёг под мостом и помер бы там, никто бы до меня не докопался, всем было бы наплевать. Но меня вынуждают встраиваться в эту долбаную систему, где всем от всех что-то нужно, а потом ещё пытаются внушить, что я это, оказывается, сделал по своей воле, вот захотелось мне повесить на шею цепи, а теперь жалуюсь, что мне тяжело, и вообще нам тоже тяжело, а чем ты лучше? Да в жизни я бы не сделал этого выбора, если бы мог вообще сделать выбор в пользу чего-то другого. Я не могу уже так жить, в какой-то момент становится невозможно терпеть и ты просто бросаешь то, что тебя заставляли делать. А потом тебя спрашивают, а почему так, ну ты же так старался, а теперь всё дропнул, как будто я делаю что-то нелогичное. Как будто то, что я перестал отпиливать себе ногу — это что-то неразумное и раз начал пилить, то надо пилить до конца. А это именно отпиливание своей ноги, нет никакой конечной цели, у меня нет никаких амбиций, мне не нужно ничего этого, меня просто заставляют страдать ради ничего. Это не обмен ресурсов моей силы воли ради достижения какого-то результата, это просто растрата моих сил в никуда, я ничего от этого не получаю, я только теряю. Я не могу так жить, мне нужен отдых, мне нужно, чтобы от меня все отстали, это невозможно больше терпеть, мне не помогает никакой копинг, это просто патовая ситуация, в которой мне, как жертве пыток, привязанной ко стулу, остаётся только ждать, когда смерть освободит меня от страданий.
Не могу переступить через себя, нет сил на это, в какой-то момент всегда иссякает сила воли и всё. Не становится со временем легче. Когда нет никакого смысла в страданиях, через время устаёшь и не можешь продолжать. У большинства нет таких проблем, я уверен, большинство делают то, что им либо хочется, либо то, что они по крайней мере не против делать, а страдаю я один. Я не знаю, может быть, разломать телефон и комп, забиться в угол и там сидеть, это, возможно, лучше, чем каждый день страдать. Мне просто нужно спокойствие, но большинству людей, видимо, этого не нужно и вообще они делают всё, чтобы его избегать, я не хочу, я устал, почему это всё должно происходить со мной, когда это закончится.
Я не могу, я не спал нормально несколько дней из-за того, что постоянно в напряжении из-за того, что мне якобы надо что-то сделать, но я не могу себя пересилить и я в итоге ничего не делаю, сегодня весь день болела голова, болели глаза и хотелось спать, сегодня снова не высплюсь, потому что буду сидеть и пытаться себя заставить себя что-то сделать, но я снова ничего не сделаю, потому что я просто не могу, у меня внутри всё противится, это невозможно побороть. Я не могу, мне нужно просто, чтобы кто-то извне обрубил этот цикл и я освободился от этих страданий.
Я, короче, буду тут писать сколько мне влезет вне зависимости от того, делаю ли я что-то или нет, и я буду постить картинки, какие захочу, мне вообще всё равно, потому что мне грустно, мне плохо, я, короче, сейчас посмотрел немного это https://www.w3.org/Graphics/GIF/spec-gif89a.txt и это должно быть не очень сложно сделать, там просто lzw сжатие, я не знаю зачем, но просто мемный формат: во-первых, в него официально можно пихать мусор (comment extension), во-вторых, можно сохранять rgb888 картинки, если распределить цвета на несколько кадров и рисовать новое поверх предыдущих кадров, в-третьих, это простейший способ сохранить видео.
И со вторым тут две идеи: наивная - все кадры одинакового размера, прозрачный цвет на местах уже закрашенных пикселей, и вторая - попытаться разбить картинку на как можно больше непересекающихся прямоугольников, чтобы не хранить избыточные прозрачные пиксели. Как это сделать - не знаю, наверное, резать пополам пока не найдёшь прямоугольник, где мало цветов, и потом так же, разрезанием пополам пытаться присоединить к нему ещё прямоугольник, чтобы по возможности максимизировать количество цветов. Но я не уверен, что это будет работать лучше, чем наивная идея.
Вариация идеи с прямоугольниками - в глобальной таблице цветов сохранить все самые часто встречающиеся цвета и в первую очередь искать прямоугольники, где много цветов из глобальной таблицы, для которых использовать глобальную таблицу вместо локальных. Ну то есть попытаться сократить повторные цвета среди локальных таблиц. Но тут, мне кажется, это совсем переусложнённый вариант и он точно будет в реальности хуже наивного.
Я начал сегодня писать читалку гифок, но пока что не успел написать даже прогу, которая бы просто проглатывала гифку без разбора. Я постараюсь найти завтра время, чтобы хотя бы просто проглотить гифку.
И со вторым тут две идеи: наивная - все кадры одинакового размера, прозрачный цвет на местах уже закрашенных пикселей, и вторая - попытаться разбить картинку на как можно больше непересекающихся прямоугольников, чтобы не хранить избыточные прозрачные пиксели. Как это сделать - не знаю, наверное, резать пополам пока не найдёшь прямоугольник, где мало цветов, и потом так же, разрезанием пополам пытаться присоединить к нему ещё прямоугольник, чтобы по возможности максимизировать количество цветов. Но я не уверен, что это будет работать лучше, чем наивная идея.
Вариация идеи с прямоугольниками - в глобальной таблице цветов сохранить все самые часто встречающиеся цвета и в первую очередь искать прямоугольники, где много цветов из глобальной таблицы, для которых использовать глобальную таблицу вместо локальных. Ну то есть попытаться сократить повторные цвета среди локальных таблиц. Но тут, мне кажется, это совсем переусложнённый вариант и он точно будет в реальности хуже наивного.
Я начал сегодня писать читалку гифок, но пока что не успел написать даже прогу, которая бы просто проглатывала гифку без разбора. Я постараюсь найти завтра время, чтобы хотя бы просто проглотить гифку.
Я, короче, не успел ничего. Нашёл такой мем 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 есть, но я не читал ещё.
Я не сделал, я слишком много думаю и ничего не делаю, а это бесполезно - думать, когда ты тупой, слишком маленький айкью, нет смысла, тем более, когда не особо много времени и есть, и осталось. Это даже не какие-то последовательные мысли, а просто обрывки, которые ни во что не складываются, примерно как когда утром наполовину просыпаешься и ты наполовину в сознании, а наполовину в башке крутятся бредовые остатки сна, который ты потом почти сразу забудешь. Я должен был умереть несколько лет назад, ничего хорошего не было и уже не будет, только страдания от низкого айкью, от тупости. Что, я не могу ничего пообещать. Мне кажется, что настолько всё плохо, что даже, если меня несмертельно ударить по голове молотком, то ничего не изменится, потому что максимум дальше можно только умереть и спрятаться в гроб, уже невозможно сделать хуже. Я купил себе новый проц, но вместе с ним нужна была и новая мать, старую вместе со старым процом положил в коробку, меня тоже нужно положить в горобку, нужно, чтобы кто-то спас меня от такой жизни.
С возвращением тебя.
>нужно, чтобы кто-то спас меня от такой жизни.
Однажды я курил с обычным пацаном с района, мы стояли и был обычный диалог гоп-стиль ни о чём. Я вижу как к нам идёт один казах, я думаю что он такой же как другой чувак, дескать типичный пацанчик с района и он так себя и вёл, пока я что-то не сказанул про античную философию...
Я люблю поговорить, но глубоких познаний у меня нëт ни в чём, этот казах меня раскатал как ребёнка. У него даже тон изменился, он стал настоящий когда мы начали говорить про философию. А выглядел как обычный "четкий пацан". Я тогда особого внимания не это не обратил.
Сейчас когда начал менять свою жизнь понял, что очень многие люди завидуют мне из-за моего интеллекта, чуствуют себя ниже и это задевает их самолюбие. Поэтому они пытаются меня клюнуть. Вот вчера выряс это с с силой из своей подружки. Я сам считал себя самым последним глупцом на свете, даже совсем не верил своему мнению. Но это потому, что меня всю жизнь подавляла мать, а отца не было, а на самом деле я как Никола Тесла, чуствую это.
А тот парнишка просто скрывал силу, ведь иначе люди не примут. Всегда появляются проблемы когда ты выше в обществе на порядок. Но говорить стоит не со всеми. Ты можешь просто не говорить с людьми или говорить с ними на их языке, как тот казах. Тогда они тебя примут, но главное внутри остаться собой. Поверь в себя.
Бог тебе в помощь.
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 считает ошибкой, но если слайс выходит за границы - то уже нет.
И что, и какой смысл во всём этом тогда.
Позавчера вчера сегодня написал всё же что-то короче декодирование, но у меня нет сейчас доделывать, как есть в общем 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 + мне испортили жизнь + я тупой даун + я тупой даун, я не знаю, что мне делать, я никак не могу дождаться, когда все сдохнут и я тоже, очень нужно уничтожение всех людей, пожалуйста
Я хочу, наверное, написать препроцессор + парсер сишных хедеров, но это выглядит как что-то слишком сложное и я, наверное, слишком тупой для этого. Типа вообще какой смысл жить если у меня плохой мозг, я каждый день от этого страдаю. Я просто не знаю, как это нормально сделать, ещё и макросы в си слишком сложные, потому что
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "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
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "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
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
Во Free Pascal макросы (там нет функциональных, но функциональные должны делаться несложной модификацией, заключающейся в том, что на время их непосредственного раскрытия их аргументы тоже считаются специальными макросами; лет через 10 сам сделаю... ... ...) сделаны следующим образом: штука, которая читает токены (на самом деле символы, но, наверное, это естественно делать на уровне токенов, чтобы проще обрабатывать пустые макросы, конкатенации и т. п.), может быть переключена на новый файл, а по его завершении возвращается к предыдущему. Само по себе это реализует инклюды, но и макросы реализованы как псевдо-файлы, на которые сканер переключается и затем возвращается к предыдущему (настоящему файлу или внешнему макросу). То есть мы работаем не со связным списком токенов, в середине которого периодически устраиваем разворачивания, а со стеком файлов и единственным токеном, читаемым в данный момент.
Это позволяет результату разворачивания макроса быть сколь угодно большим, его существование в памяти целиком не требуется. Конечно, в зависимости от того, в какие конструкции он разворачивается и что с ними происходит дальше, это может не помочь, но, во всяком случае, даже тогда препроцессору делает честь, что с нехваткой памяти упал не он.
Разбил стекло на телефоне, кинув его об пол, теперь на пальцах постоянно какие-то мелкие крошки от растрескавшегося стекла, надеюсь, они попадут мне в глаза и я ослепну
+++
Мега кринж https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d4e5b586dbb2f40abf1f7f2df303ed60 Я перестаю понимать зачем вообще жить хочется уже подохнуть поскорее, потому что вообще ничего хорошего не вижу уже, никакого смысла нету и ничего хорошего не будет
ffi кринж + аутизм 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
Мемно
https://godbolt.org/z/7n15qWd3E
Я вообще не знал, что у std::span есть второй шаблонный параметр и по дефолту он максимальный size_t и по дефолту std::span - жирный указатель, но если его размер известен в компайл тайме, то он просто указатель
Ну как бы понятно, что надо просто использовать метод .size(), но просто
Но даже с такими возможностями выстрелить себе в голову мне это больше нравится, чем
чем раст с его трейтами и с его const функциями
https://godbolt.org/z/7n15qWd3E
Я вообще не знал, что у std::span есть второй шаблонный параметр и по дефолту он максимальный size_t и по дефолту std::span - жирный указатель, но если его размер известен в компайл тайме, то он просто указатель
Ну как бы понятно, что надо просто использовать метод .size(), но просто
Но даже с такими возможностями выстрелить себе в голову мне это больше нравится, чем
чем раст с его трейтами и с его const функциями
Написал типо читалку 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:
> 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 дебила типа меня.
- посмотреть строку в буфере
- откусить сколько-то байтов (предполагается, что ты сам знаешь, сколько надо откусить, иначе всё сломается)
- прочитать в буфер больше - это все функции ниже делают автоматически при необходимости, я думал сделать этот шаг явным, но, мне кажется, если, например, тебе надо прочесть следующий символ, но он в буфере есть только наполовину, то ну типо, ты в любом случае захочешь прочитать в буфер больше байтов и тут больше вроде ничего умного в общем случае не придумать, поэтому я просто запихнул это в сами функции, из-за этого они мутируют читалку даже, если это просто 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 в спам-листе, ясно
У меня снова началась эта шиза, потому что мне хуёво блять и я либо сижу и нихуя не делаю, либо занимаюсь хуйнёй, заново переписал конфиг, не глядя на старый-старый, который я даже не использовал в пользу старого более минималистичного. Но получил в итоге примерно то же самое, но на этот раз более-менее разобрался с ленивой загрузкой плагинов, благодаря чему оно хотя бы стартовый экран с меню относительно быстро почти мгновенно открывает, тупо потому что почти ничего не грузит. Корову не я нарисовал, я её украл
Стартовый экран почти бесполезный, там полезное только это перейти в папку с конфигами за одно нажатие кнопки
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 не может их подтянуть, это же всего лишь пакетный менеджер для кроссплатформенного языка
Да и другие скриптовые языки, для них у тебя на компе обязательно должен быть установлен интерпретатор и, скорее всего, ещё и пакетный менеджер к нему, потому что миллион зависимостей является данностью для любой проги на скриптовом языке. Нельзя просто запустить прогу, потому что проги никакой нет, у тебя есть только куча бесполезных текстовых файлов
У меня типа просто есть скрипт, который скачивает всякую ерунду, но из-за того, что он написан на жс, я не могу его запустить, мне придётся устанавливать ноду и я так думаю, что ну это слишком сложно, обойдусь
Каждый ёбаный день состоит из страданий
Я обязательно нарисую треугольник, вот завтра начну, честно, если нахуй не сдохну от сердечного приступа завтра, что очень вероятно, потому что жизнь хуйня и я хочу умереть, не получается, нет времени ни на что, потому что его не очень много, я не умею пользоваться доступным и мне слишком хуёво, блять, каждый божий день.mp4
Не хочется жить больше, я не чувствовал себя живым весь день, вечером сильно болела голова из-за страданий, и только ночью стало лучше
Твой голос буквально АСМР.
А я люблю АСМР.
Не знаю о чем ты там пиздишь, но годно.
.
Я ненавижу жить блять я блять ненавижу, хочу нахуй сдохнуть уже блять пожалуйста
То ли мне показалось, что ли у тебя расхождение с тем, что ты пишешь и тем, как ты говоришь. У тебя вполне спокойный нормальный голос, не подавленный какой-то, рассказываешь интересно.
Ты это просто так пишешь, про сдохнуть, типа прикол такой?
Я хочу куда-нибудь спрятаться блять я у меня руки чешутся что-нибудь разъебать и спрятаться и чтобы меня никто не нашёл я ненавижу свою ебаную жизнь, блять я не хочу так жить больше сука, я куплю участок земли с деревянным полусгнившим домом, поселюсь там и нахуй замёрзну насмерть или случайно спалю его вместе с собой. НИчего блять хорошего, всем блять что-то надо от меня идите нахуй, я хочу просто сидеть и сидеть в экран, я не хочуть блять ничего больше
Я не могу делать то, что мне не хочется (то есть почти что всё), мне становится плохо и со временем я не привыкаю, а становится только хуже, у меня начинают чесаться руки, чтобы сломать что-то что попадётся под руку или ударить себя по башке. И в какой-то момент я просто физически не могу себя заставить вообще ни минуты больше делать то, что мне не хочется, мне физически плохо. Это примерно то же ощущение, когда берёшь нож с мыслями, ну вот ща всажу его поглубже, но как только доходит до дела, то всё внутри противится, потому что ну объективно нельзя такое делать, если ты нормальный человек, а не ебучая школьница
Я не могу учиться, я не могу работать, я ненавижу это всё, мои родители эффективно заставили меня пойти на работу, потому что я просто уже не вывозил морально их постоянное нытьё о том, что вот ты какая мразь бросил учиться. И всё, у меня подошла точка, когда меня так сильно выворачивает наизнанку, что я не могу ни на минуту сесть за комп и что-то начать делать, я слишком сильно ебал в рот этот говнокодинг какой-то хуйни, которую я ебал в рот, я ни минуты не хочу больше разбираться в этой куче хуйни
Проблема в том, что мне теперь жить спокойно не дадут, зная что я блять нихуя себе сижу дома давлю кнопки и мне за это платят какие-то обоссанные копейки, и будут ебать мне мозг точно так же, как ебали мне мозг с учёбой, только ещё сильнее, мол, давай иди, иди снова всирай свою жизнь на какую-то очередную долбоёбскую парашу
Я могу уехать от них месяца на 4 максимум, а потом, видимо, лечь на пол, сдохнуть от голода и мумифицироваться, потому что абсолютно все работы доступные человеку с низким айкью - это подобное дегроидное говно, от которого мне хочется залезть на потолок. Либо притворяться, что работаю, блять, подделывать скрины из бансковского приложения
Я не могу учиться, я не могу работать, я ненавижу это всё, мои родители эффективно заставили меня пойти на работу, потому что я просто уже не вывозил морально их постоянное нытьё о том, что вот ты какая мразь бросил учиться. И всё, у меня подошла точка, когда меня так сильно выворачивает наизнанку, что я не могу ни на минуту сесть за комп и что-то начать делать, я слишком сильно ебал в рот этот говнокодинг какой-то хуйни, которую я ебал в рот, я ни минуты не хочу больше разбираться в этой куче хуйни
Проблема в том, что мне теперь жить спокойно не дадут, зная что я блять нихуя себе сижу дома давлю кнопки и мне за это платят какие-то обоссанные копейки, и будут ебать мне мозг точно так же, как ебали мне мозг с учёбой, только ещё сильнее, мол, давай иди, иди снова всирай свою жизнь на какую-то очередную долбоёбскую парашу
Я могу уехать от них месяца на 4 максимум, а потом, видимо, лечь на пол, сдохнуть от голода и мумифицироваться, потому что абсолютно все работы доступные человеку с низким айкью - это подобное дегроидное говно, от которого мне хочется залезть на потолок. Либо притворяться, что работаю, блять, подделывать скрины из бансковского приложения
Ничего хорошего не будет, ничего хорошего не было, я блять уёбище я хочу чтобы всё закончилось, я хочу один раз удариться головой об стену и чтобы она раскололась как скорлупа у яйца и всё блять сука блять сука
Вот, видите. Именно такие мысли продуцирует неовим у каждого его пользователя.
Я ненавижу свою ебучую жизнь блять, я тупорылое уёбище и это само по себе причиняет страдания и я не могу выдерживать того, что мне сверху испортили всю мою ебаную жизнь и впереди нихуя не будет абсолютно ничего хорошего никогда, потому что физически невозможно, чтобы что-то хорошее произошло это всё равно что мне ногу отрубили и я теперь всю оставшуюся жизнь вынужден вприпрыжку передвигаться на одной сука блять ноге блять сука и давай, привыкай, живи с одной ногой и вообще тебе повезло ещё или якобы и нет никакой проблемы, а вообще одни плюсы в том, чтобы с одной ногой жить, на что ты жалуешься, блять идите нахуй сука вы ненавижу я хочу, чтобы вы все умерли
Я не знаю, что мне делать, все мысли в моей голове - ебаное говно, я тупой долбоёб
Я эту ебаную зиму не переживу, ну почему так ебано то, блять, почему настолько безнадёжно, просто всё, всё, нихуя не будет всё
почему всё так
Я пять секунд попробовал гитхаб копилот, короче, он буквально сразу же нагенерил мне заведомо нерабочий мусор, причём выглядит правдоподобно, но всё равно бред. Короче, юзлесс, как и чатгпт
Я сейчас на работе буквально ничего не делаю и каждый день придумываю оправдания, почему я что-то не сделал, создаю видимость, что я что-то делаю, кормлю завтраками и тд. Не могу себя заставить, потому что мне не хочется, мне не интересно, мне противно, нет никакого положительного стимула это делать.
Не могу даже делать минимум спустя рукава, чтобы меня не трогали. И на фоне этого ничем для себя я толком тоже не могу заниматься, из-за ощущения, что вот-вот произойдёт что-то неприятное, из-за того, что в это время мне якобы нужно делать что-то другое, из-за того, что вне зависимости ни от чего будет кто-то, кто будет постоянно трахать мне мозг какой-то хуйнёй для долбоёбов.
У тебя просто нет возможности в течение, например, недели делать только что-то одно, без переключения на другие вещи. А как-то пытаться совмещать - это бесполезно, я пытался, у меня не хватает сил ни физических, ни моральных. Получалось так, что я ничего не успевал, тот треугольник рисовал почти два месяца, например.
Я в итоге сейчас просто целыми днями сижу и ничего не делаю, в состоянии ступора какого-то, я не знаю. Я всегда хотел только одного - чтобы я мог проснуться, осознавая, что никому от меня ничего не надо, что я могу потратить своё время так, как мне вздумается. Но этого просто никогда не будет, потому что, видимо, абсолютное большинство людей всё устраивает, возможно, им даже нравится, когда им нон-стоп ебут мозг.
Не могу даже делать минимум спустя рукава, чтобы меня не трогали. И на фоне этого ничем для себя я толком тоже не могу заниматься, из-за ощущения, что вот-вот произойдёт что-то неприятное, из-за того, что в это время мне якобы нужно делать что-то другое, из-за того, что вне зависимости ни от чего будет кто-то, кто будет постоянно трахать мне мозг какой-то хуйнёй для долбоёбов.
У тебя просто нет возможности в течение, например, недели делать только что-то одно, без переключения на другие вещи. А как-то пытаться совмещать - это бесполезно, я пытался, у меня не хватает сил ни физических, ни моральных. Получалось так, что я ничего не успевал, тот треугольник рисовал почти два месяца, например.
Я в итоге сейчас просто целыми днями сижу и ничего не делаю, в состоянии ступора какого-то, я не знаю. Я всегда хотел только одного - чтобы я мог проснуться, осознавая, что никому от меня ничего не надо, что я могу потратить своё время так, как мне вздумается. Но этого просто никогда не будет, потому что, видимо, абсолютное большинство людей всё устраивает, возможно, им даже нравится, когда им нон-стоп ебут мозг.
Если я так и не начну сегодня ничего делать, то возможно меня уволят, потому что я ничего не делаю уже достаточно времени, чтобы это вызвало недовольство. Но проблема в том, что мне как-то всё равно, я хочу, чтобы всё как-нибудь просто закончилось, но мне никто не поможет, просто проблема в том, что меня потом снова погонят в рабство в стойло, либо у меня просто деньги закончатся, если я съеду от них, чтобы они меня не трогали. А откуда брать деньги, не прикладывая никаких усилий, или как жить без потребности в деньгах, при этом пользуясь интернетом и электричеством и не имея своего дома, я не знаю, я слишком тупой и бесполезный для этого
Почему я просто не родился красивой женщиной, всё было бы настолько проще, вот вообще тупо всё, а так это просто бесполезно жить так нет смысла никакого, не на что надеяться, ничего из более-менее вероятного в теории не может произойти, что могло бы исправить моё положение, и я сам ничего сделать не могу, ничего хорошего не будет
cos(колво рукавов × угол + направление закручивания × 2π × (колво оборотов × расстояние от центра + время))
Я бы не додумался сам потому что я тупорылый долбоёб
Фликеринг жёсткий
Похуй
блять мне
Я бы не додумался сам потому что я тупорылый долбоёб
Фликеринг жёсткий
Похуй
блять мне
Какая зп, какой потолок в конторе, скока получают топманагеры, главхуй, скока оборот, какая продукция производится, куда сбывается?
Сори за такие интимные вопросы, но ответь хоть на что-то, раз ты дневниковод.
>Какая зп
Недостаточно большая, чтобы можно было за год рабства ХОТЯ БЫ накопить на покупку своего участка с домом, то есть обоссанные копейки. Как и на большинстве работ: хватает только на то, чтобы покупать всякую потреблядскую парашу, но не на нормальные вещи.
>какая продукция производится, куда сбывается
Это всё не имеет значения. Если у тебя IQ <130, то тебе доступны только бесполезные бессмысленные говноработы, от которых течёт мозг и на которых ты деградируешь, просто впустую всираешь часы своей жизни, свои силы.
И мне похуй на то, что там другие люди считают "полезным" трудом, я, например, в рот ебал центральное водоснабжение. Наверняка дохуя сложно поддерживать в нормальном состоянии всю эту ебаную систему, наверняка нужны какие-то специальные знания и далеко ненулевой интеллект, наверняка большинство людей считают её даже не просто полезной, а жизненно необходимой, но в моих глазах она не нужна, потому что Я НЕ МОЮСЬ БЛЯТЬ.
И что ещё хуже, все эти говноработы порождают потребность только в ещё большем количестве говноработ. Мы построили большой город - теперь нам нужны магазины на каждом углу. Мы нахуярили магазинов на каждом углу - теперь нам нужно развозить в них свежую еду каждый день, теперь нам нужно нанять дохуя людей расставлять товары и разгружать грузовики, теперь нам нужно разрабатывать говнософт для касс самообслуживания, потому что кассиров не хватает. И так далее.
Я ебал всё в рот, мне похуй, ему похуй, похуй похуй похуй
Не, это вообще полностью бесполезно, у меня дни слились просто в один длинный, ещё и солнце не светит никогда и я не понимаю, что вокруг происходит и мне просто постоянно плохо, физически тоже постоянно ощущение сдавленности в грудной клетке, сижу ничего не делаю.
Я скорее всего, съеду от родителей в январе и тогда же стану безРАБотным с 90% вероятностью. И не знаю, что буду делать дальше, не знаю, на сколько месяцев хватит денег. Пытаться снова лезть в говнокодинг за деньги нет никакого желания, не хочу работать, работа - это рабство, мне внутри всё внутри грудной клетки прогрызли крысы
Я скорее всего, съеду от родителей в январе и тогда же стану безРАБотным с 90% вероятностью. И не знаю, что буду делать дальше, не знаю, на сколько месяцев хватит денег. Пытаться снова лезть в говнокодинг за деньги нет никакого желания, не хочу работать, работа - это рабство, мне внутри всё внутри грудной клетки прогрызли крысы
Впереди нет ничего, просто чернота, я не могу ни на что повлиять, не могу ничего сделать. Неважно, например, даже если я себя сейчас убью, то это буквально тот же самый исход, как если я не сделаю этого. Ни в чём нет смысла
Короче эта тема с якобы двойной буферизацией через сделать два скринбуфера CreateConsoleScreenBuffer и потом их по очереди показывать через SetConsoleActiveScreenBuffer как будто всё же немного улучшает, но только на conhost.exe, в виндовс терминале - без разницы, в алакрити оно как будто вообще только хуже делает. К тому же когда перезапускаешь в той же консоли заново, то во варианте с двумя скринбуферами почему-то всё неправильного размера начинает рисоваться, короче, это бред пытаться это использовать
Мельтешение при ресайзе невозможно убрать неважно с двумя скринбуферами или без них в любом случае вроде, не знаю
Единственное, что стоило сделать - это заменить растовый print! на WriteConsoleW, потому что раст похоже делает какую-то буферизацию и непонятно как преобразовывает utf8 строки в utf16 для винды, а я использую юникодовые символы, мне лень разбираться, проще самому сделать, вроде немного лучше (ну точнее в conhost.exe print вообще адекватно не работал, а виндовс терминалу было болееменее нормально с самого начала), но тоже вырвиглазно, короче бесполезно
А я просто что-то подумл зачем нужны все эти графические апи, если есть консоль, в которой можно рисовать квадратики и к тому же ещё и рендеринг текста есть, но не знаю короче
Мельтешение при ресайзе невозможно убрать неважно с двумя скринбуферами или без них в любом случае вроде, не знаю
Единственное, что стоило сделать - это заменить растовый print! на WriteConsoleW, потому что раст похоже делает какую-то буферизацию и непонятно как преобразовывает utf8 строки в utf16 для винды, а я использую юникодовые символы, мне лень разбираться, проще самому сделать, вроде немного лучше (ну точнее в conhost.exe print вообще адекватно не работал, а виндовс терминалу было болееменее нормально с самого начала), но тоже вырвиглазно, короче бесполезно
А я просто что-то подумл зачем нужны все эти графические апи, если есть консоль, в которой можно рисовать квадратики и к тому же ещё и рендеринг текста есть, но не знаю короче
Скрыть виндовый курсор, пока он находится над конолью, вроде как нельзя
Не хочется жить, не на что надеяться, почему всё настолько плохо, никто не поможет
Мне абсолютно ничего не интересно, кроме как сидеть дома и играть в игры
Всё бесполезно, никаких вариантов нет. Я не верю в то, что людей со временем начинается принятие смирение и бла бла бла, все люди пиздят, я их всех ненавижу, принятия не существует, существует, что какая-то хуйня случилась и ты со временем её забыл, а когда хуйня происходит каждый день, ты её не можешь забыть блять. Все живут и всем нормально живётся, всё устраивает, всё нравится, а кому не нравится - они спиваются, старчиваются и сдыхают. Я один страдаю, мне одному плохо
Подписался на тред
Ну и хуета, в пизду короче
Неплохо. Текстурки порельефнее сделать, (типо "запечь" но без запекания, а вручную всё отрисовав) как в старых играх типо варкрафта.
вот бы поюлозить своим хреном у тебя между сисек
блина, такой голос милый..
>выделение памяти для структуры через VirtualAlloc
хм, а разве в винде нет malloc? я мало под неё писал, вернее вообще не писал, так что не знаю
>PeekMessage
какое же winapi все таки странное, капетс
даже как-то сказать нечего, графика как была для меня темным лесом, так наверно и останется
Ебучие родаки за каким-то хуем решили порыться в моём столе и нашли заявление на увольнение. Двух недель не прошло, эти пидарасы уже успели узнать
В чём проблема? Тебе сколько годиков? Родители нашли заявление на увольнение... ХОСПАДЕ ИСУСИ
Проблема в том, что я не могу больше притворяться, что всё ещё работаю и эти хуесосы теперь снова будут трахать мне мозг тем, чтобы я снова шёл работать каким-нибудь долбоёбом
Стань мужиком и выйди на работу делов-то, все хватит ныть возьми себя в руки !!!
Работа - это рабство и деградация, если у тебя iq < 115, то не существует интересных работ, существует только унылое бессмысленное дерьмо, которым я не хочу заниматься и мне хуёво
Зачем ты привязываешь свой пессимизм к IQ? Боишься чего-то и пытаешься защититься?
Братан ну еду готовить и мусор выносить так-то тоже уныло.
+++
Вот это забавно 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, построенный на колбэках/ивентах с непонятно каким порядком выполнения кода - это зло,
скриптовые языки - это зло, потому что люди неизбежно начинают с их помощью надстраивать что-то гигантское, сложное и непонятное,
единственный правильный способ поддержки расширений - это менять исходный код через гит патчи, добавляющие нужный функционал, и самому пересобирать программу?
Или что мне нужно начать пользоваться блокнотом вместо нвима?
Я в 10 раз бросил кофе но всё ещё не хочу ничего, нет смысла жить никакого
Зачем бросил? Хуевит с него?
Пытался читать это 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 может в теории не работать. Но, по-моему, всё же на большинстве компов у них порядок байтов совпадает.
Я чего-то заметил, что под виндой, если клангом компилировать напрямую без прокладки в виде симейка, то он выдаёт более крупные экзешники (на ~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 в основном, чтобы знать дефайны, где хедеры лежат и другие параметры компилятора. Может быть, можно его и вручную попробовать генерировать. А так я бы, может быть, просто одной командой все файлы каждый раз бы компилировал.
Земленика
Но там всего лишь штук 10 ягод на пакет в 100 граммов и у ароматизатора слишком приторный запах какой-то. У меня изначально сложилось неоправданно положительное впечатление от ароматизированных чаёв из-за того, что первым попался очень вкусно пахнущий. А все последующие, что пробовал, были в лучшем случае терпимыми. Может быть, лучше пить без ароматизаторов и купить каких-нибудь сублимированных ягод. Не знаю, будут ли они сами по себе хотя бы запах давать в чае, не пробовал ни разу.
Но там всего лишь штук 10 ягод на пакет в 100 граммов и у ароматизатора слишком приторный запах какой-то. У меня изначально сложилось неоправданно положительное впечатление от ароматизированных чаёв из-за того, что первым попался очень вкусно пахнущий. А все последующие, что пробовал, были в лучшем случае терпимыми. Может быть, лучше пить без ароматизаторов и купить каких-нибудь сублимированных ягод. Не знаю, будут ли они сами по себе хотя бы запах давать в чае, не пробовал ни разу.
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.
Пытаться настроить симейк - ещё более бесполезное занятие, чем сидеть писать конфиги к текстовому редактору
Я пробовал добавлять сублимированную клубнику и смородину в чай, но они не дают ни вкуса, ни запаха, а просто размокают, но есть их интереснее сухими. Ещё в морозилке валяются какие-то замороженные ягоды, но, я думаю, проще просто умереть
Купил эрл грей, потому что просто слышал название, оказалось, что он с какими-то цитрусовыми кожурками и пахнет омерзительно, теперь мне его пить непонятно сколько времени, пока не закончится
Ничего не понимаю, что я делаю. Типа совсем, я не понимал, почему 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 вроде более-менее простое
Я ничего не делал ни вчера, ни сегодня, ни в чём не вижу смысла, нету смысла жить, ничего хорошего никогда не будет
https://youtu.be/JtgQJT08J1g?t=2003 прикольное видео, короче там примерно те же идеи используются, что и тут для прямых когда раскрываются модули в неравенстве, когда выбирается, какая следующая точка ближе к линии, которую рисуешь. Я это имел в виду тогда, но в контексте прямых
И прикольная идея с тем, что можно несколько раз применить 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}), но я не понимаю, как это формально доказать. Я не понимаю, как с погрешностью связана эта разность предыдущего и следующего приближений
У меня чувство, что по крайней мере залитые одним цветом круги проще рисовать просто проходясь по всем пикселям внутри квадрата
Я хотел типо нарисовать крестик через 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 + регистр умножить на размер элемента), у меня тоже ничего не работает
Не нужно читать по абсолютным 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.
Ну да, понятно вообщем спасибо, у меня как-то не зарегистрировалось в голове, что абсолютные адреса же ещё будут на каждом запуске разными и непредопределёнными (несмотря на то, что, запуская код в дебаггере, видел, что адреса каждый раз разные)
>сначала помещаешь его адрес в регистр соответствующим способом (RIP-relative — lea reg, [rel arr]; это отдельный способ адресации, несовместимый с base + index × scale в рамках одной и той же инструкции
Ну да, я догадался сделать так и до того, что оно не будет работать с относительными адресами, поэтому снова вспомнил, что у меня не получалось mov использовать с абсолютными в более простом варианте адресации
Похоже, что на винде нету нормального способа сделать экзешник, который при открытии из эксплорера создаёт гуишное окно, а при запуске из консоли тоже создаёт гуишное окно, но также умеет писать в консоль (из которого он был запущен).
Если делаешь 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 - тоже что-то не то, наверное, нет такого, не знаю.
Не хочется жить
А, ссылкиhttps://play.rust-lang.org/?version=stable&mode=debug&edition=&gist=e спойлерземля тебе пухом, кста а в каком моменте он был во втором сезоне? я просто дропнул сезон с первом серии мне не в катила эта тема с рабами bdebafbfaedacaadだ。.
Если ты прочитал вектор по адресу 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.
Я не могу, я пытался что-то начинать делать, но мне слишком паршиво, постоянно какая-то тяжесть в груди и я тупой, всё из рук валится, и зачем уже так жить, нету никакого смысла жить, если ты тупой, всратый и не свалилось на голову никаких богатств, я уже устал ждать смерти
Я почти допил эрл грей, который на вкус и запах так и остался для меня омерзительным. Я теперь ещё меньше верю в то, что можно так насильно изменить свои вкусовые предпочтения.
Теперь попробовал это:
>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. Но я тут и не рассчитывал ни на что с самого начала.
Короче, беспроводные устройства - это похоже просто очередной гиммик
Теперь попробовал это:
>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 тоже сохранение файла
иди нахуй
https://www.shadertoy.com/view/Ws3GRs
Как я понял, на чёрных клетках рисуешь рандомные вертикальные, на белых - рандомные горизонтальные, потом дорисовываешь недостающие
Как я понял, на чёрных клетках рисуешь рандомные вертикальные, на белых - рандомные горизонтальные, потом дорисовываешь недостающие
Спасибо, очень круто
Как я понял, это так ни в какой стандарт и не приняли
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 - это похоже кложуры в си?) И ему придётся повторять путь существующих или существовавших компиляторов (когда весь код перепишут на раст и си и плюсы будут не нужны), чтобы что?
Мыльный пэрри кринж мпч
Я так до сих пор и не прошёл элдер ринг ни разу из-за своей шизы с удалением сейвов. Айзека, кстати, только относительно недавно прошёл спустя почти 3 года после выхода репы, и первый раз все ачивки закрыты с 2014. Там как будто новое обновление будет когда-то, а у меня закрытого сейва своего уже нету, ну тут не по моей вине, его каким-то образом скорраптила стим помойка
Я так до сих пор и не прошёл элдер ринг ни разу из-за своей шизы с удалением сейвов. Айзека, кстати, только относительно недавно прошёл спустя почти 3 года после выхода репы, и первый раз все ачивки закрыты с 2014. Там как будто новое обновление будет когда-то, а у меня закрытого сейва своего уже нету, ну тут не по моей вине, его каким-то образом скорраптила стим помойка
Нет, вот куки кликер
Днём пробовал ходить ногами немного больше 20 километров, короче, это просто дикое уныние и бессмысленная трата времени и я теперь хочу умереть только ещё сильнее
Днём пробовал ходить ногами немного больше 20 километров, короче, это просто дикое уныние и бессмысленная трата времени и я теперь хочу умереть только ещё сильнее
У ножей слишком большая задержка перед окном парирования, нужно прямо совсем заранее прожимать, неудобно и тяжело. У другого оружия, кроме щитов, всё ещё хуже: задержка такая же, а окно в два раза меньше
Почему-то периодически, когда прожимаю скилл на быстрые выстрелы, то либо скилл не срабатывает, либо он вообще не стреляет как будто, особенно в режиме прицеливания. Буквально проблемы с навыком
Тот, у которого шипастые шары на палке, не парируется, к сожалению, нельзя его сбить и по-нормальному убить. Все боссы на конях - мусор, да вообще все боссы пока что мусор унылый. Особенно дебильная птица с миллионом хп сверху, которая ещё и ваншотает любым своим ударом
Такая тупость, ему можно спокойно за спину зайти. Ещё у его вот этого выпада двумя руками сразу более-менее простые тайминги, можно парировать. Больше не понимаю, что с ним можно сделать. Ему, наверное, специально так мало хп сделали, чтобы его можно было просто в лоб танковать, но это совсем дебилизм
Ненавижу этих медведей, они тупо в любой момент могут решить дешнуться тебе в лицо и если ты в этот же момент уже замахнулся оружием, то у тебя околонулевые шансы увернуться. И с них даже ничего не падает полезного и денег тоже почти не дают, я не понимаю, зачем их понатыкали на карте везде, просто чтобы закрыть пустое пространство хотя бы немного, видимо
Какая-то читерская катана, он даже в свою дебильную вторую фазу с молниями не успел перейти
Ясно, макаба окончательно разучилась генерировать обложки к видео
Парные боссы - это рнг бред. Это, понятно, что даже не босс по сути, но они будут позже и я, скорее всего, не вывезу их, если не начну прокачивать лвл. Меня с моим хп скоро будет вообще любой бомж ваншотать. Но, с другой стороны, я ненавижу прокачку в играх, какое-то дикое уныние для любителей сидеть и высчитывать, как бы заминмаксить статы
Лучше бы начальный класс полностью определял траекторию прокачки, а прокачка была бы линейной, например, по ходу прогресса тебе бы давали предметы, которые увеличивают статы. По-моему, в секире примерно так и было сделано для прокачки хп и урона, но зато было дебильное дерево прокачки протеза
Парные боссы - это рнг бред. Это, понятно, что даже не босс по сути, но они будут позже и я, скорее всего, не вывезу их, если не начну прокачивать лвл. Меня с моим хп скоро будет вообще любой бомж ваншотать. Но, с другой стороны, я ненавижу прокачку в играх, какое-то дикое уныние для любителей сидеть и высчитывать, как бы заминмаксить статы
Лучше бы начальный класс полностью определял траекторию прокачки, а прокачка была бы линейной, например, по ходу прогресса тебе бы давали предметы, которые увеличивают статы. По-моему, в секире примерно так и было сделано для прокачки хп и урона, но зато было дебильное дерево прокачки протеза
О, это же толпа врагов, рандомно понатыканных в токсичном болоте без какого-либо предполагаемого порядка их убийства. И теперь они будут мне мешать убить нпц фантома
С врагами на конях зачастую бывает так, что вроде бы в нужное время прожал парирование, но оно не сработало как будто из-за того, что ты был не той стороной к врагу повёрнут. Либо всё же действительно в тайминг не попал, не знаю
Это магическое парирование, оказывается, к сожалению, не может столько прожектайлов за один раз отразить. В конце забавно получилось, что они всё же решили скоординироваться и начать меня по очереди бить обычными атаками, а не магией, огнём или аое кринжем
Мне снова каждый день ебут мозг и я хочу умереть
Мне снова каждый день ебут мозг и я хочу умереть
Нахуя продолжать жить, если всё будет только хуже и хуже
Этот вертикальный удар на катане так быстро всех из равновесия выбивает
Я не знаю, зачем ты это делаешь, но я смотрю. Выглядит как танец. Сам я игры от этой студии не тяну, душно
Самый худший босс пока что: начиная с арены с кучей препятствий, которые мешаются под ногами, заканчивая тупыми атаками, которые непонятно как доджить, кроме как делать паник роллы в надежде, что тебя не заденет один из десятка ваншотающих прожектайлов
Как же мощно амдшный хардварный ав1 энкодер периодически не вывозит: просто в рандомные моменты начинает лагать, причём это с speed пресетом
Как же мощно амдшный хардварный ав1 энкодер периодически не вывозит: просто в рандомные моменты начинает лагать, причём это с speed пресетом
Эту атаку в конце просто не мог задоджить ни разу, слишком анскилл, абсолютно не могу увидеть, нужно ли мне перекатиться в сторону от огня или нет, и оно вроде в рандомных направлениях стреляет
Компилятор не смог осилить свэг чата джипити
Я два дня не могу сесть и доделать это, там нужно сделать ещё хотя бы объединение чанков с соседними при освобождении и отдельные списки свободных чанков для заранее определённых мелких размеров, но я не знаю, мне не хочется, мне хочется нахуй повеситься уже, зачем жить
Я два дня не могу сесть и доделать это, там нужно сделать ещё хотя бы объединение чанков с соседними при освобождении и отдельные списки свободных чанков для заранее определённых мелких размеров, но я не знаю, мне не хочется, мне хочется нахуй повеситься уже, зачем жить
Хочется повеситься от такого гейминга
Моей видеокарте тоже как-то нехорошо стало, почему-то запись ещё сильнее лагать стала
Моей видеокарте тоже как-то нехорошо стало, почему-то запись ещё сильнее лагать стала
>если у меня будет новая видеокарта, то это будет амд
Никогда больше не буду покупать этот мусор
Наверно, спасибо на том, что он своим рыком не ваншотает меня на расстоянии, а всего лишь сносит 90% хп, и что этот рык можно заблокировать щитом
H.265 тоже точно так же в рандомные моменты начинает лагать, непонятно, в среднем меньше, чем ав1, или так же. А амдшный H.264 вообще выдаёт слишком мусорное качество, чтобы им можно было пользоваться. Я не знаю, может быть, она перегревается, но почему тогда перегревается только энкодер, а всей остальной видеокарте нормально
Может быть, она просто уже подыхает, потому что вроде же недавно эта проблема не была так сильно выражена, ну, реже случалось. Либо ничего не изменилось и мне просто сейчас не повезло, что это произошло в неудачный момент, не знаю, короче. Мне просто от любой такой даже мелкой вещи сейчас хочется умереть только ещё сильнее, завтра ещё что-нибудь случится, ну типо чай пролью, и, наверное, повешусь нахуй блять
H.265 тоже точно так же в рандомные моменты начинает лагать, непонятно, в среднем меньше, чем ав1, или так же. А амдшный H.264 вообще выдаёт слишком мусорное качество, чтобы им можно было пользоваться. Я не знаю, может быть, она перегревается, но почему тогда перегревается только энкодер, а всей остальной видеокарте нормально
Может быть, она просто уже подыхает, потому что вроде же недавно эта проблема не была так сильно выражена, ну, реже случалось. Либо ничего не изменилось и мне просто сейчас не повезло, что это произошло в неудачный момент, не знаю, короче. Мне просто от любой такой даже мелкой вещи сейчас хочется умереть только ещё сильнее, завтра ещё что-нибудь случится, ну типо чай пролью, и, наверное, повешусь нахуй блять
А, так можно было что ли. Даже не знаю, что хуже: играть за мага или подобные крысиные страты
Это реальность или элдер ринг? Из него крафтится что-нибудь полезное? Или это просто закуска? Хочу жить в лесу и питаться жуками и болотной тиной, а потом ближе к зиме умереть от голода и холода
Могли бы хотя бы сделать так, что в конце, после убийства всех мелких драконов вокруг, можно было бы подойти к большому и отрубить ему голову или внутренность какую-нибудь вырезать и вырвать, но нет, он просто испаряется, уныние, какой тогда смысл его вообще убивать "правильным" способом
Ещё один неоправданно жирный моб с миллионом хп и пойза, с которого не падает ничего уникального
Не могу найти нормальную одежду, в этой игре вся одежда какая-то уродская
Я так и не понял, почему он сдыхает после того, как впустить его в академию, он изучал какие-то не те кристаллы или что. Я, короче, не буду больше в это играть, наверное, так много сейчас. Я вроде бы прошёл всё, что мог, до перехода в мидгеймовые локации на севере, кроме ренналы и радана. Но проблема в том, что их прохождение - это, скорее всего, будет очень много депрессии на миллион траев из-за того, что у меня ноль хп на базовом лвле бандита. И я не уверен, что я готов к такому геймингу и не повешусь ли я от него случайно. А лвл тут качать уже не хочется, потому что как будто тогда неинтересно уже будет. И как будто пока что всё было более-менее терпимо даже так, но, скорее всего, мидгейм меня точно сломает, если я до него доберусь, я слишком анскилл для подобного
Я решил немного попробовать его и в итоге случайно убил его, и это, естественно, оказался самый идиотский трай, где я по-дебильному получил по лицу и где я тупо его блидом затыкал, а он даже не успел свои метеориты в меня запустить, нахуя я вообще, блять всё ещё живу, я не могу даже нормально играть в ебаную игру сука блять блять вообще никаких ничего зачем жить
Очень сильно хочется уже умереть, ничего хорошего не было и не будет и я буквально не могу ничего сделать, чтобы была нормальная жизнь, в любом случае, что бы я ни делал, я буду всегда страдать и всегда будет плохо и нету смысла никакого жить, просто полная безнадёжность примерно как в аду
Тебе сколько, ОП? Сам живу в таком же состоянии, ни жив ни мёртв.
А, эти двое, оказывается уже сдохли просто автоматом, типичный дарк солс момент: сделал что-то не в том порядке и заруинил квест
Бить его по голове в основном. Во время того, как он кастует облака смерти, есть возможность в прыжке ударить. Когда он просто идёт на тебя, то пытаться стоять напротив него немного поодаль, чтобы успевать выкатываться из аое, и ждать опенинги, чтобы 1-2 раза ударить по голове.
Опенинги обычно бывают после того, как он две каких-то атаки сделал: два раза укусил, махнул лапой и ударил в землю, укусил и махнул лапой и тд, но во второй фазе это не всегда работает: у него появляются более длинные комбо. Перекатываться от его атак назад, два раза подряд, но, если видишь, что случайно сблизился с ним, то наоборот: вперёд под него, потому что иначе не успеваешь выкатиться из-под аое
В остальных случаях просто доджить все остальные атаки и ждать, из-за чего всё растягивается на минуты 4. Можно пытаться бегать у него под ногами и бить по ним, но он постоянно будет на тебя вешать электрический заряд, из-за чего не получится даже два раза нормально ударить подряд, будешь как мышь туда-сюда бегать, тяжело, хоть и будет быстрее, я думаю
Круговая атака во второй фазе доджится перекатом влево вроде довольно стабильно. Сквозь волны на земле можно перекатываться.
Текстовый туториал на босса, потому что ну правда неочевидно, что с ним делать, особенно, когда он почти всеми своими атаками меня ваншотит
Опенинги обычно бывают после того, как он две каких-то атаки сделал: два раза укусил, махнул лапой и ударил в землю, укусил и махнул лапой и тд, но во второй фазе это не всегда работает: у него появляются более длинные комбо. Перекатываться от его атак назад, два раза подряд, но, если видишь, что случайно сблизился с ним, то наоборот: вперёд под него, потому что иначе не успеваешь выкатиться из-под аое
В остальных случаях просто доджить все остальные атаки и ждать, из-за чего всё растягивается на минуты 4. Можно пытаться бегать у него под ногами и бить по ним, но он постоянно будет на тебя вешать электрический заряд, из-за чего не получится даже два раза нормально ударить подряд, будешь как мышь туда-сюда бегать, тяжело, хоть и будет быстрее, я думаю
Круговая атака во второй фазе доджится перекатом влево вроде довольно стабильно. Сквозь волны на земле можно перекатываться.
Текстовый туториал на босса, потому что ну правда неочевидно, что с ним делать, особенно, когда он почти всеми своими атаками меня ваншотит
Ладно, она легко проходится на моём низком лвле и даже без оверлвл оружия, просто это долго
Короче, я увидел видрил 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) и подумал, что, может быть, эта идея сработала бы для квайна: сделать таблицу используемых символов в программе, а сам текст программы закодировать как последовательность индексов из этой таблицы. И я заодно ещё попробовал эту свою идею:
>делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы
Получился пикрил 2 он просто печатает сам себя если что https://godbolt.org/z/odWGK7K13 и даже, после некоторых мучений в попытках скукожить код "23 умножить на 3" вместо 69 - это попытка скукожить, а не раздуть, потому что это сокращает таблицу символов, случайно получился ровный прямоугольник.
Индексы, идущие в таблицу символов (переменная t), записал в строку (переменная s) через печатаемые аски символы, получается, тут есть оверхед в записи кода программы из-за того, что индексы 6-битные, но каждый записан символом, который кодирует 8 бит, и я не знаю, как можно эффективно в код впихнуть последовательность 6-битных чисел. То есть я тупой еблан и буквально ничего не выигрываю этим и только раздуваю код необходимостью хранить таблицу.
>делать кастомный принтф, который по ходу вывода в консоль считает символы в строке и в нужные моменты сам делает перенос, без необходимости добавлять в сам литерал индикаторы того, где нужно делать переносы
Получился пикрил 2 он просто печатает сам себя если что https://godbolt.org/z/odWGK7K13 и даже, после некоторых мучений в попытках скукожить код "23 умножить на 3" вместо 69 - это попытка скукожить, а не раздуть, потому что это сокращает таблицу символов, случайно получился ровный прямоугольник.
Индексы, идущие в таблицу символов (переменная t), записал в строку (переменная s) через печатаемые аски символы, получается, тут есть оверхед в записи кода программы из-за того, что индексы 6-битные, но каждый записан символом, который кодирует 8 бит, и я не знаю, как можно эффективно в код впихнуть последовательность 6-битных чисел. То есть я тупой еблан и буквально ничего не выигрываю этим и только раздуваю код необходимостью хранить таблицу.
Эта шиза снова прогрессирует, добавил в типо контекст в дополнение к основному аллокатору дополнительный для всякого временного мусора, который бы не замусоривал основной и который можно было бы периодически чистить полностью. И проблема в том, что это именно должен быть отдельный второй аллокатор, потому что иногда функция может одновременно захотеть и выделить что-то с долгим лайфтаймом, и выделить что-то для использования чисто внутри неё самой (например, utf-16 строку, чтобы передать в виндовое апи). Из-за чего приходится раздваивать некоторые функции на обычную версию, которая создаёт что-то, используя основной аллокатор, и "временную", которая использует временный аллокатор и не мусорит в основной. Переделал динамические массивы на отдельные функции вместо макросов, которые инлайнят реализации функций на месте. Не знаю, зачем, потому что теперь невозможно использовать sizeof, чтобы узнать размер элемента, и нельзя пушить литералы, потому что тут, оказывается, нельзя брать указатели на rvalue, которые являются литералами? В итоге бред какой-то получается и сам массив какой-то жирный теперь. В итоге не уверен, что мне это всё нравится, но, неважно, я слишком тупой в любом случае ничего неважно
Я думал ещё про то, хочу ли я какие-нибудь шизоидные проверки на переполнение интов, когда выделяю память, но первая проблема в том, что это скользкая дорожка к тому, чтобы делать бесполезные проверки вообще любой степени шизовости вообще везде, а вторая - а какой вообще реалистичный сценарий того, что кто-то захочет выделить что-то вроде, например, 20000 элементов каждый из которых размером 1000 терабайтов? Или даже что-то отдалённо близкое к этому, где не было бы переполнения при перемножении. Если это происходит при чтении какого-то пользовательского ввода, например, читаешь в память битмаповый шрифт из файла и типо, допустим, там прописано, что размер какого-то глифа = миллиард миллиардов пикселей, то все эти проверки, наверное, должны быть именно там, где ты парсишь этот файл, и там у этих проверок к тому же есть шанс быть более разумными. Например, сделать лимит на размер одного глифа условно 100x100 пикселей. Если это какой-то алгоритм, которому нужна дополнительная память, то он вряд ли сразу захочет так много памяти выделить, скорее постепенно будет съедать больше и больше, и более вероятно отвалится на моменте, когда попытается выделить даже пару десятков гигабайт, гораздо раньше, чем там что-то переполнится. Короче, наверное, в этом нет смысла.
Кстати, вроде можно было бы немного сократить строку, если заменить в ней длинные числа из массива с шрифтом (переменная 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, например, выглядит красивее или нет, не знаю
Не хочется в это играть, там с самого начала первая локация - какой-то очередной гигантский пустырь и непонятно куда идти, мне гораздо больше нравился коридорный левел дизайн дарк солсов, где чётко понятно, куда идти, а бегать по пустырям и выискивать данжи, мини боссов и нпс мне приносит только уныние. И первый встретившийся мини босс - дракон скелет с душными атаками, которые нельзя задоджить, пока ты сидишь на коне, но если слезешь с коня, то он может поймать тебя своей аое, от которой не убежишь на ногах. Вместо того, чтобы сделать хотя бы один нормальный файт с драконом в этой игре, они похоже решили наоборот сделать самый худший из всех. В итоге забил в тот же день, что длц вышло.
Да и в основную игру не хочется играть, короче, я никогда не пройду эту игру. Играть на сейве, где у меня базовый RL5 бандит, стало слишком депрессивно: боссы начали слишком часто ваншотать, нужно прямо очень осторожно играть и бить только в безопасные окна, а это не очень весело. Играть в основную игру на сейве, где я по-быстрому добирался до длц, тоже не хочется, я там уже слишком оверлвл для основной игры, ну, можно перераспределить статы во что-то бесполезное, но уже нету настроения.
Короче, в итоге я забил на игру и, раз уж у меня есть стим версия игры, решил побегать немного в пвп на RL1+0 и это было довольно забавно: вторгаться в начальных локациях и мешать людям играть в коопе, в худшем случае людям, которые полчаса назад игру в первый раз запустили и даже играть толком не умеют, короче, как раз уровень моего скилла. Веселее всего офк убивать людей, прикрываясь за спинами толпы мобов или за наземным боссом. Но особо нет ощущения, что ты серьёзно руинишь кому-то игру, они по сути теряют только немного времени и аналог человечности, как в дс1, но тут он имеет нулевую ценность, потому что растёт на земле. Самый максимум неудобств, что можно принести, это вторгнуться около полудохлого дракона с гигантским хп баром, к которому некоторые люди приходят в начале игры, чтобы получить много рун забесплатно, и по-быстрому убить хоста, обнулив его прогресс по убийству дракона. Или когда вторгаешься посреди того, как кто-то кому-то передаёт предметы, и крадёшь их с пола, но это редко случается и мне ни разу не везло подобрать что-то интересное: только консервы и какие-то мусорные талисманы.
Проблема в том, что, оказывается, чуть ли не половина людей, играющих в коопе, играют вместе с высокоуровневыми фантомами, призванными по паролю. По всей видимости, это челы, которые уже прошли игру, играют с друзьями, которые только начали играть, не знаю. И, хоть вроде как их дамаг по мне скейлится вниз, я слишком анскилл, чтобы доджить их спам какими-то непонятными вепон артами и заклинаниями, которые в первый раз вижу, и продираться через их пойз и гигантскую полоску здоровья. Иногда получается их убить или быстро прикончить хоста, но зачастую нет.
Не знаю, могу ли я сам получить доступ хотя бы к каким-нибудь опшным оружиям или вепон артам, чтобы ещё более эффективно убивать людей, запустивших игру в первый раз. По-честному это придётся играть пве на RL1+0, а это раз в 10 сложнее обычного RL1. Ну, в начале убить годрика, чтобы получить реюзабельный палец для вторжений, было не очень сложно, а вот даже файт с раданом уже занял три с половиной минуты душения меня, и дальше только хуже. Чем дольше файт, тем более вероятно, что ты ошибёшься и тебя ваншотнут, либо ошибёшься достаточно раз, что у тебя закончатся фляги с хп.
А кооп в игре прямо дико унылый, даже вдвоём боссы по кд выбиваются из равновесия и в целом просто уничтожаются. В коопе весело, наверное, только стоять где-нибудь, ждать вторжений и втроём ганкать красных фантомов, особенно, если призвать кого-нибудь высоколвльного по паролю. А в пве играть с какими-то рандомами - не знаю.
Но, на самом деле, спам морозным твинблейдом или что угодно подобное не работает, если даже два человека попадаются, которые играют оборонительно, доджат мои атаки без попыток их наказывать, и периодически с двух сторон подходят, бьют почти одновременно по одному разу, отбегают, и так снова и снова. Даже необязательно чем-то тяжёлым, а просто прямыми мечами, в этой игре как будто не существует пойза. Пытаешься подбежать к одному - он убегает, а второй нападает со спины, и наоборот. В таком случае я не знаю, что этому противопоставить + я слишком анскилл, чтобы такое доджить достаточно долго, ну и в целом анскилл. Ну или, если один человек что-то кастует нон-стоп, а другой его защищает и атакует меня, но тут хотя бы бывают окна, когда у мага фп заканчиваются и тогда он становится беззащитным на несколько секунд.
В общем, если вторгаться где-нибудь подальше от начальных локаций, где конкретно сейчас много людей, которые в первый раз запустили игру из-за хайпа по длц, то меня самого зачастую начинают довольно эффективно давить как таракана, которым я и являюсь. И я перепробовал много разного оружия: когда меня убивали чем-то, то пробовал его сам использовать, и ничего не менялось, когда встречались люди, немного умеющие играть. А всякое дно вроде меня можно чем угодно забить.
В общем, если вторгаться где-нибудь подальше от начальных локаций, где конкретно сейчас много людей, которые в первый раз запустили игру из-за хайпа по длц, то меня самого зачастую начинают довольно эффективно давить как таракана, которым я и являюсь. И я перепробовал много разного оружия: когда меня убивали чем-то, то пробовал его сам использовать, и ничего не менялось, когда встречались люди, немного умеющие играть. А всякое дно вроде меня можно чем угодно забить.
Ну и чего ты ноешь? Не нравицца - не играй, если анскилл в 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∗, я не вывезу и запутаюсь.
В конце немного про отражения, выраженные через кватернионы. Я не задумывался о том, что два последовательных отражения - это поворот (или задумывался, я забыл), но с формулами отражения/поворота через кватернионы это легко выводится. Это всё немного перекликается с той статьёй про роторы, только там вроде наоборот: сначала шли отражения, а потом повороты через них выражались. Ну и формулы выглядят там визуально похоже.
Попытался сделать свою функцию для парсинга (сингловых) флоатов из строки, но получилось какое-то длинное шизоидное тормознутое полотно https://godbolt.org/z/1YKzf87sY
Основная идея в том, чтобы распаковать флоат в бинарное число с фиксированной точкой с гигантской точностью, чтобы в него уместился любой флоат без потери точности, а потом скопировать биты после первой старшей единицы в мантиссу + посчитать экспоненту так, чтобы она сдвигала точку в нужное место. Примерно то же самое, что описывал тот чел https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 для обратной операции (перевод из флоата в строку с десятичной дробью), но нет заморочек с тем, чтобы вывести самое короткое представление в десятичном виде, потому что тут результат фиксированного размера.
Проблема в том, что десятичную дробь в бинарную не всегда можно записать конечным количеством цифр, поэтому придётся округлять. Я сделал вроде примерно, как в той статье рассказывалось: что беру дополнительно два следующих бита (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 для обратной операции (перевод из флоата в строку с десятичной дробью), но нет заморочек с тем, чтобы вывести самое короткое представление в десятичном виде, потому что тут результат фиксированного размера.
Проблема в том, что десятичную дробь в бинарную не всегда можно записать конечным количеством цифр, поэтому придётся округлять. Я сделал вроде примерно, как в той статье рассказывалось: что беру дополнительно два следующих бита (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, ффмпег запускается примерно такой командой:
> 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://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 Там в начале описывается медленный алгоритм, как преобразовывать флоаты в строку, а потом показывается, как его можно ускорить, но я дальше не читал. Основная идея медленного алгоритма в том, что берём флоат, а также два числа, которые находятся посередине между входным флоатом и предыдущим и следующим флоатами. Преобразовываем все три числа в десятичную форму с максимальной точностью и отбрасываем у них десятичные цифры в мантиссах до тех пор, пока не выполнятся какие-то там магические условия выхода из цикла.
Перед преобразованием в десятичную форму смещаем бинарную экспоненту так, чтобы бинарная мантисса стала интом, дальше работаем только с интами. После, хотим в этом уравнении:
> 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 строк какой-то кринжовой хуеты, лишь бы как-то работало, по-любому там где-то есть ошибка. Не складываются слова в предложения, потому что я нахуй хочу умереть
Изначально я хотел сделать алгоритм 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 строк какой-то кринжовой хуеты, лишь бы как-то работало, по-любому там где-то есть ошибка. Не складываются слова в предложения, потому что я нахуй хочу умереть
Твой конфиг для Neovim выглядит неплохо. Плагины, которые ты используешь, действительно полезны. Однако, если ты чувствуешь, что твой конфиг слишком сложный, ты можешь попробовать использовать более минималистичный подход. Это может помочь тебе сосредоточиться на написании кода, а не на настройке редактора
>помочь тебе сосредоточиться на написании кода, а не на настройке редактора
а зачем?
Я хотел типа выделить память так, чтобы адрес был выровнен на 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 вернул, поэтому, видимо, можно даже виртуальные адреса ненужные обратно отдать? Я не проверял ничего из этого
>перебирать выровненные адреса
Можно перебирать диапазоны адресов функцией 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), но, э-э, см. числа.
Запретный сковородочный маслянистый полусырой хлеб
У меня в голове крутится шизоидная идея проги, которая берёт репозиторий с кодом и конвертирует его в картинку, на которой содержимое всех файлов выводится текстом с мелким пиксельным шрифтом, текст каждого файла пишется внутри отдельного прямоугольника вместе с названием файла и, возможно, другими метаданными. Может быть, даже конвертирует в гифку и в прямоугольниках с текстами файлов содержимое скроллится, а не сразу целиком выводится, чтобы удобнее было читать и потому что просмоторщикам картинок может стать плохо от картинок большого размера (в ширину и высоту). А также нужно, чтобы была возможность в обратную сторону прокрутить - из такой картинки воссоздать всю структуру папок и файлов и их содержимое. Короче, такой формат для архивирования репозитория в один файл, но при этом визуально читаемый.
Также можно добавить возможность делать патчи и точно так же их запаковывать в картинки, чтобы можно было запостить, например, на имиджборду, картинку с начальным состоянием репозитория, а потом самому себе реплаить по цепочке картинками-патчами с изменениями. Не знаю, как быть с мердж реквестами. Отдельную ветку в чужом картиночном репозитории создать легко, просто начинаешь сам реплаить по цепочке на какой-нибудь пост оригинального автора, но как потом объединить две параллельные цепочки: свою и авторскую - непонятно. Самый простой вариант, наверное, это чтобы автор для слияния вместо очередного патча запостил бы полноценный снапшот репозитория, в котором аккумулированы все авторские патчи и все патчи из мердж реквестовой ветки с вручную разрешёнными возможными конфликтами. Либо другой вариант, автор может вручную перепостить все твои картинки себе в цепочку, типа такой ребейз, не надо постить полноценный снапшот репозитория целиком, но это как-то муторно
У меня в голове крутится шизоидная идея проги, которая берёт репозиторий с кодом и конвертирует его в картинку, на которой содержимое всех файлов выводится текстом с мелким пиксельным шрифтом, текст каждого файла пишется внутри отдельного прямоугольника вместе с названием файла и, возможно, другими метаданными. Может быть, даже конвертирует в гифку и в прямоугольниках с текстами файлов содержимое скроллится, а не сразу целиком выводится, чтобы удобнее было читать и потому что просмоторщикам картинок может стать плохо от картинок большого размера (в ширину и высоту). А также нужно, чтобы была возможность в обратную сторону прокрутить - из такой картинки воссоздать всю структуру папок и файлов и их содержимое. Короче, такой формат для архивирования репозитория в один файл, но при этом визуально читаемый.
Также можно добавить возможность делать патчи и точно так же их запаковывать в картинки, чтобы можно было запостить, например, на имиджборду, картинку с начальным состоянием репозитория, а потом самому себе реплаить по цепочке картинками-патчами с изменениями. Не знаю, как быть с мердж реквестами. Отдельную ветку в чужом картиночном репозитории создать легко, просто начинаешь сам реплаить по цепочке на какой-нибудь пост оригинального автора, но как потом объединить две параллельные цепочки: свою и авторскую - непонятно. Самый простой вариант, наверное, это чтобы автор для слияния вместо очередного патча запостил бы полноценный снапшот репозитория, в котором аккумулированы все авторские патчи и все патчи из мердж реквестовой ветки с вручную разрешёнными возможными конфликтами. Либо другой вариант, автор может вручную перепостить все твои картинки себе в цепочку, типа такой ребейз, не надо постить полноценный снапшот репозитория целиком, но это как-то муторно
Нашёл такой сайт с объяснением, как читать сишные объявления http://unixwiz.net/techtips/reading-cdecl.html. Я до сих пор очень плохо понимал, как это делать, если честно.
Возьмём объявление переменной, идея в том, что у неё есть один "базовый" тип и к нему по очереди, наслаиваясь друг на друга, применяются типа "операторы", которые модифицируют его. Конкретно это:
- оператор "указатель на ..." (записывается звёздочкой)
- оператор "массив из ..." (записывается парой квадратных скобок с размерностью внутри)
- оператор "функция, возвращающая ..." (записывается парой круглых скобок со списком параметров внутри)
Если бы в си был нормальный синтаксис, то объявление переменной типа "массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на 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' - это не какой-то отдельный эскейп для нуля, как я думал, а восьмеричный код. Ну, понятно, что это не играет роли для нуля, но просто забавно
Возьмём объявление переменной, идея в том, что у неё есть один "базовый" тип и к нему по очереди, наслаиваясь друг на друга, применяются типа "операторы", которые модифицируют его. Конкретно это:
- оператор "указатель на ..." (записывается звёздочкой)
- оператор "массив из ..." (записывается парой квадратных скобок с размерностью внутри)
- оператор "функция, возвращающая ..." (записывается парой круглых скобок со списком параметров внутри)
Если бы в си был нормальный синтаксис, то объявление переменной типа "массив из восьми указателей на функции, которые принимают два инта в качестве параметров и возвращают указатель на 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' - это не какой-то отдельный эскейп для нуля, как я думал, а восьмеричный код. Ну, понятно, что это не играет роли для нуля, но просто забавно
Попробовал сделать оладьи и сгущённое молоко, в первый раз и то, и другое. Я, наверное, передержал его на огне: получилось слишком густым и уже начало карамелизовываться. К тому же соотношение 1:2, сахара к молоку, слишком большое. Если разбавить водой, то на вкус как магазинная сгущёнка, но оно стало слишком жидким. Если не разбавлять, то на вкус как смерть от передоза сахаром.
Оладьи на молоке, просто обычные на вкус. В рецепте зачем-то были сода и лимонная кислота как отдельные ингредиенты, хотя, как я понимаю, вместе это то же самое, что разрыхлитель. Это для какого-то кастомного соотношения соды к лимонной кислоте что ли, ну я попробовал так, вроде тесто поднялось немного. Лимонная кислота у меня была случайно, потому что я пробовал её добавлять в рис, якобы он тогда с большей вероятностью получается рассыпчатым (на деле не помогает).
Я еду никогда в жизни до этого себе не готовил и начал это делать только месяца два назад, но с тех пор не появилось ощущения, что это что-то хотя бы немного важное в жизни. Вообще, если бы существовал просто условный "человеческий корм", безвкусный и спресованный в порционные сухие брикеты, я бы лучше его использовал как основную еду, запивая чаем или кофе
Оладьи на молоке, просто обычные на вкус. В рецепте зачем-то были сода и лимонная кислота как отдельные ингредиенты, хотя, как я понимаю, вместе это то же самое, что разрыхлитель. Это для какого-то кастомного соотношения соды к лимонной кислоте что ли, ну я попробовал так, вроде тесто поднялось немного. Лимонная кислота у меня была случайно, потому что я пробовал её добавлять в рис, якобы он тогда с большей вероятностью получается рассыпчатым (на деле не помогает).
Я еду никогда в жизни до этого себе не готовил и начал это делать только месяца два назад, но с тех пор не появилось ощущения, что это что-то хотя бы немного важное в жизни. Вообще, если бы существовал просто условный "человеческий корм", безвкусный и спресованный в порционные сухие брикеты, я бы лучше его использовал как основную еду, запивая чаем или кофе
Попробовал первый раз купить потрошёную куриную тушку, до этого только филе покупал, потому что у меня слишком брезгливое отношение к костям и в целом к чему угодно несъедобному в еде, и не хотелось заморачиваться с разделкой, но, как оказалось, это легко, просто отрезаешь конечности и отрываешь спину, так что нет никаких объективных причин покупать отдельные части курицы
Попробовал из спины, моркови и луковицы сделать куриный бульон и сварить на нём суп, ну бульон вроде получился на вкус как куриный бульон. Отделение ошмётков мяса от сваренного куриного остова - это какой-то аутизм, а результат - всего лишь небольшая горка этих самых ошмётков. Подобным, наверное, стоит заниматься только, если у тебя изначально не куриная тушка, а какие-нибудь петушиные шеи, и тогда у тебя выбор: либо сидишь копаешься в костях, либо у тебя нет мяса вообще.
Я зачем-то решил сделать гороховый суп и в итоге это убило какой-либо смысл приготовления бульона перед этим, теперь не понять, сварен горох на бульоне или просто на воде, оно просто на вкус как горох. Больше было бы смысла сварить в нём что-то нейтральное по вкусу вроде лапши. Либо варить на этом бульоне суп из каких-нибудь трав, крапивы, лебеды, щавеля, и в идеале кость на бульон у бродячей собаки отобрать, чтобы все ингредиенты были околобесплатными
Попробовал из спины, моркови и луковицы сделать куриный бульон и сварить на нём суп, ну бульон вроде получился на вкус как куриный бульон. Отделение ошмётков мяса от сваренного куриного остова - это какой-то аутизм, а результат - всего лишь небольшая горка этих самых ошмётков. Подобным, наверное, стоит заниматься только, если у тебя изначально не куриная тушка, а какие-нибудь петушиные шеи, и тогда у тебя выбор: либо сидишь копаешься в костях, либо у тебя нет мяса вообще.
Я зачем-то решил сделать гороховый суп и в итоге это убило какой-либо смысл приготовления бульона перед этим, теперь не понять, сварен горох на бульоне или просто на воде, оно просто на вкус как горох. Больше было бы смысла сварить в нём что-то нейтральное по вкусу вроде лапши. Либо варить на этом бульоне суп из каких-нибудь трав, крапивы, лебеды, щавеля, и в идеале кость на бульон у бродячей собаки отобрать, чтобы все ингредиенты были околобесплатными
Увидел это видео https://youtu.be/QAja2jp1VjE, подумал попробовать сделать вариант с треугольниками, который в конце, но не уверен, что получилось: https://www.shadertoy.com/view/Mf3BzN. Как будто временами действительно видны паттерны из треугольников, шестиугольников, а как будто и нет, не знаю, что я не так сделал, оно не так, как на видео у него выглядит
Подумал, что раз мне не хочется ничего делать, то, может быть, почитать что-нибудь. Взял какую-то practical linear algebra: a geometry toolbox, почитал только первые две главы, ну там ничего особо интересного не было пока что, и мне, короче, расхотелось дальше читать, в основном потому же, почему в целом ничего не хочется делать, и совсем немного отчасти из-за того, как там подаётся информация. Там вбрасываются всякие термины и теоремы из линейной алгебры и рассматриваются только на примере 2д и 3д евклидовых пространств, не даётся обобщённых определений и доказательств. Этого можно было ожидать от книжки с таким названием, к тому же в предисловии явно написано, что это так специально, но не знаю
У меня ощущение, что внутри что-то окончательно переломилось и я теперь уже совсем больше ничего не могу делать, и я не знаю, как это исправить. Скорее всего, никак, у меня в жизни в целом никогда не было так, что мои осознанные действия приводили бы к каким-либо улучшениям, со временем в среднем просто всё становится хуже и хуже. Я бы хотел уже подохнуть, чтобы это прекратилось, потому что это путь в никуда, беспомощность, безысходность
У меня ощущение, что внутри что-то окончательно переломилось и я теперь уже совсем больше ничего не могу делать, и я не знаю, как это исправить. Скорее всего, никак, у меня в жизни в целом никогда не было так, что мои осознанные действия приводили бы к каким-либо улучшениям, со временем в среднем просто всё становится хуже и хуже. Я бы хотел уже подохнуть, чтобы это прекратилось, потому что это путь в никуда, беспомощность, безысходность
Иногда я задумываюсь https://godbolt.org/z/eeYTz1bzd
Я тупой долбоёб и хочу умереть https://godbolt.org/z/f6evhMsoP
Туториал, как раздуть объём исходного кода в два раза, не изменив функционально абсолютно ничего:
https://godbolt.org/z/KnKWhMvoz
Единственное, наверное, только, сделал поддержку паддинга для кастомных форматтеров, потому что внезапно понял, что могу им подсовывать реализацию writerа, которая ничего никуда не пишет, а просто символы считает. Это, чтобы понять, сколько нужно паддинговых символов добавить слева и справа. И, раз теперь паддинг поддерживается всеми форматируемыми значениями, то паддинговые параметры можно было бы сделать общими для всех видов значений и немного упростить код, но их там не получится вытащить на уровень вверх из структур внутри юниона, потому что тогда сломаются шизомакросы, имитирующие именованные аргументы функции. Поэтому сделал просто, чтобы все структуры в юнионе начинались с этих общих параметров, чтобы их можно было доставать, не обращая внимание на реальное содержимое юниона. И, я так понял, что это внезапно даже не будет УБ: https://stackoverflow.com/a/20752261. Типа исключение из всех этих дебильных правил сделали, из-за которых, например, чисто формально через юнион нельзя даже взять флоат и проинтерпретировать его как uint32_t, потому что типа в юнионе хранится именно флоат, а не что-то другое.
Ну и там ещё по мелочи возможность автослива после переносов строк, отделённый слой ОС и поддержка линукс-помойки, правда, через <unistd.h>, то есть она всё равно завязана на сишную библиотеку, но тут похоже иначе никак, дальше только свои врапперы для системных вызовов писать на асемблере https://gist.github.com/tcoppex/443d1dd45f873d96260195d6431b0989.
И новый виток шизы с абстрагированными аллокаторами, чтобы через них writerы создавать, ну потому что, когда начинается полиморфизм, то часто вылезает необходимость выделить объект динамически. Но на стеке тоже можно создать, причём за один стейтмент, без того, чтобы в отдельных переменных создавать буфер и структуру с данными writerа, потому что, как оказалось, в си у компаунд литералов которые "(Struct) {...}" или "(Type[]) {...}" лайфтайм растянут на весь внешний скоуп, то есть можно на них сразу брать указатели и они не протухнут в следующем же стейтменте. https//x.com/mono_morphic/status/1869303586502397994
Была ещё мысль на тему шизомакросов, которые имитируют variadic функции: вместо того, чтобы вычислять размер массива с аргументами через sizeof, сделать его терминированным специальным значением. Просто, если через sizeof делать, то препроцессор, получается, в код дважды вставляет массив, и у меня такое ощущение, что именно из-за вот таких шизомакросов, которые превращаются в кучу кода, у меня clangd периодически тупо отваливается. Плюс некоторым компиляторам становится плохо от пустых массивов-компаунд-литералов, а так эта проблема бы автоматически решилась. Но там, короче, не получится нормально сделать, нужен __VA_OPT__, чтобы убирать лишнюю запятую, когда добавляешь значение-терминал к пустому списку аргументов. Можно было бы ещё положить массив в локальную переменную и потом брать sizeof по её названию, но тогда из макроса нельзя будет ничего вернуть, потому что он раскроется в больше, чем один стейтмент. Вот тут реально была бы полезна фича с возвратом значения из блока кода, как в расте.
Ну, короче, охуеть спасибо за 2к строк говнокода, которые не делают примерно ничего, даже не могут распечатать флоат в консоль, уёбище, блять. А ещё эта срань, оказывается, всё же крашит msvcшный компилятор, если попытаться вывести просто формат строку без аргументов. Ему вроде становится плохо из-за пустого массива в виде компаунд литерала, но как будто оно до этого работало даже с пустыми массивами, просто warning был в одном месте, я как-то пропустил конкретный момент, когда мой код начал ронять компилятор.
Надо, получается, заменить это
(FormatArg[]) {__VA_ARGS__}
на это что ли
(FormatArg[]) {(FormatArg) {}, __VA_ARGS__} + 1
какой же бред, мне лень пересоздавать ссылку на годболт.
Я изначально вообще не это хотел, я снова хотел попробовать написать свой аллокатор, в этот раз дописал до чего-то более осмысленного, чем в прошлый https://godbolt.org/z/5Yq5cjsE4 Типа оно что-то выделяет, как-то освобождает, но я не дописал в итоге.
Я всё же почитал чужой код https://github.com/ennorehling/dlmalloc/blob/master/malloc.c, потому что в прошлый раз не додумался, как нормально реализовать некоторые детали, только исходя из написанного здесь https://sourceware.org/glibc/wiki/MallocInternals, ну и, короче, начал писать примерно ровно то же самое.
Конкретно, например, я не додумался до того, чтобы при разделении куска памяти, полученного от ОС, на чанки всегда иметь в конце два маленьких чанка (которые никогда ни для чего не используются), чтобы было безопасно смотреть на два чанка вперёд. Смотреть вперёд нужно при освобождении чанка, чтобы проверить, можно ли объединиться со следующим. А на два вперёд, потому что в хедере чанка хранится не то, является ли он сам занятым или свободным, а то, свободен ли чанк перед ним. А это, в свою очередь, нужно, чтобы проверять, можно ли объединиться с предыдущим чанком. И если всё так организовать, то boundary теги с размером предыдущего чанка можно хранить в самом предыдущем чанке только, когда он свободен, потому что иначе нам не надо в него лезть.
Вот, а я вроде бы изначально в чанках хранил то, являются ли они сами свободными, из-за чего приходилось также хранить размер предыдущего чанка в хедерах, чтобы можно было перейти к хедеру предыдущего чанка и там посмотреть, свободен он или занят. А это в два раза больший оверхед.
В маллоке есть бины - это связные списки из свободных чанков примерно одинакового размера нужные, чтобы быстрее находить best-fit чанк при выделении памяти. Они обязательно должны быть двусвязными, чтобы мы могли удалять из них элементы, имея на руках только лишь указатель на удаляемый элемент. Хаки вроде такого https://en.wikipedia.org/wiki/XOR_linked_list максимум позволяют итерироваться в обе стороны, и то, только начиная с конца или начала списка. Короче, всё же придётся хранить оба указателя отдельно, это понятно.
Но ещё одна проблема в том, что когда удаляешь чанк из бина, то ты не знаешь точно, из какого конкретно бина тебе нужно его убрать. А если ты сами бины хранишь как "указатель на первый и указатель последний элементы", то тебе это знать необходимо, чтобы обновить эти указатели, когда удаляется первый или последний элемент. Можно определить конкретный бин по размеру чанка, но это немного криво получается, потому что есть особый unsorted бин, в котором хранятся чанки каких угодно размеров, и приходится проверять, является ли удаляемый чанк первым/последним как в этом unsorted бине, так и в бине под размер удаляемого чанка.
Более общее решение, до которого я бы не додумался - это хранить в голове связного списка головной dummy элемент, а сам список сделать циклическим. И этот головной элемент сам будет представлять весь список. Изначально пустой список - это головной элемент, зацикленный сам на себя. Если список непустой, то первый элемент - это head->next, а последний - это head->prev. И в таком списке получается, что удаление первого или последнего элементов никак не отличается от удаления элемента из середины списка. Наверное, это какой-то дефолтный трюк, но я его в первый раз только тут увидел.
Конкретно в контексте бинов из dlmalloc тут ещё проблема, что указатели prev/next указывают на хедеры у чанков, а не на то, где начинается payload чанка, где и хранятся указатели prev/next. Из-за чего, выходит, головные элементы в бинах должны хранить в себе бесполезный хедер, чтобы не отличаться от остальных элементов списка. Можно было бы, наверное, сделать, чтобы prev/next всё же ссылались на payload после хедера. В dlmalloc же сделано так, что головные элементы бинов упакованы так, что по сути накладываются друг на друга, чтобы не тратить память на бесполезные хедеры.
Что я ещё хотел посмотреть - это то, как dlmalloc менеджит куски памяти, полученные от ОС, но, короче, никак. Под линуксом он выделяет память из кучи - это один вроде бы непрерывный кусок памяти, который есть у каждого процесса, который можно растягивать или сжимать вызовами sbrk. И dlmalloc просто кладёт один специальный чанк в конец кучи и при необходимости его растягивает, если надо запросить больше памяти у ОС, и откусывает память из его начала, если не нашлось ни одного более подходящего чанка. Проблема в том, что в винде, например, нет аналога sbrk, поэтому его приходится эмулировать через VirtualQuery, но полноценно повторить поведение sbrk не получится, потому что при попытке расширения куска памяти мы можем наткнуться на уже занятый кем-то регион. Ну, хотя, наверное, можно было бы изначально найти адрес, с которого начинается незанятый регион на достаточно много гигабайтов, не знаю, но, в общем, в dlmalloc вместо этого сделано так, что он каждый раз проверяет, действительно ли sbrk возвращает непрерывный кусок памяти, и если нет, то он просто забивает на отслеживание памяти, которую навыделял до этого (в том плане, что он её ещё может переиспользовать, потому что он уже разделил её на чанки, но уже не сможет вернуть обратно системе).
Эта проблема с не-непрерывным sbrk может возникнуть в том числе и на линуксе, если кто-то другой одновременно с dlmalloc трогает sbrk (например, другой аллокатор, который тоже из кучи берёт память), и в том числе может не только расширить кучу, но и сжать её. И куча одна на весь процесс, поэтому в многопоточном сценарии мы не сможем создать по одному инстансу dlmalloc на каждый поток, придётся запихивать один инстанс под мутекс, иначе куча будет постепенно только увеличиваться и увеличиваться (из-за того, что с точки зрения каждого отдельного инстанса, sbrk будет возвращать не-непрерывные адреса). В современном маллоке сделали умнее, там куча всё ещё используется как источник памяти, но также используются mmap-нутые "кучи". В dlmalloc mmap тоже используется, но только, если мы просим у него достаточно большой кусок памяти, он в этом случае выделяет его напрямую через mmap и потом, когда мы возвращаем память обратно, он сразу же его отдаёт системе без попытки переиспользовать.
Не особо понимаю, если честно, всех эвристик, которые используются в маллоке. Это best-fit аллоктор, который как будто в большей мере озабочен уменьшением фрагментации памяти, чем кеш локальностью или скоростью работы. Обычно он пытается eagerly совмещать вместе соседние свободные чанки, исключение - совсем мелкие чанки, которые при особождении помещаются в "фаст" бины, ни с кем не объединяются и потом могут сразу снова пойти в использование. Но фаст бины долго не живут: если следующий запрос на выделение памяти большой, то все чанки из фаст бинов объединяются. Типа расчёт на то, что деаллокации мелких кусков памяти соседствуют с аллокацией таких же мелких кусочков.
Если при аллокации выбор из нескольких чанков одного размера, то берётся LRU, слышал, что это типа тоже для борьбы с фрагментацией: если достаточно долго маринуем чанк в свободном состоянии, то больше вероятность, что соседние с ним тоже освободятся и смогут объединиться с ним.
На тему кеш локальности вроде есть только то, что если нам при аллокации пришлось откусить кусок от чанка, то при следующей аллокации мы возможно попробуем сделать укус от этого же чанка. Иными словами, есть вероятность, что последовательные мелкие аллокации будут соседствовать друг с другом.
Да, короче, блять, похуй, в итоге я даже не дописал до конца, причём, ну, я пытался в этот раз, но я слишком тупой, это не проблема концентрации или лени, я просто умственно отсталое всратое уёбище, мне каждый раз хуёво становится, когда случайно смотрю в зеркало, а потом меня добивает осознание собственной тупости и хочется очень сильно повеситься нахуй. Там единственная неукраденная и хотя бы немного интересная идея - это хранить структуру с состоянием аллокатора внутри обычного чанка, а не выделять её как-то отдельно. Но это типа очевидно, наверное, примерно аналогичная по духу идея, как то, что в том принтф велосипеде репортинг ошибок сделан через сам принтф велосипед. Но там не получилось сделать прямо в полной мере через него, потому что я зачем-то хотел сделать реализацию компилируемой через плюсовый компилятор, а в плюсах нет компаунд литералов, через которые работают все шизомакросы для форматированного вывода.
Я всё же почитал чужой код https://github.com/ennorehling/dlmalloc/blob/master/malloc.c, потому что в прошлый раз не додумался, как нормально реализовать некоторые детали, только исходя из написанного здесь https://sourceware.org/glibc/wiki/MallocInternals, ну и, короче, начал писать примерно ровно то же самое.
Конкретно, например, я не додумался до того, чтобы при разделении куска памяти, полученного от ОС, на чанки всегда иметь в конце два маленьких чанка (которые никогда ни для чего не используются), чтобы было безопасно смотреть на два чанка вперёд. Смотреть вперёд нужно при освобождении чанка, чтобы проверить, можно ли объединиться со следующим. А на два вперёд, потому что в хедере чанка хранится не то, является ли он сам занятым или свободным, а то, свободен ли чанк перед ним. А это, в свою очередь, нужно, чтобы проверять, можно ли объединиться с предыдущим чанком. И если всё так организовать, то boundary теги с размером предыдущего чанка можно хранить в самом предыдущем чанке только, когда он свободен, потому что иначе нам не надо в него лезть.
Вот, а я вроде бы изначально в чанках хранил то, являются ли они сами свободными, из-за чего приходилось также хранить размер предыдущего чанка в хедерах, чтобы можно было перейти к хедеру предыдущего чанка и там посмотреть, свободен он или занят. А это в два раза больший оверхед.
В маллоке есть бины - это связные списки из свободных чанков примерно одинакового размера нужные, чтобы быстрее находить best-fit чанк при выделении памяти. Они обязательно должны быть двусвязными, чтобы мы могли удалять из них элементы, имея на руках только лишь указатель на удаляемый элемент. Хаки вроде такого https://en.wikipedia.org/wiki/XOR_linked_list максимум позволяют итерироваться в обе стороны, и то, только начиная с конца или начала списка. Короче, всё же придётся хранить оба указателя отдельно, это понятно.
Но ещё одна проблема в том, что когда удаляешь чанк из бина, то ты не знаешь точно, из какого конкретно бина тебе нужно его убрать. А если ты сами бины хранишь как "указатель на первый и указатель последний элементы", то тебе это знать необходимо, чтобы обновить эти указатели, когда удаляется первый или последний элемент. Можно определить конкретный бин по размеру чанка, но это немного криво получается, потому что есть особый unsorted бин, в котором хранятся чанки каких угодно размеров, и приходится проверять, является ли удаляемый чанк первым/последним как в этом unsorted бине, так и в бине под размер удаляемого чанка.
Более общее решение, до которого я бы не додумался - это хранить в голове связного списка головной dummy элемент, а сам список сделать циклическим. И этот головной элемент сам будет представлять весь список. Изначально пустой список - это головной элемент, зацикленный сам на себя. Если список непустой, то первый элемент - это head->next, а последний - это head->prev. И в таком списке получается, что удаление первого или последнего элементов никак не отличается от удаления элемента из середины списка. Наверное, это какой-то дефолтный трюк, но я его в первый раз только тут увидел.
Конкретно в контексте бинов из dlmalloc тут ещё проблема, что указатели prev/next указывают на хедеры у чанков, а не на то, где начинается payload чанка, где и хранятся указатели prev/next. Из-за чего, выходит, головные элементы в бинах должны хранить в себе бесполезный хедер, чтобы не отличаться от остальных элементов списка. Можно было бы, наверное, сделать, чтобы prev/next всё же ссылались на payload после хедера. В dlmalloc же сделано так, что головные элементы бинов упакованы так, что по сути накладываются друг на друга, чтобы не тратить память на бесполезные хедеры.
Что я ещё хотел посмотреть - это то, как dlmalloc менеджит куски памяти, полученные от ОС, но, короче, никак. Под линуксом он выделяет память из кучи - это один вроде бы непрерывный кусок памяти, который есть у каждого процесса, который можно растягивать или сжимать вызовами sbrk. И dlmalloc просто кладёт один специальный чанк в конец кучи и при необходимости его растягивает, если надо запросить больше памяти у ОС, и откусывает память из его начала, если не нашлось ни одного более подходящего чанка. Проблема в том, что в винде, например, нет аналога sbrk, поэтому его приходится эмулировать через VirtualQuery, но полноценно повторить поведение sbrk не получится, потому что при попытке расширения куска памяти мы можем наткнуться на уже занятый кем-то регион. Ну, хотя, наверное, можно было бы изначально найти адрес, с которого начинается незанятый регион на достаточно много гигабайтов, не знаю, но, в общем, в dlmalloc вместо этого сделано так, что он каждый раз проверяет, действительно ли sbrk возвращает непрерывный кусок памяти, и если нет, то он просто забивает на отслеживание памяти, которую навыделял до этого (в том плане, что он её ещё может переиспользовать, потому что он уже разделил её на чанки, но уже не сможет вернуть обратно системе).
Эта проблема с не-непрерывным sbrk может возникнуть в том числе и на линуксе, если кто-то другой одновременно с dlmalloc трогает sbrk (например, другой аллокатор, который тоже из кучи берёт память), и в том числе может не только расширить кучу, но и сжать её. И куча одна на весь процесс, поэтому в многопоточном сценарии мы не сможем создать по одному инстансу dlmalloc на каждый поток, придётся запихивать один инстанс под мутекс, иначе куча будет постепенно только увеличиваться и увеличиваться (из-за того, что с точки зрения каждого отдельного инстанса, sbrk будет возвращать не-непрерывные адреса). В современном маллоке сделали умнее, там куча всё ещё используется как источник памяти, но также используются mmap-нутые "кучи". В dlmalloc mmap тоже используется, но только, если мы просим у него достаточно большой кусок памяти, он в этом случае выделяет его напрямую через mmap и потом, когда мы возвращаем память обратно, он сразу же его отдаёт системе без попытки переиспользовать.
Не особо понимаю, если честно, всех эвристик, которые используются в маллоке. Это best-fit аллоктор, который как будто в большей мере озабочен уменьшением фрагментации памяти, чем кеш локальностью или скоростью работы. Обычно он пытается eagerly совмещать вместе соседние свободные чанки, исключение - совсем мелкие чанки, которые при особождении помещаются в "фаст" бины, ни с кем не объединяются и потом могут сразу снова пойти в использование. Но фаст бины долго не живут: если следующий запрос на выделение памяти большой, то все чанки из фаст бинов объединяются. Типа расчёт на то, что деаллокации мелких кусков памяти соседствуют с аллокацией таких же мелких кусочков.
Если при аллокации выбор из нескольких чанков одного размера, то берётся LRU, слышал, что это типа тоже для борьбы с фрагментацией: если достаточно долго маринуем чанк в свободном состоянии, то больше вероятность, что соседние с ним тоже освободятся и смогут объединиться с ним.
На тему кеш локальности вроде есть только то, что если нам при аллокации пришлось откусить кусок от чанка, то при следующей аллокации мы возможно попробуем сделать укус от этого же чанка. Иными словами, есть вероятность, что последовательные мелкие аллокации будут соседствовать друг с другом.
Да, короче, блять, похуй, в итоге я даже не дописал до конца, причём, ну, я пытался в этот раз, но я слишком тупой, это не проблема концентрации или лени, я просто умственно отсталое всратое уёбище, мне каждый раз хуёво становится, когда случайно смотрю в зеркало, а потом меня добивает осознание собственной тупости и хочется очень сильно повеситься нахуй. Там единственная неукраденная и хотя бы немного интересная идея - это хранить структуру с состоянием аллокатора внутри обычного чанка, а не выделять её как-то отдельно. Но это типа очевидно, наверное, примерно аналогичная по духу идея, как то, что в том принтф велосипеде репортинг ошибок сделан через сам принтф велосипед. Но там не получилось сделать прямо в полной мере через него, потому что я зачем-то хотел сделать реализацию компилируемой через плюсовый компилятор, а в плюсах нет компаунд литералов, через которые работают все шизомакросы для форматированного вывода.
Попробовал отрисовать что-то в иксовом окне, примерно так же, как через BitBlt из GDI на винде. Не стал даже пробовать через XPutImage, потому что он каждый раз будет гонять байты отрендеренной картинки через транспортный протокол, поверх которого иксы работают, через юникс сокеты, наверное. Попробовал сделать через расширение MIT-SHM, которое позволяет в общей памяти (для твоего приложения и искового сервера) создать картинку и её отрисовывать в окно.
Не уверен, что нормально написал, скорее всего, нет, потому что у меня вылезали рандомные ошибки при запуске, похожие на какую-то гонку:
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 1 (X_ShmAttach)
Как будто они возникают из-за того, что тайловый оконный менеджер моментально сразу после создания окна и выделения картинки под него снапает окно на своё место в сетке, после чего размер окна меняется, что вызывает пересоздание картинки. Я не знаю, видимо, какие-то вызовы функций из Xlib отправляют асинхронные запросы и получается так, что иксы трогают пошаренную картинку одновременно с тем, как я её пересоздаю. Например, нельзя трогать память картинки сразу после вызова XShmPutImage, нужно дождаться, пока иксы её отрисуют, но я типа учитываю это (рисую в другую картинку, пока только что отправленная на отрисовку недоступна). А может ли подобное происходить с другими функциями, в документации не сказано.
Ошибка вроде исчезает, если изначально при создании окна не создавать под него картинку, или если поменять порядок действий: создание картинок и вывод окна на экран (XMapWindow), но я просто не вижу логики никакой в этих действиях, и не гуглится ничего, кроме советов вообще отключить это расширение. Да и в целом в иксах и этом расширении ничего не понятно, максимально непонятное апи, MIT-SHM прибит гвоздями к какому-то упоротому старому способу создания расшаренной между процессами памяти (shmget/shmctl/shmat/shmdt), может быть, я и его тоже как-то неправильно использую. Может быть, мне стоило использовать XCB - это по сути то же самое, что Xlib (сишное апи, чтобы низкоуровнево говорить с иксовым сервером), но вроде как там что-то что-то он лучше дружит с многопоточностью, но у меня моё приложение-то однопоточное, поэтому не уверен, что это помогло бы, потому что XInitThreads(), кстати, не помогает.
Ещё абсолютно не понял, в чём смысл этих каких-то кнопочных символов, зачем они, если есть кнопочные коды. Типа вроде символы учитывают раскладку клавиатуры, а коды - это физические кнопки на клавиатуре. При обработке событий ты получаешь коды, но для них нет констант как на винде (VK_KEY_UP, например), но есть константы для символов с обычной клавиатуры, поэтому типа надо установить соответствие между константами символов и кодами (через XKeysymToKeycode), чтобы понять, во что мапить коды? Из кода GLFW на эту тему https://github.com/glfw/glfw/blob/master/src/x11_init.c я не понял вообще ничего, сам написал какой-то бред. Я понимаю, что иксы не прошли проверку временем, но я тупо даже в теории не понимаю, зачем оно так запутанно сделано, в чём смысл этих абстракций над кнопками.
Ну типа такого, короче https://gist.github.com/poppyfanboy/8f81ca0fd36f1f4e7e74b069b8ffe5a1 И для винды код немного упростил, который у меня был, я изначально там зачем-то городил свою SPSC очередь, чтобы передавать события от потока, куда они приходят, к потоку, где делается рендер и обрабатываются события. Но как будто можно обработку событий впихнуть туда же, куда они приходят. И ещё не знаю, есть ли смысл на винде тоже делать две битмапы, я не особо понимаю, можно ли трогать память битмапы сразу после вызова BitBlt.
А шум этот - случайно нашёл, какой-то "ромбо-квадратный алгоритм". Он выглядит как фрактальный шум, где независимо друг от друга генерируются несколько октав и накладываются друг на друга, но тут все пиксели генерируются за один проход по каждому из них. Типа идея в том, что пиксели проходятся по сетке, которая со временем становится мельче и мельче. Значения генерируются из усреднения соседних пикселей на сетке + рандом. И чем мельче сетка, тем меньше рандома и больше играет роль интерполяция соседних пикселей, поэтому возникает вот этот эффект с локальной плюс-минус гладкостью, но с наличием более глобальных перепадов высот. Тайлится просто из-за того, как он генерируется: когда около-граничные пиксели генерируем, то семплим пиксели с противоположной стороны, а сами граничные пиксели делаем одинаковыми с противоположных сторон.
https://learn.64bitdragon.com/articles/computer-science/procedural-generation/the-diamond-square-algorithm
И потом на сгенерированный шум наложен сдвиг по палитре.
Не уверен, что нормально написал, скорее всего, нет, потому что у меня вылезали рандомные ошибки при запуске, похожие на какую-то гонку:
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 1 (X_ShmAttach)
Как будто они возникают из-за того, что тайловый оконный менеджер моментально сразу после создания окна и выделения картинки под него снапает окно на своё место в сетке, после чего размер окна меняется, что вызывает пересоздание картинки. Я не знаю, видимо, какие-то вызовы функций из Xlib отправляют асинхронные запросы и получается так, что иксы трогают пошаренную картинку одновременно с тем, как я её пересоздаю. Например, нельзя трогать память картинки сразу после вызова XShmPutImage, нужно дождаться, пока иксы её отрисуют, но я типа учитываю это (рисую в другую картинку, пока только что отправленная на отрисовку недоступна). А может ли подобное происходить с другими функциями, в документации не сказано.
Ошибка вроде исчезает, если изначально при создании окна не создавать под него картинку, или если поменять порядок действий: создание картинок и вывод окна на экран (XMapWindow), но я просто не вижу логики никакой в этих действиях, и не гуглится ничего, кроме советов вообще отключить это расширение. Да и в целом в иксах и этом расширении ничего не понятно, максимально непонятное апи, MIT-SHM прибит гвоздями к какому-то упоротому старому способу создания расшаренной между процессами памяти (shmget/shmctl/shmat/shmdt), может быть, я и его тоже как-то неправильно использую. Может быть, мне стоило использовать XCB - это по сути то же самое, что Xlib (сишное апи, чтобы низкоуровнево говорить с иксовым сервером), но вроде как там что-то что-то он лучше дружит с многопоточностью, но у меня моё приложение-то однопоточное, поэтому не уверен, что это помогло бы, потому что XInitThreads(), кстати, не помогает.
Ещё абсолютно не понял, в чём смысл этих каких-то кнопочных символов, зачем они, если есть кнопочные коды. Типа вроде символы учитывают раскладку клавиатуры, а коды - это физические кнопки на клавиатуре. При обработке событий ты получаешь коды, но для них нет констант как на винде (VK_KEY_UP, например), но есть константы для символов с обычной клавиатуры, поэтому типа надо установить соответствие между константами символов и кодами (через XKeysymToKeycode), чтобы понять, во что мапить коды? Из кода GLFW на эту тему https://github.com/glfw/glfw/blob/master/src/x11_init.c я не понял вообще ничего, сам написал какой-то бред. Я понимаю, что иксы не прошли проверку временем, но я тупо даже в теории не понимаю, зачем оно так запутанно сделано, в чём смысл этих абстракций над кнопками.
Ну типа такого, короче https://gist.github.com/poppyfanboy/8f81ca0fd36f1f4e7e74b069b8ffe5a1 И для винды код немного упростил, который у меня был, я изначально там зачем-то городил свою SPSC очередь, чтобы передавать события от потока, куда они приходят, к потоку, где делается рендер и обрабатываются события. Но как будто можно обработку событий впихнуть туда же, куда они приходят. И ещё не знаю, есть ли смысл на винде тоже делать две битмапы, я не особо понимаю, можно ли трогать память битмапы сразу после вызова BitBlt.
А шум этот - случайно нашёл, какой-то "ромбо-квадратный алгоритм". Он выглядит как фрактальный шум, где независимо друг от друга генерируются несколько октав и накладываются друг на друга, но тут все пиксели генерируются за один проход по каждому из них. Типа идея в том, что пиксели проходятся по сетке, которая со временем становится мельче и мельче. Значения генерируются из усреднения соседних пикселей на сетке + рандом. И чем мельче сетка, тем меньше рандома и больше играет роль интерполяция соседних пикселей, поэтому возникает вот этот эффект с локальной плюс-минус гладкостью, но с наличием более глобальных перепадов высот. Тайлится просто из-за того, как он генерируется: когда около-граничные пиксели генерируем, то семплим пиксели с противоположной стороны, а сами граничные пиксели делаем одинаковыми с противоположных сторон.
https://learn.64bitdragon.com/articles/computer-science/procedural-generation/the-diamond-square-algorithm
И потом на сгенерированный шум наложен сдвиг по палитре.
Решил всё же попробовать написать энкодер гифок, но как-то не получается придумать адевактное апи, чтобы с ним взаимодействовать. Я точно не хочу, чтобы оно было завязано на файловое апи, это слишком жёсткая привязка к операционной системе / стандартной библиотеке, и к тому же, а что если я не хочу сохранять гифку в файл. Также я не хочу накручивать абстракции в духе трейта Write из раста, потому что:
- Это слишком сильно переусложнит апи: чтобы им пользоваться, придётся специально определять функцию, которая берёт байты от энкодера и куда-то их пишет. А если, предположим, у тебя используются несколько независимых энкодеров, сделанных в стиле такого апи, то тебе придётся делать отдельные такие функции под каждый из них.
- Вылезает вызов функции по указателю, который ничем не оправдан. В нашем одном конкретном применении энкодера мы вряд ли захотим выводить байты гифки в овер девять тыщ различных мест, скорее всего, мы хотим сделать только что-то одно.
- Если мы пишем гифку в буфер в памяти через эту Write прослойку, то, вероятно, получится, что мы будем заниматься бессмысленным перекладыванием байтов: сначала в какой-то внутренний буфер энкодера и только потом в целевой буфер, вместо того, чтобы сразу писать, куда надо.
То есть как будто нельзя адекватно сделать, чтобы энкодер сам куда-то пушил байты, приходится вручную их из него доставать. И это требование как-то очень плохо синергирует с тем, что я бы также не хотел, чтобы у энкодера сразу был доступ ко всем кадрам, которые надо закодировать. То есть нельзя просто загрузить всю информацию для генерации гифки в энкодер за один вызов функции и потом тупо прочитать все байты гифки из него. Приходится делать вперемешку добавление новых кадров и вытягивание закодированных байтов, и всё превращается в какую-то стейт машиновую жижу, где тебе надо в каком-то чётко определённом порядке делать операции над энкодером, а иначе всё сломается. И либо делать рантаймовые проверки корректности внутреннего состояния энкодера и выводить ошибки при включённом дебаг режиме, либо вообще, видимо, лучше просто забить на какую-либо валидацию, потому что это бессмысленная духота и ты сам виноват, если неправильно используешь энкодер.
Ну просто банально можно по ошибке неполностью прочитать все закодированные байты (решив, что можно сначала вызвать gif_encoder_next_frame для всех кадров, а потом вытащить все закодированные байты для них) или в неправильный момент вызвать какую-то функцию, которая передаёт какие-то опциональные данные, вроде локальной для кадра таблицы цветов.
В расте я видел бредовый вариант решения этой проблемы - наплодить отдельных типов на каждое состояние структуры (через генерик параметр, в который записывается какой-то маркерный тип, обозначающий состояние) и под каждый тип-состояние имплементить только те методы-действия, которые можно сделать в текущем состоянии. Ну вроде такого:
> impl Encoder<Start> {
> ・・fn set_size(self, width: isize, height: isize) -> Encoder<HeaderDataRead> { ... }
> }
>
> impl Encoder<HeaderDataRead> {
> ・・fn pull_header(self, buffer: &mut [u8]) -> Encoder<ReadyForFrames> { ... }
> }
>
> impl Encoder<ReadyForFrames> {
> ・・fn add_frame(self, frame: &[u32]) -> Encoder<FrameDataRead> { ... }
> ・・fn finish_adding_frames(self) -> Encoder<AllFramesPulled> { ... }
> }
>
> impl Encoder<FrameDataRead> {
> ・・fn pull_frame(self, buffer: &mut [u8]) -> Encoder<ReadyForFrames> { ... }
> }
>
> impl Encoder<AllFramesPulled> {
> ・・fn pull_trailer(self, buffer: &mut [u8]) -> Encoder<Finish> { ... }
> }
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa12a467aeb2cf50d44845ad462fc20a
То есть тут нельзя сразу попытаться вытащить байты трейлера гифки из Encoder<Start> или попытаться несколько раз подряд вызвать add_frame, оно тупо не скомпилится.
Но это работает кое-как только, если мы знаем в компайл-тайме, где происходят переходы между состояниями, ну то есть, если у нас реально конечный автомат, а в случае с энкодером гифок, например, переход от состояния "читаю переданный мне кадр, отдаю закодированные байты" к состоянию "готов начать принять следующий кадр" происходит непонятно когда, если мы читаем закодированные байты не за один раз, а в несколько подходов.
И этот подход ещё ограничивает то, в какой последовательности можно делать действия: тут не получится вызвать методы в такой последовательности: set_size, add_frame, pull_header, pull_frame, хотя по логике в этом нет проблем. Ну либо удачи добавить миллиард дополнительных возможных состояний, чтобы так всё же можно было делать.
Ну и плюс оно даже в расте адски уродливо выглядит: там придётся постоянно копировать данные внутри энкодера между этими разными типами-состояниями, то есть их придётся в Box запихать. И постоянное переобъявление переменной encoder выглядит шизово (а оно тут необходимо, потому что тип переменной encoder меняется каждый раз) и очень плохо сочетается с циклом for, например. Короче, это только на каких-то игрушечных примерах выглядит как что-то работающее.
У меня есть в голове ещё другая идея, как можно было бы сделать ещё: типа в каком-то смысле инвертировать контроль, чтобы энкодер просил от тебя совершить какие-то действия, например, "дай мне размер гифки", "дай мне глобальную таблицу цветов", "дай мне следующий кадр", "читай из меня закодированные байты", и чтобы у тебя была возможность ответить "ок, вот тебе следующий кадр" или там "нет, не буду давать тебе таблицу цветов, сам разбирайся". Типа код, пользующийся энкодером, будет выглядеть примерно как window procedure из win32, но это окончательно просто шизофрения.
Ну, короче, в итоге я ничего не сделал по сути за сегодня, кроме этой ментальной мастурбации.
- Это слишком сильно переусложнит апи: чтобы им пользоваться, придётся специально определять функцию, которая берёт байты от энкодера и куда-то их пишет. А если, предположим, у тебя используются несколько независимых энкодеров, сделанных в стиле такого апи, то тебе придётся делать отдельные такие функции под каждый из них.
- Вылезает вызов функции по указателю, который ничем не оправдан. В нашем одном конкретном применении энкодера мы вряд ли захотим выводить байты гифки в овер девять тыщ различных мест, скорее всего, мы хотим сделать только что-то одно.
- Если мы пишем гифку в буфер в памяти через эту Write прослойку, то, вероятно, получится, что мы будем заниматься бессмысленным перекладыванием байтов: сначала в какой-то внутренний буфер энкодера и только потом в целевой буфер, вместо того, чтобы сразу писать, куда надо.
То есть как будто нельзя адекватно сделать, чтобы энкодер сам куда-то пушил байты, приходится вручную их из него доставать. И это требование как-то очень плохо синергирует с тем, что я бы также не хотел, чтобы у энкодера сразу был доступ ко всем кадрам, которые надо закодировать. То есть нельзя просто загрузить всю информацию для генерации гифки в энкодер за один вызов функции и потом тупо прочитать все байты гифки из него. Приходится делать вперемешку добавление новых кадров и вытягивание закодированных байтов, и всё превращается в какую-то стейт машиновую жижу, где тебе надо в каком-то чётко определённом порядке делать операции над энкодером, а иначе всё сломается. И либо делать рантаймовые проверки корректности внутреннего состояния энкодера и выводить ошибки при включённом дебаг режиме, либо вообще, видимо, лучше просто забить на какую-либо валидацию, потому что это бессмысленная духота и ты сам виноват, если неправильно используешь энкодер.
Ну просто банально можно по ошибке неполностью прочитать все закодированные байты (решив, что можно сначала вызвать gif_encoder_next_frame для всех кадров, а потом вытащить все закодированные байты для них) или в неправильный момент вызвать какую-то функцию, которая передаёт какие-то опциональные данные, вроде локальной для кадра таблицы цветов.
В расте я видел бредовый вариант решения этой проблемы - наплодить отдельных типов на каждое состояние структуры (через генерик параметр, в который записывается какой-то маркерный тип, обозначающий состояние) и под каждый тип-состояние имплементить только те методы-действия, которые можно сделать в текущем состоянии. Ну вроде такого:
> impl Encoder<Start> {
> ・・fn set_size(self, width: isize, height: isize) -> Encoder<HeaderDataRead> { ... }
> }
>
> impl Encoder<HeaderDataRead> {
> ・・fn pull_header(self, buffer: &mut [u8]) -> Encoder<ReadyForFrames> { ... }
> }
>
> impl Encoder<ReadyForFrames> {
> ・・fn add_frame(self, frame: &[u32]) -> Encoder<FrameDataRead> { ... }
> ・・fn finish_adding_frames(self) -> Encoder<AllFramesPulled> { ... }
> }
>
> impl Encoder<FrameDataRead> {
> ・・fn pull_frame(self, buffer: &mut [u8]) -> Encoder<ReadyForFrames> { ... }
> }
>
> impl Encoder<AllFramesPulled> {
> ・・fn pull_trailer(self, buffer: &mut [u8]) -> Encoder<Finish> { ... }
> }
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa12a467aeb2cf50d44845ad462fc20a
То есть тут нельзя сразу попытаться вытащить байты трейлера гифки из Encoder<Start> или попытаться несколько раз подряд вызвать add_frame, оно тупо не скомпилится.
Но это работает кое-как только, если мы знаем в компайл-тайме, где происходят переходы между состояниями, ну то есть, если у нас реально конечный автомат, а в случае с энкодером гифок, например, переход от состояния "читаю переданный мне кадр, отдаю закодированные байты" к состоянию "готов начать принять следующий кадр" происходит непонятно когда, если мы читаем закодированные байты не за один раз, а в несколько подходов.
И этот подход ещё ограничивает то, в какой последовательности можно делать действия: тут не получится вызвать методы в такой последовательности: set_size, add_frame, pull_header, pull_frame, хотя по логике в этом нет проблем. Ну либо удачи добавить миллиард дополнительных возможных состояний, чтобы так всё же можно было делать.
Ну и плюс оно даже в расте адски уродливо выглядит: там придётся постоянно копировать данные внутри энкодера между этими разными типами-состояниями, то есть их придётся в Box запихать. И постоянное переобъявление переменной encoder выглядит шизово (а оно тут необходимо, потому что тип переменной encoder меняется каждый раз) и очень плохо сочетается с циклом for, например. Короче, это только на каких-то игрушечных примерах выглядит как что-то работающее.
У меня есть в голове ещё другая идея, как можно было бы сделать ещё: типа в каком-то смысле инвертировать контроль, чтобы энкодер просил от тебя совершить какие-то действия, например, "дай мне размер гифки", "дай мне глобальную таблицу цветов", "дай мне следующий кадр", "читай из меня закодированные байты", и чтобы у тебя была возможность ответить "ок, вот тебе следующий кадр" или там "нет, не буду давать тебе таблицу цветов, сам разбирайся". Типа код, пользующийся энкодером, будет выглядеть примерно как window procedure из win32, но это окончательно просто шизофрения.
Ну, короче, в итоге я ничего не сделал по сути за сегодня, кроме этой ментальной мастурбации.
Только что потратил примерно 9 часов подряд на то, чтобы написать худшие за свою жизнь 400 строк кода, которые умеют создавать белые прямоугольники, закодированные в гифки, пример - пикрил два. Хочу, наверное, снова выкладывать код в гитхаб, а не в годболт. Но там просто ад в плане, что я просто пытался получить хотя бы какой-то результат. И я в очередной раз убедился в том, что моя главная проблема не в том, что я ленивый, не в том, что мне тяжело сесть и начать что-то делать, а в том, что я просто ебаное безмозглое необучаемое уёбище с очень низким потолком способностей в чём угодно, неважно, насколько сильно я стараюсь что-то делать, это всегда займёт в разы больше времени, чем у нормальных людей, а результат будет полнейшей хуетой.
Первый раз попробовал гццшный санитайзер, потому что в один момент оказался слишком сильно фрустрирован тем, что ничего не получается, и он помог найти банальный баг с умножением вместительности массива в два раза, при том, что она изначально ноль, и обругать меня за утечки памяти, на которые мне всё равно, но на деле основная ошибка оказалась логической: в гифках закодированные данные картинки подразделяются на более мелкие блоки с максимальным размером 255 байт и я почему-то подумал, что LZW коды НЕ могут быть размазаны между двумя блоками данных, а оказалось, что могут, и надо наполнять блоки битами прямо до краёв указанных размеров.
Санитайзер, кстати, оказался не супер какой-то панацеей, не знаю, как он работает, но даже за это непродолжительное использование попалась ситуация, где он не отследил выход за границы массива. Вроде бы там массив был на стеке аллоцирован внутри структуры и я случайно залез в другие поля этой же структуры, получается, вряд ли такое можно нормально отследить подобными автоматическими инструментами.
Первый раз попробовал гццшный санитайзер, потому что в один момент оказался слишком сильно фрустрирован тем, что ничего не получается, и он помог найти банальный баг с умножением вместительности массива в два раза, при том, что она изначально ноль, и обругать меня за утечки памяти, на которые мне всё равно, но на деле основная ошибка оказалась логической: в гифках закодированные данные картинки подразделяются на более мелкие блоки с максимальным размером 255 байт и я почему-то подумал, что LZW коды НЕ могут быть размазаны между двумя блоками данных, а оказалось, что могут, и надо наполнять блоки битами прямо до краёв указанных размеров.
Санитайзер, кстати, оказался не супер какой-то панацеей, не знаю, как он работает, но даже за это непродолжительное использование попалась ситуация, где он не отследил выход за границы массива. Вроде бы там массив был на стеке аллоцирован внутри структуры и я случайно залез в другие поля этой же структуры, получается, вряд ли такое можно нормально отследить подобными автоматическими инструментами.
Выше гифка не загрузилась из-за каких-то ограничений макабы. Сначала подумал, что из-за того, что не добавил опциональный блок graphic control extension, в котором можно указать фпс, прозрачность и то, зачищается ли экран после отрисовки кадра гифки (в интернете иногда попадаются гифки с прозрачностью, где видно, как следующий кадр поверх другого накладывается, вот это из-за кривых параметров в этом блоке, наверное). Но, короче, нет, она просто слишком большая. Максимум - это где-то как минимум 8,370,176 пикселей, то есть, например, самая большая 16:9 гифка, которую можно загрузить - это 3856×2169, ну, если ровно 16:9. Типа в несжатом виде с 4 байтами на пиксель в памяти будет занимать 32 мегабайта, может быть, генерация превью фейлится с ограничением по памяти, но почему из-за этого сам файл не грузится - не знаю.
Сейчас снова попробовал просто сесть и наблевать говнокодом, лишь бы что-то получилось, потратил где-то 4 часа, чтобы заставить работать энкодинг с фиксированной таблицей цветов для произвольной картинки, результат - пикрил 3, который, надеюсь, всё же загрузится сюда. Но, во-первых, получается, очевидно, говнокод, а, во-вторых, всё равно в итоге мозг расплавлен даже от 4 часов попыток его применять, всё, я ничего не могу, я реально уже смысла жить не вижу никакого, ну, серьёзно, я не могу перестать думать о том, что мне надо нахуй уже умереть, ну вот, например, я вчера услышал случайно "деление через умножение", загуглил, я бы в жизни до такого не додумался https://board.flatassembler.net/topic.php?t=20938 какие-то п-адические числа, про которые я так никогда и не почитал, при этом я уверен, что каждый человек знает всё это, и это то, что происходит на регулярной основе.
Как оказалось, необязательно сбрасывать LZW таблицу, когда она переполняется, энкодер может просто продолжить выдавать коды максимальной длины (которая всего лишь 12 бит). Непонятно, короче, когда лучше таблицу сбрасывать, но если вообще этого не делать, то пикрил 3 получается раз в 7 более жирным, чем если сбрасывать каждый раз при переполнении, ну тут потому что таблица, заполненная паттернами, полученными в небе, вообще не актуальна, когда доходим до травы, там с ней околонулевое сжатие будет.
Первый раз попробовал gdb из консоли, короче, этим примерно невозможно пользоваться, постоянно глючит этот tui режим, шизовый синтаксис команд (p/x - вывести значение в хексе, 🞰array@length - вывести по указателю несколько значений, кто это выдумал), сидишь, пальцы ломаешь об клавиатуру, чтобы просто брейкпоинт поставить и убрать его вместо того, чтобы просто мышкой нажать рядом со строкой кода.
>банальный баг с умножением вместительности массива в два раза, при том, что она изначально ноль
Кстати, спасибо большое glibc за то, что malloc(0) зачем-то выделяет память и возвращает валидный указатель, по которому я могу ошибочно начать спокойно что-то писать, вместо того, чтобы просто вернуть 0, чтобы всё упало с сегфолтом, реально тупо компилируемый джаваскрипт
>Если мы пишем гифку в буфер в памяти через эту Write прослойку, то, вероятно, получится, что мы будем заниматься бессмысленным перекладыванием байтов
Ну, кстати, я не додумался, но этот момент всё же можно обойти, как этот чел: https://lists.sr.ht/~skeeto/public-inbox/%3Cane2ee7fpnyn3qxslygprmjw2yrvzppxuim25jvf7e6f5jgxbd@p7y6own2j3it%3E
То есть не делать в этом полиморфном интерфейсе в принципе никакого write, только flush. Вместо вызовов write писать в свой внутренний буфер. Если пишем в файл, то flush делает запись в файл и очищает буфер, если пишем в память, то flush расширяет буфер.
Сейчас снова попробовал просто сесть и наблевать говнокодом, лишь бы что-то получилось, потратил где-то 4 часа, чтобы заставить работать энкодинг с фиксированной таблицей цветов для произвольной картинки, результат - пикрил 3, который, надеюсь, всё же загрузится сюда. Но, во-первых, получается, очевидно, говнокод, а, во-вторых, всё равно в итоге мозг расплавлен даже от 4 часов попыток его применять, всё, я ничего не могу, я реально уже смысла жить не вижу никакого, ну, серьёзно, я не могу перестать думать о том, что мне надо нахуй уже умереть, ну вот, например, я вчера услышал случайно "деление через умножение", загуглил, я бы в жизни до такого не додумался https://board.flatassembler.net/topic.php?t=20938 какие-то п-адические числа, про которые я так никогда и не почитал, при этом я уверен, что каждый человек знает всё это, и это то, что происходит на регулярной основе.
Как оказалось, необязательно сбрасывать LZW таблицу, когда она переполняется, энкодер может просто продолжить выдавать коды максимальной длины (которая всего лишь 12 бит). Непонятно, короче, когда лучше таблицу сбрасывать, но если вообще этого не делать, то пикрил 3 получается раз в 7 более жирным, чем если сбрасывать каждый раз при переполнении, ну тут потому что таблица, заполненная паттернами, полученными в небе, вообще не актуальна, когда доходим до травы, там с ней околонулевое сжатие будет.
Первый раз попробовал gdb из консоли, короче, этим примерно невозможно пользоваться, постоянно глючит этот tui режим, шизовый синтаксис команд (p/x - вывести значение в хексе, 🞰array@length - вывести по указателю несколько значений, кто это выдумал), сидишь, пальцы ломаешь об клавиатуру, чтобы просто брейкпоинт поставить и убрать его вместо того, чтобы просто мышкой нажать рядом со строкой кода.
>банальный баг с умножением вместительности массива в два раза, при том, что она изначально ноль
Кстати, спасибо большое glibc за то, что malloc(0) зачем-то выделяет память и возвращает валидный указатель, по которому я могу ошибочно начать спокойно что-то писать, вместо того, чтобы просто вернуть 0, чтобы всё упало с сегфолтом, реально тупо компилируемый джаваскрипт
>Если мы пишем гифку в буфер в памяти через эту Write прослойку, то, вероятно, получится, что мы будем заниматься бессмысленным перекладыванием байтов
Ну, кстати, я не додумался, но этот момент всё же можно обойти, как этот чел: https://lists.sr.ht/~skeeto/public-inbox/%3Cane2ee7fpnyn3qxslygprmjw2yrvzppxuim25jvf7e6f5jgxbd@p7y6own2j3it%3E
То есть не делать в этом полиморфном интерфейсе в принципе никакого write, только flush. Вместо вызовов write писать в свой внутренний буфер. Если пишем в файл, то flush делает запись в файл и очищает буфер, если пишем в память, то flush расширяет буфер.
Попробовал сейчас снова просто сесть и написать что-то, решил попробовать сделать генерацию палитры на основе входной картинки вместо того, чтобы использовать фиксированную, как в там используется такая просто, если что https://en.wikipedia.org/wiki/Web_colors#Color_table потому что её было очень легко сгенерировать, просто перебор всех цветов с шагом в 0x33 по каждой компоненте, но вообще она довольно уродливая, цвета неравномерные, потому что линейный шаг по нелинейному пространству.
Результат - пикрил два, 256 цветов, вроде не сильно плохо выглядит даже без дизеринга, но это, возможно, из-за того, что джипеговые артефакты входной картинки выступают в этой роли, поэтому бэндинг не сильно бросается в глаза. Использовал этот алгоритм https://en.wikipedia.org/wiki/Median_cut суть его просто в том, что берём все цвета оригинальной картинки, сортируем их по той компоненте цвета, где больше всего разброс значений, после чего разделяем цвета пополам на два куска, дальше повторяем эти действия на более мелких группах цветов, пока у нас не получится количество групп, равное желаемому количеству цветов в картинке. После чего усредняем цвета в каждой группе и используем усреднённые цвета в палитре. Можно сделать совсем мало цветов, пикрил три - это только 4 цвета. Вроде бы ещё для квантизации можно использовать k-means clustering, но я не читал про него.
В коде получился какой-то полный бред. Вхардкоженный опен адресинг хешсет для составления массива цветов из картинки. Потом куски массива цветов сортируются и разбиваются на сегменты, которые я в очереди на циклическом массиве просто храню: в цикле из начала берётся новый сегмент, разбивается на два, которые добавляются в конец. И так до тех пор либо, пока не разобъём на 256 групп, либо, пока размер всех групп не достигнет единицы (что означает, что во входной картинке меньше 256 цветов).
Этот фронтенд для gdb вроде бы неплохой https://github.com/nakst/gf не для всего есть кнопки, к сожалению, некоторые вещи вроде условных брейкпоинтов и текущей рабочей директории приходится вводить командами в gdb, нет возможности навести мышкой на переменную и посмотреть её значение, иногда глючит, но в целом лучше, чем пользоваться gdb из консоли. (И ещё его нет под виндой, но там есть варианты получше типа remedybg или RAD debugger, которые к тому же не просто фронтенды, а самостоятельные дебаггеры.)
Под конец у меня снова не было никаких сил уже любых и я еле-еле смог выискать все тупейшие ошибки в коде и доделать до минимально рабочего состояния. Работает оно, кстати, дико медленно из-за линейных лукапов последовательностей из LZW таблицы в цикле, всё ещё не заменил на хештаблицу. Самый тупой момент был, когда не мог найти ошибку из-за того, что случайно вместо изменения переменной в цикле переобъявил её внутри, и дебаггер тоже не помогал, потому что в watch окне просто показывал значение локальной для цикла переменной, короче, виноват во всём этот gf, в котором нельзя по ховеру смотреть значения переменных. А я тупо не заметил, видимо, придётся теперь всегда включать ворнинги для шедоувинга переменных, раз я напоролся на это.
Я каким-то образом сидел с этим почти 7 часов подряд, у меня снова напрочь выжжен мозг, я не знаю, что с собой сделать, я моментально устаю буквально от любых попыток приложить куда-то усилия, моя проблема 100% в том, что я генетическое уёбище, которое может только лежать в кровати и обниматься с одеялом и больше ничего не хочется, мне ничего не поможет, я хочу нахуй умереть
Результат - пикрил два, 256 цветов, вроде не сильно плохо выглядит даже без дизеринга, но это, возможно, из-за того, что джипеговые артефакты входной картинки выступают в этой роли, поэтому бэндинг не сильно бросается в глаза. Использовал этот алгоритм https://en.wikipedia.org/wiki/Median_cut суть его просто в том, что берём все цвета оригинальной картинки, сортируем их по той компоненте цвета, где больше всего разброс значений, после чего разделяем цвета пополам на два куска, дальше повторяем эти действия на более мелких группах цветов, пока у нас не получится количество групп, равное желаемому количеству цветов в картинке. После чего усредняем цвета в каждой группе и используем усреднённые цвета в палитре. Можно сделать совсем мало цветов, пикрил три - это только 4 цвета. Вроде бы ещё для квантизации можно использовать k-means clustering, но я не читал про него.
В коде получился какой-то полный бред. Вхардкоженный опен адресинг хешсет для составления массива цветов из картинки. Потом куски массива цветов сортируются и разбиваются на сегменты, которые я в очереди на циклическом массиве просто храню: в цикле из начала берётся новый сегмент, разбивается на два, которые добавляются в конец. И так до тех пор либо, пока не разобъём на 256 групп, либо, пока размер всех групп не достигнет единицы (что означает, что во входной картинке меньше 256 цветов).
Этот фронтенд для gdb вроде бы неплохой https://github.com/nakst/gf не для всего есть кнопки, к сожалению, некоторые вещи вроде условных брейкпоинтов и текущей рабочей директории приходится вводить командами в gdb, нет возможности навести мышкой на переменную и посмотреть её значение, иногда глючит, но в целом лучше, чем пользоваться gdb из консоли. (И ещё его нет под виндой, но там есть варианты получше типа remedybg или RAD debugger, которые к тому же не просто фронтенды, а самостоятельные дебаггеры.)
Под конец у меня снова не было никаких сил уже любых и я еле-еле смог выискать все тупейшие ошибки в коде и доделать до минимально рабочего состояния. Работает оно, кстати, дико медленно из-за линейных лукапов последовательностей из LZW таблицы в цикле, всё ещё не заменил на хештаблицу. Самый тупой момент был, когда не мог найти ошибку из-за того, что случайно вместо изменения переменной в цикле переобъявил её внутри, и дебаггер тоже не помогал, потому что в watch окне просто показывал значение локальной для цикла переменной, короче, виноват во всём этот gf, в котором нельзя по ховеру смотреть значения переменных. А я тупо не заметил, видимо, придётся теперь всегда включать ворнинги для шедоувинга переменных, раз я напоролся на это.
Я каким-то образом сидел с этим почти 7 часов подряд, у меня снова напрочь выжжен мозг, я не знаю, что с собой сделать, я моментально устаю буквально от любых попыток приложить куда-то усилия, моя проблема 100% в том, что я генетическое уёбище, которое может только лежать в кровати и обниматься с одеялом и больше ничего не хочется, мне ничего не поможет, я хочу нахуй умереть
Абсолютно без вариантов, векторы (которые математические) должны быть частью языка, а не пользовательскими типами с наверченными перегрузками операторов и накодогенерированными свиззлами. А в C99, мне кажется, просто невозможно реализовать нормальный вектор. Проблемы начинаются тупо с того, а как определить тип, можно так:
> typedef union {
> ・・f32 data[3];
> ・・struct { f32 x, y, z; };
> ・・struct { f32 red, green, blue; };
> } f32x3;
Но, во-первых, для анонимных структур нужен C11, в C99 придётся назвать все структуры и обращаться к ним как "vector.coord.y" или "vector.color.green". А во-вторых, тут вылезает UB из-за массива: если ты создал f32x3 и изначально инициализировал его через поля x, y, z, то ты не можешь пытаться читать их через массив data, потому что чисто формально в юнионе не лежит массив (читать red, green, blue при этом, кстати, можно, потому что одни и те же типы полей в двух структурах под юнионом).
Ладно, можно попробовать убрать массив и сделать индексированный доступ через функцию, например (под MSVC __assume(0) - эквивалент __builtin_unreachable()):
> f32 f32x3_get(f32x3 vector, int index) {
> ・・switch (index) {
> ・・・・case 0: return vector.coord.x;
> ・・・・case 1: return vector.coord.y;
> ・・・・case 2: return vector.coord.z;
> ・・・・default: __builtin_unreachable();
> ・・}
> }
Компилятор же сможет такое оптимизировать и убрать ветвление? Ну типа и да, и нет? https://godbolt.org/z/js9fvGMv7 Если он инлайнит вызов этой функции, то убирает джампы, но в коде самой функции почему-то всё равно есть ветвление.
А если сделать так:
> f32 f32x3_get_branchless(f32x3 vector, int index) {
> ・・return ((f32 🞰) &vector)[index];
> }
то опять же, чисто формально это будет UB.
Ну ок, можно подумать, что хотя бы такое сработает:
> #define RED 0
> #define GREEN 1
> #define BLUE 2
> #define X 0
> #define Y 1
> #define Z 2
> typedef f32 f32x3[3];
Но это ещё хуже, удачи попытаться вернуть массив из функции, удачи попытаться просто присвоить другое значение переменной с таким вектором:
> f32x3 vector = {1.0F, 2.0F, 3.0F};
> vector = (f32x3) {4.0F, 5.0F, 6.0F};
Это не сработает, потому что на второй строке компаунд литерал справа имеет тип "f32 🞰". То есть придётся запихивать массив внутрь структуры и обращение к элементам начинает выглядеть совсем стрёмно: vector.data[Y] или vector.data[GREEN]. Про то, что мы мы дефайнами заняли названия цветов и осей координат, я вообще молчу.
Да, короче, просто похуй на это UB, это всё бред, компилятор либо генерирует нужный тебе код, либо нет, программа просто либо работает, либо нет, эти рассуждения - бессмысленная хуета, а я ёбаный дегенерат. Я просто попытался сесть продолжить что-то писать, но выебал сам себе мозг какой-то хуйнёй, не имеющей ничего общего с реальностью, я тупое животное, я нахуй ненавижу себя
> typedef union {
> ・・f32 data[3];
> ・・struct { f32 x, y, z; };
> ・・struct { f32 red, green, blue; };
> } f32x3;
Но, во-первых, для анонимных структур нужен C11, в C99 придётся назвать все структуры и обращаться к ним как "vector.coord.y" или "vector.color.green". А во-вторых, тут вылезает UB из-за массива: если ты создал f32x3 и изначально инициализировал его через поля x, y, z, то ты не можешь пытаться читать их через массив data, потому что чисто формально в юнионе не лежит массив (читать red, green, blue при этом, кстати, можно, потому что одни и те же типы полей в двух структурах под юнионом).
Ладно, можно попробовать убрать массив и сделать индексированный доступ через функцию, например (под MSVC __assume(0) - эквивалент __builtin_unreachable()):
> f32 f32x3_get(f32x3 vector, int index) {
> ・・switch (index) {
> ・・・・case 0: return vector.coord.x;
> ・・・・case 1: return vector.coord.y;
> ・・・・case 2: return vector.coord.z;
> ・・・・default: __builtin_unreachable();
> ・・}
> }
Компилятор же сможет такое оптимизировать и убрать ветвление? Ну типа и да, и нет? https://godbolt.org/z/js9fvGMv7 Если он инлайнит вызов этой функции, то убирает джампы, но в коде самой функции почему-то всё равно есть ветвление.
А если сделать так:
> f32 f32x3_get_branchless(f32x3 vector, int index) {
> ・・return ((f32 🞰) &vector)[index];
> }
то опять же, чисто формально это будет UB.
Ну ок, можно подумать, что хотя бы такое сработает:
> #define RED 0
> #define GREEN 1
> #define BLUE 2
> #define X 0
> #define Y 1
> #define Z 2
> typedef f32 f32x3[3];
Но это ещё хуже, удачи попытаться вернуть массив из функции, удачи попытаться просто присвоить другое значение переменной с таким вектором:
> f32x3 vector = {1.0F, 2.0F, 3.0F};
> vector = (f32x3) {4.0F, 5.0F, 6.0F};
Это не сработает, потому что на второй строке компаунд литерал справа имеет тип "f32 🞰". То есть придётся запихивать массив внутрь структуры и обращение к элементам начинает выглядеть совсем стрёмно: vector.data[Y] или vector.data[GREEN]. Про то, что мы мы дефайнами заняли названия цветов и осей координат, я вообще молчу.
Да, короче, просто похуй на это UB, это всё бред, компилятор либо генерирует нужный тебе код, либо нет, программа просто либо работает, либо нет, эти рассуждения - бессмысленная хуета, а я ёбаный дегенерат. Я просто попытался сесть продолжить что-то писать, но выебал сам себе мозг какой-то хуйнёй, не имеющей ничего общего с реальностью, я тупое животное, я нахуй ненавижу себя
Ну, на самом деле, там можно было вместо каста структуры к указателю на f32 просто в массив все компоненты сложить и по индексу достать значение из него, не знаю, почему я не подумал об этом, но меня в любом случае просто как-то расстроило, что оно зачем-то ветвление делает.
Я уже несколько дней назад типо как-то улучшил (в гигантских кавычках) скорость работы просто банально за счёт того, что убрал тысячи бесполезных переводов в цикле из sRGB в линейное пространство для табличных цветов (которые нужны, чтобы найти табличный цвет ближайший к цветам пикселей из картинки). Ну типа все эти переводы можно один раз сделать в начале для всех табличных цветов и дальше переиспользовать. Вообще я почти уверен, что там сейчас неправильно всё с квантизацией цветов, потому что как будто при генерации палитры под картинку тоже нужно учитывать гамму (когда выбираешь компонент цвета, по которому делишь цвета на каждой итерации median cut quantization, когда вычисляешь среднее для группы похожих цветов), а я сейчас этого не делаю. Я подозреваю, что если сделать картинку с градиентом от чёрного до белого и урезать её до небольшого количества цветов, например, до восьми, то там будет хорошо видно, что градиент съедет по сравнению с оригинальной картинкой. Но у меня сейчас не было сил это проверять.
У меня сейчас лукапы ближайших цветов к табличным сделаны через k-d дерево и вроде бы на них тратится подавляющее количество времени, если верить gprof. Из-за этого мне мозг сверлила мысль, что может быть можно выпилить рекурсию, явные указатели на поддеревья и запихать дерево в массив, типа как когда бинарную кучу запихивают в массив? Мне почему-то казалось, что там благодаря этому можно было бы сделать как-то так, что не нужен будет бэктрекинг, ну или что как-то дерево можно было бы одним циклом обойти или уменьшить бэктрекинг, но, короче, я не придумал ничего и пикрил два код работает ровно так же, как версия с рекурсией и явным деревом. Бессмысленно, наверное, вот так разворачивать рекурсию, если приходится всё равно свой стек велосипедить. А если не k-d дерево, то я не знаю, что использовать, может быть, лучше было бы во время генерации палитры все цвета картинки впихнуть в хешмапу, которая бы маппила их в цвет из палитры, чтобы во время итерации по пикселям делать лукап по хештаблице, а не по дереву. Я не знаю, почему я так не сделал изначально, это более очевидный вариант вроде бы.
Почему-то захотелось попробовать посмотреть, что из себя представляют локально запущенные ллм, потому что как будто даже есть некий свой вайб у того, что "разговаривает" с тобой именно твой комп, который у тебя под ногами шумит и греется, автономно, без того, чтобы слать запросы в какие-то непонятные датацентры. Ну и плюс в голову лезут какие-то выдуманные сценарии про то, что человечество отупело, пришло в упадок, вся инфраструктура порушилась, электричества нет, всё взорвано атомными бомбами, но есть надежда, что можно найти мифические уцелевшие жёсткие диски с ллм, как-то их запустить и, короче, чтобы оно дало туториал как восстановить человечество. А типа у тебя прямо сейчас в настоящем на жёстком диске лежит этот мега артефакт.
Но, короче, проблема в том, что мне с 8 Гб видеопамяти, как оказалось, примерно бесполезно пытаться что-то запускать. Максимум с разумной производительностью можно запустить только модели на 7B параметров, которые, если они не зафайнтюнены на что-то конкретное вроде кодинга, то они довольно тупые. Либо на 14B параметров, но с весами урезанными до 3 бит как минимум, они менее тупые, но не особо качественные. А если на видеокарту полностью не удаётся выгрузить все слои, то скорость работы падает практически до скорости работы просто на проце. Reasoning ллмы запускать бесполезно, на 7B они как будто ещё тупее, чем обычные, а если более жирные, то с моей видеокартой не дождёшься момента, когда они завершат этот шизоидный диалог с самой собой и перейдут к ответу. Модели на 32B ещё кое-как хотя бы запускаются на процессоре с 32 Гб оперативки, на 70B - уже нет.
Кокретно, что я хотел попробовать - это вариант использования ллм как бэкситтера во время кодинга, потому что я на эту тему только один раз давно, год назад, попробовал копилот, но меня тогда почти сразу выбесило, что он посоветовал мне что-то очевидно ошибочное, и я забил. Показалось, что самое более-менее адекватное из доступного мне - это Qwen 2.5 coder 7B instruct (Q6_K) с 16к токенами контекста (больше не уместилось в VRAM). Ну, короче, вывод за пару часов использования, сейчас, пока я пытался переписать поиск по k-d дереву - оно иногда может угадать концовки комментариев, которые я пишу к коду. В остальном либо генерирует бред (из-за тупости / слишком маленького контекста), либо как будто нарочно пытается внести баги в код, но чтобы я не заметил, как на пикрил три.
И даже такая мелкая и тупая модель работает довольно медленно и периодически уходит в себя на минуту и всё это время оно что-то долго генерит, судя по нагрузке на видеокарту, но в итоге может выдать не какой-то длинный ответ, а просто короткий и тупой. Вообще я так понял, они не отвечают на твои вопросы, они тупо непрерывно генерят текст, но натренированы иногда вставлять специальные токены по типу <|im_start|>assistant, <|im_start|>user, <|im_end|>, обозначающие границы реплик себя и тебя. Но в целом ей всё равно, если её не останавливать, то она начнёт ролеплеить за юзера, задавать вопросы сама себе, сама же себе отвечать и так бесконечно, некоторые модели, которые запускал, тупо так и делали почему-то. Из-за этого создалось впечатление, что в такие моменты затупов у него не получается вовремя выдать завершающий токен, а вскодовое расширение (continue.dev) пытается заново и заново сгенерировать автокомплит, пока наконец-то не получает рандомно что-то завершённое и не сильно длинное, поэтому оно может долго тупить и потом выдать что-то короткое. По крайней мере таких затупов стало меньше после того, как выставил completionOptions.maxTokens на 128 токенов, всё равно чем больше генерит за раз, тем с большей вероятностью код оказывается полнейшим бредом.
Я пользовался ей через llama.cpp с вулкановым бэкендом, как будто бы ROCm бэкенд должен работать немного получше, но я не могу его скомпилировать, слишком много гигабайтов зависимостей, а у меня линукс помойка, на которой я зачем-то сейчас в основном сижу, сейчас находится в изгнании на довольно небольшой флешке.
Неважно, короче, у меня после этого окончательно угас любой интерес ко всему этому нейрослопу, ничего никогда не происходит
А) Не знаю, знаешь ты про это или нет, может, ты это уже делаешь и просто оставил названия RGB, но в качестве дальнейшего углубления в кроличью нору (https://en.wikipedia.org/wiki/Color_difference) можешь преобразовывать цвета в XYZ, а из неё в L＊a＊b＊. Эти модели специально сделаны в стремлении создать такое пространство, в котором ощущаемая homo sapiens разница между цветами будет соответствовать евклидовому расстоянию между векторами. Линеаризованная sRGB выражает (буквально) количество фотонов, откуда естественным образом подходит для расчёта освещения, но менее естественна для поиска ближайшего цвета в палитре через расстояние. (На этом примере результат #5 с L＊a＊b＊ очень близок к результату #2 с √(2ΔR²+4ΔG²+3ΔB²)...)
Б) abs(x) < distance эквивалентно sqr(x) < sqr_distance. :>
В) Мо... можешь разбить пространство на сетку кубиков и связать с каждым список точек, которые могут оказаться ближайшими к точке внутри кубика. У каждой известно минимальное и максимальное расстояние до кубика (например, у точек внутри кубика минимальное = 0 и максимальное = расстоянию до самой дальней вершины), точки, у которых минимальное больше, чем «минимальное из максимальных», заведомо не могут быть ближайшими.
В.2) Ещё вариант (он пересекается с предыдущим aka пространственным хэшированием, потому что иногда за хэш берут эту проекцию — у неё есть ценное свойство локальности): выбираешь одну-две-три оси, сортируешь точки вдоль каждой по проекции (скалярному произведению), и для поиска проецируешь точку и ищешь по каждой оси в обе стороны, предположительно, поочерёдно (именно поочерёдно, а не выбирая минимальную из следующих, т. к. по одной из осей может быть некрасивый ложный кластер, которого под другим углом не будет видно). То есть изначально у тебя есть 2×(число осей) «курсоров», и по мере того, как ты находишь более близкие цвета, ты прерываешь поиск по тем, по которым ушёл дальше.
