Для Англии - сначала сюда: http://www.workingintheuk.gov.uk/working_in_the_uk/en/homepage/schemes_and_pr...

Панимаишь, в Windows Way предполагается, что File->Open обязательно должно присутствовать, даже если нет никаких файлов, и никаких open над ними не определено. Однако, среднестатический виндоюзер обосрётся, если не найдёт в программе менюшки File с опцией Open, пусть даже она НИЧЕГО и не делает. Бред? Бред. Но с ним надо считаться.

Кстати, вышеописанный вариант с очередью запросов тривиально подменяется однопоточной реализацией - достаточно переписать только лишь саму очередь, остальной код трогать не надо. Так что - настоятельно рекомендую, это суть есть наиболее общее решение.

P.S. Во избежание передёргиваний и воплей "Microsoft сасёт" добавлю, что это далеко не единственная VM с нормальной поддержкой хвостовой рекурсии. Пожалуй, наоборот, JVM - досадное исключение.

Ну так и используй thread pool + очередь. Совершенно стандартный шаблон для такого типа задач. Алгоритм такой: генерится N ожидающих тредов, 1 тред висит на голове очереди запросов и очереди свободных тредов. Каждый раз, как обе очереди разблокируются одновременно, выбирается запрос из очереди запросов и тред из очереди свободных тредов, запрос отдаётся треду на выполнение, выбираем следующую пару, пока одна из очередей не заблокируется. Ещё один тред скармливает в хвост очереди запросов поступающие данные (так же и сами обработчики могут в очередь запросов что либо добавлять).

Ссылку можно?

Почти никак - у него очень навороченный plain tex.

А на хера мне писать поддержку на уровне JVM, когда у меня есть поддержка на уровне MSIL?

Нужна поддержка на уровне VM, такая, как в .NET - там разные инструкции для call и tail call, вторая не пихает контекст в стек. Если же реализовывать это через инструкции перехода, то будут получаться слишком большие методы (и куча методов будет инлайнится) - что тут не так давно обсуждалось, а JIT очень не дружит с большими методами.

Немного возни в районе Xdefaults - и внешний вид становится неубогим. "Убожество" Tk-шного интерфейса в его непривычности. Он повторяет внешний вид Motif-ных виджетов, а поколению Пепси Motif не очень знаком, так что надо подгонять под виндовые виджеты, что, к счастью, совершенно ни разу не проблема.

А так же - гойворить и писать. См. на Дж. Буша мл.

Нет хвостовой рекурсии и замыканий. Без них язык - не язык, а дерьмо.

Ха! Пионэр думает, что если он "сам" компилирует, то какчество лучшее будет. Может, ты ещё и весь компиляемый тобой код на предмет закладок просматриваешь?

Ну кто ж виноват, что ты полез пользовать пионэрский дистрибутив?

Читать умеешь, или где?!? Я же сказал - не надо пробовать. Надо характеристики читать. В первую очередь - список пакетов, обращая внимание на версии и зависимости.

В Debian sid? Из коробки? А какая из версий, их там 3 под 3 разных Питона, и (на скорый и, конечно же, неполный тест) все работают.

Что же у тебя из коробки не работает?

На хера что-то там переустанавливать - для выбора нужного дистрибутива достаточно про их ТТХ почитать.

Ещё раз, для тупых, повторяю медленно: используй дистрибутив, в котором нужный тебе софт УЖЕ есть. Какие трудности?!?

Ты не заметил, что В КАЖДОМ этом бинаре идут ВСЕ библиотеки, которые ему нужны? А теперь подумай, в какой жёпе ты окажешься, когда захочешь использовать всё это вместе.

Ну и? Та же жопа с зависимостями, весь софт от разных поставщиков. Правильно тебе сказали - юзай debian.

Ну и где в продукции компании Microsoft аналог библиотеки scipy? В венде с зависимостями ещё большая жёпа, чем в лялихе.

Я никогда не говорил, что надо знать english. Для программиста english *обязателен* - но только на уровне read only.

Динамическое позднее связывание в серверных задачах таки нужно, тут Жабка слегонца поруливает. Конечно же, всё равно ни в какое сравнение не идёт с инкрементальной компиляцией в Лиспе.

nethack, конечно же. Год проходить будешь, как минимум...