Clozure CL 1.5 + slime

А какие плюшки в использовании CCL под win32? Почему не SBCL?

В SBCL нет нативных трэдов под винду.

>В SBCL нет нативных трэдов под винду.

поправка: уже есть, но пока в альфе.

А покажи конфигурацию? Отвалы (не с CCL, однако) наблюдались из-за неправильно выставленной переменной slime-net-coding-system в моменты, когда inferior lisp пытался что-то сказать по-русски. И еще в этом же направлении посмотри ключик -K у CCL.

Больше предположений нет, так как ни CCL (пока что), ни Windows (надеюсь, что никогда больше) не пользуюсь.

>В SBCL нет нативных трэдов под винду.

Треды уже есть, но в неофициальном репозитории и требуют некоторого допиливания, но они есть.

</offtopic>

Что-нибудь пишется в буфер *inferior-lisp*?

А покажи конфигурацию?

Конфигурация самая элементарная

(set-language-environment "utf-8")

;; Set up SLIME and CCL
(add-to-list 'load-path "C:/Lisp/slime-2010-06-15/")
(setq inferior-lisp-program "C:/Lisp/ccl-1.5/wx86cl.exe -K utf-8")
(require 'slime)
(setq slime-net-coding-system 'utf-8-unix)
(slime-setup '(slime-fancy))

;; Turn on autoindent when pressing Return
(add-hook 'lisp-mode-hook 
	  '(lambda ()
	     (local-set-key (kbd "RET") 'newline-and-indent)))

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

У меня 1.5 вообще паршивенько работает под виндой, так и сижу на 1.4. Вышеописанная проблема тоже имеет место быть

Что-нибудь пишется в буфер *inferior-lisp*?

Нет, ничего.

Вот например, начал ради эксперимента набивать вот это

(defun fib (x)
  (when (< x 10)
    (do ((cur 0 next)
	 (next 1 (+ cur next)))
	((< cur 10) (format

Отвалилось на последнем format-е после нажатия пробела (код привел до момента сбоя), когда должен был появится хинт о сигнатуре функции format. После этого Slime REPL не откликается. Т.е. ввожу (format t «xxx») а в ответ тишин.

>> Треды уже есть, но в неофициальном репозитории и требуют некоторого допиливания, но они есть.

Это радует. Одной проблемой (тестирование кода в двух имплементациях уже задолбало) стало меньше.

>Конфигурация самая элементарная

Тогда проблема в CCL, похоже.

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

CLISP, например, все системные сообщения по-русски пишет: сообщения компилятора и пр. Как только приходил ответ по-русски от CLISP, то сразу же обрыв сессии происходил, если не установить coding-system в конфиге. Вот я и предположил, что, может быть, где-то с кодировкой не то. Например, в момент возврата шаблона функции. Можно погрузиться в код slime и глянуть, что он вызывает в CCL, что CCL возвращает и правильно ли все интерпретируется в slime.

Не, CCL по-русски нм чего не пишет.

>Не, CCL по-русски нм чего не пишет.

Да необязательно по-русски. Вполне может из-за ошибки в CCL, например, какой-то неинтерпретируемый символ проскочить в «странной» кодировке, а SLIME, испугавшись, рубит соединение.

Тогда можно попробовать запустить ccl отдельно, и уже в нем запустить swank.

Т.е.:

ccl -K utf-8

(load «/path/to/swank-loader.lisp»)

(swank-loader:init)

(swank:start-server «swank-port.txt» :coding-system «utf-8-unix»)

И затем в emacs'е: M-x slime-connect

И что это даст?

У dmitry_vk есть:

http://sites.google.com/site/dmitryvksite/sbcl-distr

Так что есть смысл переводить всё на SBCL, т.к. преимущества CCL теперь вовсе не ясны. Заодно, в процессе тестинга, можно проверить новые потоки.

>И что это даст?

Это даст то, что будет виден весь вывод CCL, в том числе и вывод, который может не нравится емаксу и, например, не показываться в *inferior-lisp*. И будет ясно, кто упал - slime, swank или ccl.

>> Это даст то, что будет виден весь вывод CCL

Сидел целый час набивал код в надежде получить ошибку - хрен, как назло ни разу не отвалилось.

>У dmitry_vk есть

он и сам здесь есть =)

Так что есть смысл переводить всё на SBCL

там такая «преальфа», что твои слова звучат по меньшей мере провокацией ;)

sbcl-devel тебе в очи :)

он и сам здесь есть =)

Но особо не пиарит :) Поэтому я подумал... Чтобы человек не искал.

там такая «преальфа», что твои слова звучат по меньшей мере провокацией ;)

Но эта «преальфа» вполне работоспособная, я например использую именно её под виндой (есть необходимость использовать hunchentoot).

sbcl-devel тебе в очи :)

А что там в sbcl-devel?

Утверждение, CCL не нужно ибо есть SBCL, как-то особо не впечатляет. Конкуренция ещё никому не мешала.

>Но особо не пиарит :)

И правильно делает, ибо рано. За что ему второе огромное спасибо (первое - за саму реализацию =)

Но эта «преальфа» вполне работоспособная

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

я например использую именно её под виндой

я рад, что у вас всё работает. Но так и надо было говорить - hunchentoot работает. Мало ли кто что использует.

А что там в sbcl-devel?

http://sourceforge.net/mailarchive/message.php?msg_name=loom.20100616T210543-...

У этих двух проектов похожая история и общая ниша (оптимизирующий компилятор CL на CL). Я не говорил что «не нужно», я сказал что именно мне не ясны преимущества (может они есть?), а поэтому я не вижу что может делать CCL конкурентом SBCL.

Вот в отношении CLisp всё понятно (просто интерпретатор), с GCL - понятно (встаимовость), или вот ABCL (CL для Java).

Сори за offtopic.

>Утверждение, CCL не нужно ибо есть SBCL, как-то особо не впечатляет. Конкуренция ещё никому не мешала.

у прочих CL-ей есть хоть какая-то «специализация»: clisp - «мелко-скриптовый», ecl - «встраиваемый транслятор в си» и т.п. На одном и то-же «поле» sbcl таки «изживает» конкурентов (можно посмотреть на состояние cmucl-а).

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

Но так и надо было говорить - hunchentoot

Неправильно выразился, надо было кричать что slime, bt и hunchentoot работают :)

>slime, bt и hunchentoot работают :)

Ну slime-то под sbcl с тредами под винду не очень работает - попробуйте хотя бы включить *communication-style* :spawn. Чтобы заработало, надо исправлять работу с сокетами (под виндой сокеты реализованы далеко не полностью). И ханчентут работает лишь потому что использует примитивный способ диспетчеризации запросов.

Утверждение, CCL не нужно ибо есть SBCL, как-то особо не впечатляет. Конкуренция ещё никому не мешала.

Согласен с этим. Так же, как и с тем, что SBCL - это основная реализация лиспа на сегодняшний день.

Но особо не пиарит

Эх, было бы чего пиарить :) Нити пока работают довольно медленно и не очень стабильно.

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

