LINUX.ORG.RU

Вышел новый релиз реализации языка Common Lisp - Clozure CL 1.5

 ,


0

0

Вышел новый релиз реализации языка Common Lisp - Clozure CL 1.5. Этот релиз включает много исправлений и улучшений:

  • Изменена версия FASL файла и образа памяти по сравнению с 1.4. Для перехода на версию 1.5 необходимо пересобрать все старые FASL файлы.
  • [Mac OS X] Ядро лисп системы собрано с SDK 10.5 поэтому небходима версия Mac OS X Leopard или выше.
  • Улучшена стандартная функция CL:RANDOM. Используется MRG321k3p генератор с периодом 2^185.
  • опция PURIFY теперь поддерживается на х86 архитектурах. PURIFY'ed объекты копируются в область памяти, которая не сканируется сборщиком мусора. Pезультатом может быть увеличенная скорость сборки мусора, a также улучшено совместное использование виртуальной памяти, если одновременно запущенно несколько процессов.
  • REBUILD-CCL теперь подавляет предупреждения при измении констант.
  • Переменные ввода/вывода связанные WITH-STANDARD-IO-SYNTAX (*PRINT-BASE*, *PRINT-ARRAY*, etc.) теперь локальны для каждого треда.
  • Добавлены бивалентные векторы. Они похожи на строковые потоки, только используются векторы размером (UNSIGNED-BYTE 8).
  • Ядро системы загружает только образ памяти, имя файла которого состоит из «kernel_name» + ".image" суффикс.
  • Улучшены утилиты анализа памяти: CCL:HEAP-UTILIZATION, CCL:HEAP-IVECTOR-UTILIZATION.

Поддерживаемые платформы:

  • Mac OS X 10.5 и позже(x86, x86-64, ppc32, ppc64)
  • Linux (x86, x86-64, ppc32, ppc64)
  • FreeBSD 6.x и позже (x86, x86-64)
  • Solaris (x86, x86-64)
  • Microsoft Windows XP и позже (x86, x86-64)

>>> Подробности



Проверено: isden ()

Ответ на: комментарий от www_linux_org_ru

> HTML & ODF тоже DSL

И эти люди рассуждают о DSL? И PNG это, конечно, тоже DSL?

archimag ★★★ ()
Ответ на: комментарий от dave

> DSL подразумевает декларативность прежде всего.

скорее нет, чем да

декларативность сюда (к еДСЛ-ям) затесалась по той причине, что по-настоящему декларативные конструкции требуют такой обработки компилятором хост-языка, которой обычно не предусмотрено

например, мы хотим сделать свой switch с банановым вкусом (с константными строками-образцам), при этом сделать оптимизацию: если один образец является начальной подстрокой другого, то повторно совпадение не проверяется; я не знаю, как такое сделать в скале (и думаю, что невозможно)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от archimag

> И PNG это, конечно, тоже DSL?

да,

и вполне реально, что кому-то захочется реализовать его как embedded DSL

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

>> И PNG это, конечно, тоже DSL?

да


Ну тогда и JPEG тоже DSL. И gif DSL, и формат документов MS Office это тоже DSL, и BMP если внимательно присмотреться - тоже DSL.

Хватит курить траву, вредно для здоровья...

archimag ★★★ ()
Ответ на: комментарий от archimag

> Да точно нет, как ни смотри, ибо это просто формат, как и HTML.
формат ? - а почему не декларация (уже упамянутая) или спецификация

то какая из лисп библиотек лучше, чем аналогичные возможности lxml (python)?


смотря что считать лучше, если гибкость то однозначно лисп хоть с либой из pcl, если нужен готовый набор фичастых кубиков то mainstream рулит, а lisp еще пока не совсем, смотря что пишем и надолго ли

А вот это совершенно не понятно,

тогда так, представь что описываеш внешний DSL, а потом когда опишеш просто добавь скобочек :) кстати верно и обратное, если из примера на сайте cl-pdf выкинуть скобочки и прочее второстепенное появится текст понятный даже некоторым продвинутым полиграфистам

PostScript, XSLT или там awk. И между этими примерами достаточно легко можно обнаружить общность, что это именно DSL


а можно сформулировать общность PostScript и XSLT

Но кроме «макросов» другой общности мне увидеть не удаётся.

и даже макросов может и не быть, не то что преобразований

И опять таки, если полезность внешних DSL хорошо известна и доказана практикой, то на каких основаниях можно судить о пользе eDSL совершенно не ясно.


а чем по сути так отличаются внешние и внутренние DSL, кроме аспектов реализации, тем более с точки зрения полезности ? к тому же последние куда мощнее за счет возможности взаимной интеграции ...


ed ★★ ()
Ответ на: комментарий от archimag

>> Наличие выделенного этапа трансляции eDSL -> host language.

