Разработка под Android → Ожидание пользовательской реакции на Dialog в Android из песочницы
Прежде чем что-то изобретать, я, конечно, погуглил (автор этого поста уже после выложил своё решение).
Дело в том, что в UI потоке нельзя ждать, а Activity предоставляет событийную модель работы с диалогами: по закрытию диалога вызывается общий обработчик с идентификатором диалога. Такой подход мне показался не очень удобным и я решил сделать все по-своему.
Дело в том, что в UI потоке нельзя ждать, а Activity предоставляет событийную модель работы с диалогами: по закрытию диалога вызывается общий обработчик с идентификатором диалога. Такой подход мне показался не очень удобным и я решил сделать все по-своему.
Разработка под Android → Еще один способ синхронизации потоков
В этом топике рассматривается еще один способ синхронизации потоков с использованием Intent, BroadcastReceiver и Handler. Метод этот может показаться очень громоздким, но тем не менее вполне удобным, особенно если в приложении используется достаточно много ассинхронных потоков. Например, если реализуется сервис, который общается с вебсервисом в фоновом режиме. Еще один пример – приложение, которое портируется сразу на несколько платформ и большую часть кода работы с API можно совместно использовать и в Android, и в J2ME, и в Windows Phone 7.
Python → Генерим PDF бочками
Предыстория
На хабре неоднократно упоминались различные инструменты и способы создания скриншотов WEB страниц.
Хочу поделиться собственным «велосипедом» для создания PDF на Python и QT, дополненным и улучшенным для централизованного использования несколькими проектами.
Изначально генерация запускалась из PHP скрипта, примерно так:
<?php
// локальный файл
exec('xvfb-run python2 html2pdf.py file:///tmp/in.html /tmp/out.pdf');
// или URL
exec('xvfb-run python2 html2pdf.py http://habrahabr.ru /tmp/habr.pdf');
?>этого было достаточно и все было хорошо…
Perl → Многопоточность в Perl, или Как я посмотрел ролик о съёмках Warehouse 13
Всё началось с того, что я наткнулся на видео, которое рассказывало о съёмках одного из моих любимых сериалов, Warehouse 13:
www.aoltv.com/2009/07/10/behind-the-scenes-of-warehouse-13/
Клёвые штуковины в стиле «стимпанк», рассказ о взаимовыручке и дружбе, и лёгкая волшебная атмосфера, уводящая от серых будней — вот, чем мне нравится этот сериал. И вообще мне не менее интересно, чем сам фильм, бывает смотреть, как снимают этот фильм.
Но, как принято на сайте AOL TV, видео оказалось доступно только жителям US. Зачем накладывать такие ограничения — я не могу взять в толк. Где и какая жаба их душит, непонятно.
Но такая мелочь меня не могла остановить.
Python → PyQt: простая работа с потоками из песочницы
Очень часто в программах приходится использовать многопоточность. Иногда это монстрообразные пулы потоков со сложным взаимодействием, но гораздо чаще это бывает простой код, главное требование к которому — не замораживать интерфейс.
Программирование → Параллельные вычисления по сети на Си из песочницы
Добрый день, хабражители! Недавно мне пришлось написать программу для параллельного вычисления определённого интеграла. Естественно, после окончания работы был приобретен некий опыт, и я хотел бы поделиться этим опытом с вами. Сразу скажу, что в рамках статьи я не буду рассматривать парсинг интегрируемой функции, а заострю внимание на взаимодействии тредов и компьютеров между собой.
Конечно, прежде чем начать писать код нужно правильно поставить себе задачу, требования к программе были следующие:
Постановка задачи
Конечно, прежде чем начать писать код нужно правильно поставить себе задачу, требования к программе были следующие:
- Вычисления должны производиться на нескольких машинах параллельно (в пределах локальной сети)
- Вычисления должны быть многопоточными
- Доступ к компьютерам, на которых производятся вычисления, непостоянный
Python → PyGTK: потоки и магия обёрток
Всем хорош GTK+, но наблюдается большая проблема при работе с ним в многопоточных приложениях. Сам по себе GTK является thread-safe, но требуя принудительной блокировки со стороны пользователя. Вторая проблема заключается в том, что блокировка реализована через мутексы, и вы должны вызывать блокировку строго один раз, иначе ваш код «зависнет» на linux, прекрасно при этом работая на windows.
Python → Потоки в wxPython
При написании программ на Python, используя при этом графический интерфейс иногда приходится запускать различные долгие обработки каких либо данных, при этом в большинстве случаев будет блокироваться интерфейс и пользователь увидит программу замороженной. Чтобы этого избежать необходимо нашу задачу запустить в параллельном потоке или процессе. В данной статье мы рассмотрим, как это сделать в wxPython с помощью модуля Threading.
В wxPython существуют три метода для работы с потоками. Если ими не пользоваться, то при обновлении интерфейса программы Python могут подвиснуть. Чтобы этого избежать, необходимо использовать потокобезопасные методы: wx.PostEvent, wx.CallAfter и wx.CallLater. По словам Robin Dunn (создатель wxPython) wx.CallAfter использует wx.PostEvent для отправки события на объект приложения. Приложение будет иметь обработчик этого события и будет реагировать на него соответственно заложенному алгоритму. На сколько я понимаю wx.CallLater вызывает wx.CallAfter с заданным параметром времени, чтобы он знал сколько ему ждать перед отправкой события.
Robin Dunn также отметил, что Global Interpreter Lock (GIL) не допустит одновременного выполнения более одного потока, что может ограничить количество используемых ядер процессора. С другой стороны, он также сказал, что wxPython освобождается от GIL вызывая API функции библиотеки wx, поэтому другие потоки могут работать одновременно. Другими словами быстродействие может изменяться при использовании потоков на многоядерных машинах. Обсуждение этого вопроса может быть интересным и не понятным…
Прим. перев. — для более полного знакомства с GIL прошу сюда.
Наши три метода можно разделить на уровни абстракции, wx.CallLater находится на самом верху, далее идет wx.CallAfter, а wx.PostEvent находится на самом низком уровне. В следующих примерах вы увидите, как использовать wx.CallAfter и wx.PostEvent в программах WxPython.
Потокобезопасные методы wxPython
В wxPython существуют три метода для работы с потоками. Если ими не пользоваться, то при обновлении интерфейса программы Python могут подвиснуть. Чтобы этого избежать, необходимо использовать потокобезопасные методы: wx.PostEvent, wx.CallAfter и wx.CallLater. По словам Robin Dunn (создатель wxPython) wx.CallAfter использует wx.PostEvent для отправки события на объект приложения. Приложение будет иметь обработчик этого события и будет реагировать на него соответственно заложенному алгоритму. На сколько я понимаю wx.CallLater вызывает wx.CallAfter с заданным параметром времени, чтобы он знал сколько ему ждать перед отправкой события.
Robin Dunn также отметил, что Global Interpreter Lock (GIL) не допустит одновременного выполнения более одного потока, что может ограничить количество используемых ядер процессора. С другой стороны, он также сказал, что wxPython освобождается от GIL вызывая API функции библиотеки wx, поэтому другие потоки могут работать одновременно. Другими словами быстродействие может изменяться при использовании потоков на многоядерных машинах. Обсуждение этого вопроса может быть интересным и не понятным…
Прим. перев. — для более полного знакомства с GIL прошу сюда.
Наши три метода можно разделить на уровни абстракции, wx.CallLater находится на самом верху, далее идет wx.CallAfter, а wx.PostEvent находится на самом низком уровне. В следующих примерах вы увидите, как использовать wx.CallAfter и wx.PostEvent в программах WxPython.
PHP → Одноврéменно || Одновремéнно
Введение
ZendX_Console_Process_Unix позволяет разработчикам создавать объекты под видом процессов, и таким образом параллельно выполнять несколько задач. Из-за особенностей реализации на текущий момент эта возможность доступна только на *nix системах, таких как Linux, Solaris, Mac / OSX и другие в CLI или CGI режиме. Кроме того для работы этого компонента необходимы следующие модули: Shared Memory, Process Control и POSIX. Если одно из требований не выполняется, то будет брошено исключение.
Основы использования ZendX_Console_Process_Unix
ZendX_Console_Process_Unix это абстрактный класс, который должен быть расширен пользователем. В нем находится единственный абстрактный метод _run(), который должен описывать реализуемый алгоритм обработки тех или иных данных. Так же в классе определенны методы для проверки состояния процесса и обмена переменными между основным и дочерними процессами.
Метод _run(), а так же каждый метод вызванный внутри него будет выполняться в отдельном процессе. Любой другой метод, вызванный в вашем приложении будет выполняться в родительском процессе.
Методы setVariable () и getVariable () могут быть использованы для передачи переменных между родительским и дочерними процессами. Для наблюдения за статусом дочернего процесса следует вызывать внутри него метод _setAlive () через короткие промежутки времени, таким образом родительский процесс сможет получить информацию о состоянии дочернего процесса посредством вызова метода getLastAlive (). Чтобы получить PID дочернего процесса, родитель может вызвать getPid().