А мне чем-то CCL нравится. Он довольно хороший, но при этом, вроде, устроен проще, чем SBCL. Кстати, а что за козыри CCL? Я с ccl слабо знаком, поэтому интересно.

>А мне чем-то CCL нравится. Он довольно хороший, но при этом, вроде, устроен проще, чем SBCL.

есть подозрение, что простота в первую очередь - за счёт компилятора. т.е. надо-бы полноценно погонять оба, дабы понять - есть ли таки преимущества у sbcl и на сколько они велики =) Вроде где-то когда-то были какие-то таблички со сравнением CL-ей (скорости выполняемого кода), и в сумме у sbcl из свободных не было конкурентов. Но да - местами в sbcl нагромождение кода такое, что не хочется даже и задумываться - зачем сделали именно так...

Кстати, а что за козыри CCL? Я с ccl слабо знаком, поэтому интересно.

ну те-же треды под винду, причём родные, на сколько я понимаю, а не через pthreads, плюс, опять-же если не ошибаюсь, работа с файлами/потоками/прочим (open и компания) родная, а не через posix-совместимые обёртки. Больше - хз, не ковырял глубоко, ибо последний не запустить на домашнем стареньком атлоне :)

>причём родные, на сколько я понимаю, а не через pthreads

Что значит «родные, а не через pthreads»? pthreads - это просто API для нитей.

Это все - не козыри, а детали реализации, которые, в общем-то, не существенны.

>Что значит «родные, а не через pthreads»? pthreads - это просто API для нитей.

я про pthreads-win32: dll-ка с этим «простым апи» весит от 60-100 kB и таки что-то делает (ужа из ежа)

Это все - не козыри, а детали реализации, которые, в общем-то, не существенны.

кому как: использование под офтопиком posix-функций существенно сокращает доступный системный функционал. В частности: использование процессов и манипуляция их потоками I/O

но если это не «козыри», то тогда я их вообще не знаю :)

>я про pthreads-win32: dll-ка с этим «простым апи» весит от 60-100 kB и таки что-то делает (ужа из ежа)

