love5an: (Default)
Над портом SBCL на win32 сейчас работает Антон Коваленко ( [livejournal.com profile] akovalenko ).

Вот здесь можно посмотреть подробности, узнать текущий статус форка, и, естественно, скачать новые версии, в т.ч. в виде msi-инсталлятора: http://www.siftsoft.com/inprogress/forknews.html

Обсуждение тут: http://akovalenko.livejournal.com/35889.html

Я настоятельно рекомендую использовать именно эту версию SBCL при работе под Windows - там добалена многопоточность(спасибо [livejournal.com profile] dmitry_vk), добавлена поддержка stdcall-коллбэков, коллбэков в сторонние треды(грубо говоря, можно, например, лисповые коллбэки поставлять в CreateThread), пофиксены многие баги в подсистеме ввода/вывода, и так далее - ну по первой ссылке можно посмотреть подробности.

Для работы stdcall-коллбэков в CFFI необходимо применить мой патч, вот он:
http://cloud.github.com/downloads/Lovesan/virgil/cffi-sbcl-stdcall.patch
love5an: (R)
Я тут снова взялся за SLXI.

И первое, что сделал - выкинул C#. Теперь кросс-интерпретатор будет написан на Common Lisp.

https://github.com/Lovesan/SLXI

Собственно, на данный момент готов только парсер, и некоторые функции для работы с данными SL, в частности - со списками и символами.

Парсер в кросс-интерпретаторе я сделал не расширяемый, обычный, потому что мне лень, и потому что использовать расширяемый синтаксис в будущем компиляторе я не планирую. Несмотря на это, сам будущий компилятор конечно будет поддерживать расширяемый синтаксис.

Еще, парсер не поддерживает комплексные числа(в SL будет синтаксис комплексных чисел как в Scheme) и read-eval, это потому что мне лень, да и автомат для лексера и так уже очень жирный.

Скоро начну работу над компилятором в байт-код.

Lisp FTW!
love5an: (R)
Собственно, наконец-то у меня дотянулись руки начать писать транслятор лисп-объектов в AST в SLXI.

Для тех кто всё пропустил - SLXI это кросс-интерпретатор моего лиспа, похожего на CL, написанный на C#


Ну так вот, какие TODO:

В SLXI(а конкретно, в классе LispObject) в первую очередь не хватает представлений для функций и для объектов ОО-системы.

Функций пока нет потому, что пока не определился, как они будут представляться, а именно - каким-либо байткодом, либо AST. Скорее всего AST, т.к. у SLXI задача состоит исключительно в том, чтобы забутстраппить будущий компилятор, написанный на самом лиспе, и мне дико лень тратить на сам кросс-интерпретатор излишне много усилий.

ОО-система же, естественно, будет похожа на CLOS, с некоторыми изменениями. В частности все объекты будут т.н. funcallable.
Кстати, в коде на гитхабе можно заметить, что такие вещи, как представление лексического окружения в трансляторе, представление переменных и деклараций, являются internal-объектами, грубо говоря C#-выми штуками. На самом деле, это временная мера; с введением ОО-системы они станут полноценными объектами, которые дадут пользователю лисп-системы возможность достаточно тонко управлять компиляцией на этапе раскрытия макросов.

Еще, как заметно, нету пока что и намека на парсер, т.е. reader. Нету потому, что он будет частью стандартной библиотеки. Считыватель будет очень расширяемым, настраиваемым, и вообще достаточно интересным. Про него подробнее тут: http://love5an.livejournal.com/377367.html

