to post messages and comments.

А, совсем забыл сказать, относительно свежий (1.0.57.0-2, из sid'а) sbcl собран под squeeze. Чуть-чуть позже, надеюсь, руки дойдут и до действительно свежего (1.1.2), но пока — упс.

Брать как обычно в packages.gnolltech.org.

Как заставить emacs работать и с clojure, и sbcl

1. установить slime and slime-repl from elpa
— устанавливает версию 20100404.1, но только кусочков slime, необходимых для работы с clojure. Т.е. не устанавливает *.lisp файлы

2. Установить соотв. копию slime:
— cd ~/src/elisp
— cvs -d :pserver:anonymous:[email protected]:/project/slime/cvsroot co -D 20100404 slime

3. Добавить строчку в .emacs:
(setq inferior-lisp-program "sbcl")

4. M-x slime запустит slime 20100404 с sbcl. Почему-то говорит о version mismatch, что, мол swank оказывается от 20100403. (если подтвердить, то дальше, вроде, работает)

5. открыть файл из проекта созданного lein -> M-x clojure-jack-in

Вопрос может и дурацкий, но все же: можно как-то получить список всех символов и их значения из текущего окружения? Скажем в repl было объявлено несколько функций/макросов, протестировал их, исправил какие-то ошибки, могу ли я теперь увидеть список введенных символов и их определения, чтобы отправить их в файл какой-нибудь?

После последних обновлений перестал работать sbcl и соответственно все что от него зависит (maxima, например).
Обсуждение проблемы — bbs.archlinux.org
p.s. sbcl из git кстати не собирается:
//entering make-host-1.sh
//building cross-compiler, and doing first genesis
make-host-1.sh: line 31: 8034 Segmentation fault $SBCL_XC_HOST < make-host-1.lisp

Антон Коваленко анонсировал, что он завёл sbcl на x86-64 архитектуре. Собственно линк: siftsoft.com

Его порт явно не может работать (как минимум из-за того что в src/runtime/x86-64-assem.S не исправлено соглашение о передаче параметров, которое на win64 отличается от всех остальных x86_64 систем) и у меня не работает. Жуйкоюзер, если у тебя шестидесятичетырёхбитные окошки — можешь попробовать запустить? Если я правильно понимаю код и это не мои локальные проблемы, а он действительно не работает, то надо будет идти в рассылку со своим вариантом порта (где на данный момент GC ещё не хочет работать, но вся остальная инициализация из src/code/cold-init.lisp проходит).

Кроме указанных в предыдущем сообщении проблем (вторая и третья поправлены, первая заменена заглушкой) наткнулся на то, что соглашения о вызове функций на Windows x64 отличается от всех остальных систем архитектуры x86_64. Так в юниксах для аргументов используется соответственно последовательность мест "rdi — rsi — rdx — rcx — r8 — r9 — rest on stack", а для windows x64 "rcx — rdx — r8 — r9 — rest on stack".

Пока получается что-то вроде pastebin.com

Наверное стоить оформить окончательно удаление long из кода и, если такие изменения не придутся по нраву разработчикам sbcl, то забить на доведение кода до рабочего состояния.

Для портирования SBCL на 64-битную Windows необходимо решить три проблемы:

1. Замена SEH на VEH, для обработки ошибок. Тут можно оставить заглушку до тех пор, пока не соберется относительно рабочий SBCL.
2. Изменить схемы именования системных функций. Так функции, которые в 32-битной системе (кстати, это особенность Windows или MinGW?) соответствуют символам "[email protected]", а в 64-битной "_Name" или просто "Name" (откуда возникает эта проблема? В amd64-mingw у меня под дебианом создаются символы "_Name", а с использованием drangon.org сборки — "Name")
3. Убрать из исходников надежду на то, что система поддерживает ANSI C. Или, говоря конкретнее, исправить все места, где встречается long int или unsigned long int, подставив вместо long подходящий тип, который будет иметь размер не меньше, чем long int, int и void* на всех архитектурах.

Третий пункт требует порядка 500 правок. К сожалению после того как я внёс эти правки, а также поправил правила именования и организовал заглушку на исключениях, получившийся runtime не в состоянии правильно разобрать сгенерированный в результате кросскомпиляции sbcl.core файл. Так что, судя по всему, до сих пор в коде есть места, в которых размеры переменных не сходятся.

"1.3.1 How to Report Bugs Effectively

Please include enough information in a bug report that someone reading it can reproduce the problem, i.e. don't write

Subject: apparent bug in PRINT-OBJECT (or PRINT-LENGTH?)
PRINT-OBJECT doesn't seem to work with PRINT-LENGTH. Is this a bug?

but instead

Subject: apparent bug in PRINT-OBJECT (or PRINT-LENGTH?)
In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
I compile and load the file
(DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
(LET ((PRINT-LENGTH 4))
(PRINT X Y)))))
X Y)
then at the command line type
(MAKE-FOO)
the program loops endlessly instead of printing the object.

A more in-depth discussion on reporting bugs effectively can be found at

chiark.greenend.org.uk "

Жуйк, при выполнении кода в репле компилируется ли код и вставляеться ли он в существующий образ? Я думаю что он комплируеться, но не добавлятся к текущему образу, разве что это не дефинишон чего-либо.