К сожалению windows'а у меня нет… Но думаю, точно так же можно собрать с помощью MSVC. В крайнем случае попробовать cygwin.
ICU для windows есть: icu-project.org/download/4.0.html#ICU4C
При компилляции SQLite с поддержкой ICU нужно указать дефайн SQLITE_ENABLE_ICU(-DSQLITE_ENABLE_ICU для gcc, для MSVC не знаю). Ну и соответствено путь к хидерам и к самой либе ICU.
Попробуйте. Отпишитесь если удастся:)
Я считаю, что OpenID на сервисе с широкой аудиторией — бред. Да и вообще, по большей части бред:).
Вобще, основное использование OpenID сейчас — это «по быстрому заценить еще один бесполезный стартап», чтобы не мучаться с регистрацией. В таком случае, лучше вводить юзера demo/demo.
На сервисах, которыми мы пользуемся постоянно, у нас у всех нативные аккаунты, логины/пароли от которых мы прекрасно помним. Кстати, у большинства, на всех аккаунтах одинаковые ники/пароли, ну или набор из двух-трех разных.
Обычный же пользователь, зайдя на ссервис с OpenID, привычно будет искать обычную форму регистрации, но не найдет. Ему придеться(если нет аккаунта в жж, в рунете это похоже единственный провайдер) идти искать провайдера, и регистрироваться там. Провайдер скорее всего иностранный, пользователь не факт что знает английский, да и вобще слабо понимает, счевой то его куда-то посылают. В итоге, в большенстве случаев сервис просто теряет пользователя.
Решением тут может стать то, что сервис сам будет являться провайдером OpenID(как жж), но по сути, тогда теряется вся идеология этого дела.
И вобще, почему OpenID, а не OAuth например?:)
>По моему мнению, грамотность, прежде всего, берётся из прочитанной литературы.
Я исключение:) За школьные годы прочитал горы худлита, и сейчас очень много читаю.
При этом, по русскому у меня была тройка, и то, с натягом. Наверно больше внимания уделяю содержанию материала, а не его подаче. И сейчас, как не стараюсь, все равно очень часто пишу неграмотно, аж до позорных тся/ться доходит:)
Наверно по-этому меня ужасно раздражают указания на ошибки в коментариях. Увидел ошибку — отпиши в личку, не засоряй топик граммар-нацивским флудом!:)
Немного выше про это написал. Обычно используют сишный экстеншн.
Mongrel — многомного сишного кода.
Thin — EventMachine(которая внутри C++).
Ebb — обертка сишной libebb.
А Webricks в продакшене никто не использует:)
Сервер «на чистом PHP» — не для продакшена(покрайней мере не для больших нагрузок).
В продакшене обычно только то, что с приставкой «С»:)
На дебиане под гномом использую KDE'шные Amarok и тоже SMPlayer. Прописал kdeinit, на следующей перезагрузки посмотрим:)
Кстати, я правильно понял, что это влияет только на первый запуск KDE'шных программ?
Динамические языки в таком случае очень удобный для прототипирования. К примеру использование стандартной либы gserver в Ruby:
require 'gserver'
class MyServer < GServer
def serve io #обработка подключившихся клиентов
puts io.recv(256) #читаем что пришло от клиента
io.puts "request pprocessed" #отправляем в ответ
end
end
server = MyServer.new 1234
server.start
server.join
Для обкатки протокола — самое то, сишный код — в разы объемнее и запутаннее:)
А вот насчет продакшена — иногда и можно использовать.
К примеру есть питоновская библиотека Twisted(была на хабре даже статья), проекты на которой используется в продакшене.
И ее руби аналог — EventMachine тоже. Например на ней написан сервер руби приложений Thin, который с успехом используется в продакшене как альтернатива Mongrel(самый популярный руби сервер).
И меня не покидает чувство, что автор занимается велосипедостроением, я почти уверен что и для PHP есть высокопроизводительный аналог EventMachine или Twisted.
Такие либы обычно выполняются в виде С/С++ экстеншена, и вполне могут использоваться в продакшне.
А топикастеру совет, если это и вправду не велосипед, то оформить в виде сишного экстеншена, и уже вполне можно пускать как опенсурсный проект, PHP сообщество думаю будет благодарно:)
Хм, похоже вы путаете потоки и процессы. Когда форкаемся — порождается дочерний процесс. То есть по сути, еще один экземпляр программы. Потоки же работают в рамках одного процесса, а следовательно разделяют и его адресное пространство. Вобщем например все глобальные переменные/классы/функции — доступны в каждом потоке, проблемы обмена данными как таковой вобще нет. Так не только в Ruby, это в любом языке с поддержкой потоков.
Вот простой пример, на Ruby:
a = 25; #глобальная переменная
3.times do |i| #три раза пускаем поток
Thread.new do #создаем и запускаем поток
a +=1 #изменяем a в потоке
print "Hi from thread #{i}, a = #{a}\n"; #выводим номер потока и значение a
end
end
sleep 1 #дожидаемся пока завершатся потоки, иначе главный поток завершиться раньше, и остальные потоки принудительно завершатся
Результат выполнения
Hi from thread 0, a = 26
Hi from thread 1, a = 27
Hi from thread 2, a = 28
Да, еще в Ruby потоки «зеленые»(green-threads), смысл в том, что Ruby потоки не являются системными потоками, а эмулируются на уровне интерпретатора, тоесть, например почти тоже самое что и процессы в Erlang'e(процессами там такие легкие потоки называют, специфичные для Erlang'a).
Многопоточность — это очень удобная практика программирования, например для тех же серверов.
Если на каждого клиента форкаться — уйдет больше памяти, и сложнее синхронизироваться между процессами.
Но, правда и тут есть свои нюансы, основная проблема это синхронизация(всмысле доступа). Когда несколько потоков одновременно меняют одну и ту же переменную или в файл пишут и т.п. Боряться с этим мьютексами, но тут начинаются проблемы с дэдлоками:) Но вобще, потоки намного удобнее чем форк.
А pthreads — это популярная библиотека для реализации потоков в C/C++, судя по всему вот и PHP порт есть.
Я к сожалению про PHP точно сказать не могу(я Ruby программист), но могу накидать ссылок:)
Помимо Curl Easy есть еще Curl Multi интерфейс, он позволяет в одном потоке запускать сразу несколько подключений:
2. Enable multiple simultaneous transfers in the same thread without making it complicated for the application.
В PHP похоже есть обертка для Curl Multi интерфейса http://ru2.php.net/curl
И гугл по запросу php curl multi дает множество примеров.
Другой вариант запускать граббинг паралельно в потоках, например в Ruby я делаю так:
["http://google.com", "http://habrahabr.ru", "http://ruby-doc.org"].each do |site|
Thread.new {grab site}
end
Если я не ошибаюсь, в PHP нет нативной поддержки потоков, но гугл подсказал например порт pthreads. Хотя там вроде все сыро, так что в таком случае да, проще форкнутся.
ICU для windows есть: icu-project.org/download/4.0.html#ICU4C
При компилляции SQLite с поддержкой ICU нужно указать дефайн SQLITE_ENABLE_ICU(-DSQLITE_ENABLE_ICU для gcc, для MSVC не знаю). Ну и соответствено путь к хидерам и к самой либе ICU.
Попробуйте. Отпишитесь если удастся:)
Вобще, основное использование OpenID сейчас — это «по быстрому заценить еще один бесполезный стартап», чтобы не мучаться с регистрацией. В таком случае, лучше вводить юзера demo/demo.
На сервисах, которыми мы пользуемся постоянно, у нас у всех нативные аккаунты, логины/пароли от которых мы прекрасно помним. Кстати, у большинства, на всех аккаунтах одинаковые ники/пароли, ну или набор из двух-трех разных.
Обычный же пользователь, зайдя на ссервис с OpenID, привычно будет искать обычную форму регистрации, но не найдет. Ему придеться(если нет аккаунта в жж, в рунете это похоже единственный провайдер) идти искать провайдера, и регистрироваться там. Провайдер скорее всего иностранный, пользователь не факт что знает английский, да и вобще слабо понимает, счевой то его куда-то посылают. В итоге, в большенстве случаев сервис просто теряет пользователя.
Решением тут может стать то, что сервис сам будет являться провайдером OpenID(как жж), но по сути, тогда теряется вся идеология этого дела.
И вобще, почему OpenID, а не OAuth например?:)
Я исключение:) За школьные годы прочитал горы худлита, и сейчас очень много читаю.
При этом, по русскому у меня была тройка, и то, с натягом. Наверно больше внимания уделяю содержанию материала, а не его подаче. И сейчас, как не стараюсь, все равно очень часто пишу неграмотно, аж до позорных тся/ться доходит:)
Наверно по-этому меня ужасно раздражают указания на ошибки в коментариях. Увидел ошибку — отпиши в личку, не засоряй топик граммар-нацивским флудом!:)
Спасибо за статью:)
Mongrel — многомного сишного кода.
Thin — EventMachine(которая внутри C++).
Ebb — обертка сишной libebb.
А Webricks в продакшене никто не использует:)
Сервер «на чистом PHP» — не для продакшена(покрайней мере не для больших нагрузок).
В продакшене обычно только то, что с приставкой «С»:)
Кстати, я правильно понял, что это влияет только на первый запуск KDE'шных программ?
require 'gserver' class MyServer < GServer def serve io #обработка подключившихся клиентов puts io.recv(256) #читаем что пришло от клиента io.puts "request pprocessed" #отправляем в ответ end end server = MyServer.new 1234 server.start server.joinДля обкатки протокола — самое то, сишный код — в разы объемнее и запутаннее:)
А вот насчет продакшена — иногда и можно использовать.
К примеру есть питоновская библиотека Twisted(была на хабре даже статья), проекты на которой используется в продакшене.
И ее руби аналог — EventMachine тоже. Например на ней написан сервер руби приложений Thin, который с успехом используется в продакшене как альтернатива Mongrel(самый популярный руби сервер).
И меня не покидает чувство, что автор занимается велосипедостроением, я почти уверен что и для PHP есть высокопроизводительный аналог EventMachine или Twisted.
Такие либы обычно выполняются в виде С/С++ экстеншена, и вполне могут использоваться в продакшне.
А топикастеру совет, если это и вправду не велосипед, то оформить в виде сишного экстеншена, и уже вполне можно пускать как опенсурсный проект, PHP сообщество думаю будет благодарно:)
Вот простой пример, на Ruby:
a = 25; #глобальная переменная 3.times do |i| #три раза пускаем поток Thread.new do #создаем и запускаем поток a +=1 #изменяем a в потоке print "Hi from thread #{i}, a = #{a}\n"; #выводим номер потока и значение a end end sleep 1 #дожидаемся пока завершатся потоки, иначе главный поток завершиться раньше, и остальные потоки принудительно завершатсяРезультат выполнения
Да, еще в Ruby потоки «зеленые»(green-threads), смысл в том, что Ruby потоки не являются системными потоками, а эмулируются на уровне интерпретатора, тоесть, например почти тоже самое что и процессы в Erlang'e(процессами там такие легкие потоки называют, специфичные для Erlang'a).
Многопоточность — это очень удобная практика программирования, например для тех же серверов.
Если на каждого клиента форкаться — уйдет больше памяти, и сложнее синхронизироваться между процессами.
Но, правда и тут есть свои нюансы, основная проблема это синхронизация(всмысле доступа). Когда несколько потоков одновременно меняют одну и ту же переменную или в файл пишут и т.п. Боряться с этим мьютексами, но тут начинаются проблемы с дэдлоками:) Но вобще, потоки намного удобнее чем форк.
А pthreads — это популярная библиотека для реализации потоков в C/C++, судя по всему вот и PHP порт есть.
Помимо Curl Easy есть еще Curl Multi интерфейс, он позволяет в одном потоке запускать сразу несколько подключений:
В PHP похоже есть обертка для Curl Multi интерфейса http://ru2.php.net/curl
И гугл по запросу php curl multi дает множество примеров.
Другой вариант запускать граббинг паралельно в потоках, например в Ruby я делаю так:
["http://google.com", "http://habrahabr.ru", "http://ruby-doc.org"].each do |site| Thread.new {grab site} endЕсли я не ошибаюсь, в PHP нет нативной поддержки потоков, но гугл подсказал например порт pthreads. Хотя там вроде все сыро, так что в таком случае да, проще форкнутся.