Игру за неделю!

Питон фтопку потому что тормозит!! ;)

На самом деле это конечно же не так. Щяс многие игрушки на нем пишут. Тот же Civ4 и Battlefield2 используют питон

может слабаем клон огейма, например?

Разве, что пых-пых-пых?;)

Все как всегда остановится на выборе языка программирования.

язык в правилах конкурса предусмотрен только один -- питон

>язык в правилах конкурса предусмотрен только один -- питон

Нет проблем: какой тулкит будем использовать? :)))

хто придёть???

Ща придёт geek и скажет про GTK+. :)

P.S. А Python как основа, а не подключаемый модуль - жрущий память мутант. :)

какая разница?

для веба гтк... это не юмор, это клиника

советую попить йоду

У вас кончилось место под плашки памяти, кои стоят сейчас в базарный день рубль ведро?

Free memory - wasted memory (c) bo

зато с 3D должно быть всё заебись, дум третий летает просто?

У вас неправильный PDA. На нем еще небось и майкрософт уиндоуос стоит?

Уиндоуос не оправдание, ибо есть http://pythonce.sourceforge.net.

Читайте внимательнее, я сказал в порт не обернешь. Это вам не скомпилил - бинарник в $prefix/bin кинул и свободен. Это мля невнятная куча файлов, которые непонятно куда класть и где пути к ним прописывать.

glibc тоже в каждый бинарник линкуем? чтоб в бин кинул и свободен?

Ну, а то, что make у FreeBSD'шников, начиная с 6.x работает, похоже, только на FreeBSD - вообще анекдот (у Net/Open-BSD'шников make свой, растущий из того же корня, но уже несовместимый по ключам и языку, но зато реально переносимый и _работающий_ на других платформах).

// очень злой Лёша, которому давеча пришлось погрузиться в это смердящее BSD'шное болото.

а у меня есть. на Loox 720.

nerezus

Итого, порты.

Имеется перл-5.8.7 с некоторым набором CPAN-овских модулей. Требуется перл-5.8.8. Поскольку в портах модули ставятся по следующему пути:

/usr/local/lib/perl5/<exact-perl-version>/... и /usr/local/lib/perl5/site_perl/<exact-perl-version>/

то такое незначительное, на первый взгляд, изменение в системе приводит к необходимости переустановки ВСЕХ перловых пакетов. Разумеется, при желании этот процесс можно и автоматизировать, но изначальная система (напомню, использовать портапргейд - против правил) - крайне убога.

Кто-то может сказать: "неудачный порт". "Идиот? Да их тут сотни!". Количество косячков в портах переваливает все разумные пределы. Но да ладно, поищем чего-нибудь пофундаментальнее, благо, примеров - хоть отбавляй.

Если порт B требует порт A, то при сборке в зависимости к B попадает A с указанием точной версии, стоявшей на момент сборки B. Соответственно, вне зависимости от реальной потребности в пересборке, для сохранения целостности базы мы обязаны пересобирать все зависящие от него пакеты (причем, в момент такой пересборки система будет, мягко говоря, в разобранном состоянии, так как нормального атомарного апгрейда все еще нет как нет).

Ну, и всякие мелкие глупости, типа завязок на точную версию аутотулз USE_AUTOCONF_VER=xyz, в то время как весь остальной мир уже давно определяет требуемую софтине версию (maj.min) автоматом...

Сходу вспоминается еще крайне убогая система спецификации версий в *_DEPENDS. То есть, теоретически, поддерживается <>, практически для этого нужно знать некоторые интересные подробности реализации, которых большинство "пейсателей" портов не знает, а поэтому не пользуется.

Еще не устали? Могу и про make рассказать :-). Тут уж примеры кода будут и цитатки из комментариев.

Да, кстати, в курсе, что каждый, кто использует FreeBSD - пособник вора? Ой, не зря вас по судам таскали :-).

> Да, кстати, в курсе, что каждый, кто использует FreeBSD - пособник вора? Ой, не зря вас по судам таскали :-). `А мужики-то и не знают!'... Меня лично никуда не таскали. Если я пособник вора - меня это нисколько не огорчает, даже наоборот :) Расскажите же скорей у кого мы воруем?

Стоп. портапгрейдом мне пользоваться запретили :-). Но и у портапгрейда есть неисправимые родовые травмы.

Это не претензия. Это констатация факта. Порты ущербны. А будут они как-то развиваться, или подохнут в страшных муках - мне все равно.

Большая! Для сравнения - Zope и yum - монстры, целиком писанные на Python, а Петька и ВИЧ - весьма шустрая игра _с_использованием_ Python. :)

А кто говорил про Web? :)

P.S. Для Web и Python - клиника. :)

Деньги можно потратить более эффективно. Тем более, что никаких толковых решений на Python нет. :)

> Большая! Для сравнения - Zope и yum - монстры, целиком писанные на Python, а Петька и ВИЧ - весьма шустрая игра _с_использованием_ Python. :)

во-первых в оригинале было

> Python как основа, а не подключаемый модуль

про "целиком писанные на Python" вопрос не ставился.

если питон -- именно "основа", т.е. высокоуровневый код который для чёрной работы юзает внешние библиотеки (например SDL в играх), такая программа ничем не отличается от "питон как подключаемый модуль".

zope -- действительно монстр, и не потому что питон, а потому что перемудрили с архитекторуой. но zope это прошлый век. сейчас есть вполне шустрые и удобные django и turbogears.

> А кто говорил про Web? :) 

см.вверх по треду -- там было предложено клонировать огейм

> P.S. Для Web и Python - клиника. :)

чтобы слепить что-нибудь за неделю -- сгодится