Сергей Скобликов mgsxx

Приделал асинхронное API.
Пример использования на GitHub.

Конечно генерил, я же не мазохит ;)

Могу выложить, но парсер/генератор писались сугубо под себя и сугубо под мою задачу. Если парсер Thirft еще можно приспособить, то генератор кода заметно нужно будет менять. А комментариев там нет как класс.

Эксперимент есть эксперимент. Наверное, попробую сделать асинхронный вариант API. Я правда пока сомневаюсь, что сам я найду ему применение, но, может, кому-то и пригодится. Время покажет.

Не вижу смысла продолжать дискуссию с неадекватным собеседником. Я бы резче выразился, но правила хабры запрещают срачи.

Хотелось много чего сказать, но я ограничусь одним тезисом: полезно читать перед тем как писать.

Прочитайте еще раз мою заметку, гляньте исходники QEverCloud. Надеюсь, вам станет понятно, что целью QEverCloud является заменить предлагаемые Evernote сгенеренные thrift компилятором файлы, которые громко именуются Evernote SDK for C++, а не написать конкретную прикладную программу.

В рамках этой цели предлагаемые вам исходники не представляют интереса — там этот самый Evernote SDK for C++ во всю используется, а не заменяется.

Все дальнейшее в программе по поводу Evernote мало интересно с точки зрения общего SDK, предназначенного для любых программ с самыми разнообразными задачами и архитектурой. QAbstractItemModel в качестве API к Evernote? Даже не смешно. Как решение задач конкретной программы — почему бы и нет, но как SDK к Evernote (а именно это есть тема заметки) — идея явно не очень здравая.

Более того, ваш глубокомысленный тезис о «другие пользователи опередили» имеет неявный подтекст, что предлагаемый мною подход к написанию программ — многопоточность с вынесением обращений к Evernote в отдельные потоки — неверен. Что явно говорит о том, что вы не потрудились ознакомится с темой, перед тем как писать. Ибо в приведенных вами исходниках используется именно этот подход, против которого EuroElessar привел массу разумных и интересных контраргументов, пусть с ними и можно поспорить. Вы уж определитесь, что вы хотите сказать.

Так что я ваш тезис о хороших идеях как-то не понял. В приведенных вами исходниках я их не нашел ничего нового и особого интересного.
Если вам хочется конструктивной дискуссии — пожалуйста, конкретику в студию. Какие хорошие с вашей точки зрения идеи вы хотели бы видеть в QEverCloud, но не видите? Или может вы хотели бы реализовать хорошую идею с помощью QEverCloud, но не можете из-за каких-то ограничений библиотеки?

Ссылка на исходники?

Да, но не в 2010. В 2010 очень много чего нет… и в 2012 тоже много не хватает. Вот какого хрена в 2012 даже сырых (raw) строк нет? Загадка.

Увы, но MSVC2010 все еще бывает актуальным. И когда уже оно подохнет…

Как общаться с тем потоком из гуя? Все равно придется городить асинхронное API, т.е. опять приходим к начальной проблеме

Зато на более высоком уровне, более соответствующем логике конкретной программы. Я не назвал бы это изначальной проблемой. К тому же, общение между потоками в Qt не есть большая проблема. Все готово, сигналы/слоты между потоками работают.

Многопоточность — это накладные расходы, лишняя память, лишние context switch'и. Асинхронное API, основанное на event loop почти всегда быстрее.

Это верно, но, насколько я понимаю, по сравнению с затратами на сетевые вещи все эти расходы теряют значимость.

«Я не понимаю никакого бонуса выноса синхронных методов в отдельный поток, с точки зрения API будет хуже, чем event loop-based API, писать сложнее, использовать тоже сложнее.»
Это субъективно. Моему субъекту, например, все кажется прямо наоборот.

Вашему примеру для полноты картины не хватает последовательности вызовов Evernote. В качестве гипотетического случая: три раза createNote, строго один за другим. В синхронном API это выглядит проще некуда:

ns->createNote(note);
ns->createNote(note);
ns->createNote(note);

А в асинхронном?

Понятно. Ну, значит нужно выносить наружу.

«Вообще мне кажется плохим тоном инициализировать qsrand из библиотеки — этим должно заниматься приложение.»

В принципе, я согласен. Лезть исподтишка библиотекой в глобальное состояние — оно действительно некрасиво. Но в данном случае, имхо, это не то чтобы совсем страшно. Если программист вызовет qsrand() где-нибудь в main, то мои закулисые манипуляции потеряют эффект, а если нет — то ему, по видимому, все равно, qrand/rand он не использует и я ему не мешаю.