А вообще, есть много things to discuss об этом моем лиспе с представителями лисп-сообщества и интересующимися. В частности, надо будет продумать ОО-систему до конца, надо будет основательно поработать над стандартной библиотекой, ну и вот еще интересный вопрос про модульность - у меня вот уже давно висит идея сделать нормальную модульность лиспу, с блэкджеком и куртизанками, т.е. например наподобие как в .NET - со сборками(assembly), модулями и чем-то типа GAC. Еще интересный вопрос - IO-подсистема в стандартной библиотеке: сейчас мода на асинхронность(я вообще дико влюблен в async await в C#), и надо бы это как-нибудь красиво прикрутить. Вобщем, на одной из встреч надо будет эту тему поднять(ну и в интернете конечно буду писать про это всё).
love5an: (R)
Народ!
Питер!
Сегодня как обычно - субботняя встреча на тему метапрограммирования, функционального программирования, лиспов, и не только.

Место - Молли Шелтер, на Итальянской 29, как обычно.


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

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

Встречайте SLXI:

https://github.com/Lovesan/SLXI

Кросс-интерпретатор моего лиспа, написанный на Microsoft .NET. Ну, пока что не совсем написанный, но в процессе.

После того, как SLXI будет готов, я, уже на самом лиспе, напишу компилятор в native, и рантайм. Одна из первых планируемых платформ - Windows(NT 6 и выше), x86 и x64. Но сначала надо доделать SLXI.

Среди других возможных тем - "девушки в IT" :)

Короче говоря - приглашаются все желающие, место - еще раз напомню - Питер, Итальянская 29, Молли Шелтер.
love5an: (R)
Главная проблема у first-class продолжений в том, что они устраняют понятие dynamic-extent, то есть контекста с динамическим временем жизни, а соответственно:

Во-первых, делают невозможной строгую стековую модель исполнения, а это значит, что никакие формы управления потоком вычислений основанные на оной модели(например все коммонлисповые - tagbody+go, block+return-from, throw+catch, unwind-protect) не могут быть нормально реализованы(они, во-первых, просто теряют смысл, а во-вторых их семантику становится легко, случайно и непреднамеренно даже, сломать, использовав продолжения).

Во-вторых, так как у нас теряется понятие dynamic extent, то все first-class и second-class сущности, включая теперь и собственно поток вычислений, получают unlimited extent, а значит мы теперь не можем детерминированно управлять временем жизни неуправляемых ресурсов, навроде файловых дескрипторов.

В-третьих, продолжения несут громаднейший оверхед. Мы получаем просто невероятно дикую неэффективность, как по памяти, так и по производительности, во-первых из-за того что вынуждены хранить фреймы активации в динамической памяти, и не можем использовать стек и все его плюшки(включая машинные инструкции для работы с ним и бонусы от локальности памяти), а во-вторых из-за того, что компилятору становятся практически недоступны все нелокальные оптимизации, так как у него нет гарантий относительно хода исполнения программы. Некоторые оптимизирующие компиляторы Scheme, в основном коммерческие, проводят небольшие оптимизации в этом плане, когда возможно складывая некоторые фреймы на стек например, но тем не менее, оптимизации эти возможны далеко не всегда, и они неслабо так усложняют компиляторы.
love5an: (Default)
Как наверное некоторые знают, одной из самых близкий и интересных мне тем в области программирования, и CS вообще, является синтаксический анализ.

В свободное время, как я уже писал, я занимаюсь разработкой своего языка программирования, основанном на Common Lisp, и одна из тем, которая меня очень сильно интересует это расширяемый синтаксис.
Read more... )
love5an: (Default)
Оказывается в ЖЖ время от времени проходят специальные олимпиады на тему погромирования:
http://metaclass.livejournal.com/662100.html

Там по ссылке, правда, какая-то скучная, унылая, энтерпрайз-олимпиада.

А вот я предлагаю такую:

Я тут написал игрушечную виртуальную RISC-машину с некоторой периферией.
Вернее, еще не дописал, но осталось совсем немного.

https://github.com/Lovesan/SpecialVM

Так вот, я предлагаю написать под нее рантайм и компилятор простого, игрушечного лиспа, похожего на Scheme.

Со сборщиком мусора, естественно, и всем таким прочим. Но, без арифметики с плавающей точкой, потому что в VM нет FPU :)

Короче, говоря: минимальные типы: symbol, cons, string, char, integer, ratio, vector, и, естественно, function.
Числа должны быть неограниченной точности(bignums).
Функции должны уметь замыкания. Естественно, область видимости должна быть лексической.
В стандартной библиотеке должны быть разные функции для сравнения, проверки на эквивалентность, конструирования объектов и т.п. - как в минимальной Scheme, вобщем. Естественно, должны быть define и присваивание (set!)