Выглядит убедительно, но можно практический пример?

Простейший пример - мaкрос ford, который дал Саныч (это такой примитивный eDSL из одной конструкции). Добавить в него проверку границ, чтобы он генерировал пустой оператор, если границы равны - будет настоящий транслятор :)

cl-who, пожалуй делает нечто подобное

В CL не разбираюсь вообще.

tailgunner ★★★★★ ()
Ответ на: комментарий от archimag

> Зачем тогда вообще отдельно упоминать об этом eDSL? Если его не отличишь от обычного api?

а тут смотря как определить API, в моем понимании API это foo_create_node(FOO_X) и foo_set_attribute(FOO_A,«b»), при этом:

1. все очень длинно

2. компилятор не замечает имя атрибута с опечаткой

3. компилятор не замечает несовместимого набора атрибутов

4. IDE не делает completion

в хорошо сделанном eDSL все наоборот

на самом деле перечень явно не полный...

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от ed

> формат ? - а почему не декларация (уже упамянутая) или спецификация

Если говорить правильно, то язык разметки, на который есть спецификация.

если нужен готовый набор фичастых кубиков то mainstream рулит


Да при чём тут mainstream? Я имел в виду конкретно это решение: http://codespeak.net/lxml/tutorial.html#the-e-factory

если из примера на сайте cl-pdf выкинуть скобочки и прочее

второстепенное появится текст понятный даже некоторым продвинутым


полиграфистам



Гы ))) Ты вообще когда-нибудь читал спецификацию на PDF? а на PostScript? А с cl-pdf много работал? Подозреваю элементарную инженерную неграмотность.

а можно сформулировать общность PostScript и XSLT


Это специализированные языки программирования. На них можно программировать, но эффективно только в рамках предметной области.

а чем по сути так отличаются внешние и внутренние DSL, кроме

аспектов реализации, тем более с точки зрения полезности ?