Гораздо неприятнее будет, если программист забудет вызвать qsrand() и в таком виде отдаст свою программу пользователям. Дыра в безопасности, которую моя библиотека некрасивыми средствами пытается закрыть.

Я думал об этом, но пришел к выводу, что в случае с Thrift вообще и Evernote в частности такая модель не стоит того гембеля, что она привносит. Согласитесь, асинхронность превратит код в лапшу.

Thrift по своей идеологии имитирует вызов локальных функций, и Evernote этой идеологии всецело придерживается. Почти всегда перед тем, как выполнять следующий запрос к Evernote, нужно знать результат предыдущего. Как следствие, основное преимущество асинхронной модели — параллелизируемость на уровне отдельных запросов — сводится практически на нет.

Имхо проще и в целом так же эффективно будет реализовывать логически связанные последовательности запросов (как то же создание заметки) в виде синхронных вызовов, выполняемых в отдельном потоке. Тогда отдельные последовательности параллелизируются, код удобочитаем, и интерфейс = главный поток «замирать» не будет.

Если народ захочет асинхронности, то можно и сделать… но я пока не ощутил в ней насущной необходимости.

«Заморозку» интерфейса можно решить многопоточностью. Распараллеливание на уровне отдельных обращений к Evernote таким образом не получится, но оно по логике самого API в целом неосуществимо.

Т.е. претензии собственно к синхронности, а не к конкретно ее реализации через QEventLoop.

Фейспалм. Фиксю.

«Сейчас все адекватные компиляторы уже умеют c++11 в достаточной степени» — это если не поминать MSVC незлым тихим словом.

Не поделитесь, чем конкретно такой подход мешает реализации реальных проектов? Не сочтите за иронию, мне действительно интересно знать ваше мнение.

Спасибо за то, что дали себе труд глянуть исходники. Я приветсвую любую конструктивную критику.

QDialog::open — да, забыл про него. Видимо потому, что никогда не использую :)
Пофиксю при случае.

По поводу «256 возможных значений» не понял. Можете ткнуть носом в конкретную строку? Я такого бага не вижу.

std::mt19937_64 — это, если я не ошибаюсь, c++11. Библиотека под c++03.

Пожалуй, надо бы фанктор прикрутить в параметры authenticate для генерации nonce.

Хм… Видимо, Evernote в принципе не предназначен для реальных сложных проектов. Все SDK им предлагаемые — синхронные.

Кстати, если серьезно: ничто не мешает мне сделать асинхронный вариант API, немного поменяв генератор кода. Единственный вопрос: как оно, это асинхронное API, дожно выглядеть? У вас похоже, есть ответ на этот вопрос. Не поделитесь ответом?

Именно так это и было сделано.

На счет хитрого бага несколько раз прочитал, но не уверен, что я понял суть.

Чтобы даты заметки были одинаковыми я бы просто задавал created и updated при создании заметки. В QEverCloud это бы выглядело где-то так:

quint64 time = QDateTime::currentMSecsSinceEpoch();
Note note;
note.created = time;
note.updated = time;
note.title =…
note.content =…
noteStote->createNote(note);

Как это в Java API будет и какие там еще баги подстерегают — этого я уже не скажу…

По крайней мере, клиент под Windows такую дату не отображает.

Сейчас вот проверил. 0 работает. Т.е. поле Note.updated должно быть передано со значением 0 в updateNote.

Ха, надо бы попробовать.

Библиотека может то и ровно то, что позволяет Evernote Cloud API. Ни больше, ни меньше. Если через EDAM API теоретически возможно можно «обнулить» updated, то значит и с помощью QEverCloud можно.

А что, Qt это не С++? ;)
Если вас это беспокоит, то могу уверить, что кроме std::exception из стандартной библиотеки никиких других классов не используется.

Неожиданный конец — это без выводов? Меня за это регулярно пеняют. Не люблю воды, а вроде уже сказал все, что хотел. «Кому интересно, качаем и смотрим» — вроде и так подразумевается.

1) Это не формулировка, по задумке.
2) Стандартные фичи — это те, которые с Qt поставляются. При чем тут проекты?
3) То, что сидит в QMAKE_CXX не имеет никакого отношение ко всему вышеизложенному. И выполняется он (компилятор) не в qmake, а в make — уж заведомо после любых скриптов qmake.
4) Приведенный в посте скрипт не делает лишних билдов.