Там содержится реализация примитивов синхронизации и вызовов pthreads. Ничего «ненативного» из нитей pthreads-win32 не делает. Кстати, sbcl не использует pthreads-win32.

кому как: использование под офтопиком posix-функций существенно сокращает доступный системный функционал. В частности: использование процессов и манипуляция их потоками I/O

Каким образом? posix-функции - это просто обертки вокруг win32 i/o.

s/posix-функции/posix-функции под виндой/

>Там содержится реализация примитивов синхронизации и вызовов pthreads. Ничего «ненативного» из нитей pthreads-win32 не делает.

мы скатимся к терминологическому спору. я подозреваю, с pthreads-нитью вы не сможете обращаться как с «нативной» win32-нитью (т.е. минус win-32 функционал), равно как не всё из pthreads реализовано в pthreads-win32. Да, я согласен, pthreads-win32 «работает» поверх нативных нитей офтопика. Сам он от этого «нативным» не становится. Ок?

Кстати, sbcl не использует pthreads-win32.

я рад за вас :) ecl (кажется) использовал.

Каким образом? posix-функции - это просто обертки вокруг win32 i/o.

и вы можете «прозрачно» превращать posix-потоки ввода/вывода (особенно стандартные) в win32-хандлеры и обратно? А весь виндовый функционал требует именно последние. Не будете же вы утверждать, что win-posix покрывает нативный win-api чуть более чем полностью? =)

>равно как не всё из pthreads реализовано в pthreads-win32

Да, в винде нет сигналов.

Сам он от этого «нативным» не становится. Ок?

Нативная нить - это нить, которая управляется ОС. Ненативная нить - это зеленая нить. Нить, которая создана pthreads-win32 - нативная.

и вы можете «прозрачно» превращать posix-потоки ввода/вывода (особенно стандартные) в win32-хандлеры и обратно?

Да. _open_osfhandle и _get_osfhandle

Не будете же вы утверждать, что win-posix покрывает нативный win-api чуть более чем полностью?

posix полностью не покрывает API ни одной ОС. Тем не менее, называть позикс «ненативным» - что незнакомое мне.

>Нативная нить - это нить, которая управляется ОС.

Нить, которая создана pthreads-win32 - нативная.

и вы можете передать её _любой_ функции, которая ждёт win32-нить? Не ломая при этом ничего в pthreads-win32? (в пределе - остановить нить)

Да. _open_osfhandle и _get_osfhandle

оопс, посыпаю голову пеплом :)

>и вы можете передать её _любой_ функции, которая ждёт win32-нить?

Непосредственно pthread_t обычно вряд ли получится передать, но передать соответствующий хэндл вполне можно.

Не ломая при этом ничего в pthreads-win32?

А вы можете передать хэндл нити в _любую_ функцию и ожидать, что все будет хорошо работать? Нет же, все очень хрупко. Остановка нити запросто порушит userspace-часть winapi. Конкретно pthreads-win32 не делает ничего хитрого с нитью - аналогичные вещи делает и msvcrt. Так что от реализации pthreads API ничего не меняется здесь.

А вообще, для винды win32-нить - это тоже не нативная нить (пользуяюсь таким вольным трактованием нативности).

А для линукса что является нативной нитью?

И ханчентут работает лишь потому что использует примитивный способ диспетчеризации запросов.

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

Теперь же он запускается и не отбирает поток - его (ацептор в потоке) можно настраивать (из потока slime например) во время выполнения, и он создаёт треды обработки запросов. Хорошо же!

Archimag писал, что лиспер.ру на CCL в 8 раз медленнее чем на SBCL.

Ещё, субъективно: исходники SBCL «доставляют», CCL - нет.

Проблема скорее всего в этом http://trac.clozure.com/ccl/ticket/677, http://trac.clozure.com/ccl/ticket/696. Тоже столкнулся с похожей проблемой, после пары дней копания во внутренностях CCL возможно решил проблему(у меня slime теперь нормально работает), попробуй этот патч:

--- thread_manager.c (revision 13781)
+++ thread_manager.c (working copy)
@@ -2020,7 +2020,9 @@
!((where < (pc) 0x16000) &&
(where >= (pc) 0x15000)) &&
!((where < (pc) (ts->high)) &&
- (where >= (pc) (ts->low)))) {
+ (where >= (pc) (ts->low))) &&
+ !((where < (pc) readonly_area->high) &&
+ (where >= (pc) readonly_area->low))) {
/* The thread has lisp valence, but is not executing code
where we expect lisp code to be and is not exiting from
an exception handler. That pretty much means that it's