У середу відкрив ля себе Boost.MPL. Четвер, п’ятниця і обидва вихідних тупо випали і спробувати її не було нагоди. Зате читав багато документації і уявляв як усе буде круто і як наступить щастя на планеті.
Реальність виявилась не такою чарівною. Variadic Templates у Boost.MPL досі не підтримуються. А значить щоб зробити apply вектора типів треба його рекурсивно розгортати. Тим часом мій Sort працює з Variadic Templates і apply'їться без проблем.
Постав перед вибором: красиво і стандартно чи коротко і зрозуміло.
В принципі, мені-то тільки boost::mpl::sort і потрібен, а значить можна обійтись своїми "велосипедами".
PS:
apply стібрив звідси: https://github.com/scientific-coder/Computer-Languages/blob/master/interpreting/apply.hxx
Бо мене трошки запарило розгортати ці рекурсивні типи даних.
Одним словом: розчарування.
Реальність виявилась не такою чарівною. Variadic Templates у Boost.MPL досі не підтримуються. А значить щоб зробити apply вектора типів треба його рекурсивно розгортати. Тим часом мій Sort працює з Variadic Templates і apply'їться без проблем.
Постав перед вибором: красиво і стандартно чи коротко і зрозуміло.
В принципі, мені-то тільки boost::mpl::sort і потрібен, а значить можна обійтись своїми "велосипедами".
PS:
typedef boost::mpl::vector<B, D1, D2, DD>::type types; typedef boost::mpl::sort<types, boost::mpl::not_<std::is_base_of<boost::mpl::_1, boost::mpl::_2>>>::type sortedTypes; typename apply<HContainer, sortedTypes>::type data;
apply стібрив звідси: https://github.com/scientific-coder/Computer-Languages/blob/master/interpreting/apply.hxx
Бо мене трошки запарило розгортати ці рекурсивні типи даних.
Одним словом: розчарування.
З релізом мене!
Останні два тижні пройшли під девізом "ні дня без комміту". Один день всього пропустив, зате в інші по десятку коммітів робив.
( Чим же я займався? )
Дякую компанії Vikos за наданий у тимчасове користування MacBook і своїй сестричці
oxymona за тестування отриманих dmg. Код і пакунки, як завжди, лежать тут: http://code.google.com/p/qia. Є українська і російська локалізація.
Останні два тижні пройшли під девізом "ні дня без комміту". Один день всього пропустив, зате в інші по десятку коммітів робив.
( Чим же я займався? )
Дякую компанії Vikos за наданий у тимчасове користування MacBook і своїй сестричці
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Transfer-Encoding: debug
Nov. 7th, 2011 11:08 amКартинко:
( Read more... )
Під кодом три термінали: майже оригінальні дані (source -> production caster -> localhost), відрелеєні дані (source -> production caster -> relay -> local caster -> localhost), релей (який і дебажимо), локальний транслятор (caster). На око наче нічо так...
( Read more... )
Під кодом три термінали: майже оригінальні дані (source -> production caster -> localhost), відрелеєні дані (source -> production caster -> relay -> local caster -> localhost), релей (який і дебажимо), локальний транслятор (caster). На око наче нічо так...
Transfer-Encoding: code
Nov. 6th, 2011 03:58 pmЯк і обіцяв, код:
( Read more... )
Наведений раніше семпл містить помилку. Справа в тому що у рядку із chunk length можна крім довжини chunk вказати різні параметри після крапки з комою - так звані "chunk extensions" у вигляді key=value, розділені крапкою з комою. Якщо chunk extensions не використовуються - крапка з комою не ставляться. За стандартом ці extensions можна сміливо ігнорувати. Парсер довжини chunk наведений у семплі використовує квантор "+" для "зайвих" символів, а треба використовувати квантор "*". Ну і там ще у тому ж парсері проблеми з визначенням довжини рядка з chunk length.
Тепер щодо buffer overflow. Якщо при використанні read_until розміру буферу не вистачить для пошуку то функція завершиться з помилкою "Element not found". Наведений вище код коректно веде себе в умовах коли chunk body не влазить у бувер - оброблює його "по шматкам". Якщо ж у буфер не влазить рядок з chunk length то він завершується з помилкою "Element not found". Перевіряв це змінюючи max_size для streambuf.
( Read more... )
Наведений раніше семпл містить помилку. Справа в тому що у рядку із chunk length можна крім довжини chunk вказати різні параметри після крапки з комою - так звані "chunk extensions" у вигляді key=value, розділені крапкою з комою. Якщо chunk extensions не використовуються - крапка з комою не ставляться. За стандартом ці extensions можна сміливо ігнорувати. Парсер довжини chunk наведений у семплі використовує квантор "+" для "зайвих" символів, а треба використовувати квантор "*". Ну і там ще у тому ж парсері проблеми з визначенням довжини рядка з chunk length.
Тепер щодо buffer overflow. Якщо при використанні read_until розміру буферу не вистачить для пошуку то функція завершиться з помилкою "Element not found". Наведений вище код коректно веде себе в умовах коли chunk body не влазить у бувер - оброблює його "по шматкам". Якщо ж у буфер не влазить рядок з chunk length то він завершується з помилкою "Element not found". Перевіряв це змінюючи max_size для streambuf.
Transfer-Encoding: chunked
Nov. 3rd, 2011 09:21 pmБолюча тема.
( Read more... )
Скажу чесно, код ще не тестував, і мені цікаво як він поведе себе на великих chunk. Буде дуже сумно вертати все в зад. Завтра подивимось. Якщо все буде добре - покажу код.
PS: сьогодні колеги поставили ще одну станцію - у Донецьку. Тепер у системі 16 базових станцій (правда, із них 4 - ретранслятори RTK від СКНЗУ і "сирих даних" по ним немає): TNT-TPI GNSS Network. Здається, обігнали найближчих конкурентів - ZAKPOS.
( Read more... )
Скажу чесно, код ще не тестував, і мені цікаво як він поведе себе на великих chunk. Буде дуже сумно вертати все в зад. Завтра подивимось. Якщо все буде добре - покажу код.
PS: сьогодні колеги поставили ще одну станцію - у Донецьку. Тепер у системі 16 базових станцій (правда, із них 4 - ретранслятори RTK від СКНЗУ і "сирих даних" по ним немає): TNT-TPI GNSS Network. Здається, обігнали найближчих конкурентів - ZAKPOS.
Boost.Spirit та ітератори
Jul. 21st, 2011 09:11 pm( розрив шаблонів )
В процесі битви з компіляторами я знайшов щонайменше 3 виходи із ситуації (константний std::string, ітератори окремо і через шаблонну функцію), але шило в жопі не давало покинути проблему не розібравши її до кінця :). Да, константний std::string - останнє рішення, яке просто підтвердило гіпотезу про проблеми з константністю.
PS: обожнюю розставляти < і > замість < і > :(
PPS: а ще я сьогодні поборов скіпери, так що тепер з чистою совістю буду дивитись кіна під червоного вина :)
В процесі битви з компіляторами я знайшов щонайменше 3 виходи із ситуації (константний std::string, ітератори окремо і через шаблонну функцію), але шило в жопі не давало покинути проблему не розібравши її до кінця :). Да, константний std::string - останнє рішення, яке просто підтвердило гіпотезу про проблеми з константністю.
PS: обожнюю розставляти < і > замість < і > :(
PPS: а ще я сьогодні поборов скіпери, так що тепер з чистою совістю буду дивитись кіна під червоного вина :)
Чим краще тим гірше
Jul. 6th, 2011 04:48 pmЄ у мене одна софтинка, написана для GTS, якою я пишаюсь. CMake, Boost, ключі і конфігураційний файл, плагіни, дуже ідіоматично написана, близько до мого ідеалу. . І у ній знайшлась дуже тупа бага. В залежності від типу зборки вона або взагалі не падала, або падала з таким повідомленням:
або з таким:
При чому падала тільки у production, локально усе було нормально. А проблема виявилась у неправильному порядку слідування членів класу плагіну. thread ініціалізувався і запускався раніше ніж ініціалізувався mutex. І у production він встигав спробувати цей mutex захопити.
Дивно інше: як так вийшло що я не проганяв перед релізом софтинку через valgrind?
PS: ні, я у GTS не повернувся. Просто виконую деякі їх побажання за домовленістю.
nfa: /usr/include/boost/thread/pthread/mutex.hpp:50: void boost::mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
або з таким:
nfa: pthread_mutex_lock.c:312: __pthread_mutex_lock_full: Assertion `(-(e)) != 3 || !robust' failed.
При чому падала тільки у production, локально усе було нормально. А проблема виявилась у неправильному порядку слідування членів класу плагіну. thread ініціалізувався і запускався раніше ніж ініціалізувався mutex. І у production він встигав спробувати цей mutex захопити.
Дивно інше: як так вийшло що я не проганяв перед релізом софтинку через valgrind?
PS: ні, я у GTS не повернувся. Просто виконую деякі їх побажання за домовленістю.
Спілкування з духами
Nov. 12th, 2010 06:54 pmМо кому згодиться - парсер детальної статистики Stargazer на Boost.Spirit2:
( многабукаф )
( многабукаф )
Parsec vs. Boost.Spirit
Sep. 6th, 2010 12:11 pmВчора осилив Parsec. Після Boost.Spirit такі штуки мене вже більше не дивують. Вражає лише лаконічність коду: BNF перекладається майже без проблем. Із ghci дуже зручно тестувати парсери і їх комбінації (вихлоп g++ при помилках у Boost.Spirit мене досі лякає).
Коротше кажучи, приємна і зручна у користуванні бібліотека.
Цікаво те що і Parsec і Boost.Spirit у мене випливли в одному й тому ж проекті. Сам проект на C++, а одну маленьку утиліту вирішив спробувати написати на Haskell (отримавши натхнення від статті Дмитра Астапова "Давно не брал я в руки шашек"). Низхідне проектування майже вийшло, тільки в кінці на одній функції застряг. Треба буде пошукати як прийнято у Haskell обробляти помилки.
Коротше кажучи, приємна і зручна у користуванні бібліотека.
Цікаво те що і Parsec і Boost.Spirit у мене випливли в одному й тому ж проекті. Сам проект на C++, а одну маленьку утиліту вирішив спробувати написати на Haskell (отримавши натхнення від статті Дмитра Астапова "Давно не брал я в руки шашек"). Низхідне проектування майже вийшло, тільки в кінці на одній функції застряг. Треба буде пошукати як прийнято у Haskell обробляти помилки.
Boost.Spirit 2
Mar. 13th, 2010 09:15 pmДовгими холодними зимовими вечорами займаюсь однією "шабашкою". І як я уже для себе завів, беру від шабашки не тільки гроші а і новий досвід. Цього разу вирішив зайняти себе вивченням Boost. А точніше Boost.Asio і Boost.Spirit.
( Багато незрозумілих значків )
( Багато незрозумілих значків )