Не знаю, я хочу увидеть пример хорошего eDSL, но мне его не показывают :(

archimag ★★★ ()
Ответ на: комментарий от www_linux_org_ru

> а тут смотря как определить API, в моем понимании API это

foo_create_node(FOO_X) и foo_set_attribute(FOO_A,«b»), при этом:


В таком случае, библиотека lxml (http://codespeak.net/lxml/) является примером DSL?

archimag ★★★ ()
Ответ на: комментарий от tailgunner

> Простейший пример - мaкрос ford, который дал Саныч

Это просто макрос. Хорош язык с одной конструкцией и без определённого domain.

archimag ★★★ ()
Ответ на: комментарий от archimag

А cl-pdf просто библиотека, api для генерации pdf, почему стоит причислять её к eDSL мне не понятно.

я склонен cl-pdf отнести к api (а что там по моим пунктам 2,3,4?)

вот хорошая тема для обсуждения: как должен выглядеть этот фрагмент кода в eDSL

(pdf:with-document ()
   (pdf:with-page ()
     (let ((helvetica (make-instance 'pdf:font)))
       (pdf:add-fonts-to-page helvetica)
       (pdf:in-text-mode
         (pdf:set-font helvetica 36.0)
         (pdf:move-text 100 800)
         (pdf:draw-text "CL-PDF: Example 1"))
       (pdf:translate 230 500)
       (loop repeat 101
         for i = 0.67 then (* i 1.045)
         do (pdf:in-text-mode
           (pdf:set-font helvetica i)
           (pdf:move-text (* i 3) 0)
           (pdf:draw-text "rotation"))
         (pdf:rotate 18))))
   (pdf:write-document #P"ex1.pdf"))

И вопрос: pdf:with-document и pdf:with-page работают лексически или динамически? Т.е. если вдруг внутри мы вызовем функцию, которая (неожиданно) тоже создает пдф-документ, она будет писать в тот же документ на ту же страницу?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от archimag

>> Простейший пример - мaкрос ford, который дал Саныч

Это просто макрос

Это просто пример.

Хорош язык с одной конструкцией и без определённого domain.

Его domain - генерация циклов :)

tailgunner ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> И вопрос: pdf:with-document и pdf:with-page работают лексически

или динамически?


Эти макросы просто настраивают динамические переменные *document* и *page* (про динамические переменные можно почитать здесь: http://lisper.ru/articles/cl-vars), плюс with-page проводит финализацию страницы, по сути, они аналогичны макросу with-open-file, просто работают с другими объектами. Какой-либо обработки кода (&body) внутри макроса не производиться, он вызывается как есть (обратный пример можно посмотреть в упоминавшейся cl-who, в которой тело макроса обрабатывается специальным образом). Так же и макрос in-text-mode, просто настраивает динамическое окружение.

archimag ★★★ ()
Ответ на: комментарий от archimag

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> неявные параметры передавать можно и нужно лексически (это даже ява

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

переменные это дурной тон...



Да ладно, это одна из мощнейших и широко используемых фич Common Lisp, принципиально упрощающих программирование во многих ситуациях.

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


И чё? Common Lisp вообще-то язык динамический...

archimag ★★★ ()
Ответ на: комментарий от archimag

> И чё? Common Lisp вообще-то язык динамический...

затруднено программирование в функциональном стиле

например, необходимо читать из входного потока команды на запись и параллельно (но в рамках одной нити) писать в 10 страниц одной пдф-ки

функционально было бы сделать массив, положить туда 10 замыканий; каждому замыканию на вход подается команда, оно что-то пишет на свою страницу и возвращает новое замыкание (либо нил, если команда была закончить работу)

можно ли обернуть (не переписать) этот код во что-то, чтобы

1. страница и документ сохранялись в замыканиях?

2. этот код нормально работал в параллельно исполняемых нитях?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> затруднено программирование в функциональном стиле

ничего, это мы переживём ;)

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


Можно. Только зачем?

этот код нормально работал в параллельно исполняемых нитях?


Я использую cl-pdf на стороне веб-сервера во время обработки запросов. Никаких проблем с параллельным исполнением. Кажется ты не понял, что такое динамические переменные ;)

archimag ★★★ ()
Ответ на: комментарий от www_linux_org_ru

5. в хорошо сделанном eDSL все что может быть вычеслено во время компиляции вычисляется именно тогда

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> в хорошо сделанном eDSL все что может быть вычеслено во

время компиляции вычисляется именно тогда


Тогда я вообще не знаю примера eDSL для Common Lisp. Наверное на Common Lisp не пишут eDSL.

archimag ★★★ ()
Ответ на: комментарий от archimag

> Я использую cl-pdf на стороне веб-сервера во время обработки запросов. Никаких проблем с параллельным исполнением. Кажется ты не понял, что такое динамические переменные ;)

твой веб-сервер работает на нитях или форкается?

и да, я не знаю, может в CL придумали thread-local по умолчанию для лексических переменных

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> твой веб-сервер работает на нитях

на нитях.

и да, я не знаю, может в CL придумали thread-local по умолчанию

для лексических переменных



В CL придумали динамические переменные.

archimag ★★★ ()
Ответ на: комментарий от archimag

я уж заговариваться стал, для динамических конечно

так вот я не знаю, как динамические переменные взаимодействуют с нитями; с замыканиями они взаимодействуют хреново, а вот для нитей язык может и костыль подставить

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от archimag

> Хм, а ODT это тоже DSL??

ты путаешь теплое с мягким, ODT — формат хранения данных, для HTML формат данных — plain text.

korvin_ ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> с замыканиями они взаимодействуют хреново

в чем проявляется хреновость?

korvin_ ★★★★★ ()
Ответ на: комментарий от korvin_

Почувствуй разницу между лексичекскими (AKA полными) и динамическими замыканиями.

naryl ★★★★★ ()
Ответ на: комментарий от korvin_

> ты путаешь теплое с мягким, ODT — формат хранения данных,

для HTML формат данных — plain text.


Пойди почитай что такое ODT

archimag ★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

archimag ★★★ ()
Ответ на: комментарий от korvin_

> в чем проявляется хреновость?

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

ну и доступ к ним думаю помедленнее, чем к локальным переменным

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от archimag

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

тогда объясни: вот порядок выполнения:

Thread 1                              Thread 2
(pdf:with-document ()
   ...                                (pdf:with-document ()
   ...                                   ...
   (pdf:write-document #P"1.pdf"))       ...
                                         (pdf:write-document #P"2.pdf"))

с динамическими переменными окажется, что нить 2 запишет файл 1.pdf, нет? если нет, то почему?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> динамические переменные хреновы не сами по себе,

а как средства передачи значения по умолчанию


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

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


Сферические замыкания в вакууме?

ну и доступ к ним думаю помедленнее, чем к локальным переменным


Конечно, но это того стоят.

archimag ★★★ ()
Ответ на: комментарий от www_linux_org_ru

> с динамическими переменными окажется, что нить 2 запишет файл 1.pdf,

нет? если нет, то почему?


Нет, конечно. Связывание динамических переменных с новыми значениями производится (обычно, и конкретно в with-document) с помощью формы let и это связывание имеет действие только для вложенного в let кода, так требует стандарт языка.

archimag ★★★ ()
Ответ на: комментарий от archimag

> Связывание динамических переменных с новыми значениями производится (обычно, и конкретно в with-document) с помощью формы let и это связывание имеет действие только для вложенного в let кода

Вопрос был в том, относится ли имя *document* к разным переменным.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

> Вопрос был в том, относится ли имя *document* к разным переменным.

Конечно.

archimag ★★★ ()
Ответ на: комментарий от naryl

> Почувствуй разницу между лексичекскими (AKA полными) и динамическими замыканиями.

при чем тут разность? кто Вам запрещает делать лексические замыкания, когда они Вам нужны и динамические когда они Вам нужны? вопрос был «в чем хреновость»? не нужно — юзай лексические

korvin_ ★★★★★ ()
Ответ на: комментарий от archimag

> Нет, конечно. Связывание динамических переменных с новыми значениями производится (обычно, и конкретно в with-document) с помощью формы let и это связывание имеет действие только для вложенного в let кода, так требует стандарт языка.

кстати, для LispWorks'ного CAPI это не работает. это как-то связано с CFFI?

korvin_ ★★★★★ ()
Ответ на: комментарий от archimag

> Сферические замыкания в вакууме?

вполне практические сценарии развития проекта и практические задачи, одну я уже кратко описал

да и вообще все ООП возникло в значительной степени как способ лексически передавать неявные параметры — значит задач хватает

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> да и вообще все ООП возникло в значительной степени как способ

лексически передавать неявные параметры


В Simula то? Опять что-то курим? ;) Вообще знакомая песня, чую хаскелиста :)) Смысл ООП в определённом подходе к декомпозиции задачи, а не «способе лексически передавать неявные параметры», тем более, что такое вряд ли можно сказать о реализации ООП в Common Lisp.

archimag ★★★ ()
Ответ на: комментарий от korvin_

> кстати, для LispWorks'ного CAPI это не работает. это как-то

связано с CFFI?


Без понятия о чём ты, у меня нет LispWorks (я запустил его один раз, ужаснулся и больше делать этого не стал) и я не работал с CAPI.

archimag ★★★ ()
Ответ на: комментарий от archimag

>> Вопрос был в том, относится ли имя *document* к разным переменным.

Конечно.

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от archimag

> Вообще знакомая песня, чую хаскелиста :))

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> а что делать, если нам нужны неявные аргументы, читаемые и

записываемые двумя разными нитями?


Не пойму, ты про использование глобальных переменных? Тогда нам нужны мьютексы и т.п. Или про что? В Hunchentoot для каждого запроса создаются объекты request и reply, которые связываются с динамическими переменными *request* и *reply*, какие-либо конфликты исключены, каждый потоки спокойно работают каждый со своей версией привязки.

Короче, приведи какой-нибудь реалистичный пример, а то я не понимаю.

archimag ★★★ ()
Ответ на: комментарий от archimag

> Если говорить правильно, то язык разметки, на который есть спецификация.
это был наводящий вопрос

Да при чём тут mainstream? Я имел в виду конкретно это решение: http://codespeak.net/lxml/tutorial.html#the-e-factory


я же написал про библиотеку из pcl, даже там в последнем варианте есть compile-time оптимизация статических строк, и где это в lxml ? или макро-систему лиспа можно применять поверх той html библиотеки.
про mainstream я написал потому что даже не смотря на эту разницу lxml все равно полезен в определенных задачах. И твой вопрос в лоб что лучше - не состоятелен, если ты опять не понял

Гы ))) Ты вообще когда-нибудь читал спецификацию на PDF? а на PostScript? А с cl-pdf много работал? Подозреваю элементарную инженерную неграмотность.


жену свою подозревай :) есть что сказать - говори, изображать тут не надо, еще и по Мартину поясни за одно

