Да, есть такой момент, что 200-400 Мб кэшей скачиваются на локаль. Но при наличии стабильного и скоростного интернета это все равно в разы быстрее компиляции. Плюс, producer-fast позволяет не скачивать заново уже имеющиеся локально артефакты кэшей в неизменившихся модулях.
Решил собрать нечто подобное, возник затык с файлом serial.cgi — по ссылке не качается. Чувствую, что изменить там надо минимум, но что конкретно — пока не понял. Автор, перевыложи файл, если не трудно.
Хорошо. Volatile, так volatile. Спасибо за него, кстати.
Но кто-нибудь может объяснить, почему этого в debug build не происходит, а только в release? Перепроверил все флаги и build settings — все одинаково для обеих конфигураций
За подсказку с NSLock спасибо, в авральном режиме работаем, вылетела из головы эта фича.
По поводу GCD: изначально все писалось на нем, были красивые конструкции вроде dispatch_group_wait и так далее. Но у GCD проблема с рендерингом вьюшек. Поэтому был создан свой класс, унаследованный от NSThread и там была реализована человеческая очередь на выполнение.
Да, вы меня сейчас забросаете помидорами за использование UIKit вне главного потока, но все же это не критично. Ибо главное не обращаться к одной и той же вьюшке из конкурирующих потоков.
отличная статья, жаль, что для меня уже не актуальная :)
Сам во всём разбирался. Кстати, автор, match_extra у меня в RAD Studio 2009 работал как надо.
еще не совсем понял почему regex_match пытается поставить в соответствие всю строку регулярному выражению.
А если мне нужно из текста выдрать несколько одинаковых конструкций, ну к примеру внутри формы вытащить все инпуты, то приходится извращаться вот так:
boost::regex xRegEx(".*(<input[^>]*>)+.*");
т.е. «лишние» по сравнению с php конструкции вида ".*(<выражение>)+.*"
Это и очень отжирает память, ведь в результаты идет вся строка.
Да, дополнительно еще раз отмечу, что в результатах помещаются указатели на исходную строку, и пока не разберешь результаты поиска, ничего с искомой строкой делать нельзя :) Сам на это попадался, прога вылетала с Access Violation в произвольном месте, еле откопал причину.
Глаз — это не монитор. У него все объекты не находятся одновременно в фокусе. Фокусировка глаза выполняется растяжением и сжатием хрусталика. Если хотите — для мозга это еще один датчик «усилие растяжения хрусталика», который тоже принимает участие в определении расстояния до объекта.
походи с закрытым одним глазом неделю, месяц. Тренируйся жонглировать серыми шариками на берегу озера, где небо с водой почти сливается — наиболее неблагоприятные условия для глаза. Будешь видеть почти так же, как двумя глазами.
1) у нас в наличии нет алкогольной продукции, свободная реализация которой запрещена или ограничена
2) у нас нет (пока) дистанционных продаж. я бы назвал это дистанционным резервированием
День добрый.
Да, есть такой момент, что 200-400 Мб кэшей скачиваются на локаль. Но при наличии стабильного и скоростного интернета это все равно в разы быстрее компиляции. Плюс,
producer-fast
позволяет не скачивать заново уже имеющиеся локально артефакты кэшей в неизменившихся модулях.Но кто-нибудь может объяснить, почему этого в debug build не происходит, а только в release? Перепроверил все флаги и build settings — все одинаково для обеих конфигураций
Да, у GCD во время создания контекста (рендерил пдф) я тоже ловил невнятные и непонятные ошибки, вроде context is null, и cannot restore null context.
И цикл не выпиливался, NSLog до него выполняется, а после него — нет.
По поводу GCD: изначально все писалось на нем, были красивые конструкции вроде dispatch_group_wait и так далее. Но у GCD проблема с рендерингом вьюшек. Поэтому был создан свой класс, унаследованный от NSThread и там была реализована человеческая очередь на выполнение.
Да, вы меня сейчас забросаете помидорами за использование UIKit вне главного потока, но все же это не критично. Ибо главное не обращаться к одной и той же вьюшке из конкурирующих потоков.
Блин, и почему нельзя было сделать Regex_search с флагом match_all?
Сам во всём разбирался. Кстати, автор, match_extra у меня в RAD Studio 2009 работал как надо.
еще не совсем понял почему regex_match пытается поставить в соответствие всю строку регулярному выражению.
А если мне нужно из текста выдрать несколько одинаковых конструкций, ну к примеру внутри формы вытащить все инпуты, то приходится извращаться вот так:
boost::regex xRegEx(".*(<input[^>]*>)+.*");
т.е. «лишние» по сравнению с php конструкции вида ".*(<выражение>)+.*"
Это и очень отжирает память, ведь в результаты идет вся строка.
Да, дополнительно еще раз отмечу, что в результатах помещаются указатели на исходную строку, и пока не разберешь результаты поиска, ничего с искомой строкой делать нельзя :) Сам на это попадался, прога вылетала с Access Violation в произвольном месте, еле откопал причину.
походи с закрытым одним глазом неделю, месяц. Тренируйся жонглировать серыми шариками на берегу озера, где небо с водой почти сливается — наиболее неблагоприятные условия для глаза. Будешь видеть почти так же, как двумя глазами.
Тоже что ли выложить парочку своих курсовых для истории…
Пиво не относится к алкогольной продукции
2) у нас нет (пока) дистанционных продаж. я бы назвал это дистанционным резервированием