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 ()

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

> Все остальное, что в язык было внесено для облегчения реализации LINQ, к самому LINQ не относится.

Пойдите на сайт микрософта и почитайте поподробнее. Это всё части проекта LINQ.

Ты дебил и быдло.

Ох уж эта анонимная школота, так возбуждается из-за несущественных вопросов.

Пойди к мамке, пусть она тебе рот с мылом вымоет. Мал ещё взрослым дядям хамить.

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

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

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

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

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

на яве все переменные, которые надо передать неявно, лежат в классе

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

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

при этом оба запуска должны иметь общие данные на чтение-запись (map с оценками позиций)

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

2. если запуск не реализовывать в виде нити? в яве придется переписывать самую малость, а сколько придется переписывать в лиспе? (да-да, неожиданно вспоминается та самая симула)

_____________________

З.Ы. передача неявных аргументов через динамические переменные — это еще худший атавизм, чем бесстековые процедуры фортрана

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

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

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



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


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

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

являются динамическими


Зачем так делать?

при этом оба запуска должны иметь общие данные на чтение-запись


Вряд ли, при решении подобных задач обычно лучше придерживаться чистого функционального стиля.

в яве придется переписывать самую малость,

а сколько придется переписывать в лиспе?



Сколько?

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

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

где неявная передача аргументов в виде this не удобна, а удобны

именно динамические переменные



Ты продолжаешь что-то сильно путать. Возможности ООП в Common Lisp превосходят аналогичные возможности Java. Классы/объекты и динамические переменные используются для решения различных задач. Как их можно сравнивать? И главное зачем?

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

> Вряд ли, при решении подобных задач обычно лучше придерживаться чистого функционального стиля.

что ж, придется повторить сценарий по шагам:

- в начале развития проекта мы не рассчитывали, что наш код будет работать параллельно и юзали with-foobarbaz (в точности как автор cl-pdf)

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

- проект на быдлояве оказался готов к такому повороту событий (из-за классов)

- а проект на лиспе со своими with-foobarbaz устанавливающими *foobarbaz* ?

________________________________

вообще-то мне уже надоело критиковать лисп... я надеюсь что в ответ мне дадут пример «что неудобно сделать через this, но удобно через *foobarbaz*»

ну и еще интересно, как дин. переменные работают с рестартами (но я торможу придумать какой-нить пример)

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

> а проект на лиспе со своими with-foobarbaz

устанавливающими *foobarbaz*?


А какие с ним проблемы? Ты понимаешь разницу между динамическими и глобальными переменными?

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


Я привёл ссылку, где я не стал делать «через this»

как дин. переменные работают с рестартами


А какие могу быть проблемы?

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

> Возможности ООП в Common Lisp превосходят аналогичные возможности Java.

но при этом для неявной передачи аргументов почему-то используются дин. переменные, а нее CLOS ?

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

> Я привёл ссылку, где я не стал делать «через this»

почитаю

А какие могу быть проблемы?

сорри я торможу щас...

например у нас есть дин. переменная А

в функции В мы сделали новое связываение для А, а затем вызвали функцию С

в С мы тоже сделали новое связываение для А, затем через рестарт попапли снова в стэковый фрейм В

1. какое связывание для А мы увидим?

2. что будет, если мы во фрейме В еще раз сделаем новое связываение для А?

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

> но при этом для неявной передачи аргументов почему-то используются

дин. переменные, а нее CLOS ?


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

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

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

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

Простая вещь: связывание действует только внутри блока let и никак иначе, это гарантируется стандартом и реализацией. Связывание не изменяет старое значение, а только создаёт новое связывание.

в С мы тоже сделали новое связываение для А,

затем через рестарт попапли снова в стэковый фрейм В



И? Ты же не беспокоишься за судьбу лексических переменных и вообще за судьбу стэка? Реализация обеспечивает правильную обработку что бы не произошло.

что будет, если мы во фрейме В еще раз сделаем новое

связываение для А?



Будет новое связывание.

Динамические переменные работают абсолютно чётко и никаких проблем с ними нет.

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

Ты спрашиваешь как это реализовано в машинных кодах или что? При выходе за пределы let восстанавливается предыдущие связывание. let не изменяет глобальное состояние системы.

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

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

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

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

> но вполне возможно, я не знаю подходящих юз кейсов,

почему и спрашиваю


Раньше разработчики любили глобальные переменные (да C-кодеры их и сейчас любят), они очень удобны и просты, но у них масса недостатков. Динамические переменные - это такая улучшенная версия глобальных переменных: взяли все плюсы, и выкинули минусы.

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

> Ты спрашиваешь как это реализовано в машинных кодах или что?