Минимальный синтаксис:
Read more... )

Победитель будет определяться по результатам соотношения навороченности лиспа к производительности и объему используемой памяти, и получит почет, славу и уважение, а также печеньки.

Полная спецификация машины:
Read more... )
love5an: (Default)
Использовать например так:
build-sbcl.sh --with-git=/c/Git

Работает в любой директории, но если не указаны sbcl-srcdir и win32-srcdir, то скрипту требуется Git, для скачивания последних версий исходников из соответствующих репозиториев.
Также, Git нужен для определения версии SBCL.
Git для Windows можно взять тут: http://code.google.com/p/msysgit/

Кроме того, для сборки требуются более-менее новые GCC и SBCL.

Естественно, так как скрипт работает под MSYS, ему нужна более-менее полная среда MSYS.

Для поддержки SBCL core compression(SBCL умеет сжимать образы лиспа, т.е. ".core"-файлы) также нужна zlib, установленная там, где GCC сможет ее найти, т.е. например в c:/mingw. Причем, в этом билд-скрипте используется статическая версия, т.е. gcc должен суметь найти libz.a

Для сборки .MSI-пакета также необходим Windows Installer XML

300 строчек шелла )
love5an: (Default)
Ну и небольшой драфт языка, вообще.

Репозиторий на гитхабе тут(если кто прошлый постинг еще не читал):
https://github.com/Lovesan/Microlisp

Read more... )

Microlisp

Dec. 12th, 2011 07:36 pm
love5an: (Default)
Совершенно от нефиг делать: https://github.com/Lovesan/Microlisp

Буду коммитить на гитхаб по ходу разработки, вобщем. Кому интересно написание интерпретаторов и компиляторов Common Lisp-подобных языков — фоловите.

Планы такие - дописать XI(кросс-интерпретатор, написанный на CL), потом написать компилятор на самом микролиспе, потом им скомпилировать рантайм, стандартную библиотеку и самого себя.
Ну то есть, без всяких там Си.
love5an: (Default)
Я на самом деле очень сильно удивлен тем, что очень много людей даже примерно не представляют себе, сколько оверхеда вносят счетчики ссылок, и насколько они менее эффективны, чем нормальный сборщик мусора.

Не перестают меня удивлять и заявления о том, что де, раз в C++ есть boost, с его shared_ptr и прочим, то проблема сборки мусора для C++ фактически решена.

Ладно уж, не будем о том, что счетчики ссылок неспособны разрешить циклические зависимости, просто сравним ту самую производительность, за которую писатели на C++ так трясутся.

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

Заключается он в следующем:
Создаем вектор на 'length' элементов, заполняем его указателями на структуры, подобные лисповым cons-ячейкам, и 'n' раз прогоняем цикл, в котором создаем копию этого вектора, а старый удаляем(элементы при этом мы не копируем, а копируем только указатели на них). Указатели, в C++, естественно, используем "умные".
В качестве противника C++, то есть в качестве языка, в реализациях которого присутствует нормальный GC, я взял Common Lisp, если конкретно - SBCL.

Read more... )
love5an: (Default)
SBCL 1.0.46.24 под Windows, с многопоточностью и прочими плюшками: http://rghost.ru/4689066

Собственноручно собрал под msys+mingw из сорцов [livejournal.com profile] akovalenko:
https://github.com/akovalenko/sbcl-win32-threads
love5an: (Default)
Я тут подумал - неплохо бы приделать к 32битному SBCL SSE.

Но, тут все не так просто.
Read more... )
love5an: (Default)
свежие бинарники sbcl под винду я буду выкладывать вот тут:
http://github.com/Lovesan/sbcl-win32-binaries

там две ветки; "dev" - "промежуточные" релизы

(по ходу дела разбираюсь с git и github, так что если что вдруг криво - сильно не пинать)

upd.
вот еще ссылка, на всякий случай:
http://dl.dropbox.com/u/5521262/sbcl-1.0.36-x86-windows-binary.msi