Если вы дадите себе труд прочитать ответ, которы я написал выше на ваш вопрос о «первой и второй части», то там все расписано по шагам.

1. Обратите внимание, об этом написано. Если вы читали.
2. Фичи очень даже могут менять макросы, и это очень в духе этой конкретной консерватории. Стандартные фичи этим тоже занимаются.
3. Вы любите пользоваться понятными только вам терминами. По крайней мере, мне не понятно, что такое «скрипт» и что такое «компилятор» в вашем вопросе. Так что затрудняюсь ответить.

Будет. Только вот переменная DEFINES еще не будет содержать нужного значения — фичи (features) отрабатывают после конца файла. Проверьте сами — вставьте message(DEFINES=$$DEFINES) в конец файла, а потом посмотрите переменную DEFINES в Makefile.

Вся суть описанного мною извращения состоит в том, что я ловлю финальное значение DEFINES, после того как все фичи сделают свое дело.

Ну и кроме того, просто кусок кода не решает той проблемы, что если defines.txt будет удален, то qmake не перезапустится.

Первая часть, я так понял, это recompile_on_defines_txt_not_existsing, вторая — recompile_on_defines_txt_not_existsing2.

Суть такова: recompile_on_defines_txt_not_existsing не есть полноценный rule, он не содержит команды и не выполняется. Это просто задание зависимости Makefile от defines.txt. Можно добавить в этот rule команду по запуску qmake напрямую, но зачем этот гембель, если эта команда уже есть готовая для таргета qmake? Так что я просто подвязываюсь к готовому правилу.

Получается такая последовательность: после запуска make проверит rule для Makefile, тот проверит defines.txt, и если он не существует (или менялся), то начнет проверять зависимости defines.txt — т.е. таргет qmake, что вызовет qmake, который создаст defines.txt и при следующем запуске make правило для Makefile на defines.txt уже не споткнется — поскольку при запуске qmake defines.txt гарантированно создастся раньше, чем Makefile.

Давайте не будем о том, что у кого как лежит в голове. А то вам, может, неприятно будет слушать.

Вы по ссылке заходили? Видели объем? Даже если нужный материал скомпилировать, получится многократно превышающий объем поста оффтопик. Человек или знает, что такое QMAKE_EXTRA_COMPILERS с QMAKE_EXTRA_TARGETS, или нет. Если нет, то краткие выжимки не помогут. Также напоминаю вам, что перепост запрещен правилами Хабра. Вы ведь, вроде, знакомы с правилами? Поэтому — ссылка. Не ссылки, ибо других на тему qmake банально не очень есть.

На этом предлагаю флуд закончить. Если есть что по делу — прошу.

Хм… а куда мне еще ссылку ставить? На предыдущий пост? На официальную доку, в которой ничего толком нет? На Гугл?

Что подсказывает? А то мне подсказывается прямо обратное. Все что можно автоматизировать, лучше автоматизировать. Где ручные правки — там ошибки.

И где эту переменную задавать? В командной строке qmake? Что-то мне подсказывает, что это — плохая идея. Хотя бы потому, что .pro.user файлы нельзя считать частью исходников.

Я бы согласился, если бы только Qt Creator с CMake дружил так же хорошо, как с qmake.

Типа того (если я вас правильно понял).

Какие там библиотеки использует подключаемая библиотека — это вопрос ее реализации. А реализация не должна влиять на интерфейс библиотеки (т.е., заголовочные файлы, которые становятся доступными проекту, к которому подключается библиотека).

Ваш пример совершенно корректен, когда задача — отличить debug от release. Но в данном посте преследуется совершенно другая задача.

Нет. Я имею в виду, что библиотеки, используемые подключаемыми библиотеками, не добавляют путь к своим заголовочным файлам в INCLUDEPATH проекта. Они только линкуются и добавляются в PRE_TARGETDEPS.

И если вы считаете, что переменной LIBS достаточно для подключения библиотек, то спешу вас разочаровать. LIBS задает только линковку с библиотеками, более ничего.

Здесь это не нужно, имя каталога включает в себя Debug, Release или какое другое имя конфига.
И проблема вообще-то не в debug vs release, а в том, чтобы Kit нужный узнать. Лучшего пути, чем посмотреть имя каталога для shadow build (вида build-MyProject-Desktop_Qt_5_0_2_MinGW_32bit-Release), я не знаю.

Для заинтересовавшихся, вот пост в моем блоге с подробным описанием того, что умеет QMAKE_EXTRA_COMPILERS.