Тут два аспекта. Стандартно, для вывода можно было использовать прерывания 10h (BIOS) и 21h (DOS). Конечно, Turbo Vision не использовала эти прерывания, потому что они работали медленно.
Там был собственный метод вывода и, конечно, он работал через видеопамять. Но как он вызывался? Через пользовательское прерывание 60h (или 61h, я сейчас уже не помню). Пользовательские прерывания отдавались на откуп программистам, их можно было использовать, как угодно. В Turbo Vision — для вывода.
Почему этот метод работал быстрее, чем прерывания BIOS? Там были режимы "скопировать прямоугольную область на экран", "повторить символ N раз" (это для повторения символов). В BIOS и DOS привязаны к курсору: чтобы вывести символ, надо передвинуть курсор. Это было медленно. Простое копирование в видеопамять без привязки к курсору — быстро.
Некоторые детали могут не соответствовать действительности. История из 92-го года, больше 30-ти лет прошло.
Я не знаю, что такое Graphics Vision. Тогда у ребят в Turbo Pascal, кажется, 6-й версии была текстовая GUI библиотека Turbo Vision. Оказалось, что весь её вывод сконцентрирован буквально в одном пользовательском прерывании, если не ошибаюсь, 60h.
Мы переводили экран в графический режим при старте, перехватывали прерывание и там был код, который выводил текст в графических режимах 80060016 или 64040016. Думаю, мы не одни такие были, так что наверное были и другие похожие решения.
В начале 90-х принимал участие в переводе Turbo Vision в графический режим для новых тогда адаптеров SVGA. Вдоль и поперёк перечитывал книги Джордейна и Нортона, которые рассказывали, как управлять адаптерами EGA. Естественно, делал на языке ассемблера.
Это не так круто, как эффект Фехнера (я про него и не знал до прочтения статьи), но где-то рядом. Испытал острое чувство ностальгии. Спасибо.
Здесь есть проблема в коде. В .NET double.Epsilon — это не то же самое, что DBL_EPSILON из стандартной библиотеки C. Давняя проблема, которая тянется с момента появления .NET.
В C/C++ под эпсилоном понимают максимальную возможную точность. Формальное определение: это такое минимальное число, при котором выполняется неравенство DBL_EPSILON + 1.0 != 1.0. Используется для сравнения чисел друг с другом, при этом числа не должны быть равны нулю, иначе смысл сравнения теряется.
Если хотите сравнивать с нулём, нужно использовать значение DBL_MIN — это минимальное представимое нормализованное число. Отсекает все ненормализованные числа, приравнивая их к нулю.
В .NET значение double.Epslion — совершенно бесполезное в принципе представимое минимальное число. Оно даже ненормализованное, то есть там значимых бит меньше, чем 52.
Его нельзя использовать ни для чего, в том числе для определения слишком маленьких чисел, потому что чисел меньше не бывает. Оно на 300 порядков меньше, чем DBL_EPSILON. В C/C++ ему соответствует константа DBL_TRUE_MIN.
Самый простой способ поправить код: использовать double.MinValue вместо dboule.Epslion там, где сравниваете с 0, и использовать double.BitIncrement вместо DBL_EPSILON. Это аналог, который появился, если не ошибаюсь, в 6-м .NET Core. Значения констант, чтобы не искать, можно посмотреть в MSDN.
Яндекс Школа оплачивает проезд и проживание тем, кто прошёл отборочные. У Т1 не знаю точно, как всё устроено, но это кемпинг, то есть все живут где-то в живописном месте за городом. И у Яндекса, и у Т1 есть офисы в разных городах Москвы и есть возможность удалённой работы.
Я сам давным-давно сеньор, у меня, наверное, даже не пик карьеры, а закат. Проблем с поиском работы нет очень давно. Но мне не очень нравится, что толковым студентам трудно найти работу, потому что в индустрии все боятся людей, прошедших двухмесячные курсы.
Мой совет — искать стажировки, которые проходят крупные компании. Вот Яндекс.Школа в этом году летом работает, есть шанс хорошо провести время и попасть на работу в Яндекс. Плюс Т1 собирается проводить летний кэмп и тоже с возможностью потом устроится на работу.
Это как бы ещё один совет к тем, что к статье, надеюсь, что всё-таки полезный, а не вредный.
Да, вы совершенно правы, это моя ошибка. Я просто метался в этом месте, сначала написал тысячу, потому подумал, что это выбивается из примера с вопросами. Никто же не будет задавать тысячу вопросов.
Поменял на двадцать, забыл убрать тысячу. Решил убрать тысячу, убрал двадцать. Всё потому, что середина рабочего дня, тем более понедельника. Созвоны, программирование, опять созвоны, опять программирование, и где-то в перерывах исправление ошибок.
Очень здорово, что где-то хорошая документация есть. Да она, очевидно есть. Пусть MSDN это проект коммерческой компании, там люди за зарплату пишут. Но ведь и во многих open source проектах с документацией все в порядке.
Просто почему то в разнообразных легаси проектах с документацией всё плохо.
Ну, я писал о том, как реально бывает, а не о том, как хотелось бы, чтобы было. Я согласен, что документация должна быть хорошей. Но на практике она почему то везде плохая. Ну, почти везде.
Часто её заставляют писать программистов. А писать документацию надо уметь, и не все программисты умеют. И начинают они с того, что знают лучше всего: с потрохов программы.
В Nix общие библиотеки всё-таки разделяются между всеми программами. Там есть одно общее хранилище, поэтому, если одна и та же библиотека нужна пяти программам, она окажется в этом хранилище только один раз.
Пассивная агрессия всё-таки вполне объективный термин. Если вы погуглите passive-aggressive behavior definition, то обнаружите на первой странице медицинские и психологические сайты. Даже на странице вики есть ссылки на научные труды.
В то же время toxicity definition ведёт на разного рода интернет-словари.
В этом нет никакой фантазии или каких-то образов с Васей и Петей. Всё довольно приземлённо.
Кажется, что на английском можно не переустанавливать, достаточно добраться до Settings и там добавить английский лейаут.
Через конфигурацию, конечно, тоже можно, просто я не самый большой специалист в NixOS. Как я уже говорил, я программист, мне хватает, когда удаётся написать конфигурацию, которой достаточно для сборки проектов. Как и раньше, могу посоветовать спросить в Tg чате NixOS RU. Там гораздо больше специалистов.
Тоже обратил внимание, что токсичность — понятие субъективное. Если пассивная агрессия, например, это медицинский термин, у которого есть определение, какая-то научная база и полемика, то токсичность — бытовое слово.
Заметил, кстати, что тот, кто больше всех обвиняет других в токсичности --- самый неприятный из коллег. Заставляет задуматься.
По первому вопросу я вам не помогу, у меня опыта с зашифрованными разделами нет. Скорее, всего, вам смогут помочь в Tg-чате NixOS RU.
По второму: сам я ставился с английским языком, потом в GUI зашёл в Settings/Keyboard и добавил там русский язык и раскладку. По умолчанию языки переключаются через Win+Space, но клавиши можно поменять.
Я менял через командную строку, потому что "моя" комбинация не ставится через GUI. Делал вот по этому ответу на Ask Ubuntu.
Да, обычно создают файл shell.nix, где получают пути к деривациям (пакетам) по именам.
Далее можно их добавить в существующие переменные окружения, либо описать новые. Я не силён в gcc, кажется, он использует переменные C_INCLUDE_PATH и CPLUS_INCLUDE_PATH.
Затем в каталоге запускаете nix-shell, выполняется shell.nix и у вас воссоздаётся нужная среда для разработки.
По первому вопросу — пакеты можно делать самостоятельно, так поступает большинство разработчиков. Для этого надо освоить язык программирования Nix и разобраться в деталях.
Есть неофициальная документация по этому вопросу, Nix Pills. Сейчас я её перевожу и публикую здесь на Habr. Можете прочитать быстро в оригинале, если владеете английским, или подождите, где-то в течение пары месяцев я закончу.
По второму вопросу — но машине одно хранилище пакетов Nix, в каталоге /nix/store, так что пакеты дублироваться не будут. Правда, есть тонкость. На обычных дистрибутивах, чтобы использовать Nix, надо зайти под пользователем nix. На NixOS это может быть действительно многопользовательская система.
С другой стороны, вам может быть, и не надо именно так детально управлять конфигурацией пользователей. В каждый проект можно сложить по файлу shell.nix. Перед работой запускать nix-shell, а по окончании выходить из него. В shell.nix описать, какие именно пакеты нужны для работы. Это окружение смогут разделить все участники проекта.
Тут два аспекта. Стандартно, для вывода можно было использовать прерывания 10h (BIOS) и 21h (DOS). Конечно, Turbo Vision не использовала эти прерывания, потому что они работали медленно.
Там был собственный метод вывода и, конечно, он работал через видеопамять. Но как он вызывался? Через пользовательское прерывание 60h (или 61h, я сейчас уже не помню). Пользовательские прерывания отдавались на откуп программистам, их можно было использовать, как угодно. В Turbo Vision — для вывода.
Почему этот метод работал быстрее, чем прерывания BIOS? Там были режимы "скопировать прямоугольную область на экран", "повторить символ N раз" (это для повторения символов). В BIOS и DOS привязаны к курсору: чтобы вывести символ, надо передвинуть курсор. Это было медленно. Простое копирование в видеопамять без привязки к курсору — быстро.
Некоторые детали могут не соответствовать действительности. История из 92-го года, больше 30-ти лет прошло.
Я не знаю, что такое Graphics Vision. Тогда у ребят в Turbo Pascal, кажется, 6-й версии была текстовая GUI библиотека Turbo Vision. Оказалось, что весь её вывод сконцентрирован буквально в одном пользовательском прерывании, если не ошибаюсь, 60h.
Мы переводили экран в графический режим при старте, перехватывали прерывание и там был код, который выводил текст в графических режимах 80060016 или 64040016. Думаю, мы не одни такие были, так что наверное были и другие похожие решения.
В начале 90-х принимал участие в переводе Turbo Vision в графический режим для новых тогда адаптеров SVGA. Вдоль и поперёк перечитывал книги Джордейна и Нортона, которые рассказывали, как управлять адаптерами EGA. Естественно, делал на языке ассемблера.
Это не так круто, как эффект Фехнера (я про него и не знал до прочтения статьи), но где-то рядом. Испытал острое чувство ностальгии. Спасибо.
Выздоравливайте!
Здесь есть проблема в коде. В .NET
double.Epsilon— это не то же самое, чтоDBL_EPSILONиз стандартной библиотеки C. Давняя проблема, которая тянется с момента появления .NET.В C/C++ под эпсилоном понимают максимальную возможную точность. Формальное определение: это такое минимальное число, при котором выполняется неравенство
DBL_EPSILON + 1.0 != 1.0.Используется для сравнения чисел друг с другом, при этом числа не должны быть равны нулю, иначе смысл сравнения теряется.
Если хотите сравнивать с нулём, нужно использовать значение
DBL_MIN— это минимальное представимое нормализованное число. Отсекает все ненормализованные числа, приравнивая их к нулю.В .NET значение
double.Epslion— совершенно бесполезное в принципе представимое минимальное число. Оно даже ненормализованное, то есть там значимых бит меньше, чем 52.Его нельзя использовать ни для чего, в том числе для определения слишком маленьких чисел, потому что чисел меньше не бывает. Оно на 300 порядков меньше, чем
DBL_EPSILON. В C/C++ ему соответствует константаDBL_TRUE_MIN.Самый простой способ поправить код: использовать
double.MinValueвместоdboule.Epslionтам, где сравниваете с 0, и использоватьdouble.BitIncrementвместоDBL_EPSILON. Это аналог, который появился, если не ошибаюсь, в 6-м .NET Core. Значения констант, чтобы не искать, можно посмотреть в MSDN.Думаю, тут всё просто. На стажировках джуны, они по определению не могут знать бизнес-логику. Учите алгоритмы.
Яндекс Школа оплачивает проезд и проживание тем, кто прошёл отборочные. У Т1 не знаю точно, как всё устроено, но это кемпинг, то есть все живут где-то в живописном месте за городом. И у Яндекса, и у Т1 есть офисы в разных городах Москвы и есть возможность удалённой работы.
Я сам давным-давно сеньор, у меня, наверное, даже не пик карьеры, а закат. Проблем с поиском работы нет очень давно. Но мне не очень нравится, что толковым студентам трудно найти работу, потому что в индустрии все боятся людей, прошедших двухмесячные курсы.
Мой совет — искать стажировки, которые проходят крупные компании. Вот Яндекс.Школа в этом году летом работает, есть шанс хорошо провести время и попасть на работу в Яндекс. Плюс Т1 собирается проводить летний кэмп и тоже с возможностью потом устроится на работу.
Это как бы ещё один совет к тем, что к статье, надеюсь, что всё-таки полезный, а не вредный.
Да, вы совершенно правы, это моя ошибка. Я просто метался в этом месте, сначала написал тысячу, потому подумал, что это выбивается из примера с вопросами. Никто же не будет задавать тысячу вопросов.
Поменял на двадцать, забыл убрать тысячу. Решил убрать тысячу, убрал двадцать. Всё потому, что середина рабочего дня, тем более понедельника. Созвоны, программирование, опять созвоны, опять программирование, и где-то в перерывах исправление ошибок.
Спасибо. Всё исправил, теперь там двадцать
Очень здорово, что где-то хорошая документация есть. Да она, очевидно есть. Пусть MSDN это проект коммерческой компании, там люди за зарплату пишут. Но ведь и во многих open source проектах с документацией все в порядке.
Просто почему то в разнообразных легаси проектах с документацией всё плохо.
Я совершенно согласен. Правда, по какой-то причине я ни разу не видел технического писателя ни в одной из команд, где я работал.
Ну, я писал о том, как реально бывает, а не о том, как хотелось бы, чтобы было. Я согласен, что документация должна быть хорошей. Но на практике она почему то везде плохая. Ну, почти везде.
Часто её заставляют писать программистов. А писать документацию надо уметь, и не все программисты умеют. И начинают они с того, что знают лучше всего: с потрохов программы.
Да, согласен. Но здесь у меня перевод, я стараюсь не сильно отходить от оригинального текста. Там у Скотта wrapper type.
В Nix общие библиотеки всё-таки разделяются между всеми программами.
Там есть одно общее хранилище, поэтому, если одна и та же библиотека нужна пяти программам, она окажется в этом хранилище только один раз.
Пассивная агрессия всё-таки вполне объективный термин. Если вы погуглите passive-aggressive behavior definition, то обнаружите на первой странице медицинские и психологические сайты. Даже на странице вики есть ссылки на научные труды.
В то же время toxicity definition ведёт на разного рода интернет-словари.
В этом нет никакой фантазии или каких-то образов с Васей и Петей. Всё довольно приземлённо.
Кажется, что на английском можно не переустанавливать, достаточно добраться до Settings и там добавить английский лейаут.
Через конфигурацию, конечно, тоже можно, просто я не самый большой специалист в NixOS. Как я уже говорил, я программист, мне хватает, когда удаётся написать конфигурацию, которой достаточно для сборки проектов. Как и раньше, могу посоветовать спросить в Tg чате NixOS RU. Там гораздо больше специалистов.
Тоже обратил внимание, что токсичность — понятие субъективное. Если пассивная агрессия, например, это медицинский термин, у которого есть определение, какая-то научная база и полемика, то токсичность — бытовое слово.
Заметил, кстати, что тот, кто больше всех обвиняет других в токсичности --- самый неприятный из коллег. Заставляет задуматься.
По первому вопросу я вам не помогу, у меня опыта с зашифрованными разделами нет. Скорее, всего, вам смогут помочь в Tg-чате NixOS RU.
По второму: сам я ставился с английским языком, потом в GUI зашёл в Settings/Keyboard и добавил там русский язык и раскладку. По умолчанию языки переключаются через Win+Space, но клавиши можно поменять.
Я менял через командную строку, потому что "моя" комбинация не ставится через GUI. Делал вот по этому ответу на Ask Ubuntu.
Да, обычно создают файл shell.nix, где получают пути к деривациям (пакетам) по именам.
Далее можно их добавить в существующие переменные окружения, либо описать новые. Я не силён в gcc, кажется, он использует переменные
C_INCLUDE_PATHиCPLUS_INCLUDE_PATH.Затем в каталоге запускаете nix-shell, выполняется shell.nix и у вас воссоздаётся нужная среда для разработки.
Да, вопросы можно задать в группе Tg, посвящённой Nix и NixOS: https://t.me/ru_nixos
Я не на все могу ответить, потому что я программист и у меня конфиги очень простые, буквально на несколько строк.
По первому вопросу — пакеты можно делать самостоятельно, так поступает большинство разработчиков. Для этого надо освоить язык программирования Nix и разобраться в деталях.
Есть неофициальная документация по этому вопросу, Nix Pills. Сейчас я её перевожу и публикую здесь на Habr. Можете прочитать быстро в оригинале, если владеете английским, или подождите, где-то в течение пары месяцев я закончу.
По второму вопросу — но машине одно хранилище пакетов Nix, в каталоге /nix/store, так что пакеты дублироваться не будут. Правда, есть тонкость. На обычных дистрибутивах, чтобы использовать Nix, надо зайти под пользователем nix. На NixOS это может быть действительно многопользовательская система.
С другой стороны, вам может быть, и не надо именно так детально управлять конфигурацией пользователей. В каждый проект можно сложить по файлу shell.nix. Перед работой запускать nix-shell, а по окончании выходить из него. В shell.nix описать, какие именно пакеты нужны для работы. Это окружение смогут разделить все участники проекта.