Меня весьма печалят ваши не оправдавшиеся надежды, но давайте отложим пока специальную олимпиаду.
>Это yield — поддержка программных прерываний потока без глобальной блокировки процесса.
Трудно описать радость от появления «yeild» в ноде. Не вдаваясь в излишнее теоретизирование, давайте разберем какую проблему это должно решать. Если необходимо выполненить что-то вне основного потока, то есть воркеры. О преимуществах fiber c нейтивной yeild и их use case'ах я не услышал.
Касательно node-sync в статье вы обозначили три проблемы, которые она призвана решить. Вот решение двух последних, обработка ошибок и «неконфликтность», не совсем очевидно из этой статьи, на что я и указываю.
>В примере со статьи, любая ошибка, вылетевшая из любой вызванной там функции, попадет в результирующий callback
То есть, первая же ошибка прервет выполнение и вызовет колбек? В таком случае это просто синтаксическим сахар, а не «корректна обработка», ничего некорректного в обычной обработке нет, чего эта реализация бы корректировала.
Далее, к третьей проблеме, расширение базовых прототипов это реально плохая идея. Этим: Function.prototype.sync() вы предлагаете всем остальным отказаться от именования своих ф-ий/свойств как sync дабы не перекрывать вашу глобальную. Это никак не улучшает шансы безболезненной интеграции с существующим или будущим кодом.
Так и не понял что такого феноменального было сделано, библиотек для упрощения асинхронного кода только активно используемых десяток, и тут я не вижу какой-либо новизны.
>Главная идея в том, что метод Function.prototype.sync()
Т.е. augumenting built-in prototype теперь хорошая идея?
Представленный вами «реальный» код, реален настолько же насколько реальна необходимость в один шаг: открыть соединение с монго, создать в нем новую коллекцию, заполнить ее новыми документами и выбрать из них же что-то обратно. Пример не удачен, хотя в ноде и не мало мест где можно далеко уйти с колбеками. Но все равно не понял как ваша обертка помогает ловить ошибки, в примере с ней даже нет намека на переменную с ошибкой. Вот как здесь:
var cursor = collection.find.sync(collection, {'_id':new ObjectID(«aaaaaaaaaaaa»))
поймать ошибку упавшего соединения и обработать ее не роняя ноду?
В моем случае речь идет о чеченском, если не вдаваться в детали. Но в аналогичной ситуации еще много языков, поэтому думаю вопрос будет интересен не только мне.
>>Хотелось бы больше узнать о системе распознавания, а именно. Будет ли она «языконезависимой» или будет в том числе опираться на морфологию каждого языка, как и нынешняя система в FineReader'е? Во втором случае, планируется ли использовать открытый формат или технологию позволяющую добавлять правила морфологии для новых языков самим пользователям? Скажем по примеру hunspell/aspell словарей в браузерах.
>Я надеюсь, что предыдущие ответы прояснили эту тему. Если нет, уточните, пожалуйста.
Да, спасибо за ответы, многое стало понятнее. Значит наращивать «листки» для новых языков надо будет.
Я работаю с малораспространенным, архаичным, чертовски запутанным языком, у которого всего только несколько больших словарей и пара десятков книг в сети. Ни ABBYY, ни кто-либо другой добавлять его поддержку в продукты не будет, поэтому хотел узнать смогу ли я, на добровольной основе, как-то реализовать его поддержку где-либо, пользуясь какими-либо открытыми стандартами (на манер стандарта для словарей Lingvo), и вообще что эта технология может дать для таких языков.
Хотелось бы больше узнать о системе распознавания, а именно:
1. Будет ли она «языконезависимой» или будет в том числе опираться на морфологию каждого языка, как и нынешняя система в FineReader'е?
2. Во втором случае, планируется ли использовать открытый формат или технологию позволяющую добавлять правила морфологии для новых языков самим пользователям? Скажем по примеру hunspell/aspell словарей в браузерах.
Остановился на nirvanahq.com Среди прикладных программ под Windows ничего вменяемого не нашел. Среди веб-сервисов на тот момент (прошлая осень) нирвана была единственным кто позволял полностью офф-лайн работу. Плюс сходство с Things, https, простота и прочие плюшки. Рекомендую.
>не уж-то следует ждать server-side реализации jQuery? — прим. перев.
Не знаю что вы имели ввиду, но оно там уже давно через node.js есть: node.js+jsdom(для генерации DOM)+jquery и сервер делает почти все то же что и браузер.
>Это yield — поддержка программных прерываний потока без глобальной блокировки процесса.
Трудно описать радость от появления «yeild» в ноде. Не вдаваясь в излишнее теоретизирование, давайте разберем какую проблему это должно решать. Если необходимо выполненить что-то вне основного потока, то есть воркеры. О преимуществах fiber c нейтивной yeild и их use case'ах я не услышал.
Касательно node-sync в статье вы обозначили три проблемы, которые она призвана решить. Вот решение двух последних, обработка ошибок и «неконфликтность», не совсем очевидно из этой статьи, на что я и указываю.
>В примере со статьи, любая ошибка, вылетевшая из любой вызванной там функции, попадет в результирующий callback
То есть, первая же ошибка прервет выполнение и вызовет колбек? В таком случае это просто синтаксическим сахар, а не «корректна обработка», ничего некорректного в обычной обработке нет, чего эта реализация бы корректировала.
Далее, к третьей проблеме, расширение базовых прототипов это реально плохая идея. Этим: Function.prototype.sync() вы предлагаете всем остальным отказаться от именования своих ф-ий/свойств как sync дабы не перекрывать вашу глобальную. Это никак не улучшает шансы безболезненной интеграции с существующим или будущим кодом.
>Главная идея в том, что метод Function.prototype.sync()
Т.е. augumenting built-in prototype теперь хорошая идея?
Представленный вами «реальный» код, реален настолько же насколько реальна необходимость в один шаг: открыть соединение с монго, создать в нем новую коллекцию, заполнить ее новыми документами и выбрать из них же что-то обратно. Пример не удачен, хотя в ноде и не мало мест где можно далеко уйти с колбеками. Но все равно не понял как ваша обертка помогает ловить ошибки, в примере с ней даже нет намека на переменную с ошибкой. Вот как здесь:
var cursor = collection.find.sync(collection, {'_id':new ObjectID(«aaaaaaaaaaaa»))
поймать ошибку упавшего соединения и обработать ее не роняя ноду?
mai.exler.ru/articles/editorial/dogs.html
>Я надеюсь, что предыдущие ответы прояснили эту тему. Если нет, уточните, пожалуйста.
Да, спасибо за ответы, многое стало понятнее. Значит наращивать «листки» для новых языков надо будет.
Я работаю с малораспространенным, архаичным, чертовски запутанным языком, у которого всего только несколько больших словарей и пара десятков книг в сети. Ни ABBYY, ни кто-либо другой добавлять его поддержку в продукты не будет, поэтому хотел узнать смогу ли я, на добровольной основе, как-то реализовать его поддержку где-либо, пользуясь какими-либо открытыми стандартами (на манер стандарта для словарей Lingvo), и вообще что эта технология может дать для таких языков.
1. Будет ли она «языконезависимой» или будет в том числе опираться на морфологию каждого языка, как и нынешняя система в FineReader'е?
2. Во втором случае, планируется ли использовать открытый формат или технологию позволяющую добавлять правила морфологии для новых языков самим пользователям? Скажем по примеру hunspell/aspell словарей в браузерах.
today правда действительно не strict GTD, лучше бы отдельную категорию sheduled для задач с четким сроком.
>The app is currently unreachable.
Пишет мне хром.
Функционал очень на поминает nirvanahq.com 2 версию, посмотрите если не видели. И там так же не хватает bookmarklet'а и smart add'а.
Для полноты GTD здесь не хватает Waiting for.
Не знаю что вы имели ввиду, но оно там уже давно через node.js есть: node.js+jsdom(для генерации DOM)+jquery и сервер делает почти все то же что и браузер.