[doj@korica ~/dembro/trunk/release]$ ./de
Loaded default system file
! Runtime(, 0, 0): cannot open file 'docs/rus/all.utf8.de'
DEmbro v0.11 built Sat Aug 11 01:30 2012
Type "quit" to exit
dembro> ." Hello FreeBSD!!!!!!!!!!!!!!!!!1111111111111111"
Hello FreeBSD!!!!!!!!!!!!!!!!!1111111111111111 ok
dembro>
Благополучно скомпилировал и запустил DEmbro в FreeBSD. Для этого потребовалось заменить в некоторых местах IFDEF LINUX на IFDEF LINUX_or_BSD, подправить вызов парочки утилит и собрать свежий Free Pascal с свна (в пакете fpc для FreeBSD не работает модуль DynLib).
Потихоньку настраиваю себе домашний сервер, на нём будут регулярно запускаться автоматические тесты функциональности DEmbro.
августа 11, 2012
DEmbro портирован в FreeBSD
августа 10, 2012
DEmbro v0.11 -> v0.12
Планируется серьёзное переписывание ядра и системы команд DEmbro, а именно
- Расширенные возможности работы с шитым кодом: несколько отдельных буферов, возможность стирать часть кода.
- Расширенные возможности работы со словарём: возможность менять поведение словаря в некоторых случаях (например, когда происходит создание слова с именем, которое уже есть в словаре: сгенерировать исключение, создать новое, заменить старое, сделать что-то ещё), возможность удалять созданные ранее команды, поддержка механизма локальных слов.
- Упразднить универсальный стек W, который может работать с любым типом данных, до стека, умеющего работать только с ячейками. Добавить команды по работе с byte, word, dword в памяти по указателям.
- Стабилизировать систему команд для чисел с плавающей точкой.
- Вынести команды по работе со стеками R и L, унифицировать хранение traceback данных (точки возврата из команд) в R, унифицировать работу с исключениями.
- Пронести работу с исключениями в ядро, вынести возможность их обработки вне de32.dll/libde32.so, без «undefined behavior» как сейчас.
- Отщепить от «дембро-машины» так называемое «дембро-состояние», сделать возможность одной дембро-машине иметь несколько дембро-состояний. Это нужно для реализации многопоточности: сейчас все стеки и данные привязаны к глобальной дембро-машине и потому ни о какой многопоточности не может быть и речи.
- Собственно, реализовать многопоточность.
- Перевести основную часть функций по работе со строками и исходным кодом на «классические фортовские строки», т.е. на пару ячеек: размер строки и указатель на начало строки. В DEmbro сейчас основным типом строк является str — строки со счётчиком ссылок, но во многих случаях можно обойтись без них, а работают они медленно.
- Унифицировать шитый код, написать нормальную дампилку, может быть добавить новый «меташитый код». :)
- Исправить устаревшие названия на новые.
марта 27, 2012
Текущее состояние DEmbro
DEmbro сейчас не в лучшем состоянии, тем не менее разработка ведётся.
Из-за старта поддержки дембро под линуксом, появились ветвления
для каждой из платформ на разных уровнях — в исходниках, в makefile'е
и в m4 скриптах. Время от времени компиляция ломается, общая схема
стабилизации пока что не придумана.
Запланированный год назад глобальный рефакторинг, видимо,
следует считать успешным. Но я планировал сделать гораздо больше,
чем написал в том посте, и потому считаю рефакторинг провальным :)
Принял решение разделить исполняемый файл «dembro32»
на динамическую библиотеку de32.dll/libde32.so и программу-оболочку,
анализирующую командную строку и реализующую repl, который
перенаправляет запросы в библиотеку. Сразу же столкнулся с тем,
что free pascal версии 2.4 неправильно создаёт динамическую
библиотеку у меня в линуксе, подробнее история тут.
Чтож, начал переписывание исходников под свежую версию fpc.
Таким образом, ближайшие задачи: переписать код под новый паскаль,
стабилизировать компиляцию, откатить неудачные последствия глобального
рефакторинга, и после всего этого навести порядок на свне.
февраля 24, 2012
Реанимация DEmbro
DEmbro был в коме более месяца. Разработки не только не велись, но даже скомпилировать проект из транка было невозможно, т.к. makefile для сборки был в подвешенном состоянии. Вчера, наконец, я смог выделить время и реанимировал компиляцию в линуксе, а сейчас приступил к написанию универсальной сборки, чтобы и в posix-окружении, и в windows работало, причём без конфигурационных инструментов. Пришлось использовать небольшой хак. :)
У меня в голове есть несколько глобальных мыслей о DEmbro, и я решил их потихоньку оформлять в виде текстов в этом блоге. (Кстати, заметил, что то, что в моей голове выглядит мощно, в записанном виде получается чем-то незначительным или бредовым. Поэтому не претендую на то, что тут что-то умное.)
Мысли о «собери DEmbro сам»
Я понял, что не хочу иметь большую монолитную систему, какими обычно являются компиляторы/интерпретаторы. Хочу получить эдакий конструктор «собери DEmbro сам», с возможностью определять базовый набор команд в бинарнике, особенности DEmbro-машины и прочее. Польза от этого следующая:
- Лёгкость в совершении глобальных изменений.
- Возможность в случае возникновения специфической задачи быстро сделать специализированное под эту задачу ядро DEmbro
- (Следствие пункта 1.) Возможность тестирования и прикидок -- можно попробовать несколько решений и посмотреть какое из них ведёт себя лучше.
Технически гибкость достигается, понятное дело, разделением кода на части, связи между которыми минимальны. И первый шаг к этому я уже сделал: команды дембро описываются в отдельных файлах со своим форматом, из которых собираются исходные коды. Как минимум я уже получил независимость реализации дембро-машины от команд, которые доступны в языке, и как следствие возможность лёгкого отключения групп команд (например, можно скомпилировать ядро без команд для работы с плавающей точкой). В идеале у меня есть идея записывать реализации этих команды не на паскале, а на каком-то совсем своём ограниченном промежуточном языке, который легко преобразовывать в конкретный (паскаль/си/etc), тогда можно бы было реализовать дембро-машину на разных языках программирования, что повысило бы переносимость.
Мысли о совместимости версий
Исходя из предыдущей идеи, у DEmbro не должно быть как таковой линейки версий, а должно быть большое дерево разновидностей с кучей диалектов, не совместимых друг с другом. Тем не менее, некую основную ветвь я буду разрабатывать, под неё писать спецификацию.
Однако, я не хотел бы себя загонять в рамки бесконечной поддержки предыдущих версий. Т.е. если я захочу переназвать кучу команд, изменить тонкости их поведения и т.д., то я это и сделаю (и уже делал). Это, конечно же, приведёт к тому, что код, расчитанный на предыдущие версии дембро, в новых версиях не будет работать. Чтобы, однако, не терять старый код, будет возможность включать режим старых диалектов, как-то так:
include" units/dialects/dembro.0.23.de"
DIALECT DEMBRO0.23
// код, расчитанный под старую версию DEmbro
\DIALECT
// тут снова можем писать код для новой версии DEmbro
Технически это не должно быть чем-то сложным. Как минимум, уже сейчас есть механизм словарей, обеспечивающий лвиную долю функционала.
Возможно, даже, будет что-то типа такого :)
include" units/dialects/retroforth.de"
DIALECT RETROFORTH
...
\DIALECT
февраля 01, 2012
Лисп в первый раз в жизни
Вопрос к лисп-аудитории.
Мне скоро потребуется заменить моего друга на кружке по теории алгоритмов. Рассказывать я могу о чём угодно в течении полутора часов, и я решил рассказать о некоторых философских идеях лиспа для расширения кругозора. Пока что мне приходят в голову две темы для рассказа:
- Кодогенерация (макросы, использование программы как данных)
- ФП на примере обработки списков (lambda, map, reduce, apply и т.д.)
[update] Если что, то слушатели — десятиклассники, их опыт программирования недалеко выходит за школьный, но есть некоторая стандартная алгоритмическая база.