Это специализированные языки программирования.

а на iterate совсем нельзя программировать в рамках ее предметной области ?

Не знаю, я хочу увидеть пример хорошего eDSL, но мне его не показывают :(

eDSL-и в этом не виноваты :) если такие проблемы возьми тоже же XLST и переложи синтаксис на лисп максимально близко, только потом не говори что это просто набор макр. :) затем задай вопрос чем это принципиально отличается от iterate

ed ★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

(defvar *default-foo* 123) ; так переменная глобальна для всех нитей, доступ через mutex

(defun func-foo (&optional (foo *default-foo*)) ; dynamic -> lexical local
#'(lambda () (print foo)))

; в Thread X

(funcall (func-foo)) ; 123


(let ((*default-foo* 321)) ; теперь и внутри *default-foo* другая динамическая переменная = 321, только для thread X
(funcall (func-foo)) ; 321
)

(funcall (let ((*default-foo* 321)) (func-foo))) ; 321

ed ★★ ()
Ответ на: комментарий от ed

в случае если действительно нужен конкурентный доступ из разных тредов, тогда в func-foo береш значение с with-lock-held

ed ★★ ()
Ответ на: комментарий от korvin_

> кстати, для LispWorks'ного CAPI это не работает. это как-то связано с CFFI?
код покажи

ed ★★ ()
Ответ на: комментарий от anonymous

> Ну разве не идиот? Идиот, причем клинический. Такой бред человек с мозгом писать не стал бы.

Дети бушуют. Весна.

yk4ever ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.