upd.
с гитхаба лучше качать через веб-интерфейс(выбирать ветку и нажимать кнопку "download source"), т.к. с ним я еще до конца не разобрался(и поэтому там могут быть глюки)
love5an: (Default)
SBCL под винду все еще довольно сырой.
Не считая того, что нет тредов, вот каковы результаты прохождения им собственных тестов:
Finished running tests.
Status:
 Failure:             interface.pure.lisp / WITH-TIMEOUT-FORMS
 Failure:             stream.pure.lisp / (STREAM LISTEN-VS-SELECT)
 Unhandled error      alien.impure.lisp
 Unhandled error      clos-interrupts.impure.lisp
 Unhandled error      deadline.impure.lisp
 Expected failure:    debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
 Failure:             debug.impure.lisp / (THROW NO-SUCH-TAG)
 Invalid exit status: exhaust.impure.lisp
 Failure:             external-format.impure.lisp / (CHARACTER-DECODE-LARGE
                                                     ATTEMPT-RESYNC)
 Unhandled error      foreign-stack-alignment.impure.lisp
 Unhandled error      load.impure.lisp
 Expected failure:    packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
 Expected failure:    packages.impure.lisp / IMPORT-SINGLE-CONFLICT
 Unhandled error      pathnames.impure.lisp
 Unhandled error      print.impure.lisp
 Failure:             run-program.impure.lisp / RUN-PROGRAM-CAT-1
 Failure:             signals.impure.lisp / (ASYNC-UNWIND SPECIALS)
 Failure:             signals.impure.lisp / (SIGNAL ERRNO)
 Unhandled error      stream.impure.lisp
 Unhandled error      swap-lispobjs.impure.lisp
 Unhandled error      threads.impure.lisp
 Failure:             timer.impure.lisp / (TIMER DEREFERRABLES-BLOCKED)
                                          ;btw, тест DEREFERRABLES-UNBLOCKED
                                          ;просто виснет, приходится его закомменчивать
 Failure:             timer.impure.lisp / (TIMER RELATIVE)
 Failure:             timer.impure.lisp / (TIMER ABSOLUTE)
 Failure:             timer.impure.lisp / (TIMER REPEAT-AND-UNSCHEDULE)
 Failure:             timer.impure.lisp / (TIMER RESCHEDULE)
 Failure:             timer.impure.lisp / (TIMER STRESS)
 Failure:             timer.impure.lisp / (WITH-TIMEOUT TIMEOUT)
 Failure:             timer.impure.lisp / (WITH-TIMEOUT NESTED-TIMEOUT-SMALLER)
 Failure:             timer.impure.lisp / (WITH-TIMEOUT NESTED-TIMEOUT-BIGGER)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RESTART-FRAME
                                                              SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RESTART-FRAME
                                                              OPTIONAL-SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RESTART-FRAME
                                                              NORMAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RETURN-FROM-FRAME
                                                              SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RETURN-FROM-FRAME
                                                              OPTIONAL-SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RETURN-FROM-FRAME
                                                              NORMAL)
 Unhandled error      unwind-to-frame-and-call.impure.lisp
test failed, expected 104 return code, got 1

Набор ошибок в тестах уже которую версию примерно одинаковый. На линуксе же, судя по всему, тесты проходятся полностью.
Ну и, плюс, испокон веков не компилируется contrib модуль sb-simple-streams.

Плюс, еще вот тут указаны противные windows-специфичные баги:
https://bugs.launchpad.net/sbcl/+bugs?field.tag=os-windows
Баг с READ-CHAR-NO-HANG, в частности, мешает корректной работе SLIME.

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

Это довольно грустно, потому что SBCL - лучший открытый компилятор CL, а Windows как платформа - занимает огромную часть рынка, игнорировать ее нельзя.
love5an: (Default)
Кстати, если кому-нибудь надо последний SBCL под win32, могу поделиться - регулярно собираю.
Сейчас вот есть 1.0.35.6, например, msi.
А то на официальном сайте там старье - 1.0.29

upd:
http://ifolder.ru/16341188

Profile

love5an: (Default)
Dmitry Ignatiev

December 2016

S M T W T F S
    123
45678910
11121314 151617
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 03:49 am
Powered by Dreamwidth Studios