4:19 - Ща сделаем простую и понятную библиотеку
4:20 - Remove "Redux itself is very simple"
https://github.com/reduxjs/redux/pull/2950/files
4:20 - Remove "Redux itself is very simple"
https://github.com/reduxjs/redux/pull/2950/files
Наткнулся на видос, где рассказывают, какие неочевидные проблемы могут возникнуть при поиске среднего двух чисел:
https://www.youtube.com/watch?v=sBtAGxBh-XI
Удивительно, что доклад на такую, казалось бы, простую тему может длиться час. Но там действительно огромное поле для ошибок.
При написании алгоритма поиска среднего велик соблазн сделать просто
Ровно из-за такой ошибки в Java 9 лет некорректно работал бинпоиск. Аналогичная проблема была и в имплементации JS от Mozilla.
Помимо переполнения есть еще другие сложности: integer promotion при работе с
Если лень смотреть, то есть документ с описанием имплементации
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0811r3.html
Также можно глянуть итоговую имплементацию
https://github.com/llvm/llvm-project/blob/main/libcxx/include/__numeric/midpoint.h
https://www.youtube.com/watch?v=sBtAGxBh-XI
Удивительно, что доклад на такую, казалось бы, простую тему может длиться час. Но там действительно огромное поле для ошибок.
При написании алгоритма поиска среднего велик соблазн сделать просто
return (a + b) / 2
, однако такая реализация может переполниться и привести к неопределенному поведению.Ровно из-за такой ошибки в Java 9 лет некорректно работал бинпоиск. Аналогичная проблема была и в имплементации JS от Mozilla.
Помимо переполнения есть еще другие сложности: integer promotion при работе с
short
, зависящий от имплементации знак у char
. Ловушки в специализации шаблонов. А кроме целых типов ведь есть еще флоты и указатели, с которыми тоже приколов хватает.Если лень смотреть, то есть документ с описанием имплементации
std::midpoint,
на основе которого и был сделан доклад (тут не все, но все равно есть, что почитать):https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0811r3.html
Также можно глянуть итоговую имплементацию
std::midpoint
:https://github.com/llvm/llvm-project/blob/main/libcxx/include/__numeric/midpoint.h
YouTube
CppCon 2019: Marshall Clow “std::midpoint? How Hard Could it Be?”
http://CppCon.org
—
Discussion & Comments: https://www.reddit.com/r/cpp/
—
Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/CppCon/CppCon2019
—
The standards committee adopted "P0811: Well-behaved interpolation…
—
Discussion & Comments: https://www.reddit.com/r/cpp/
—
Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/CppCon/CppCon2019
—
The standards committee adopted "P0811: Well-behaved interpolation…
Зацените!
Проект, который по истории коммитов строит красивый таймлапс развития репозитория:
https://github.com/acaudwell/Gource
Видел такой видос как-то давно у майнкрафта, но не знал, что кто угодно может такой же сделать:
https://youtu.be/zRjTyRly5WA?si=Bg_tM7o3pWOwCqCO
Интересно, как он справится с каким-нибудь проектом с гигантским количеством контрибьютеров, вроде brew с их 10к разработчиков:
https://github.com/Homebrew/homebrew-core
Проект, который по истории коммитов строит красивый таймлапс развития репозитория:
https://github.com/acaudwell/Gource
Видел такой видос как-то давно у майнкрафта, но не знал, что кто угодно может такой же сделать:
https://youtu.be/zRjTyRly5WA?si=Bg_tM7o3pWOwCqCO
Интересно, как он справится с каким-нибудь проектом с гигантским количеством контрибьютеров, вроде brew с их 10к разработчиков:
https://github.com/Homebrew/homebrew-core
Есть очень известная проблема 38 года. Но мало кто знает, что похожее уже происходило в 2000х - событие называется Y2K.
Проблема заключался в том, что раньше в компьютерах год представлялся двумя последними цифрами, чтобы экономить память. А при выводе к этим цифрам просто дописывалось 19 в начало. Поэтому в 1999 при переходе к следующему тысячелетию ожидались глобальные проблемы с датами.
По прогнозам на устранение ущерба от внезапно наступившего 1900 или 19100 года потребуется от 400 миллионов до 600 миллиардов долларов (читай любая сумма).
Однако люди оказались не такими тупыми и заранее исправили ошибку, поэтому глобального отказа всех систем не произошло, хоть и были локальные курьезы.
Upd. Мне тут сказали, что проблема 2000 года наоборот более известна, чем проблема 38. Ну, видимо, от возраста зависит)
Проблема заключался в том, что раньше в компьютерах год представлялся двумя последними цифрами, чтобы экономить память. А при выводе к этим цифрам просто дописывалось 19 в начало. Поэтому в 1999 при переходе к следующему тысячелетию ожидались глобальные проблемы с датами.
По прогнозам на устранение ущерба от внезапно наступившего 1900 или 19100 года потребуется от 400 миллионов до 600 миллиардов долларов (читай любая сумма).
Однако люди оказались не такими тупыми и заранее исправили ошибку, поэтому глобального отказа всех систем не произошло, хоть и были локальные курьезы.
Upd. Мне тут сказали, что проблема 2000 года наоборот более известна, чем проблема 38. Ну, видимо, от возраста зависит)
F
Гитхаб больше не поддерживает SVN
Фанфэкт, что последний релиз SVN был всего 3 недели назад (я думал его уже похоронили давно)
Гитхаб больше не поддерживает SVN
Фанфэкт, что последний релиз SVN был всего 3 недели назад (я думал его уже похоронили давно)
Оказывается, в emacs есть встроенный психотерапевт, с которым можно поболтать))
Даже поставил его себе, чтобы поиграться
Включить доктора можно командой:
Нашел первый коммит, в котором этот доктор был добавлен в emacs, и знаете какой это год?1991! Что с лицом, copilot?
Если интересно, как это работает, то вот ссылка на описание: https://en.wikipedia.org/wiki/ELIZA - это специальная программа, которая задумывалась для того, чтобы проходить тест Тьюринга и которая была сделана еще в 196X году.
Upd. Кстати, для nvim есть такой плагин:
https://github.com/iagoleal/doctor.nvim
Даже поставил его себе, чтобы поиграться
Включить доктора можно командой:
M-x doctor
. В моем случае Esc + x
и набрать doctor.Нашел первый коммит, в котором этот доктор был добавлен в emacs, и знаете какой это год?
Если интересно, как это работает, то вот ссылка на описание: https://en.wikipedia.org/wiki/ELIZA - это специальная программа, которая задумывалась для того, чтобы проходить тест Тьюринга и которая была сделана еще в 196X году.
Upd. Кстати, для nvim есть такой плагин:
https://github.com/iagoleal/doctor.nvim
Очень хочется тоже сделать какой-то такой обучающий материал:
https://github.com/srush/GPU-Puzzles
Чтобы он был лаконичным, чтобы можно было легко запустить и были красивые и наглядные иллюстрации.
Надеюсь, однажды замотивируюсь достаточно сильно…
Можно, кстати, тоже коллаб заиспользовать, я даже специальный ноутбук уже делал, чтобы с параллельными алгоритмами из 17 плюсов можно было поиграться и ничего не устанавливать:
https://colab.research.google.com/drive/1_XmRWgpsLu4XmbachJ0oq9lsfbwqTueh?usp=sharing
https://github.com/srush/GPU-Puzzles
Чтобы он был лаконичным, чтобы можно было легко запустить и были красивые и наглядные иллюстрации.
Надеюсь, однажды замотивируюсь достаточно сильно…
Можно, кстати, тоже коллаб заиспользовать, я даже специальный ноутбук уже делал, чтобы с параллельными алгоритмами из 17 плюсов можно было поиграться и ничего не устанавливать:
https://colab.research.google.com/drive/1_XmRWgpsLu4XmbachJ0oq9lsfbwqTueh?usp=sharing
GitHub
GitHub - srush/GPU-Puzzles: Solve puzzles. Learn CUDA.
Solve puzzles. Learn CUDA. Contribute to srush/GPU-Puzzles development by creating an account on GitHub.
Миша пишет код
Итак, спустя 10 собесов, среди которых 6 финалов и архитектура, я отправляюсь разрабатывать ydb. Сегодня пока получал всякие доступы и вводился в курс дела, так что особо интересного ничего не могу рассказать. Но у меня очень большие ожидания, собираюсь…
Ну все, испытательный срок позади и работа, как и жизнь, потихоньку встает на понятные и предсказуемые рельсы.
Эти три месяца были супер интенсивными, я узнал целую кучу всего нового, провел часы в гдб и поймал все мыслимые и немыслимые ошибки. Поэтому в своем познании настолько преисполнился, что теперь у меня есть где-то миллиард заметок, которыми я очень хочу поделиться. Вероятно, некоторые посты надо будет согласовывать, но так даже прикольнее - как будто какой-то настоящий блогер.
Очень круто работать в коллективе, где каждый человек обладает какой-то ну просто запредельной экспертизой. Изо всех сил стараюсь не продалбываться, а впитывать и записывать каждую мысль (обсидиан раскрывается во всей красе).
По поводу постов: писать что-то каждый день оказалось такой же ловушкой, как и писать редко - звучит прикольно, но сохранять невозможно (простите за старческую отсылку). При этом, оказывается, после перерыва еще и страшно начинать снова писать: боишься, что первый пост теперь должен быть какой-то важный и особенный.
Поскольку в очередной раз подтвердилось, что без строгой регулярности я делать ничего не могу, то коммичусь теперь на 2 поста в неделю: один не позже среды, второй не позже субботы. Посмотрим, что из этого выйдет. По плану получится более интересный контент при сохранении хоть какой-то регулярности.
В кои-то веке подумал наперед и все свои ошибки, вопросы, а главное ответы на эти вопросы я записывал и структурировал. Однажды на волне мотивации собираюсь скомпоновать это все в большой материал с кодом и кишками C++.
Всем хорошей пятницы и спасибо за терпение!
Эти три месяца были супер интенсивными, я узнал целую кучу всего нового, провел часы в гдб и поймал все мыслимые и немыслимые ошибки. Поэтому в своем познании настолько преисполнился, что теперь у меня есть где-то миллиард заметок, которыми я очень хочу поделиться. Вероятно, некоторые посты надо будет согласовывать, но так даже прикольнее - как будто какой-то настоящий блогер.
Очень круто работать в коллективе, где каждый человек обладает какой-то ну просто запредельной экспертизой. Изо всех сил стараюсь не продалбываться, а впитывать и записывать каждую мысль (обсидиан раскрывается во всей красе).
По поводу постов: писать что-то каждый день оказалось такой же ловушкой, как и писать редко - звучит прикольно, но сохранять невозможно (простите за старческую отсылку). При этом, оказывается, после перерыва еще и страшно начинать снова писать: боишься, что первый пост теперь должен быть какой-то важный и особенный.
Поскольку в очередной раз подтвердилось, что без строгой регулярности я делать ничего не могу, то коммичусь теперь на 2 поста в неделю: один не позже среды, второй не позже субботы. Посмотрим, что из этого выйдет. По плану получится более интересный контент при сохранении хоть какой-то регулярности.
В кои-то веке подумал наперед и все свои ошибки, вопросы, а главное ответы на эти вопросы я записывал и структурировал. Однажды на волне мотивации собираюсь скомпоновать это все в большой материал с кодом и кишками C++.
Всем хорошей пятницы и спасибо за терпение!
Миша пишет код
Мой рабочий сетап - vim + tmux, причем я очень сильно люблю tmux - все через него делаю. Поэтому у меня всегда на компе открыто штук 10-15 tmux сессий. И меня все время раздражало, что во всех панелях (окнах) одна и та же общая история команд. Хочется, чтобы…
Апдейт по моим попыткам улучшить жизнь в терминале.
Остался очень доволен идеей с разными историями в разных панелях тмукса - суперсильно экономит время на поиск нужной команды и мотивирует каждую панель отводить под конкретные задачи. Из минусов: все-таки перезагрузка компьютера происходит болезненно - приходится руками переименовывать файлики с историями из-за того, что тмукс их начинает нумеровать с нуля. Однажды решу этот вопрос, но не сегодня...
Попробовал попользоваться atuin, про который писал где-то выше. По идее он хранит всю историю команд в базе данных и позволяет умно искать по истории. Но он ощущается каким-то тяжеленным комбаином. Я не нашел в себе мотивации учить еще дополнительный DSL, чтобы просто искать по истории, а без него смысл сходит почти на нет. Вероятно, это полезно для системного администрирования или вроде того, но я не так много разных команды пишу, чтобы настолько сильно запариваться. В итоге почти все время по старинке использовал алиасы и
Наткнулся на видос про zoxide - более умный
Понял, что меня раздражает zsh. Из всех его возможностей я пользуюсь только тем, что у него регистронезависимый автокомплит. При этом ловлю все недостатки: тормоза при использовании внутри большого репозитория из-за вывода имени ветки на каждую команду (отрубил в итоге), долго запускается в первый раз, постоянно предлагает обновить его (тоже отрубил). Буду искать что-то более простое (мб даже обычный баш).
Остался очень доволен идеей с разными историями в разных панелях тмукса - суперсильно экономит время на поиск нужной команды и мотивирует каждую панель отводить под конкретные задачи. Из минусов: все-таки перезагрузка компьютера происходит болезненно - приходится руками переименовывать файлики с историями из-за того, что тмукс их начинает нумеровать с нуля. Однажды решу этот вопрос, но не сегодня...
Попробовал попользоваться atuin, про который писал где-то выше. По идее он хранит всю историю команд в базе данных и позволяет умно искать по истории. Но он ощущается каким-то тяжеленным комбаином. Я не нашел в себе мотивации учить еще дополнительный DSL, чтобы просто искать по истории, а без него смысл сходит почти на нет. Вероятно, это полезно для системного администрирования или вроде того, но я не так много разных команды пишу, чтобы настолько сильно запариваться. В итоге почти все время по старинке использовал алиасы и
ctrl+r
. Еще, кстати, меня напрягает, что они пушат использование их базы данных для хранения истории, что во-первых звучит небезопасно, а во-вторых выглядит как очень большой overkill.Наткнулся на видос про zoxide - более умный
cd
. Вот сам видос. Если кратко, то он подсчитывает статистику по переходам между директориями и на ее основе умеет угадывать путь по некоторым частям из него. Например, чтобы сделать cd a/b/c/d
, можно набрать просто z d
или z b d
- второе особенно актуально, потому что часто не помнишь весь путь, а только какие-то куски из него. Выглядит многообещающе, попробую заценить. При этом он еще интегрируется с fzf, что в моих глазах всегда +10 очков проекту дает)Понял, что меня раздражает zsh. Из всех его возможностей я пользуюсь только тем, что у него регистронезависимый автокомплит. При этом ловлю все недостатки: тормоза при использовании внутри большого репозитория из-за вывода имени ветки на каждую команду (отрубил в итоге), долго запускается в первый раз, постоянно предлагает обновить его (тоже отрубил). Буду искать что-то более простое (мб даже обычный баш).
Поскольку я теперь ковыряюсь с базами данных, то параллельно занимаюсь ускоренным закрыванием пробелов в знаниях
Мне сказали для начала посмотреть видосы CMU (Carnegie Mellon University) по базам данных.
Также я отправился смотреть их же курс, который идет прямо сейчас и который мега качественно сделан: со ссылками, видео и материалами.
https://15721.courses.cs.cmu.edu/spring2024/schedule.html
Делюсь вот материалами, может тоже будет интересно. Даже просто в общеобразовательных целях советую глянуть, чтобы в общих чертах представлять, как там данные внутри баз крутятся
P.S. каждый раз немного расстраиваюсь, когда нахожу крутые бесплатные материалы, что есть столько возможностей узнать новое, а я вместо этого залипаю в твитор....
Мне сказали для начала посмотреть видосы CMU (Carnegie Mellon University) по базам данных.
Также я отправился смотреть их же курс, который идет прямо сейчас и который мега качественно сделан: со ссылками, видео и материалами.
https://15721.courses.cs.cmu.edu/spring2024/schedule.html
Делюсь вот материалами, может тоже будет интересно. Даже просто в общеобразовательных целях советую глянуть, чтобы в общих чертах представлять, как там данные внутри баз крутятся
P.S. каждый раз немного расстраиваюсь, когда нахожу крутые бесплатные материалы, что есть столько возможностей узнать новое, а я вместо этого залипаю в твитор....
Зацените, какие штуки оказывается можно делать в си:
https://godbolt.org/z/TfWhjdb74
Вообще на сишный код не похоже)
Эта штука называется
В частности из-за этого стиля
Однако, в 23 стандарте запретили объявлять функции без прототипов, поэтому там код уже компилироваться не будет:
https://godbolt.org/z/qd4KW4PMc
До 23 стандарта получить ошибку компиляции в таком коде можно, если добавить прототип (тут это уже функция принимающая 0 аргументов):
P.S.
Сам наткнулся на этот факт тут - https://habr.com/en/articles/786096/ (но надо читать еще и комменты, так как в статье есть ошибки)
Более подробно про прототипы можно глянуть вот тут:
https://stefansf.de/post/declaring-defining-and-prototyping-functions/
#include <stdio.h>
int sum(a, b) int a; long b;
{
return a + b;
}
int main() {
printf("%d\n", sum(1, 3));
return 0;
}
https://godbolt.org/z/TfWhjdb74
Вообще на сишный код не похоже)
Эта штука называется
K&R C
, но что-то полезное лучше искать по K&R definition style. Такой стиль поддерживается компиляторами си, но не c++.В частности из-за этого стиля
void foo();
это не "функция принимающая 0 аргументов", а "функция без прототипа". Из-за чего такой код компилируется, хотя и может приводить к УБ:
#include <stdio.h>
int sum() {
return 5;
}
int main() {
printf("%d\n", sum(1, 3));
return 0;
}
Однако, в 23 стандарте запретили объявлять функции без прототипов, поэтому там код уже компилироваться не будет:
https://godbolt.org/z/qd4KW4PMc
До 23 стандарта получить ошибку компиляции в таком коде можно, если добавить прототип (тут это уже функция принимающая 0 аргументов):
#include <stdio.h>
int sum(void) {
return 5;
}
int main() {
printf("%d\n", sum(1, 3));
return 0;
}
P.S.
Сам наткнулся на этот факт тут - https://habr.com/en/articles/786096/ (но надо читать еще и комменты, так как в статье есть ошибки)
Более подробно про прототипы можно глянуть вот тут:
https://stefansf.de/post/declaring-defining-and-prototyping-functions/
godbolt.org
Compiler Explorer - C (x86-64 gcc 13.2)
int sum(a, b) int a; long b;
{
return a + b;
}
int main() {
printf("%d\n", sum(1, 3));
return 0;
}
{
return a + b;
}
int main() {
printf("%d\n", sum(1, 3));
return 0;
}
Сижу разбираюсь в технических особенностях ситуации с бэкдором в XZ. Тяжело идет, знаний в области безопасности у меня совсем мало. С удовольствием посмотрел бы какой-нибудь 4х часовой разбор.
Объявляю воскресную викторину под названием "Попробуй не написать lgtm на PR, в котором отключается landlock в xz":
Сам ПР:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
Справка: landlock (1)(2) - система безопасности, которая позволяет процессу запуститься в песочнице с ограниченными правами на некоторые действия.
Подсказка 1.
Проблема в первом файле
Подсказка 2.
Проблема в одном символе и это точка
Подсказка 3.
Сразу после инклюдов
Даже зная инфу из второй подсказки, я все равно с трудом нахожу ошибку...
Пояснение:
В Cmakelists проверялось, поддерживается ли в системе landlock. Раньше проверка выполнялась просто по наличию соответствующего заголовочного файла. В ПР же поддержка landlock определяется по тому, компилируется ли небольшой сниппет кода. Если код не компилируется, значит landlock не поддерживается, "HAVE_LINUX_LANDLOCK" выставляется в false и песочница не включается. Из-за лишней точки код перестает компилироваться и landlock остается выключенным на всех системах.
Обсуждение:
https://news.ycombinator.com/item?id=39874404
Объявляю воскресную викторину под названием "Попробуй не написать lgtm на PR, в котором отключается landlock в xz":
Сам ПР:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
Справка: landlock (1)(2) - система безопасности, которая позволяет процессу запуститься в песочнице с ограниченными правами на некоторые действия.
Подсказка 1.
Подсказка 2.
Подсказка 3.
Даже зная инфу из второй подсказки, я все равно с трудом нахожу ошибку...
Пояснение:
Обсуждение:
https://news.ycombinator.com/item?id=39874404
Зацените, какой прикол
Вот тут подробнее можно посмотреть:
https://unix.stackexchange.com/questions/73713/how-safe-is-it-to-cat-an-arbitrary-file
Создать такой же файл:
Вот тут подробнее можно посмотреть:
https://unix.stackexchange.com/questions/73713/how-safe-is-it-to-cat-an-arbitrary-file
Создать такой же файл:
echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n\033[A\033[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' > demo.sh
chmod a+x demo.sh
Копался в случайных issues на гитхабе и нашел интересное обсуждение:
https://github.com/rust-lang/rust/issues/28728
TLDR:
Раст ловил ошибки в бесконечных циклах из-за того, что LLVM привык выкидывать такие циклы в плюсах.
Чуть более развернуто:
Компилятор C++ в некоторых случаях может выбрасывать бесконечные циклы. Все к этому привыкли и пугают детей вот такими примерами с УБ: https://godbolt.org/z/KKa34Mjar.
Но в программах на Rust не бывает УБ*, бесконечные циклы разрешены и поэтому примеры с УБ (раз) (два) пугают уже не только детей.
Ошибки выше обусловлены тем, что LLVM, которым компилируется и Rust, и C++, выбрасывал бесконечные циклы, так как считал, что выполнение программы должно к чему-то приводить.
Проблема в итоге починилась в 2021 году спустя 6 лет после обнаружения в расте и спустя 15! лет после обнаружения в си. Решением стало добавление атрибута mustprogress в LLVM IR для циклов в языках с forward progress guarantee.
Интересно, кстати, что в расте предлагалось добавлять
к циклам, чтобы создать side effect, запрещающий компилятору выбрасывать бесконечные циклы.
Мораль:
Ты можешь быть бесконечно без УБ, но какой в этом толк, если твой программист плачет
P.S.
Еще всякие рандомные ссылки, которые я нашел, пока разбирался:
1. Forward progress guarantees: Base definitions
2. Why undefined behavior for infinite loops
3. The as-if rule
4. C Compilers Disprove Fermat’s Last Theorem
5. Trivial infinite loops are not Undefined Behavior
https://github.com/rust-lang/rust/issues/28728
TLDR:
Раст ловил ошибки в бесконечных циклах из-за того, что LLVM привык выкидывать такие циклы в плюсах.
Чуть более развернуто:
Компилятор C++ в некоторых случаях может выбрасывать бесконечные циклы. Все к этому привыкли и пугают детей вот такими примерами с УБ: https://godbolt.org/z/KKa34Mjar.
Но в программах на Rust не бывает УБ*, бесконечные циклы разрешены и поэтому примеры с УБ (раз) (два) пугают уже не только детей.
Ошибки выше обусловлены тем, что LLVM, которым компилируется и Rust, и C++, выбрасывал бесконечные циклы, так как считал, что выполнение программы должно к чему-то приводить.
Проблема в итоге починилась в 2021 году спустя 6 лет после обнаружения в расте и спустя 15! лет после обнаружения в си. Решением стало добавление атрибута mustprogress в LLVM IR для циклов в языках с forward progress guarantee.
Интересно, кстати, что в расте предлагалось добавлять
unsafe {asm!("" :::: "volatile")}
к циклам, чтобы создать side effect, запрещающий компилятору выбрасывать бесконечные циклы.
Мораль:
Ты можешь быть бесконечно без УБ, но какой в этом толк, если твой программист плачет
P.S.
Еще всякие рандомные ссылки, которые я нашел, пока разбирался:
1. Forward progress guarantees: Base definitions
2. Why undefined behavior for infinite loops
3. The as-if rule
4. C Compilers Disprove Fermat’s Last Theorem
5. Trivial infinite loops are not Undefined Behavior
GitHub
LLVM loop optimization can make safe programs crash · Issue #28728 · rust-lang/rust
The following snippet crashes when compiled in release mode on current stable, beta and nightly: enum Null {} fn foo() -> Null { loop { } } fn create_null() -> Null { let n = foo(); let mut i...
Пытался тут на досуге перемапить видео из полноценного rgb в 16 цветов (даже не спрашивайте).
Решил, что я самый умный и не буду это делать через серый цвет, а буду для каждого исходного пикселя искать наиболее близкий цвет из 16 по метрике Евклида:
Оказалось, что такой подход работает плохо и человеческое ощущение близости цветов может сильно отличаться от "компьютерного", особенно, когда нужно выбрать похожий всего из 16.
Википедия советует вводить веса для разных компонентов цвета, но это тоже плохо работает. В итоге я сдался и сделал через серый, что получилось вполне сносно.
Однако, мысль, что простыми квадратами я не могу нормально сравнивать цвета никак не ложилась мне в голову. Возможно, людям, которые работают с цветами это очевидно, но мне хотелось прямо наглядно в этом убедиться. Поэтому я смастерил небольшой тул, чтобы визуализировать цвета и смотреть на расстояния между ними.
Прикладываю мою js поделку. Там есть 3 пресета, на которых можно наглядно увидеть, как ошибается метрика. Также там есть рандом и "умный" рандом, который сгенерирует цвета, в которых Евклид будет не прав (почти всегда). Ну и цвета можно руками менять.
https://lll-phill-lll.github.io/colordiff/
В качестве "человеческой" оценки я использовал метрику CIEDE2000, которая вполне совпадает с моим собственным ощущением близости цветов. И которая в коде выглядит просто как случайные умножения случайных чисел.
На скрине из тула видно, что Евклид считает зеленый более близким к оранжевому, чем к кислотно зеленому. (ну надеюсь, что видно, хороший интерфейс я сделать так и не осилил).
В общем, надеюсь интересно будет потыкать на Smart Random и посравнивать свои внутренние ощущение с ощущениями Евклида)
Кстати, интересный цикл статей про цвета и связанную с ними математику: https://samgoree.github.io/2019/07/13/color_theory_2.html
Решил, что я самый умный и не буду это делать через серый цвет, а буду для каждого исходного пикселя искать наиболее близкий цвет из 16 по метрике Евклида:
l = (r1 - r2)² + (g1 - g2)² + (b1 - b2)²
Оказалось, что такой подход работает плохо и человеческое ощущение близости цветов может сильно отличаться от "компьютерного", особенно, когда нужно выбрать похожий всего из 16.
Википедия советует вводить веса для разных компонентов цвета, но это тоже плохо работает. В итоге я сдался и сделал через серый, что получилось вполне сносно.
Однако, мысль, что простыми квадратами я не могу нормально сравнивать цвета никак не ложилась мне в голову. Возможно, людям, которые работают с цветами это очевидно, но мне хотелось прямо наглядно в этом убедиться. Поэтому я смастерил небольшой тул, чтобы визуализировать цвета и смотреть на расстояния между ними.
Прикладываю мою js поделку. Там есть 3 пресета, на которых можно наглядно увидеть, как ошибается метрика. Также там есть рандом и "умный" рандом, который сгенерирует цвета, в которых Евклид будет не прав (почти всегда). Ну и цвета можно руками менять.
https://lll-phill-lll.github.io/colordiff/
В качестве "человеческой" оценки я использовал метрику CIEDE2000, которая вполне совпадает с моим собственным ощущением близости цветов. И которая в коде выглядит просто как случайные умножения случайных чисел.
На скрине из тула видно, что Евклид считает зеленый более близким к оранжевому, чем к кислотно зеленому. (ну надеюсь, что видно, хороший интерфейс я сделать так и не осилил).
В общем, надеюсь интересно будет потыкать на Smart Random и посравнивать свои внутренние ощущение с ощущениями Евклида)
Кстати, интересный цикл статей про цвета и связанную с ними математику: https://samgoree.github.io/2019/07/13/color_theory_2.html
Пропустил, что вчера было ровно 33 года с первого релиза vim.
В честь этого 3+3 прикола в лучшем текстовом редакторе Microsoft Word:
1.
2.
3.
4.
5.
6.
В честь этого 3+3 прикола в лучшем текстовом редакторе Microsoft Word:
1.
:smile
- нарисовать смайл (🤯). nvim, кстати, на это выдает NOPE и рисует grumpy cat.2.
:TOhtml
- сохранить текущий файл в виде HTML с подсветкой синтаксиса (скриншот по-дедовски)3.
vim -y
- запустить вим в детском режиме. Копировать/вставить/отменить на ctrl+c/ctrl+v/ctrl+z, включена мышь и все такое. Из insert режима выйти становится невозможно. Из вима, кстати, тоже.4.
ggg?G
- закодировать весь файл в rot13. Полезно, когда пишешь на php и в комнату резко заходит мама.5.
vim <url>
- редактировать файл по урлу, который вим сам скачает.6.
:earlier 3m
- откатить файл к состоянию, которое было 3 минуты назад. Также есть :later
. Пришел на работу, набрал :later 8h
и идешь пить кофе.Неплохая пара получилась сегодня.
По плану было поговорить про функции для работы с файлами в си: readdir, stat, access и все такое. Решил, что будет более наглядно показывать не просто абстрактное использование функций, а напрогать что-то целостное и по ходу обсуждать новый материал, если понадобится.
В итоге написали собственный
Обычно страшно вживую код писать, потому что волнуешься и мозг только наполовину работает + надо говорить что-то. Но попробовал, получилось славно и даже достаточно динамично. Особо и не затупил нигде)
Конспект вот скрафтил по тому, как работают права:
https://github.com/lll-phill-lll/hse_caos_practice/blob/master/12-fs/README.md
Ну и запись пары:
https://youtu.be/eMnMRuf1lNc
https://vkvideo.ru/video-221776054_456239046
По плану было поговорить про функции для работы с файлами в си: readdir, stat, access и все такое. Решил, что будет более наглядно показывать не просто абстрактное использование функций, а напрогать что-то целостное и по ходу обсуждать новый материал, если понадобится.
В итоге написали собственный
ls -l.
Он хорошо покрыл материал: и про биты прав поговорили и по директориям походили, обсудили inode и symlink. Цвета всякие разные поиспользовали в зависимости от типа файла.Обычно страшно вживую код писать, потому что волнуешься и мозг только наполовину работает + надо говорить что-то. Но попробовал, получилось славно и даже достаточно динамично. Особо и не затупил нигде)
Конспект вот скрафтил по тому, как работают права:
https://github.com/lll-phill-lll/hse_caos_practice/blob/master/12-fs/README.md
Ну и запись пары:
https://youtu.be/eMnMRuf1lNc
https://vkvideo.ru/video-221776054_456239046
YouTube
Работа с файлами: inode, readdir, lstat, symlink, rwxrwSrwT
Пишем свой ls -l.
Узнаем, как обходить директорию с помощью opendir и readdir.
Получим данные файла через stat.
Разбираемся, как работают права, что такое inode
Архитектура компьютера и операционные системы.
Семинарское занятие 238 группы ФКН ПМИ. НИУ…
Узнаем, как обходить директорию с помощью opendir и readdir.
Получим данные файла через stat.
Разбираемся, как работают права, что такое inode
Архитектура компьютера и операционные системы.
Семинарское занятие 238 группы ФКН ПМИ. НИУ…