Как стать автором
Обновить

Комментарии 18

Спасибо вам! Наконец-то я узнал, как правильно выйти из командной строки node!
Да не, .exit функция синхронная, для правильного надо:
.exit(function(err, result) {
if(err) throw err;
return result;
}
Спасибо вам! Наконец-то я узнал, как правильно выйти из командной строки node!
Рекомендую читать документацию; в частности, подраздел «REPL Features» в разделе «REPL». Там ожидают удивительные открытия: не только «.exit», но также и «.break», «.clear», «.help», «.save», «.load»…
Пока libuv не до конца интегрирована, поддерживать различия между v0.4.x и v0.6.x можно пытаться. А вот с v0.8 мне кажется будет уже сложнее.
Не понял о каких различиях речь? Для v0.4.x ставим старую версию, для v0.6.x новую. Для v0.8 будут свои версии. Новые возможности вниз по версиям распространяться не будут.
По моим наблюдениям довольно много разработчиков не собираются срочно переходит на 0.6, особенно те, кто уже запустиили проекты в продакшн. Лишать их багфиксов и нового функционала не очень хорошо, имхо. Разве что у вас действительно совсем не расширяется функционал последнее время.
А вот о чем. Да для меня пока эта проблема не актуальна. Я как раз надеюсь на увеличение количества разработчиков в связи с лучшей поддержкой Windows.
Тоже жду пока «из коробки» будет работать тулза для сборки аддонов. Видимо в следующей версии придётся отказаться от обратной совместимости, а вот дальше уже обещают более спокойную жизнь.
Так а что мешает держать один скрипт для node-waf. А другой для node-gyp или как оно там будет называться? Сама то логика работы сильно меняться не должна. Что касается libuv/libev так по-моему там все очень подобно и можно ввести дополнительный уровень абстракции на шаблонах например. Впрочем, сам я таким заниматься не готов :-).
Да, приходится держать разные макросы для разных способов инициализации буферов (уже отказался от этого) и разных сигнатур eio_custom (между v0.4 и v0.6). А в 0.7-0.8 уже хорошо бы uv_async использовать, выходит три разные версии. Вот я пока тоже не готов :)
Не пользуюсь SQL, не слышал ранее про Firebird, но рад, что нода обрастает драйверами.
Удачи вам с модулем и спасибо что рассказали.

Раз речь про C++ плагины зашла, в монговском драйвере отказались от С++ парсера BSON для новой ноды 0.6, сославшись на то что разница в скорости нивелировалась. Точнее как опция он все еще есть, но рекомендуют использовать нейтивный (js) парсер. Не понял пока из-за чего, то ли скорость нейтивной догнала C++, то ли конвертации туда-обратно снижают скорость сишной до обычной.
В 0.6 со скоростью всё действительно сильно лучше. Раньше для MySQL нативный драйвер отставал от бинарного в 3-15 раз, теперь только в 1.5-2. Лучше, но есть куда стремиться. Так что я пока не намерен бросать поддержку своего бинарного модуля.
P.S. Может они это решили потому что монгуст много оверхеда всё равно добавляет? :D
Тоже может быть, правда автора в сговоре с монгуставцами не замечал.
Вот что пишут:
>From V0.8.0 to V0.9.6.9, the Javascript bson parser was slower than an optional C/C++ bson parser. As of V0.9.6.9+, due to performance improvements in the Javascript parser, the C/C++ perser is deprecated and is not installed by default anymore.

>Раньше для MySQL нативный драйвер отставал от бинарного в 3-15 раз, теперь только в 1.5-2.
Ничего себе, это только благодаря V8 или сама нода что-то подточила? Или авторы библиотеки.
Промазал :)
Нативную библиотеку последнее время не смотрел, могу упустить что-то. Но Node.js с V8 могли и сами дать такой прирост, за послдние полгода очень многое улучшилось.
Самому мне к Firebird SQL Server обращаться незачем, но зато прежде я не знал, что есть, есть ужé модули Node.js, для которых предоставляются предварительно (самим разработчиком модуля) скомпилированные двоичные файлы для Windows. Думал, что это является делом пускай и близкого, но всё же будущего. Так что эта блогозапись порадовала меня, преисполнила оптимизма.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории