Существует ли хотя бы одна вменяемая реализация Common Lisp?

>> Кроме того, о нормальной дистрибуции программ можно забыть.

Что есть «нормальная дистрибуция»? Средство для чистки имиджа? Если да, то этим могут похвастаться разве что коммерческие реализации (ACL, LW).

есть

называется python

Существует ли хотя бы одна вменяемая реализация Common Lisp?

исследовал данный вопрос, увы, для свободно распространяемых реализаций получил схожий результат, если только LispWorks или Allegro Common Lisp, то есть коммерческие, но они за очень большие деньги

> Кроме того, о нормальной дистрибуции программ можно забыть.

Если речь о размерах, то они терпимы. Например Windows инсталлятор моей поделки на SBCL и GTK+ занимает 15МиБ (Вместе с GTK+). Многовато для такой мелкой проги, но вполне терпимо.

Или, вот, maxima. Deb-пакет 11МиБ, а в нём образ для GCL на 57МиБ.

Размер образа большой, но растёт не быстро.

Кроме того, о нормальной дистрибуции программ можно забыть.

Жопой чую, save-lisp-and-die поможет отцу русской демократии.

Но все равно

Но каждый экземпляр весит в оперативной памяти хотя бы 50 мб

Вот прикинь, если в твоем top каждый процесс, жрущий менее 50 мб, станет жрать 50 мб? И каждый установленный бинарник в твоем /, занимающий менее 30 мб, станет занимать 30 мб?

> Существует ли хотя бы одна вменяемая реализация Common Lisp?

Очевидно, что вменяемость характеристика очень субъективная и сильно зависит от ваших целей. Я использую CL для сервера приложений и для меня SBCL весьма вменяемая реализация.

Набор характеристик конкретной реализации зависит от потребностей её разработчиков. Часто бывает так, что они не соответствуют вашим, увы. Но, в любом случае, патчи приветствуются.

>SBCL, Clisp - казалось бы, все хорошо. Но каждый экземпляр весит в оперативной памяти хотя бы 50 мб

Про CLISP вранье. Не весит его ядро столько!

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

Ни разу такого не было. О каких массивных библиотеках идет речь? McCLIM я могу считать массивной? В CLISP работает. Никаких проблем *при загрузке* я не припомню.

На многих системах (в том числе и у меня)

А у кого еще? Давай конкретику, что за библиотека вызывает падение, а не общими словами, иначе это гон.

Про массивные ничего не знаю, но то что значительная часть библиотек в clisp не грузится как бы факт.

>Про CLISP вранье. Не весит его ядро столько!

А, звиняй. Я имел в виду SBCL и CMUCL.

А у кого еще? Давай конкретику, что за библиотека вызывает падение, а не общими словами, иначе это гон.

http://www.google.ru/search?q=clisp+stack+overflow&ie=utf-8&oe=utf-8 http://www.google.ru/search?q=stumpwm+stack+overflow&ie=utf-8&oe=utf-8

Например CXML, CLX.

>Вот прикинь, если в твоем top каждый процесс, жрущий менее 50 мб, станет жрать 50 мб? И каждый установленный бинарник в твоем /, занимающий менее 30 мб, станет занимать 30 мб?

Одептов изотерического программирования такие мелочи не волнуют. Полагается, что человек обязательно должен купить серверную платформу с 64Gb+ RAM и 10TB+ HDD, чтобы можно было запускать их скобочные поделки.

>http://www.google.ru/search?q=clisp+stack+overflow&ie=utf-8&oe=utf-8

http://www.google.ru/search?q=stumpwm+stack+overflow&ie=utf-8&oe=utf-8

Проблемы в cl-ppcre.

Например CXML,

Вранье. Загружается без проблем. Только что проверил.

CLX.

Вранье. Загружается без проблем. Только что проверил.

>А у кого еще? Давай конкретику, что за библиотека вызывает падение, а не общими словами, иначе это гон.

clisp-2.48 и clisp-2.49 под linux/amd64. Падение при вызове любого коллбэка.

> Одептов изотерического программирования такие мелочи не волнуют. Полагается, что человек обязательно должен купить серверную платформу с 64Gb+ RAM и 10TB+ HDD, чтобы можно было запускать их скобочные поделки.

зачем прилетел сюда? говном тут еще не обмазывали. Кыш, кыш.

>Вранье. Загружается без проблем. Только что проверил.

http://www.codinghorror.com/blog/2007/03/the-works-on-my-machine-certificatio...

>http://www.codinghorror.com/blog/2007/03/the-works-on-my-machine-certificatio...

Говноссылки не нужны. Давай конкретику. Я ее не вижу. Пока порожняк.

>clisp-2.48 и clisp-2.49 под linux/amd64. Падение при вызове любого коллбэка.

Это проблема, вызванная переполнением стека, да? Не аргумент вообще, а только проблема с конретной архитетурой. Причем тут это? Разве вопрошающий про это говорил, Да залезь в багзилу любого пакета — везде ошибки есть. Я про конкретную, о которой автор. Вот пусть воспроизведет и даст полный расклад, что за версия, откуда брал и т. д. ТОгда будет предметный разговор.

>> http://www.codinghorror.com/blog/2007/03/the-works-on-my-machine-certificatio...

Говноссылки не нужны. Давай конкретику.

Я не ходил по ссылке, но она намекает на то, что «УМВР» не является убедительным аргументом в разговоре о сбоях ПО.

>Я не ходил по ссылке, но она намекает на то, что «УМВР» не является убедительным аргументом в разговоре о сбоях ПО.

Я тоже сходил, хотя уже по самой ссылке было понятно, куда я попаду. Но я разве не просил конкретики у автора? Просил сразу же, а он мне ссылки из гугла.

Присоединяюсь к вопросу.

Есть ли вменяемая реализация плагина для поддержки кодинга/колоринга/синтаксиса на Lisp к редактору Eclipse IDE?

>Это проблема, вызванная переполнением стека, да?

Нет. Проблема вызвана, как я понимаю, тем, что используемая в clisp библиотека ffcall давно заброшена ее автором.

Причем тут это?

При том, что из-за этого в clisp много всяких биндингов работать не будут. И в связи с этим говорить о серьезности использования clisp не приходится.

>Да залезь в багзилу любого пакета — везде ошибки есть.

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

>Есть ли вменяемая реализация плагина для поддержки кодинга/колоринга/синтаксиса на Lisp к редактору Eclipse IDE?

Cusp и Dandelion по какой-то причине невменяемы ?

>При том, что из-за этого в clisp много всяких биндингов работать не будут. И в связи с этим говорить о серьезности использования clisp не приходится.

Если эта проблема еще не исправлена (я не смотрел), то она говорит только о проблемах на отдельной архитектуре. Я думаю, что ее исправят. У меня дома машин с архитектурой 64 бита нет, проверить и исправить не могу. Ты подтверждаешь проблему на 32-битах? Можно твой вердикт распространить на все порты clisp?

> ECL ... Кроме того, о UTF-8 можно забыть

Вроде бы в последних версиях это пофиксили, вы какую версию смотрели?

Вот прикинь, если в твоем top каждый процесс, жрущий менее 50 мб, станет жрать 50 мб?

/home/ugoday% ps -A|wc -l
128
/home/ugoday% dc
50
128
*
p
6400

С одной стороны шесть тыщ четыреста мегобайтов --- это как-то нереально дохрена для компьютера, в котором кроме emacs,conkeror,pidgin,transmission и пары терминалов ничего не запущено. Но на самом деле большая часть из этих 128 процессов составляет мелкая скриптовня, которую писать на КЛ в лобовую просто бессмысленно. Вместо этого, вздумай кто заменить обычный шелл лиспом, следовало бы написать обычный сервер приложений на КЛ и скриптовать уже его. Всё вместе это заняло бы не многим более тех же самых 50МБ, что вполне приемлимо.

Одептов изотерического программирования

Что-то я криптоштангистов не заметил в обсуждении.

на 32бит таких проблем нет.

Автор, тебе уже все расписали по 100 раз, в lisp@c.j.r в том числе.
Даже ссылки на c.l.l. давали.

Чо ты какой упоротый? Сходи пролечись от наркозависимостей.

Чо ты какой упоротый?

Love5an

Это говорит человек, который на Си вызывает clisp чтобы узнать домашний каталог.

Это тут при чем? Или ты так, просто пердануть зашел?

при том, что ты сам упоротый. А у автора конкретные вопросы.

Коротко резюмируя, можно повторить фразу с c.l.l.

«Ok, Lisp is not made for hello world programs. For that you can use C, it's exactly it's domain of application.

Come back when you have a real application to write. »

классная фраза :)))

Только от этого SBCL не стал занимать меньше, Clisp не стал менее глючным (впрочем, ув. Zubok мне не верит), а ECL не стал загружать весь cliki с пол-пинка. А убеждать меня в том, что для любой десктопной программы сложнее хеллоуворлда отжирать столько не является актом проявления неуважения к своим пользователям - то же самое, что пытаться меня убедить что черное является белым. Я же надеюсь, что никто не будет утверждать, что я - упоротый потому, что отказываюсь признавать столь очевидно неверное утверждение?

> А убеждать меня в том, что для любой десктопной программы сложнее

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

к своим пользователям

Поэтому такие программы с помощью свободных реализаций CL и не пишут. Ни одна из свободных реализаций CL в настоящий момент не годится для создания «обычных» декстопных приложений. Либо ты принимаешь подобное положение вещей, либо пишешь на C++.

Всё имеет свою цену и за возможность использовать CL тоже надо платить.

>Ни одна из свободных реализаций CL в настоящий момент не годится для создания «обычных» декстопных приложений.

