Лисперы, а верно ли высказывание, что в sbcl все dynamic-биндинги — thread-local?
А, совсем забыл сказать, относительно свежий (1.0.57.0-2, из sid'а) sbcl собран под squeeze. Чуть-чуть позже, надеюсь, руки дойдут и до действительно свежего (1.1.2), но пока — упс.
Брать как обычно в packages.gnolltech.org.
Брать как обычно в packages.gnolltech.org.
Решение проблемы с развертыванием образов, содержащих clsql: ситуация, когда clsql'ные foreign-библиотеки на целевой системе лежат в другом месте. Может кому пригодится: gist.github.com
Вышел SBCL 1.1.0 — sbcl.org
Чота кажись в usocket под win32 херня при отсутствующем таймауте в wait-for-input:
paste.lisp.org
хз, правильно пофиксил или нет, но УМВР.
paste.lisp.org
хз, правильно пофиксил или нет, но УМВР.
Скрипт для сборки SBCL(из сорцов sbcl-win32-threads) под MinGW+MSYS
love5an.livejournal.com
love5an.livejournal.com
Good news, everyone!
Оказывается, с версии 1.0.52 save-lisp-and-die поддерживает компрессию образа через zlib.
Оказывается, с версии 1.0.52 save-lisp-and-die поддерживает компрессию образа через zlib.
Как заставить emacs работать и с clojure, и sbcl
1. установить slime and slime-repl from elpa
— устанавливает версию 20100404.1, но только кусочков slime, необходимых для работы с clojure. Т.е. не устанавливает *.lisp файлы
2. Установить соотв. копию slime:
— cd ~/src/elisp
— cvs -d :pserver:anonymous:anonymous@common-lisp.net:/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
1. установить slime and slime-repl from elpa
— устанавливает версию 20100404.1, но только кусочков slime, необходимых для работы с clojure. Т.е. не устанавливает *.lisp файлы
2. Установить соотв. копию slime:
— cd ~/src/elisp
— cvs -d :pserver:anonymous:anonymous@common-lisp.net:/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
Обсуждение проблемы — 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
Опа, уже 1.0.47 вышел.
Антон Коваленко анонсировал, что он завёл sbcl на x86-64 архитектуре. Собственно линк: siftsoft.com
Его порт явно не может работать (как минимум из-за того что в src/runtime/x86-64-assem.S не исправлено соглашение о передаче параметров, которое на win64 отличается от всех остальных x86_64 систем) и у меня не работает. Жуйкоюзер, если у тебя шестидесятичетырёхбитные окошки — можешь попробовать запустить? Если я правильно понимаю код и это не мои локальные проблемы, а он действительно не работает, то надо будет идти в рассылку со своим вариантом порта (где на данный момент GC ещё не хочет работать, но вся остальная инициализация из src/code/cold-init.lisp проходит).
Его порт явно не может работать (как минимум из-за того что в 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, то забить на доведение кода до рабочего состояния.
Пока получается что-то вроде pastebin.com
Наверное стоить оформить окончательно удаление long из кода и, если такие изменения не придутся по нраву разработчикам sbcl, то забить на доведение кода до рабочего состояния.
Для портирования SBCL на 64-битную Windows необходимо решить три проблемы:
1. Замена SEH на VEH, для обработки ошибок. Тут можно оставить заглушку до тех пор, пока не соберется относительно рабочий SBCL.
2. Изменить схемы именования системных функций. Так функции, которые в 32-битной системе (кстати, это особенность Windows или MinGW?) соответствуют символам "_Name@number", а в 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. Замена SEH на VEH, для обработки ошибок. Тут можно оставить заглушку до тех пор, пока не соберется относительно рабочий SBCL.
2. Изменить схемы именования системных функций. Так функции, которые в 32-битной системе (кстати, это особенность Windows или MinGW?) соответствуют символам "_Name@number", а в 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 файл. Так что, судя по всему, до сих пор в коде есть места, в которых размеры переменных не сходятся.
#ifdef LISP_FEATURE_WIN32
/ touch every single page in the space to force it to be mapped. /
for (count = 0; count < bytes; count += 0x1000) {
volatile int temp = addr[count];
}
#endif
/ touch every single page in the space to force it to be mapped. /
for (count = 0; count < bytes; count += 0x1000) {
volatile int temp = addr[count];
}
#endif
"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 "
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 "
Доступна pre-alpha SBCL с поддержкой threads под win32. Лисперы, айда тестировать!
dmitry-vk.livejournal.com
dmitry-vk.livejournal.com
Жуйк, при выполнении кода в репле компилируется ли код и вставляеться ли он в существующий образ? Я думаю что он комплируеться, но не добавлятся к текущему образу, разве что это не дефинишон чего-либо.