В общем-то, Sleep(10) тоже не гарантирует, что поток проснётся через указанное время, проснуться может и раньше и позже, плюс-минус один квант, что обычно плюс-минус 15-20 мс — так что, как выше сказали, уж лучше мультимедийные таймеры, которые позволяют регулировать эту ошибку.
А нам удалось под FreeBSD собрать и даже немного поиграться, скорость ещё не тестировали, огорчает что expire time пока (?) не поддерживается или мы что-то не так делаем.
Не улавливаю смысл всей этой возни вокруг преждевременной оптимизации. Если есть опыт разработки хотя бы два-три года и маломальская теоретическая база в голове, то с современными средами-фреймворками писать неэффективный код это ещё постараться надо — почти все необходимые среднестатистические алгоритмы-структуры уже в фреймворке. А если для разработки выбран низкоуровневый язык, скажем С, где с фреймворками не так всё гладко, то наверное его и выбрали для того чтобы этими «преждевременными» оптимизациями заниматься.
Ага, мне тоже сразу APL вспомнился после увиденной λ, ну как вспомнился, не программил конечно на нём, так книжку в детстве прочитал о нём — язык адский.
Вопрос немного не в тему, но может кто-нибудь знает. Есть апач в префорк режиме и модуль пхп. Возможно ли сделать так чтобы инициализация пхп модуля просиходила только один раз (трудоёмкие вычисления), а не в каждом инстансе. Или апач их всё же каждый раз с диска пускает, а не форком? Про mmap знаю ;)
Вот этим ребятам выдали 100 000 баксов авансом, чтобы записать вот это, и да, это альбомная «студийная» версия. Один из членов команды сказал, если вычесть из потраченных денег стоимость выпитого пива, то запись альбома обошлась баксов в 10.
Что-то я не уловил в чём инновации, у знакомого дедули подобные очки для автолюбителей ещё со времён совка сохранились, первые для пасмурной погоды повышают контрастность (туман, дождь, снег, т.д.), вторые для яркого солнца, чтобы глаза не уставали, и те и другие жёлтого оттенка.
Скорее, в пр-инструмент, достаточно посмотреть на блог оперы, они там каждый свой пук документируют и что «удивительно» каждый раз попадают на главную.
У Хрома это пожалуй просто порядковый номер внутренней итерации разработки, для пользователей могли бы конечно и что-то не так быстро меняющееся сделать, но зачем?
История из жизни (возмножно, немного не в тему) — был один у нас один продукт, обновлялся часто, релизы были раз в месяц, а то и чаще. Сначала сделали привычную нумерацию версий, мажоры-миноры, мажор меняли когда добавляли реально крупные фичи, т.е. раз в полгода-год. Загвоздка была в том, что из-за быстрых итераций разработки был целый зоопарк одновременно живущих версий типа 2.1, 2.5, 3.21 (кто-то не обновился, кому-то старая нравится, т.д.), причём эти номера имели не очевидное отображение на реальную ревизию внутренней органиции движка.
В итоге решили сделать версию из двух чисел, первое — номер ревизии подсистемы хранения данных, второе — номер ревизии визуальной оболочки, например 32.103, причём нумерация сквозная, т.е. любое, даже минимальное, изменение кода уходящее в релиз приводило к увеличению номера версии подсистемы — всем сразу стало проще жить. Пользователи тоже кстати были рады, по номеру можно было примерно понять где и насколько сильно что-то поменялось.
Не, ну если очень нужны m менее 16, в публикации есть метод расчёта alpha_m для них, 0.673 их так же плохо аппроксимирует, как и 0.7213 / (1 + 1.079 / m). В любом случае, смысла особого нет в их использовании, т.к. абсолютная величина ошибки в 95%-доверительном интервале практически равна самой измеряемой величиной.
История из жизни (возмножно, немного не в тему) — был один у нас один продукт, обновлялся часто, релизы были раз в месяц, а то и чаще. Сначала сделали привычную нумерацию версий, мажоры-миноры, мажор меняли когда добавляли реально крупные фичи, т.е. раз в полгода-год. Загвоздка была в том, что из-за быстрых итераций разработки был целый зоопарк одновременно живущих версий типа 2.1, 2.5, 3.21 (кто-то не обновился, кому-то старая нравится, т.д.), причём эти номера имели не очевидное отображение на реальную ревизию внутренней органиции движка.
В итоге решили сделать версию из двух чисел, первое — номер ревизии подсистемы хранения данных, второе — номер ревизии визуальной оболочки, например 32.103, причём нумерация сквозная, т.е. любое, даже минимальное, изменение кода уходящее в релиз приводило к увеличению номера версии подсистемы — всем сразу стало проще жить. Пользователи тоже кстати были рады, по номеру можно было примерно понять где и насколько сильно что-то поменялось.