Замечательно подходит, если только не ориентироваться на нищебродов с системниками 10летней давности.

>А убеждать меня в том, что для любой десктопной программы сложнее хеллоуворлда отжирать столько не является актом проявления неуважения к своим пользователям - то же самое, что пытаться меня убедить что черное является белым.

Да ты упоротый чтоли?
Сколько «столько»? 30 мегабайт на стандартную библиотеку?

2010 год на дворе! Гигабайты оперативки стоят копейки! А гигабайты места на жестких дисках и того дешевле.

Вот именно что только для каких-нибудь сраных хелловордов это и может показаться излишним. Любая хоть что-нибудь полезное делающая десктопная программа и так тащит за собой такой вагон говна, что 30 мб по сравнению с ним просто ничего не значат.

2010 год на дворе! Гигабайты оперативки стоят копейки! А гигабайты места на жестких дисках и того дешевле.

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

Оптимизировать надо во-первых, по производительности, во-вторых постфактум, после использования профайлера, и в третьих - если и по памяти, то уж точно не на уровне программы - основное место в любой более-менее крупной десктопной программе занимает разнообразное медиа, соответственно, если и оптимизировать, то в плане форматов данных.

И совсем другое, что вы все нищеброды, раз не можете себе это позволить.

Ну а если действительно нищеброды и нытики? Никто из разработчиков свободных реализаций CL не будет за просто так и в здравом уме перехерачивать всю систему дампа образа в файл и писать сложную инфраструктуру tree-shaker'а только потому, что некоторым нищебродам так жалко 30 мегабайт.

Ну а если действительно нищеброды и нытики? Никто из разработчиков свободных реализаций CL не будет за просто так и в здравом уме перехерачивать всю систему дампа образа в файл и писать сложную инфраструктуру tree-shaker'а только потому, что некоторым нищебродам так жалко 30 мегабайт.

даже если 32 Мб - размер дискового накопителя? Для примера, в этот размер умещается ARM система с небольшой Qt3/fb программой.

Страшное скажу и на однокристалках КЛ тоже не взлетит.

> Замечательно подходит

Поскольку мы не имеем большого колличества декстопных приложений на CL, то, очевидно, это не так.

пользовал stumpwm+sbcl на 256Мб (сейчас добил до 512) памяти и 1200м celeron-е. Вполне нормально работало (если параллельно chromium с тяжелыми страницами не запускать). И это совсем ископаемая машина, по нынешним временам.

>называется python

ага, только оно тоже для «нормальной» дистрибуции таскает с собой интерпретатор

Но каждый экземпляр весит в оперативной памяти хотя бы 50 мб (впрочем, лисперы утверждают, что по нынешним временам это нормально).

Это довольно известная проблема SBCL, скорее техническая - это не вопрос «вменяемости» или неуважения к пользователям. Проблема в том, что имеется компилятор (даже не в компиляторе дело, а в интроспекции REPL-а) доступный во время исполнения, поэтому сделать линкер типичного вида (как в реализациях языка си, например) оказывается сложно - проще всего либо полностью сохранять весь образ, либо кэшировать скомпилированный код в fasl-ы (+ стандартный образ). Что сейчас и делается. Другие варианты решения, в порядке увеличения сложности, могут быть такие:

• Проще всего запускать одну версию SBCL и проксировать ей весь выполняемый код, в том числе загрузку уже скомпилированного в fasl-ы кода. Это по крайней мере избавляет от нескольких образов в памяти - образ один, а «приложения» выполняются в контексте своих трэдов. Проблема тут может возникнуть если разным приложениям понадобятся разные версии одной и той же библиотеки. Вот кстати - http://lisper.ru/forum/messages/4949.
• Стабильные в широком диапазоне версий fasl-ы. И распространение программ как архивов fasl-ов. dmitry_vk писал что без стабильного ABI fasl-ов это сложно сделать (а сделать этот ABI стабильным тоже не так просто).
• Tree shaking, т.е. некая процедура shake-lisp-and-die позволяющая сохранить образ только с необходимыми частями. Был такой proof-of-concept у одного из разработчиков - http://jsnell.iki.fi/blog/archive/2005-07-06.html (это, кстати, человек, который пилил SBCL по заказу ITA Software). В этом случае может быть сложным детектировать какие часть нужны а какие нет - простейшая программа (loop (print (eval (read)))) должна привести к сохранению всех частей образа (та самая проблема интроспекции).
• OS compatible shared libraries, т.е. сохранение непосредственно в формате ELF, PE или Mach-O. Что выглядит совсем сложно.

Так что пока можете посмотреть на lispx-proxy.

Кроме того, о нормальной дистрибуции программ можно забыть.

О нормальной дистрибуции программ с закрытым исходным кодом вы хотели сказать?

Не имеем мы их из-за небольшого размера сообщества, непопулярности и отсутствия более-менее вменяемых(юзер-френдли) бесплатных средств разработки, а не из-за того, что CL «не подходит».