А можно для тех, кто не в теме, что этот код делает? Если речь об x86, то по этому адресу должен обработчик int 82h располагаться, а я такого раньше не встречал (максимум 80h в Linux/FreeBSD, а в DOS я помню только 33h для работы с мышкой).
А Вы с теорией телескопов со сверхдлинной базой знакомы? Во-первых, в настоящее время это возможно только в радиодиапазоне (т.к. нужно точно записывать амплитуду и фазу принимаемого сигнала), а во-вторых, в результате получается только часть «фурье-спектра» (заполнения uv-плоскости), по которой пытаются «угадать» исходное изображение, что вряд ли сможет полностью заменить прямые наблюдения.
Разрешающая способность телескопа равна отношению длины волны к диаметру зеркала телескопа (это так называемый «дифракционный предел») и в настоящее время увеличивать эффективность телескопа можно только увеличивая диаметр зеркала. В космос запускают телескопы, работающие в диапазоне длин волн, недоступном на Земле из-за атмосферы. Телескоп Хаббл — исключение, но когда его проектировали адаптивная оптика еще не была так развита, а сейчас наземные телескопы дают примерно такое же качество изображения.
Наверное, никто не мешает сделать реализацию, в которой при выполнении splice внутреннее поле размера устанавливается в -1 и будет пересчитано автоматически при выполнении последующих операций, требующих знания размера.
Считается, что в 90-й, но без боли на это смотреть нельзя. Если не ошибаюсь, формально там есть только 1) инкапсуляция данных через структуры с приватными полями и доступом из модуля и 2) полиморфизм на уровне функций.
ikea.com — это просто заглушка с выбором языка и домена. Нужно проверять, например, www.ikea.com/us/en или www.ikea.com/ru/ru, где результат уже далеко не такой замечательный.
Если контент может меняться динамически (т.е. скроллбар может появляться и скрываться), то при 100% контент будет «прыгать» в момент появления/скрытия сколлбара, так что vw выглядит более стабильным решением в этом случае.
Не всё так просто. Даже если opensource, то далеко не факт, что дадут. Например, если вы предлагаете платную поддержку, то лицензию не дадут. Если новые версии выходят реже, чем раз в три месяца — тоже. Если у проекта нет «активного коммьюнити» (чтобы это ни значило) — тоже нет.
При компиляции плагина можно задать until-build, но как правило плагины устанавливают только since-build, надеясь, что в последующих версиях плагин тоже будет работать. Если сейчас требовать от всех until-build, то сразу отвалится существенная доля плагинов.
PS
PS. Если у разработчика плагина нет лицензии на Ultimate версию, то ему нужно снести текущий триал и установить новый (оставим в стороне вопрос легальности этого после окончания испытательного срока), установить ряд необходимых плагинов, пересобрать плагин, проверить его и загрузить на plugins.jetbrains.com. В итоге, если разработка плагина ведется просто в свое удовольствие и нового функционала пока не добавляется, то не имеет смысла тратить время на еженедельное тестирование плагина в EAP, потом в RC, и в релизе, чтобы гарантировать работоспособность.
А как же переход к матричному формализму и быстрое возведение матрицы в степень? Или даже приведение этой матрицы к диагональному виду? (но тут, в отличие от ряда Фибоначчи, к сожалению будет комплексно-сопряженная пара собственных значений)
Если использовать классический конечный автомат Томпсона, то да, никаких проблем с производительностью не будет — сложность линейно растет с длиной строки. Но если брать что-то более сложное с поддержкой backreference (например, PCRE), то там уже соответствие с регулярным выражением запросто может приводить к экспоненциальному росту сложности.
Возможно, тут имеется в виду интервал времени (например, минуты и секунды), а не дата, и если так, то 8601-2001 тут не применим (но даже для интервалов запись 0:12 не является стандартной). Без контекста это понять, конечно же, невозможно.
с тем же эффектом. А там и все гарантийные сроки истекут.
/(A*)*/и на больших объемах текста вести себя так себе.