Решился-таки потратить время и залезть в NHibernate, чтобы добавить туда некоторые нужные вещи. Интересная особенность - в NHibernate используется AntLRv3, и создание SQL-запросов проходит через 2 промежуточных представления и 3 парсера/преобразователя деревьев (все 3 написаны на ANTLR). Деревья: 1) Дерево для HQL. Здесь у нас запросы в терминах классов и их свойств. 2) Дерево для SQL. Здесь у нас запросы в терминах таблиц и колонок. Парсеры: 1) Парсер из текстового представления HQL-запросов. Здесь нет ничего особенно интересного. 2) Набор правил переписывания для преобразования HQL-дерева в SQL-дерево. Вот здесь скрыта вся соль NHibernate'а. 3) Генератор текстового представления SQL-запросов. Здесь тоже нет ничего интересного. Парсер/переписыватель дерева в п.2 достаточно грязен - мутирует отдаленные узлы, написан достаточно императивно, содержит эвристики, не всегда работающие. Но ANTLR на такой задаче, конечно, рулит. Все другие API NHibernate'а работают через генерацию HQL-дерева. Как мне кажется, использовать HQL AST в качестве внутренного представления (IR, Internal Representation) запросов - не очень хорошая идея. Более хорошим было бы сделать внутренне представление, основанное на реляционной алгебре, в которой узлами были бы классы, таблицы, подзапросы и реляционные операции. В таком виде несложно делать преобразование HQL -> IR, ICriterion -> IR, IQueryable -> IR и IR' -> SQL, где IR' содержит только таблицы и колонки, а не классы и свойства. А преобразование IR -> IR' можно сделать в несколько проходов: 1) Устранить цепочки навигационных свойств 2) Добавить необходимые joined-таблицы и фильтры в качестве подзапросов 3) Преобразовать свойства в колонки 4) Соптимизировать дерево. Хм, почему так не было сделано?
Рекомендуют ограничить заряд до 50% для максимального срока службы при постоянной работе от сети.
Я вот подумал об этом и теперь хочется, чтобы во всех девайсах с аккумуляторами была такая возможность.
elizarov.livejournal.com очень интересный доклад про параллельное программирование; рекомендую; (видеозапись легко гуглится).
Во-первых, это оказалось совсем несложно — всего в 4 строчки запускаем группу процессов с ограничением по памяти и процессору (чтобы всякие java-монстры не пожирали ресурсы, например):
$ sudo cgcreate -a username -g cpu,memory:groupname
$ cgset -r cpu.shares=512 groupname
$ cgset -r memory.limit_in_bytes=1024M groupname
$ cgexec -g cpu,memory:groupname programname
en.wikipedia.org когда под «map function» имеют в виду функцию, которая применяется с помощью map, а под «reduce function» — функцию, которая применяется с помощью reduce.
Или в очень многих местах путают и смешиавют авторизацию и аутентификацию. Птичий язык просто какой-то.
Во всех описаниях map-reduce меня больше всего возмущает одна простая вещь: названия «map function» и «reduce function» (хотя бы в той же википедии: Или в очень многих местах путают и смешиавют авторизацию и аутентификацию. Птичий язык просто какой-то.
plproxy.projects.postgresql.org
Интересно, они это серьезно?
Why does PL/Proxy require the number of partition be power of 2?
We would need to define mod function for negative integers that maps to positive range. This sounds like a source for confusion and bugs.
Интересно, они это серьезно?