я спрашиваю как это реализовано в терминах стэка, про который ты писал на http://lisper.ru/articles/cl-vars

Каждая форма let (и эквивалентные ей), в которой указана динамическая переменная, в начале помещает на стек новое связывание и удаляет его в конце выполнения.

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

видимо все же код придется написать, завтра или послезавтра, а не словами спрашивать

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

> я спрашиваю как это реализовано в терминах стэка,

про который ты писал на http://lisper.ru/articles/cl-vars


Это не я писал, на lisper.ru нет моих статей ;) (кстати, сервер сейчас лежит - это нормально, я его обновляю)

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

> http://paste.lisp.org/display/98435
там все нормально работает, если учесть что callback дергается после выхода из dynamic scope let-a, вот и получается что *foo* уже в глобальном

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

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

тока какой стратегический смысл этих каверзных вопросов ? потому что:
- в лиспе все хорошо, поверь мне на слово, точнее есть некоторые вещи но на прямую к языку они не относятся
- в лиспе как правило есть несколько путей сделать что то
- делать упор на ООП подход vs лисп самоубийство
- лисп программируемый язык программирования и его можно менять под свои нужды и твои придирки

и что то мы забыли про решение на scala ?

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

> там все нормально работает, если учесть что callback дергается после выхода из dynamic scope let-a, вот и получается что *foo* уже в глобальном

а, т.е. динамическая привязка не сохраняется?

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

> в лиспе все хорошо, поверь мне на слово, точнее есть некоторые вещи но на прямую к языку они не относятся

верю на слово, что все хорошо, пока едешь по прямой асфальтовой дороге :-) а вот вопросы типа «если я крутану руль на высокой скорости с целью кувыркнуть машину и снова стать на колеса, выдержит ли она?» надо выяснять

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

> делать упор на ООП подход vs лисп самоубийство

1. мы рассматриваем не ООП в целом, а всего лишь передачу неявных аргументов через синтаксис ООП

2. и самое главное — расскажи, как оно, самоубийство, получается-то?

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

жду :-)

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

Если ты используешь объекты для передачи «неявных» параметров, рекомендую почитать Thinking In Java и осилить в конце концов ООП.

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

ты прямо скажи, чем это по-твоему плохо либо хуже дин. переменных

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

и вообще-то речь шла об использовании не объектов, а синтаксиса ООП (хотя может и объекты тоже можно)

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

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

а поможет ли это поменять под мои нужды *уже готовые* библиотеки, типа cl-pdf, *без* их переписывания?

www_linux_org_ru ★★★★★ ()

эта нить попала в топ10 на первую страницу, так что думаю дискуссия пойдет живее

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

> а поможет ли это поменять под мои нужды *уже готовые* библиотеки,

типа cl-pdf, *без* их переписывания?


Что значит «поменять под мои нужды»? Если ты опять про использование *динамических* переменных, то это не надо, ибо не создаёт абсолютно никаких проблем.

Кстати, макрос pdf:with-document создаёт новое связывание переменной pdf:*document* с новым объектом класса pdf::document (вот сюрприз то!), так что, ни о каком противопоставлении *динамические переменные* vs ООП в контексте cl-pdf речи не идёт, ибо используются оба подхода.

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

> синтаксиса ООП

можно небольшой пример кода? а то никак не пойму, как связано ООП (тем более «ООП-синтаксис») и неявные параметры

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

> верю на слово, что все хорошо, пока едешь по прямой асфальтовой дороге :-) а вот вопросы типа «если я крутану руль на высокой скорости с целью кувыркнуть машину и снова стать на колеса, выдержит ли она?» надо выяснять

думаеш лисп вчера придумали и ты первый сел за руль ?)

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

> расскажи, как оно, самоубийство, получается-то?
потому что что все ООП в mainstream, и не только, языках и рядом не лежало с CLOS+MOP, а это всего лишь часть лиспа

а лисперы со своими дин. переменными на белом коне

лисперы уже на коне, у них есть свобода выбора

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

> а поможет ли это поменять под мои нужды *уже готовые* библиотеки, типа cl-pdf, *без* их переписывания?

напиши свои макры defun и пр., в них сделай нужные тебе преобразования body

(setf (macro-function 'defun-orig) (macro-function 'defun))

(defmacro defun (name lambda-list &body body)
`(defun-orig ,name ,lambda-list (format t «enter: ~a~%» ',name) ,@body))


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

> Особенно если это Mono.

Вот с моно у немерле всё странно, разработчики про него не знают: http://code.google.com/p/nemerle/downloads/list

Ну то есть к примеру в дебиан компилятор есть в репах, но вот уже xbuild не билдил nemerle.

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