Мышь для веселья, клавиатура для боя!

Лисп в первый раз в жизни

2012-02-01T17:19:00.001+04:00

Вопрос к лисп-аудитории.

Мне скоро потребуется заменить моего друга на кружке по теории алгоритмов. Рассказывать я могу о чём угодно в течении полутора часов, и я решил рассказать о некоторых философских идеях лиспа для расширения кругозора. Пока что мне приходят в голову две темы для рассказа:

Кодогенерация (макросы, использование программы как данных)
ФП на примере обработки списков (lambda, map, reduce, apply и т.д.)

А какие ещё идеи по вашему мнению стоило бы включить в рассказ?

[update] Если что, то слушатели — десятиклассники, их опыт программирования недалеко выходит за школьный, но есть некоторая стандартная алгоритмическая база.

ConnectBot

2011-12-30T00:45:00.001+04:00

В догонку к моему недавнему посту про настройку линукса под андроидом. В программе ConnectBot, которая нужна для работы через консоль, можно назначить Esc на клавишу поиск, что очень полезно, т.к. на док. станции к моему планшету нет клавиши Esc. Это даже удобнее, чем если бы клавиша Esc была: она в виме используется весьма часто, и на обычной клавиатуре находится далеко от основных клавиш. А вот клавиша поиск находится слева от пробела. Теперь я даже при работе за обычным компьютером или ноутом применяю комбинацию Ctrl+C, потому что не хочу тянуться к Esc.

DEmbro в unix+ARM окружении!

2011-12-15T16:09:00.000+04:00

Начал портировать DEmbro на свой планшет :) Сейчас уже запускается, правда, почему-то не хочет исполнять внешние файлы, а без этого туго: дембро при запуске не имеет почти что команд, их нужно подключать конфигурационным файлом. Вообще, это было плохой идеей, я хотел сделать нечто типа "собери свой форт сам", но лучше это теперь вынести на этап компиляции, потому что тормозит запуск (хочется, чтобы моментально запускался и сразу начинал исполнять, без всяких подготовок). Ну а пока что я могу поиграться, вручную подключив нужный функционал командой builtin :)

Портировал по принципу "что не пашет, то комментирую". Основные проблемы при портировании были из-за разделителя директорий, который отличается в windows и unix, из-за разных символов переносов строк. Из-за того, что ассемблерные вставки для i386 не работают в ARM, и из-за использования windows-специфичных функций серьёзных проблем не возникло. Может быть потому, что я был к этому готов.

Надо будет как-то получше организовать сборку с учётом платформ и зависимостей, а то сейчас всё в кашу превратилось. Может быть написать систему конфигурации на DEmbro? :) А то как-то лениво изучать существующие.

Устанавливаем на планшет Asus Eee Transformer tf101 в дополнение линукс

2011-12-11T02:37:00.007+04:00

Недавно я стал счастливым обладателем планшета ASUS Eee Transformer tf101 16gb с док-станцией в комплекте и Android в качестве операционной системы. Мне, как программисту, хочется использовать девайс не только для чтения книг и интернета, но и для программирования. Поэтому я решил установить в дополнение к андроиду линукс.

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

На нижней стороне устройства находится его серийный номер. Если он начинается на B60 или меньше, то в инете можно найти кучу способов для получения root-доступа. Мне же досталась серия B80, для нее единственный известный способ -- использование программы Razorclaw. Программу нужно скачать, установить, запустить, и нажать на единственную в ней кнопку, после чего рут-доступ получен. Возможно, что перед этим потребуется обновить андроид до последней версии (это можно сделать в настройках).

Ок, после того, как рут-доступ получен, можно приступить к установке линукса. Для этого качаем с маркета программу Linux Installer, документацию для нее смотрите здесь. Авторы предупреждают, что неправильное использование программы может привести к порче устройства (если система будет достаточно серьезно повреждена, то восстановить ее не получится, и устройство можно будет выбрасывать).

Итак, запускаем Linux Installer, открываем в меню Setup. Нужно поменять только один параметр: путь к loop-файлу, я его установил в "/data/Linux.loop". На значение по умолчанию выдавался варнинг о том, что путь вроде как находится на съемном диске (несмотря на то, что это не так). По вкусу я еще поменял hostname и domainname на более короткие и приятные.

Возвращаемся из Setup, далее действуем по инструкции, которая выводится вверху экрана рядом с пингвином. А именно: жмем create target loop, format target loop, далее идем в Setup, ставим галку около "Allow write to /sys", возвращаемся, жмем mount loop, жмем install distribution in loop. Начались закачивание и установка линукса, нужно подождать какое-то время. Как только это закончилось, жмем Udpate launcher script, теперь для безопасности жмем Stop env loop, заходим в Setup, снимаем галку у "Allow write to /sys", возвращаемся и жмем mount loop. Ок, линукс готов к использованию.

Теперь нужно установить программу-консоль. У меня клавиатура внешняя (на док-станции) и сильно отличается от того, что обычно бывает на смартфонах, поэтому стандартный ConnectBot не подходит. Зато есть специальный ConnectBot для именно моего планшета. Устанавливаем, запускаем. В левом нижнем углу выбираем тип соединения local, вводим какое-нибудь название для сессии (doj, например), жмем Enter. Сейчас мы находимся в псевдолинукс системе самого андроида, в нем мы мало что можем делать. Набираем linuxchroot, должен запуститься установленный ранее линукс с bash в качестве оболочки.

Устанавливем базовый комплект для программирования, для этого набираем:
apt-get install vim
apt-get install make
apt-get install gcc
apt-get install g++

Ок, теперь у нас есть vim (версии 7.2, т.е. со всеми основными вкусностями вима) и компилятор g++. Можем приступить непосредственно к программированию:
mkdir /root/hello
cd /root/hello
vim hello.cpp

Отмечу на счет вима вот что: на клавиатуре нет клавиши Esc, вместо нее нужно использовать комбинацию Ctrl+C. Набираем минимальную прогу
#include <stdio.h>

int main(int argc, char* argv[]) {
printf("Hello from Android!\n");
return 0;
}

Выходим, выполняем
g++ hello.cpp -o hello
./hello

Видим, что прога работает.

Меняем шрифты в vim'е

2011-11-23T03:53:00.001+04:00

Недавно по рекомендации Darthman'а решил сменить используемый шрифт. Всегда раньше использовал FixedSys, но попробовать другие стало интересно. В посте я попытался описать как настраивать шрифты в виме.

Если vim запущен в консольном режиме, то отображаемый шрифт полностью зависит от программы-оболочки, реализующей консоль. Поэтому всё, что написано ниже, имеет отношение к gVim'у.

Опция gVim'а, настраивающая шрифт, называется guifont. Если в качестве параметра ей передать звёздочку, то появится диалоговое окошко (проверено под Windows, в других ОС не гарантируется)
:set guifont=*

Этот способ запуска полезен для перебора разных вариантов, но неудобен для настроек (не поместить в vimrc файл, например). Вместо звёздочки можно передать название шрифта с дополнительными опциями. Вот что написано в хелпе о формате дополнительных опций под windows:
        For the Win32 GUI                                       *E244* *E245*
        - takes these options in the font name:
                hXX - height is XX (points, can be floating-point)
                wXX - width is XX (points, can be floating-point)
                b   - bold
                i   - italic
                u   - underline
                s   - strikeout
                cXX - character set XX.  Valid charsets are: ANSI, ARABIC,
                      BALTIC, CHINESEBIG5, DEFAULT, EASTEUROPE, GB2312, GREEK,
                      HANGEUL, HEBREW, JOHAB, MAC, OEM, RUSSIAN, SHIFTJIS,
                      SYMBOL, THAI, TURKISH, VIETNAMESE ANSI and BALTIC.
                      Normally you would use "cDEFAULT".

          Use a ':' to separate the options.
        - A '_' can be used in the place of a space, so you don't need to use
          backslashes to escape the spaces.
        - Examples: >
            :set guifont=courier_new:h12:w5:b:cRUSSIAN
            :set guifont=Andale_Mono:h7.5:w4.5

Вот несколько моих примеров со скриншотами:
set guifont=consolas:h11:cRUSSIAN

set guifont=DejaVu_Sans_Mono:h11:cRUSSIAN

Некий обзор шрифтов для программирования можно почитать в этой статье.

Если не передавать опцию cRUSSIAN, то могут начаться проблемы с отображением русских букв в разных ситуациях. Если же всё же нет возможности передать такую опцию, то ИМХО самым простым способом решения проблемы является изменение кодировки ввода и языка сообщений:
set guifont=consolas:h11
set encoding=utf-8
lan mes en

Vim'у сегодня исполняется ровно 20 лет!

2011-11-03T13:08:00.000+04:00

А мы с ним одногодки, оказывается :)

Язык разметок на DEmbro

2011-10-25T08:59:00.004+04:00

Я пытаюсь написать свой универсальный язык разметок. Использование M4 сопровождается множеством неудоств, в частности, долгой отладкой. Из-за этого прогресс с языком разметок немного встал.

Единый язык разметок удобен тем, что можно писать один текст, и из него генерировать много текстов в различных форматах (html, tex, wiki, simple). В частности, такая возможность мне очень необходима при написании файлов помощи DEmbro — как минимум планируется документация на вики и в REPL режиме.

Недавно я придумал, как этот язык разметок можно организовать на DEmbro. В качестве основы я взял свои идеи по созданию аналога функции printf в DEmbro, и... реализовал всё самое главное в течении нескольких минут (единственная большая функция занимает 8 строк: она тут). Осталось только написать нужный набор команд, но это не составит труда (пример того, что уже начато для googlecode wiki тут).

Опишу идею и её реализацию. Размеченный текст представляет из себя просто обычный текст, в котором иногда встречаются специальные команды, влияющие на отображение этого текста. Почему бы мне не написать команду на DEmbro, которая читает размеченный текст, обычную составляющую просто выводит, а специальные фрагменты выделяет и выполняет их так, как будто это код на DEmbro? Сразу придумался синтаксис: фигурные скобки выделяют в тексте специальные фрагменты. Получается следующее
variable *doing?
: \page *doing? off ;
: {page}
 *doing? on
 begin *doing? @ while
 " {" source-cut str.
 " }" source-cut evaluate
 repeat ;

Команда {page} выделяет в цикле фрагменты исходника, зажатые между фигурными скобками, и выполняет их. Команда \page обрывает этот цикл. Как этим пользоваться: допустим, мы хотим добавить в язык разметок команду b для генерации жирного шрифта в формате HTML. Тогда пишем следующее:
: b " " str. ;
: \b " " str. ;

(Разница слешей в последней команде нелепа, но в DEmbro я больше привык закрывающие команды писать именно с таким наклоном, потому что другой «занят» под деление.)

Теперь можно смело использовать:
{page}
 Это просто текст.
 {b}А это уже жирный текст{\b}
{\page}
(Это программа на DEmbro, которая выведет текст, преобразованный в html-форматированный.)

Если есть желание использовать вместо фигурных скобок другие, легко написать другую page-команду, например:
: [page]
 *doing? on
 begin *doing? @ while
 " [" source-cut str.
 " ]" source-cut evaluate
 repeat ;

При этом каким-либо образом переопределять команды \page, b, \b и другие не нужно: можно смело писать
[page]
 Это просто текст.
 [b]А это уже жирный текст[\b]
[\page]

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

Между фигурными/квадратными скобками не обязательно писать лишь одну команду, можно сразу несколько. Например,
: i " " str. ;
: \i " " str. ;
: u " " str. ;
: \u " " str. ;
[page]
 Это просто текст.
 [b i u]А это уже жирный курсивный подчёркнутый текст[\u \i \b]
 [b i][u] И это тоже, несмотря на непарность конструкций[\u \i \b]
[\page]

Более того, т.к. в управляющем коде допустимо писать любой DEmbro-код, можно прямо в нём объявлять команды, переменные, вычислять время и т.д.
{page}
 {: _ " " ; ( Тут мы объявили команду, печатающую пробел)
 : int int->str DOC-GENERATOR << ^ ; ( Тут мы объявили команду int, которая печатает число)}
 Значение таймера на момент генерации страницы: {timer int}
 Числа от {8 dup int} до {0 dup int}: {
 :noname swap begin 2dup <= while dup int _ 1- repeat ; execute
 }
{\page}

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

В итоге я осознал, что больше не буду использовать M4 в своих разработках (по крайней мере в качестве языка разметок), а буду дальше развивать свой язык разметок (или даже макропроцессор) на DEmbro.

Пара слов по поводу кода, который находится сейчас среди модулей DEmbro (ссылки были выше). В нём используется та же идея, что описана тут, только слова разложены по пространствам имён, и сделана возможность сменить команду вывода на свою. В будущем конвертирование из моего формата в необходимый будет происходить как-то так:
HTML " sample.dep" evaluate-file ^
TEX " sample.dep" evaluate-file ^
GOOGLECODE " sample.dep" evaluate-file ^
SIMPLE " sample.dep" evaluate-file ^

Текущий пример для googlecode можно посмотреть тут
sample.dep -> test.wiki -> так это выглядит в итоге

Вставка кода с подсветкой в блог при помощи вима

2011-10-16T06:08:00.001+04:00

Уже не первый год я вставляю сюда фрагменты кода. Для того, чтобы сгенерировать код с подсветкой, я использую команду :TOhtml вима, которая генерирует html-код с подсветкой текущего файла или выделенного фрагмента. Код html появляется в отдельном окне, содержит теги head и body, содержит теги br, которые здесь в блоггере не нужны, содержит кучу лишних переносов строк.

Поэтому создание кода с подсветкой занимало у меня некоторое время: сгенерировать, выполнить команду для удаления тегов br, удалить ненужные переносы строк, выделить фрагмент html-кода без тегов head, body, скопировать, закрыть окно, и, наконец, вставить html в нужное место.

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

Собственно, писать особо не о чем, приведу фрагменты кода, которые я разместил в свой _vimrc файл:
fun! Code(line1, line2)
 " Исполняем встроенную команду TOhtml
 " Она создаст в отдельном окне код html-странички
 exec a:line1.','.a:line2.'TOhtml'
 " Удаляет всё, что находится выше строки, которая содержит <body
 %g/<body/normal k$dgg
 " Хитрое выражение с регуляркой
 " Оно обрабатывает содержимое открывающего тега body, извлекает
 " значения параметров bgcolor и text, и заменяет этот тег body
 " на открывающий тег font, в котором в качестве цвета указывается
 " параметр, который находился в параметре text тега body
 %s/<body\s*$bgcolor="\#[a-f0-9]\{6\}"$\s*text=$"\#[a-f0-9]\{6\}"$\s*>//i
 " Заменяет всё, что находится между закрывающим тегом body
 " и закрывающим тегом html, на закрывающий тег font
 %s#</body>$.\|\n$*</html>##i
 " Удаляет все теги br
 %s# ##i
 " Удаляет лишний перенос строки после самой первой строки
 normal ggJ
 " Удаляет лишний перенос строки перед самой последней строкой
 normal GkJ
 " Компируем в буфер всё содержимое TODO: копировать в именованный
 " буфер
 normal ggVGy
 " Выходим из окна, не сохраняя ничего
 q!
 " Вставляем вместо выделенного фрагмента получившийся код
 normal gvp
endf

(Подсветка этого кода сгенерирована им самим же.)

Добавляем возможность вызова команды для выделенного промежутка строк:
command -range=% Code :call Code(<line1>,<line2>)

Наконец, вешаем всё это на клавишу F4:
vmap <F4> :Code<CR>

Как этим пользоваться: выделяем фрагмент кода, подсветку которого хотим сделать, жмём F4, и вуаля! Вместо фрагмента кода появляется html-код с подсветкой.

Чтобы проще было разобраться как работают команды внутри функции Code, опишу как можно выполнить эту функцию вручную и пошагово. Пусть у нас есть код, подсветку которого хочется сделать:
:a CreateWindowExA DWORD LPCTSTR LPCTSTR DWORD LONG LONG
 LONG LONG HWND HMENU HINST LPVOID HWND user32;
:a DefWindowProcA HWND UINT WPARAM LPARAM LRESULT user32;
:a DestroyWindow HWND BOOL user32;
:a DispatchMessageA LPMSG LONG user32;

Выделяем его при помощи shift+v (в терминах вима S-V), выполняем
:'<,'>TOhtml

У нас открывается новое окно со следующим содержимым:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>D:\proj\DForth\trunk\release\units\windows.de.html</title>
<meta name="Generator" content="Vim/7.3">
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
</head>
<body bgcolor="#000000" text="#a8a8a8">
:a CreateWindowExA DWORD LPCTSTR LPCTSTR DWORD LONG LONG 
                   LONG LONG HWND HMENU HINST LPVOID    HWND user32; 
:a DefWindowProcA HWND UINT WPARAM LPARAM               LRESULT user32; 
:a DestroyWindow HWND                                   BOOL user32; 
:a DispatchMessageA LPMSG                               LONG user32; 
</body>
</html>

Выполняем
:%g/<body/normal k$dgg
, удаляется всё, что выше body:
<body bgcolor="#000000" text="#a8a8a8">
:a CreateWindowExA DWORD LPCTSTR LPCTSTR DWORD LONG LONG 
                   LONG LONG HWND HMENU HINST LPVOID    HWND user32; 
:a DefWindowProcA HWND UINT WPARAM LPARAM               LRESULT user32; 
:a DestroyWindow HWND                                   BOOL user32; 
:a DispatchMessageA LPMSG                               LONG user32; 
</body>
</html>

Теперь выполним сперва
:%s/<body\s*$bgcolor="\#[a-f0-9]\{6\}"$\s*text=$"\#[a-f0-9]\{6\}"$\s*>//i
затем
:%s#</body>$.\|\n$*</html>##i
Первая команда затронет строку, в которой открывается body, вторая -- строки, в которой закрываются body и html:

:a CreateWindowExA DWORD LPCTSTR LPCTSTR DWORD LONG LONG 
                   LONG LONG HWND HMENU HINST LPVOID    HWND user32; 
:a DefWindowProcA HWND UINT WPARAM LPARAM               LRESULT user32; 
:a DestroyWindow HWND                                   BOOL user32; 
:a DispatchMessageA LPMSG                               LONG user32; 


Удаляем все теги br:
:%s# ##i

Получаем:

:a CreateWindowExA DWORD LPCTSTR LPCTSTR DWORD LONG LONG
                   LONG LONG HWND HMENU HINST LPVOID    HWND user32;
:a DefWindowProcA HWND UINT WPARAM LPARAM               LRESULT user32;
:a DestroyWindow HWND                                   BOOL user32;
:a DispatchMessageA LPMSG                               LONG user32;


Наконец, удаляем первый перенос строки и последний:
ggJ
GkJ
Получаем:
 :a CreateWindowExA DWORD LPCTSTR LPCTSTR DWORD LONG LONG
                   LONG LONG HWND HMENU HINST LPVOID    HWND user32;
:a DefWindowProcA HWND UINT WPARAM LPARAM               LRESULT user32;
:a DestroyWindow HWND                                   BOOL user32;
:a DispatchMessageA LPMSG                               LONG user32; 

Всё, код полностью готов для вставки в блог.

Пространства имён в DEmbro

2011-10-16T05:12:00.001+04:00

Недавно в DEmbro появилась конструкция, которую я называл «короткое пространство имён», и я решил написать о пространствах имён в DEmbro и словарях вообще.

Обычные пространства имён

Пространства имён объявляются при помощи конструкции
namespace name ... \namespace

Все команды, объявленные внутри многоточия, будут командами пространства имён name. Например, рассмотрим код
: command ." Global command" ;
namespace X
 : command ." X command" ;
\namespace

Если теперь вызвать command, то будет напечатано "Global command". Чтобы вызвать слово из прострнства имён, нужно подключить прострнство X, просто вызвав его имя, затем вызвать команду, затем отключить пространство имён командой «^»:
X command ^

Можно между «X» и «^» вызывать несколько команд из пространства имён X, а так же глобальные команды, если они не были перекрыты внутри X. Возможно объявлять пространства имён внутри пространств имён. Вот достаточно крупный пример с комментариями:
: command1 ." Global command 1" ;
namespace X
 command1 // напечатает "Global command 1", потому что команда ещё не перекрыта
 : command1 ." X command 1" ;
 command1 // напечатает "X command 1" — теперь это перекрытая команда
 : command2 ." X command 2" ;
 namespace Y // создаём подпространство имён
 : command1 ." Y command 1" ;
 command1 // напечатает "Y command 1"
 \namespace
 command1 // напечатает "X command 1" — мы уже вне пространства имён Y
\namespace
X command1 ^ // напечатает "X command 1" — мы подключили пространство имён X
X Y command1 ^ ^ // напечатает "Y command 1" — мы подключили подпространство имён Y
X X command1 ^ ^ // напечатает "X command 1": X можно вызвать внутри, т.к. оно определено глобально
X Y command2 ^ ^ // напечатает "X command 2" — внутри Y нет команды command2
Y command1 ^ // ошибка: не объявлена команда Y

Конструкция uses

Если нужно подключить сразу много пространств имён, то можно утомиться закрывать их все командой «^»:
X Y Z W Q
 .....
^ ^ ^ ^ ^

Чтобы сделать это автоматически, можно воспользоваться конструкцией «uses ... \uses». Эта конструкция автоматически отключает все пространства, подключённые внутри многоточия. Например, предыдущий фрагмент перепишется в виде:
uses X Y Z W Q
 .....
\uses

Расширения прострнства имён

Иногда может возникнуть необходимость расширить пространство имён новыми словами вне конструкции «namespace ... \namespace». В этом случае можно воспользоваться конструкцией «extend-namespace .. \extend-namespace». Она берёт последнее подключённое пространство имён и делает так, что все команды, объявляемые внутри многоточия, будут создаваться внутри него (если это поведение не будет явно изменено другими действиями с пространствами имён):
X extend-namespace
 ...
\extend-namespace

«Короткие» пространства имён

Помимо механизма «uses» есть и другой механизм упрощения отключения пространства имён: короткие пространства имён. Единственное их отличие от обычных в том, что они ищут только следующую команду в пространстве, и не требуют закрывающего слова. Проще такое понять на примере:
: command ." Global command" ;
shortnamespace X
 : command ." X command" ;
 shortnamespace Y
 : command ." Y command" ;
 \shortnamespace
\shortnamespace
command // Global command
X command // X command
command // Global command — короткие пространства имён воздействуют только на следующую команду
X Y command // Y command
X X X X X X command // X command

Если проводить аналогии с языком C++, то поведение обычных пространств имён напоминает то, что делает слово «using», а поведение коротких пространств имён — оператор «::». Можно даже в коде на DEmbro объявлять короткие пространства имён с таким суффиксом для большей наглядности:
shortnamespace X::
 shortnamespace Y::
 : command ." Y command" ;
 \shortnamespace
\shortnamespace

X:: Y:: command

Словари, context и target стеки

Расскажу теперь о том, как это всё организовано внутри.

Первое важное понятие — словарь. Словарь — это просто список, сопоставляющей имени команды её код. Когда создаётся новое слово, оно добавляется в конец словаря. Когда ищется слово — оно ищется в словаре с конца.

Для поддержки разделения команд на группы, в DEmbro-машине может быть несколько словарей. Есть специальный стек словарей, называющийся context. Когда DEmbro-машина ищет слово, чтобы его выполнить, она берёт самый верхний словарь со стека, пытается найти слово в нём, если не находит, то берёт следующий словарь, и пытается найти в нём, и т.д.

Отдельный стек target используется для в каком-то смысле обратного действия — добавления команд. При добавлении команд DEmbro-машина берёт верхний словарь со стека target, и добавляет в него команду.

Изначально в обоих стеках лежит словарь GLOBAL (на самом деле, это не совсем правда, но пока что предполагается так).

Всю работу на DEmbro со словарями и стеками context и target можно выразить пятью основными словами:
vocabulary-new ( -- voc) создаёт новый словарь и кладёт его в стек
context< ( voc --) переносит словарь с основного стека в context
context> ( -- voc) переносит словарь из стека context в основной
target< ( voc --) переносит словарь с основного стека в target
target> ( -- voc) переносит словарь из стека target в основной

Реализация пространств имён через словари

Напоследок я покажу как реализуются все слова по работе с пространствами имён через эти пять. Реализацию вы можете посмотреть в файле core/default/voc.de. Тут я опишу немного упрощённую версию, но полностью соответствующую описанному выше в посте.

Сперва объявим вспомогательное слово vocabulary:
: vocabulary ( "name") create vocabulary-new ,
 does> ( -- voc) @ ;

Оно полезно для создания именованных словарей. Например, если теперь написать
vocabulary X
то в дальнейшем вызов команды X будет приводить к тому, что на стек будет класться словарь, созданный командой vocabulary-new внутри vocabulary.

Теперь объявим конструкцию «namespace»:
: namespace ( "name") create vocabulary-new dup context< dup target< ,
 does> @ context< ;
: \namespace context> drop target> drop ;

Команда «namespace» создаёт и кладёт словарь в стеки context и target, команда «\namespace» скидывает верхние значения этих стеков. Кроме того, команда namespace переопределяет действие создаваемого слова: после строки
namespace X
вызов X будет приводить к тому, что словарь кладётся в стек context, а не в обычный, как в случае с vocabulary.

Легко объявить закрывающую конструкцию «^». Сперва я ещё объявляю конструкцию «^^^», явлюящуюся не-immediate версией «^»:
: ^^^ context> drop ;
' ^^^ alias ^ immediate
В последней строке команда «^» объявляется как копия «^^^», только делается ещё и immediate.

Объявим конструкцию расширения пространства имён:
: extend-namespace context> dup context< target< ;
' \namespace alias \extend-namespace
Тут всё элементарно.

Конструкция «uses» использует («задокументированную») фичу: в стеки словарей можно класть ноль:
: uses 0 context< 0 target< ;
: \uses begin context> 0= until begin target> 0= until ;

Остались короткие пространства имён. Короткое пространство имён кладёт словарь в стек context, выполняет один шаг DEmbro-машины, после этого снимает словарь со стека. Для того, чтобы выполнить один шаг, используется команда «dembro-step»:
: shortnamespace ( "name") namespace
 does> @ context< dembro-step context> drop ;
' \namespace alias \shortnamespace
Конструкция отличается от «namespace» только поведением создаваемого ей словом.

Условные переходы

2011-10-13T05:18:00.000+04:00

Сессия сдана, пришло время продолжить разработки.

Как я уже писал раньше, я пишу транслятор ассемблера. Только что пройден исторический этап: транслятор начал поддерживать инструкции условных переходов. Ура!

Вот пример цикла:

:asm-noname PREFIX
  *auto-integers? on
    mov eax 555
    mov ebx 111
  @> LOOP
    sub eax 2
    sub ebx 1
    jnz @@ LOOP
    mov d[ *out disp ] eax
    ret
  all-resolve
\PREFIX asm-noname; execute

Технические детали: при помощи :asm-noname ... asm-noname; execute код на асме транслируется и сразу запускается. Блок PREFIX ... \PREFIX указывает на то, что мы будем использовать префиксную запись инструкций (т.е. инструкции перед операндами). Вызов *auto-integers? on делает так, что целые числа автоматически считаются операндами команд. (Без этой опции после чисел 555, 111, 2, 1 нужно бы было просто вызывать команду imm. Это полезный режим, если мы хотим операнды вычислять, например, в этом режиме можно писать mov eax 64 1024 * imm, если не хочется в уме перемножать 64 и 1024. Кроме того, код может зависеть от чего-нибудь внешнего: например, тут mov eax timer imm заносится состояние таймера в момент трансляции, операнд в явном виде не указан.)

Теперь по коду. Сперва в соответствующие регистры кладётся 555 и 111. Далее, создаётся метка с именем LOOP. После этого в цикле из eax вычитается 2, из ebx вычитается 1 до тех пор, пока ebx не обнулится. То, что останется от eax, переносится в *out — глобальную переменную DEmbro, которую нужно определить выше, например, так:

variable *out

Но так делать вовсе необязательно, вместо *out может быть любой указатель. Как нетрудно догадаться, в *out будет занесено 333, далее с переменной можно работать из кода на DEmbro, или из следующей ассемблерной вставки. Таким образом ассемблер может обмениваться данными с DEmbro. Планируется более детальный механизм взаимодействия: из ассемблера можно будет получать доступ к стекам и другим структурам DEmbro-машины.

Команда all-resolve разрешает все метки. Дело в том, что на метку могут быть ссылки выше метки, ниже метки, или одновременно и так, и так. Нет возможности сразу это предугадать, поэтому метки и ссылки собираются в две таблицы, а в конце кода командой all-resolve ссылкам ставятся в соответствие метки и нужные адреса проставляются. Из-за этой муторности условные переходы и были написаны самыми последними среди прочих инструкций. Теперь, я надеюсь, мне осталось только перебить таблицы из документации к ia-32 в свой транслятор.

Сейчас транслятор поддерживает уже 84 инструкции. Подробнее о том, как я делал этот транслятор и о том, как сделать свой транслятор, напоминаю, планируется большой цикл статей.

Полнота по Тьюрингу — насколько это хорошо?

2011-09-20T03:48:00.010+04:00

Часто любят говорить, что такой-то язык программирования полон по Тьюрингу. Насколько хорошо полнота по Тьюрингу характеризует язык с точки зрения практического применения?

ИМХО, это свойство само по себе ничего не значит, его следует считать обязательным для любого языка программирования. Напротив, если какой-то язык программирования не полон по Тьюрингу, то это очень плохо, плохо настолько, что даёт повод серьёзно задуматься: а является ли этот язык языком программирования?

Например, есть язык программирования BitBitJump, о нём на русском можно почитать тут. Язык состоит всего из одной инструкции: скопировать в памяти один бит в другой, и перейти по заданному адресу (переход происходит в любом случае, т.е. он безусловный). Инструкция имеет три операнда: 1) адрес, откуда копируем, 2) адрес, куда копируем, и 3) адрес, на который будет совершён переход выполнения программы. Важная оговорка: программа и данные находятся в одной памяти вместе, т.е. во время выполнения программа может модифицировать свой код.

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

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

С точки зрения здравого смысла ясно, что BitBitJump радикально уступает привычным языкам программирования в практическом применении, потому что все они умеют копировать биты и совершать безусловные переходы.

Для оценки именно практичности нужны какие-то другие критерии. Я не знаю, какие именно, но полнота по Тьюрингу на эту роль точно не подходит. Полнота по Тьюрингу скорее полезна в роли эдакого теста на дурака: отметать то, что не является языком программирования, но пытается себя за него выдать.

Например, известен факт, что метапрограммирование (шаблоны в частности) в C++ является полным по Тьюрингу. Но это само по себе вовсе не говорит об удобстве (или неудобстве) в его применении на практике. Если бы метапрограммирование в C++ происходило на языке BitBitJump, то навряд ли это кого-то обрадовало бы, хотя полнота по Тьюрингу сохранилась бы.

Новости с разработок DEmbro

2011-09-12T17:33:00.008+04:00

Сейчас у меня много дел, и на DEmbro остаётся мало времени.

Недавно начал писать заголовок к windows sockets, вроде как самое необходимое объявлено. Написал при помощи него для примера простенькие клиент и сервер. Кроме того, написал hello world http-ответом.

Но основное направление деятельности сейчас — написание транслятора ассемблера. Планируется полная поддержка ia32 ассемблера (он же x86). Сейчас уже реализована 51 инструкция. До юзабельности не хватает системы меток и инструкций переходов, а до полного счастья не хватает всяких там sse :)

В целом, транслятор мне нравится. Вот пример кода на нём:

mov eax h100 imm
mov ecx d[ *in2 disp ]
xor eax d[ *in4 disp ]
imul ecx eax
lea eax d[ ecx 2* eax 256 disp ]
and d[ *out6 disp ] eax

Конкретные примеры использования асма на DEmbro можно посмотреть здесь.

О трансляторе подробно будет целый цикл статей, если руки дойдут.

Таблицы различия диалектов ЯПов

2011-08-17T16:12:00.001+04:00

Наткнулся на отличный сайт о различиях схожих языков программирования
http://hyperpolyglot.org/

В частности, там есть очень полезная таблица сравнения лиспов.

Скрытие раздела «Добро пожаловать»

2011-08-16T11:32:00.002+04:00

Чтобы раздел «Добро пожаловать» не отображался на странице с постом, в настройках дизайна содержимое виджета я заключил в оператор if:

<b:widget id='Text1' locked='false' title='Добро пожаловать!' type='Text'>
<b:includable id='main'>
<b:if cond='data:blog.pageType != "item"'>
....
</b:if>
</b:includable>
</b:widget>

DEmbro уже год

2011-08-16T11:18:00.002+04:00

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

Поначалу у меня не было никакого опыта программирования на фортах, а было теоретическое, чисто математическое понимание того, чем они хороши и удобны. Спустя несколько месяцев DEmbro был развит до того, что я начал писать какие-то библиотеки и программы, и время от времени у меня возникал вопрос «Как на таком можно писать??». Но со временем привык, и теоретическое понимание перешло в практическое.

Многое в DEmbro было заложено в самом начале разработки, пока я ещё не до конца разобрался с устройством форта, и потому некоторые фундаментальные вещи написаны неправильно и требуют рефакторинга. Рефакторинг висит на мне уже несколько месяцев, мешая дальнейшей разработке.

Изначальная вера в то, что я смогу всё реализовать, немного пошатнулась. В первую очередь, концептуальные проблемы возникают с преобразованиями шитого кода (которые нужны для оптимизации и сборки исполняемого кода). Вторая проблема, которую я считаю концептуально серьёзной, — числа с плавающей точкой (да и вообще типы с фиксированным размером, но нестандартным). Об этих проблемах я подробно напишу позже.

Остальное задуманное не предвещает бед. Локальные переменные, исключения и шаблоны уже используются в некотором объёме, но требуют некоторой шлифовки. После рефакторинга ядра будут начаты классы (с итератороми и элементами функционального программирования), они уже запроектированы. Взаимодействие с внешними программами планируется очень хорошее, аналогов задуманному нигде не видел.

Вот график количества изменений DEmbro по месяцам:

Первый провал графика связан с зимней сессией, которая была с декабря 2010ого по явнварь 2011ого. Второй провал связан с летней сессией, начавшейся в мае (пятый месяц). Провал графика между ними, скорее всего, связан с жизненными проблемами, когда мне было не до DEmbro. Сейчас на свне уже более 550 коммитов.

Я надеюсь, что дальше всё будет идти успешно, и я осуществлю хотя бы бо́льшую часть задуманного.

Добавление команд в ядро DEmbro

2011-08-10T23:32:00.001+04:00

Упростил процедуру добавления команд в ядро DEmbro.

Допустим, что я хочу добавить группу команд «file», в которую входят fopen, fclose, fwrite и fread.

Как это было раньше
Заходим в директорию source\DEmbro\commands, создаём там файл DCommandsFile.pas4, в нём пишем паскалевский модуль, в котором реализуем все команды.

Создаём в модуле публичную функцию LoadCommands, в которой добавляем каждую команду в ядро (при помощи функции AddCommand).

Далее, заходим в главный файл проекта source\DEmbro\dembro32.dpr, в разделе uses добавляем подключение нового модуля.

Теперь, заходим в source\DEmbro\DForthMachine.pas4, в приватной секции uses тоже прописываем новый модуль. В методе OForthMachine.Create того же файла добавляем строку DCommandsFile.LoadCommands(@Self);.

В этот момент команда появилась в ядре дембро, проект можно компилировать. Чтобы при стандартном запуске дембро эти команды были видны, нужно проделать ещё пару шагов.

Заходим в core\release\default, создаём файл file.de, в нём при помощи команды samebuiltin прописываем подключаемые команды.

В файле core\release\default\system.de прописываем
str" core\default\file.de" evaluate-file

Теперь всё сделано. За исключением того, что ещё желательно писать хелп для каждой команды. Ужас, не правда ли?

Как это будет теперь
Заходим в source\DEmbro\commands, создаём файл file.cmd, в нём реализуем команды в таком виде:

DECLARE(fopen)
    body( code for open );
RUS SUMMARY ( i B: s -- f) открывает файл по имени с заданными флагами

DECLARE(fclose)
     body( code for close);
RUS SUMMARY ( f --) закрывает файл, открытый ранее при помощи команды fopen

DECLARE(fread)
     body( code for read);
RUS SUMMARY ( pif --) читает i байт в область памяти p из файла f

DECLARE(fwrite)
     body( code for write);
RUS SUMMARY ( pif --) записывает i байт из области памяти p из файла f

Далее, в файле source\DEmbro\commands\groups.list добавляем строку GROUP(file).

Теперь в директории source\DEmbro можно выполнить make commands и команды будут автоматически разнесены по всем нужным файлам, остаётся только скомпилировать ядро.

Как это работает
Файлы *.cmd и groups.list обрабатываются при помощи m4 в несколько проходов, каждый раз предварительно подгружаются разные библиотеки. Библиотеки распологаются в source\m4 и начинаются с буквы «c» (от слова commands).

Например, чтобы сгенерировать список подключения команд в ядре, используется cload.m4 в следующей команде
    m4 ..\m4\cload.m4 temp\all.cmd > temp\load.inc4

Сгенерированный файл load.inc4 выглядит примерно так:
    AddCommand("malloc", _malloc, False);
    AddCommand("free", _free, False);
    AddCommand("realloc", _realloc, False);
    AddCommand("move", _move, False);
    AddCommand("fill", _fill, False);
    AddCommand("current-directory", _current_directory, False);

А если проделать то же самое, но подключать cbuiltin.m4, то получим файл вида mem.de.

Аналогичным образом строятся другие файлы, а в будущем будут строиться хелпы. Напоследок приведу текущий код скрипта, раскидывающий команды (таргет commands в главном makefile):
    type commands\mem.cmd commands\misc.cmd > temp\all.cmd
    m4 ..\m4\cgroups.m4 commands\groups.list > temp\all.cmd
    m4 ..\m4\cload.m4 temp\all.cmd > temp\load.inc4
    m4 commands.m4 temp\load.inc4 > temp\load.incq
    dquotes temp\load.incq load.inc
    m4 ..\m4\cbody.m4 temp\all.cmd > temp\body.inc4
    m4 commands.m4 temp\body.inc4 > temp\body.incq
    dquotes temp\body.incq body.inc
    m4 ..\m4\cevaluate.m4 commands\groups.list > ..\..\release\core\builtin\all.de
    m4 ..\m4\cbuiltin.m4 commands\mem.cmd > ..\..\release\core\builtin\mem.de
    m4 ..\m4\cbuiltin.m4 commands\misc.cmd > ..\..\release\core\builtin\misc.de

Официальные каты

2011-08-10T15:53:00.002+04:00

А официальные каты таки существуют!

В режиме «создать» есть кнопка разрыва страницы. Но в режиме «Изменить HTML» я не видел этой кнопки. В этом режиме следует использовать строку

Текст ссылки на полную версию поста можно поменять в меню «Настройки -> Дизайн -> Элементы страницы -> Сообщения блога -> Изменить -> Текст ссылки на Страницу сообщения».

Кроме того, включил обновлённый редактор, функция отключения автовставки тега br радует.

Ещё одна игра на DEmbro

2011-07-30T14:56:00.006+04:00

Написал ещё одну игру, опять на конкурс IGDC. Темой конкурса была змейка.

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

В основном, переделывал предыдущую игру (Maze Journey). Изначально у меня была
идея ради эксперимента не трогать основные модули, а только написать специальные
уровни для Maze Journey, в которых реализуется змейка. Но передумал, как минимум
управление хотелось сделать по-нормальному.

Что забавно, в получившейся змейке можно подгрузить уровень из Maze Journey,
и он будет благополучно работать. (Чем я и воспользовался при изготовлении
«титров» — делал в последний момент в спешке, просто переделав соответствующие
титры из Maze Journey. Плохо, конечно, но ИМХО лучше абы какие титры, чем
никаких.)

Забыл проверить размер перед отправкой, а зря — оказалось, что релиз весит 1,99 МБ.
Большой размер связан с тем, что я отправил дебаг версию DEmbro, весящую более
полутора мегабайта, в то время как релиз версия весит всего 76 КБ.

Бажные каты

2011-07-18T22:25:00.004+04:00

Предыдущий пост на главной странице выглядит некорректно — каты сработали неправильно, рррррр. Тег table включает отображение текста, даже если сам тег вложен внутрь скрытого span'а. Странное поведение. Пришлось отключить кат.

Когда же наконец появится что-нибудь официальное для катов вместо этой глючной поделки?

[updated] Нашёл официальные каты.

Пара слов о том, как делался Maze Journey

2011-07-18T15:01:00.014+04:00

Недавно участвовал в конкурсе IGDC, писал игру на DEmbro. Это был достаточно интересный опыт использования на практике своего языка.

Сразу оговорюсь, что в DEmbro полно недоделок, он глючный, и я плохо на нём программирую :)

Средства разработки

DEmbro и текстовый редактор Vim. Выглядит это как-то так:

Из средств отладки — печать значений на консоль, комментирование подозриетльных фрагментов кода, и возможность без запуска всей игры загрузить какой-то отдельный модуль в REPL режиме и быстро посмотреть как себя ведут команды.

Коротко о языке

Я использовал (за исключением нескольких незначительных мест) только три типа: целое число, указатель и строка. Хотя типов как таковых в DEmbro нет. Все операции производятся на стеке, для чисел и указателей один стек, для строк — отдельный. Круглые скобки используются для многострочных комментариев, а для однострочных — общепринятое «//».

Несколько примеров:

1 // положить на стек число 1
2 // положить на стек число 2
3 4 5 // положить на стек числа 3, 4 и 5. Теперь стек выглядит так: 1 2 3 4 5
+ // сложить два верхних числа. Теперь стек выглядит так: 1 2 3 9
* // умножить два верхних числа. Теперь стек выглядит так: 1 2 27
swap // поменять два верхних числа местами, 1 27 2
div // нацело поделить два верхних числа, 1 13
max // из двух верхних элементов оставить максимальный, 13
1+ // увеличить верхнее число на 1, получится 14
drop // скинуть верхний элемент со стека, теперь стек вернулся в начальное состояние

Можно писать свои команды при помощи конструкции

: name ..... ;

где name — имя команды.

(Именем может быть любая последовательность символов без пробелов. Никаких ограничений на имя нет (можно переопределять стандартные слова).)

Например, в программе всё измеряется в миллесекундах. Но иногда приходится задавать время в минутах. Чтобы задать пять минут, нужно 5 умножить на 60*1000, и получится соответствующее число миллисекунд. Чтобы делать это вычисление автоматически, можно написать команду

: mins 60000 * ;

Теперь можно просто записать

5 mins

и получить время в миллесекундах для пяти минут.

Команды можно выполнять косвенно. При помощи символа апостроф, за которым идёт название команды, можно положить указатель на эту команду. А при помощи команды execute выполнить указатель с вершины стека. Т.е.

5 ' mins execute

эквивалентно коду «5 mins».

Можно создавать анонимные команды при помощи команды «:noname»:

:noname ." Hello world" cr ;

После выполнения этого кода на стеке будет лежать указатель на команду, который можно скормить команде execute на выполнение. Так, например:

:noname ." Hello world" cr ; execute

Пара примеров на работу с указателями и переменными:

variable x // создаёт область памяти под целое число или указатель
// теперь вызов команды x кладёт на стек указатель на эту область памяти
5 x ! // записать число 5 в переменную x
x @ // положить в стек значение переменной x
. // распечатать на консоль полученное число
x off // записать в переменную x ноль

Ещё есть условный оператор и циклы.

: printbool if ." TRUE" else ." FALSE" then cr ; // создаём команду printbool
// она снимает со стека верхний элемент, и если он ноль, то печатает FALSE
// иначе TRUE
false printbool // напечатает FALSE
true printbool // напечатает TRUE
100 10 > printbool // напечатает TRUE
100 10 < printbool // напечатает FALSE
100 0<> printbool // напечатает TRUE

// печатает числа от 0 до 10
:noname 0 begin dup 10 <= while dup . 1+ repeat drop ; execute

Условные операторы и циклы являются компилирующими командами, и потому их можно использовать только внутри описания команд.

Сказанного должно быть достаточно для понимания того, что будет ниже. Чтобы не затягивать вступление до бесконечности, дам напоследок несколько ссылок

Практически никакого контроля нет ни на стадии компиляции, ни на стадии интерпретации. Что лежит на стеке или в памяти узнать нельзя. Можно написать на свой страх и риск почти любую фигню с непредсказуемым исходом.

Кратко об игре
Лучше один раз увидеть, чем сто раз услышать, так что отсылаю читателя самому сыграть в игру (в конкурсном архиве запускать надо Doj\mazejourney\release\run.bat). Я написал на DEmbro создание окна и инициализацию OpenGL достаточно давно. Т.к. числа с плавающей точкой в DEmbro немного сыроваты (в частности, нет нормального способа передать double в виде параметра в dll функцию), я решил для упрощения жизни их не использовать вообще. Кроме того, я не писал ни поддержки текстур, ни каких-то хитрых примитивов. Единственное, что я использовал при рендере — цветные квадраты. Игру я писал с девизом «каждый уровень имеет свой уникальный геймплей». Поэтому нужно было иметь удобные конструкции для описания уровней.

Как описывается уровень
Чтобы не томить любителей ковыряться самостоятельно, рекомендую посмотреть файл «game\levels\big.de» — он является очень простым примером того, как описывается уровень. Кстати, по-поводу этого уровня, в нём можно усмотреть букву O — это чит, позволяющий пройти в определённом месте сквозь стену и оказаться у выхода. Итак, первым делом я написал команду lab, которая позволяет в наглядном текстовом виде описывать уровни. Например, так:

lab
##########
#S       #
#        #
#        #
#        #
#        #
#       F#
##########
\lab

(Из-за бага в ядре дембро, после слова «lab» нужно ставить пробел.) Команда lab использует функцию ядра «source-next-line», которая читает следующую строку исходника. По первой строке определяется ширина уровня, а дальше создаёт двумерный массив, содержащий ascii коды символов. После выполнения этой конструкции можно при помощи команды last-lab-x получить ширину лабиринта, при помощи last-lab-y высоту лабиринта, а при помощи last-lab-maze указатель на двумерный массив. Далее я написал команду «level», которая создаёт уровень. Напрямую она практически не используется, но в файле «game\levels\list.de» определяется надстройка над ней — newlevel, которая внутри себя вызывает level, выполняет файл, имя которого следует после «newlevel», и связывает уровни в последовательность. В том же файле list.de можно обнаружить сам список уровней. Как только мы создали уровень (командой level) можно приступать к его наполнению. Команда «maze!» установит на текущем уровне последний лабиринт, созданный командой «lab». При помощи команд «cell-x!» и «cell-y!» можно установить размер в пикселях одной ячейки лабирнта текущего уровня, например так: 16 cell-x! 16 cell-y! При помощи команд «offset-x!» и «offset-y!» задаётся положение лабиринта на экране. Т.к. всегда мне нужно было центрировать лабирит, я написал команду «centrize», которая автоматически вызывает «offset-x!» и «offset-y!», вычисляя смещение при помощи размера лабиринта и размера ячейки. При помощи команд «player-x!» и «player-y!» можно установить координаты ячейки, в которой будет появляться игрок в начале уровня. Перейдём к более нетривиальным элементам уровня — событиям. Можно описать команды, которые будут выполняться при старте уровня — при помощи этого механизма запускается звук гонга перед началом уровня:

:noname pchar" data\sounds\newlevel.wav" sound ;init

Тут просто вызывается команда sound, которая принимает один параметр — указатель на pchar-строку, содержащую имя звукового файла. Менее тривиальный примеры — события, когда игрок входит на какую-то ячейку. Можно установить на каждый тип (т.е. ascii-символ) ячейки свой обработчик. Обработчику на стеке передаются x,y координаты ячейки, на которую пытается войти игрок. Если их скинуть со стека, то игрок не сможет зайти в ячейку, т.е. можно описать обработчик для стены:

:noname drop drop ;enter_ #

Есть команда passed, которая, наоборот, считывает x,y и смещает в них игрока. Можно написать

:noname passed ;enter_ O

Тогда игрок сможет заходить в букву O. Чтобы буква O выглядела как обычная стена, для неё нужно определить такой же обработчик рисования (который тоже принимает координаты x,y), как и для стены:

: draw_# COLOR 2dup PURPLES GEN[]2 ^ set-color draw-cell-rect ;
:noname draw_# ;draw_ #
:noname draw_# ;draw_ O

Есть ещё один тип обработчиков для каждой ячейки — обработчик инициализации. Обработчики инициализации нужно установить перед вызовом команды «lab». Тогда при считывании каждой ячейки внутри конструкции «lab .... \lab» будет вызван соответствующий заданному ascii-символу обработчик инициализации. Пример использования: всегда неудобно задавать положение игрока координатами при помощи «player-x!» и «player-y!». Гораздо удобнее пометить нужную ячейку буквой S. Для этого перед выполнением «lab» достаточно добавить обработчик инициализации ячейки S:

:noname player-y! player-x! ;oninit_ S

При входе на букву F по умолчанию задан переход к следующему уровню командой «next». При желании аналогичной функциональностью можно наделить другие буквы, и сделать переходы на другие уровни. Таковы общие принципы создания уровней. Теперь я разберу особенности разработки некоторых уровней. Часто, из-за копипасты в описнии уровней можно увидеть много ненужного кода, — я не успел его удалить до дедлайна.

Уровень в темноте (dark.de)
На этом уровне игрок видит только соседние с собой клетки. Нужно просто при рисовании стены посчитать расстояние игрока до стены, и если оно больше одного, то не рисовать стену:

:
2dup player-y @ - abs swap player-x @ - abs max 1 > if drop drop exit then
COLOR 2dup PURPLES GEN[]2 ^ set-color draw-cell-rect
;draw_ #

Уровень-цикл (loop.de)
Тоже уровень в темноте, в котором если ходить по часовой стрелке, то будешь бегать по кругу, а если пойти против часовой стрелки, то прийдёшь к выходу. Реализация простая: описываются при помощи команды «lab» три лабиринта — тот, который изначально, тот, который с циклом, и тот, который с выходом. Изначальный нужен, чтобы закрутить игрока идти по часовой стрелки, его мы устанавливаем в уровне командой «maze!». Остальные два сохраняем в переменные. Вот, например, цикличный лабиринт:

lab
     #######
     #1    #
###### ### #
#      # # #
# ###### # #
# #      # #
# #      # #
# ######## #
#     2    #
############
\lab
  last-lab-x value 1maze-x
  last-lab-y value 1maze-y
  last-lab-maze value 1maze-ptr

На карте есть ячейки 1 и 2. При наступании на 1 включается лабиринт с циклом, при наступании на 2 — лабиринт с выходом. Вот их обработчики:

:noname passed 1maze-x maze-x ! 1maze-y maze-y ! 1maze-ptr maze-ptr ! ;enter_ 1
:noname passed 2maze-x maze-x ! 2maze-y maze-y ! 2maze-ptr maze-ptr ! ;enter_ 2

Проверка видимости сделана так же, как и в dark.de, только расстояние берётся не 1, а 3 ячейки.

Уровень с убегающим выходом (runningexit.de)
Алгоритм убегания выхода простой. Если игрок приблизился на близкое расстояние по обеим координатам, то выход смещается. Выбирается координата, по которой расстояние до игрока больше, после чего выход смещается от игрока по этому направлению. Если это не удаётся (стена), пытаемся сместить выход в перпендикулярном направлении. Поэтому, например, если игрок идёт на выход по узкому коридору, то выход будет убегать по этому коридору от игрока, и свернёт в бок, как только упрётся в стену. Там используется событие after-update для всех этих расчётов и рендера выхода (рендер сделан отдельный, потому что выход при смещении с ячейки на ячейку должен смещаться плавно). Когда выход смещается, в лабиринте перезаписывается его расположение, поэтому событие попадания в выход обрабатывается корректно обычным образом.

Уровень с двигающимися стенами (movingwalls.de)
Идея аналогична уровню-циклу. Я создал два лабиринта: главный прямоугольник с выходом, и лабиринт со штуковиной. И сохранил его в переменные (moving-x, moving-y, moving-ptr). Далее, я переопределил события рендера и входа для пробела:

: draw#brown COLOR 2dup BROWNS GEN[]2 ^ set-color draw-cell-rect ;
:noname 2dup moving-x * + player-y @ + cells moving-ptr + @
35 = if draw#brown else 2drop then ;draw_
:noname 2dup moving-x * + player-y @ + cells moving-ptr + @
35 = if 2drop else passed then ;enter_

(Там в конце, каждого определения должно быть по два пробела.) Число 35 — это ascii код для символа решётки (который я получил при помощи команды «ga» в виме). Тут всё просто: чтобы определить нужно ли рисовать на пустом месте что-то, берётся значение из вспомогательного лабиринта со штуковиной, с прибавлением y-координаты игрока.

Заключение
В целом, разрабатывать игру мне очень понравилось.

Разработка игры длилась суммарно около 10ти дней, большинство из которых я ещё и ходил на работу. При этом первая половина этого времени была потрачена на написание основного функционала, а вторая — на придумывание и реализацию уровней.

m4: временные макросы

2011-06-15T02:55:00.001+04:00

Часто при использовании m4 может возникнуть необходимость использования локальных определений. Например, в случае языка разметки часто нужно оформлять какие-то списки. Списки бывают разных типов — по оформлению: нумерованный, с кружочками; по применению: оглавление, список литературы. И хочется иметь возможность быстро сменять один тип на другой, т.е. было бы удобно записывать как-то так:

LIST(
 ITEM(Ананас)
 ITEM(Банан)
 ITEM(Кокос))
REFERENCES(
 ITEM(Энциклопедический словарь Брокгауза и Ефрона: В 86 томах (82 т. и 4 доп.). — СПб.: 1890—1907.)
 ITEM(Перевод главы о бананах из книги Julia F. Morton «Fruits of Warm Climates» 1987)
 ITEM(Кокосовая пальма — статья из Большой советской энциклопедии))

Здесь в обоих конструкциях используется макрос ITEM, но в разных смыслах: в первом случае он будет раскрыт в нумерованный элемент, во втором — в элемент списка литературы.

Однако, подобный синтаксис реализовать в m4 невозможно. В любых конструкциях сперва вычисляются аргументы (т.е. ITEM'ы), и только после этого вызываются макросы, в которые эти аргументы передаются, т.е. в LIST и REFERENCES. Поэтому LIST и REFERENCES не могут никак повлиять на то, как будут вычисляться ITEM'ы. Как можно было бы обойти это ограничение? Самый простой способ — отказаться от локальных объявлений, а сделать глобальные, но с разными именами:
LIST(
 ITEM(Ананас)
 ITEM(Банан)
 ITEM(Кокос))
REFERENCES(
 RITEM(Энциклопедический словарь Брокгауза и Ефрона: В 86 томах (82 т. и 4 доп.). — СПб.: 1890—1907.)
 RITEM(Перевод главы о бананах из книги Julia F. Morton «Fruits of Warm Climates» 1987)
 RITEM(Кокосовая пальма — статья из Большой советской энциклопедии))

Этот метод не очень красив, не очень удобен, и может привести к трудностям, если требуется делать вложенные списки. Вместо этого способа мне больше нравится разделение LIST и REFERENCES на открывающий и закрывающий макросы:

LIST
 ITEM(Ананас)
 ITEM(Банан)
 ITEM(Кокос)
_LIST
REFERENCES
 ITEM(Энциклопедический словарь Брокгауза и Ефрона: В 86 томах (82 т. и 4 доп.). — СПб.: 1890—1907.)
 ITEM(Перевод главы о бананах из книги Julia F. Morton «Fruits of Warm Climates» 1987)
 ITEM(Кокосовая пальма — статья из Большой советской энциклопедии)
_REFERENCES

Теперь уже можно внутри REFERENCES ввести своё собственное объявление ITEM'а, а внутри _REFERENCES восстановить старое.

Создание временных макросов в m4 имеет несколько тонкостей. Во-первых, вместо обычного define следует использовать пару pushdef и popdef. Первый макрос определяет новый макрос, сохраняя все предыдущие, popdef удаляет последнее определение, восстанавливая предыдущие.

Во-вторых связано с использованием локальных переменных: если записать
define(`LIST', `<OL>pushdef(`ITEM', `<LI>$*</LI>')')
то вместо $* будет подставлен параметр макроса LIST, а не макроса ITEM. Более того, даже если заключить параметр в сколь угодно большое кол-во символов цитирования, всё равно оно будет считаться параметром макроса LIST. Я придумал решение, быть может не очень красивое, но рабочее: нужно сгенерировать текст «$*» вычислением, самый простой способ — конкатенация:
define(`CONCAT', `$1$2')
define(`_DS', `CONCAT($,*)')
define(`LIST', `<OL>pushdef(`ITEM', `<LI>_DS</LI>')')
define(`_LIST', `popdef(`ITEM')</OL>')
(DS — аббревиатура для Dollar Star).

Можно аналогичным образом определить макросы _D1, _D2, ..., _D9 для, соответственно, $1, $2, ..., $9.

Ещё есть красивое решение, которое заключается в написании макросов _S, _1, _2, ..., _9, которые заменяются на, соответственно, *, 1, 2, ..., 9. Тогда «локальные параметры» подмакросов можно будет записывать как $_S, $_1, $_2, ..., $_9.

Составные конструкции можно ещё усовершенствовать: вместо пар LIST/_LIST, REFERENCES/_REFERENCES можно задавать всего по одному макросу LIST и REFERENCES, внутри которых будет определяться макрос END, определённый аналогичным ITEM'у способом. Этот способ реализован в моём языке разметок, в файлах util.m4 и html.m4 (см. списки и таблицы). В файле examples.m4 можно посмотреть примеры использования всего этого, а в файле examples.html то, что из этого сгенерировано: как видно, все списки и таблицы благополучно раскрываются в то, что нужно.

Починил каты

2011-06-14T12:55:00.004+04:00

Напомню, что когда-то я настроил в блоге каты, а когда сменил дизайн, они сломались: даже если пост не содержит ката, то на странице со списком всё равно писалось «Читать дальше......».

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

Менеджер памяти

2011-06-14T11:57:00.003+04:00

Известно, что если передавать паскалевские строки в/из длл, и ни в чём себя не ограничивать, то прога может упасть. Поэтому при взаимодействии с длл большинство использует строки в стиле Си.

Наткнулся на забавную статью, предлагающую решение проблемы в случае, если и прога, и длл пишутся вместе. Автор утверждает, что если и у длл, и у программмы установить один менеджер памяти, то проблем не будет. Это стоит ещё проверить, но звучит правдоподобно.

DEmbro: классы для исходного кода

2011-06-14T04:31:00.003+04:00

Выносил из центрального объекта обработку исходного кода. Перемудрил с архитектурой. С первого раза написать хороший код не получилось, вышла большая каша, желание переделывать которую не было. Писать другие части DEmbro не представлялось возможным без этого, поэтому почти полтора месяца (!) я был деморализован и боялся всё переписывать. Недавно, наконец, нашёл в себе силы и осуществил задуманное.

Я думал, что в коде очень много связности и потребуется долгое переписывание под новую архитектуру, но это оказалось не так, и всё очень быстро встроилось.

Теперь о самом исходном коде. Его обработка в DEmbro крайне проста: исходный код просматривается в один проход, за время которого часть его сразу исполняется, а часть преобразуется в шитый код, который можно будет выполнить позже. Т.е. никакого препроцессинга, лексического, синтаксического или семантического анализа нету, поэтому весь исходный код хранить целиком в оперативной памяти во многих случаях не нужно.

За время этого прохода необходимо всего несколько операций: прочитать следующий символ входного потока, прочитать следующее слово (последовательность символов без пробелов) и прочитать всё до определённого ограничителя (например, комментарий пропускает все символы до заданного ограничителя). Возможно, что будут и другие операции, но эти — основные. Написание классов, отвечающих за это, и вынесение в них функционала по обработке исходников, и было одной из задач рефакторинга.

Самый главный класс — TSource, отвечает за промежуточное хранение исходного кода (последовательности символов) в оперативной памяти, и делегирует выполнение операций с исходным кодом вспомогательным классам. Пока что исходный код хранится только в памяти, и поэтому TSource может хранить в буфере его целиком, но в будущем будет возможность получать исходники и из других мест: из файла, из произвольного потока, по сети и т.д. Идея этого заключается в том, что так как нам не нужно хранить весь исходный код целиком в оперативке, а нужен только небольшой фрагмент, то разумно этим воспользоваться и в качестве бонуса получить малое потребление оперативной памяти. Кроме того, пользуясь особенностями конкретных источников исходника, можно оптимизировать чтение и выиграть в скорости (например, если исходный код приходит по сети, то можно выполнять по мере поступления приходящие куски). Кроме того, TSource должен хранить название источника кода (имя файла, например).

У этого класса есть два вспомогательных — TSpaceSkipper и TNameReader. Первый, как нетрудно догадаться, нужен для того, чтобы пропускать пробелы. Пока что пробелами считаются символы в диапазоне от 0 до 32, но при необходимости можно будет унаследовать своё поведение. Кроме того, в TSpaceSkipper можно будет добавить функциональность по подсчёту числа пробелов, и этим воспользоваться в DEmbro (например, в языке программирования питон для выделение блоков вместо ограничителей begin...end или {...} используются отступы — что достаточно удобно и наглядно. При записывании уровня игры символами в виде псевдографики проще пользоваться пробелами, чем какими-то другими символами). TNameReader, в свою очередь, читает имена. В имя могут входить только символы не из диапазона от 0 до 32, но можно будет унаследовать класс, который, например, будет воспринимать слова с пробелами, если слово заключено в одинарные кавычки.

Наконец, есть дополнительный класс — TLineReader. Он выделяет строки, считает номер текущей строки, и позицию в строке. Если это нужно, конечно, — класс можно будет отключить для ускорения работы.

Вроде как получилось расширяемо и ортогонально, но немного муторно.

m4: Универсальный язык разметок

2011-06-02T02:52:00.010+04:00

Этот пост — небольшая обучалка по m4. Как мне кажется, приведённый ниже пример
хорошо иллюстрирует некоторые базовые принципы использования m4.

Я весьма часто пишу тексты, и для разметки приходится использовать довольно разный
синтаксис: то html, то LaTex, то google wiki, то bbCode (upd ещё vkontakte разметку бывает
приходится использовать). Даже html бывает разного вида (например, некоторые блоги
сами вставляют тег br в конце каждой строки).

Запомнить и набить руку на все эти варианты быстро не получается, да и не особо
хочется, поэтому приходится постоянно лезть в документации и вспоминать как
что-то делается. А хочется иметь какой-то единый синтаксис на все случаи
жизни. Во-первых, тогда можно будет изучить только его. А, во-вторых, написанный
текст можно будет конвертировать сразу в несколько выходных форматов.

Для обеспечения единого синтаксиса я решил воспользоваться m4, а именно:
текст будет писаться с использованием макросов, а в зависимости от того
какой выходной файл нужно будет получить, эти макросы будут по разному
раскрываться.

Рассмотрим это на примере HTML и LaTeX. Я создал два файла: html.m4 и tex.m4.
Когда требуется из файла изготовить текст на HTML, то следует вызывать
m4 html.m4 file.m4 > file.html
Если же требуется получить LaTeX, то нужно вызывать
m4 tex.m4 file.m4 > file.tex

Этот вызов сначала выполнит html.m4 или tex.m4, потом file.m4, сольёт результат вместе и
запишет в file.out. При этом в файлах html.m4 и tex.m4 находится исключительно служебная
информация, и мы не хотим, чтобы из них что-то печаталось. Поэтому в начало
каждого такого файла добавляется строка
divert(-1)
которая весь дальнейший вывод выбрасывает, а в конце файла пишем
divert
после чего вывод будет происходить нормально.

Приступим, наконец, к написанию макросов. Самое простое — перевод строки.
html.m4:
define(`BR', ` ')
tex.m4:
define(`BR',`\\')

Я решил, что все макросы будут писаться большими буквами, чтобы было по-меньше
конфликтов имён.

Перейдём к более сложному макросу: жирный шрифт. Использование такого макроса
будет выглядеть примерно так: BOLD(жирный шрифт). Для реализации нужно
в теле макроса написать $* — вместо него будет подставлено всё, что находится
между скобочек:
html.m4:
define(`BOLD', `$*')
tex.m4:
define(`BOLD', `\textbf{$*}')

Далее, запись списков. Я выбрал такой синтаксис:
LIST(
 ITEM(Ананас)
 ITEM(Манго)
 ITEM(Кокос)
)

Оно создаст соответствующий нумерованный список. Реализация:
html.m4:
define(`LIST',`<OL>$*</OL>')
define(`ITEM',`<LI>$*</LI>')
tex.m4:
define('LIST', `\begin{enumerate}$*\end{enumerate}')
define('ITEM', `\item $*')

Перейдём к более сложному примеру: ссылки. Ссылки уже требуют двух параметров:
куда ссылается и что отображается. Для получения отдельных параметров вместо $*
следует использовать $1, $2, и т.д. Поэтому реализацию ссылки можно бы было
записать так:
define(`LINK', `<a href="$1">$2</a>')

Но эта конструкция имеет проблему: если написать
LINK(google.com, Используй гугл перед тем, как задать вопрос, пожалуйста)
то m4 будет думать, что тут четыре параметра, и второй — «Используй гугл перед тем»,
а не вся фраза целиком. Для решения проблемы следует использовать макрос «shift»:
он возвращает все свои параметры, кроме первого.
html.m4
define(`LINK', `<a href="$1">shift($*)</a>')
tex.m4
define(`LINK', `\href{shift($*)}{$1}')

Теперь указанный выше пример сработает корректно.

Далее — дело техники, уже перечисленного достаточно для реализации многого.
В случае, если при наборе какого-то текста критично то, что макросы для разметки слишком длинные, то легко можно вставить где-то в тексте строки вида:
define(`B',`BOLD')
и использовать краткие варианты макросов, ничего при этом не потеряв.

Вот мои файлы: html.m4 и tex.m4. Пока что они не полные и скорее полигон для экспериментов, чем что-то, что я использую в боевых условиях, но со временем эти файлы будут пополняться и совершенствоваться.

Реализация полиморфизма

2011-05-26T04:47:00.001+04:00

Наткнулся на статью C++ всегда быстрее Smalltalk?, в которой в частности утверждается:

«<…> в C++ виртуальные вызовы происходят косвенным образом через таблицу диспетчеризации виртуальных методов. А, как известно, косвенный вызов является очень дорогостоящим на нынешнем поколении процессоров.

В динамических языках, в которых полиморфизм не привязан к иерархии классов/интерфейсов, реализация полиморфного вызова осуществляется совершенно другим образом, намного более эффективным.»

Мне вот теперь интересно, что это за более эффективные реализации, ибо в голову совершенно не приходит никаких идей.

Метапаскаль: dquotes

2011-05-19T02:33:00.003+04:00

Т.к. программировать на паскале приходится часто, чтобы автоматизировать многие вещи я решил по полной задействовать m4.

Метапаскаль (выдуманный мною термин) — это псевдоязык, компиляция исходников которого происходит в два шага: сначала применяется m4, потом fpc. Причём изначально доступно множество макросов, упрощающих жизнь, и меняющих программирования до неузнаваемости (к примеру, будут макросы для описания классов, методов). Сегодня я занимался «лексической частью» метапаскаля.

Использование m4 с паскалем имеет серьёзную проблему: ограничитель ' (апостроф) используется в m4 для ограничения цитат, и любая строковая константа паскаля сбивает его с толку.

Их можно поменять, но подобрать другие удобные символы для m4 мне не удалось (нужно два различных ограничителя слева и справа, по умолчанию используются ` и '). Кроме того, стандартный (и немаленький) комплект библиотек для m4 написан с использованием ` и '.

Поэтому я решил, что нужно в коде на паскале использовать для строковых констант " вместо ', а перед самой компиляцией конвертировать в исходниках двойную кавычку на одинарную. Собственно, это и делает написанная мною небольшая утилита dquotes.

Она содержит множество параметров на многие случаи жизнь. Например, такой вызов
dquotes -r .\ D*.pasq *.pas
рекурсивно обходит все файлы, начиная с текущей директории, и файлы с названием, начинающимся на D и расширением .pasq сконвертирует и сохранит в файл с таким же названием, но расширением .pas

Можно организовать и обратное преобразование:
dquotes -qq -aq -r .\ D*.pas *.pasq

Из того, что ещё предстоит сделать: обработка стандартных ввода и вывода (для организации цепочки вычислений наподобии «m4 file.pas4 | dquotes -i > file.pas»).

В качестве бонуса, утилитка позволяет задать преобразование любого символа в любой другой, задав их хекс-коды. Поэтому попутно можно решить ещё одну проблему: символ $ (доллар) используется в m4 для получения параметров, и конфликтует с $ из паскаля. Поэтому я решил, что хекс-константы в метапаскале будут записываться начиная с &, а при помощи dquotes конвертироваться в стандартные, начинающиеся с $.

DEmbro: разнесение команд по файлам

2011-05-05T01:19:00.003+04:00

Вынес команды из центрального файла в тематические. Но кодить теперь, возможно, станет сложнее: если раньше нужную команду я искал в одном файле, то теперь таких файлов 25, и команды распределены весьма условно (не всегда ясно к какой именно категории отнести команду).

Начинаю разбивать монолитную DEmbro-машину на классы.

DEmbro: начало глобального рефакторинга

2011-05-03T01:33:00.005+04:00

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

Весь код ядра практически находится в одном файле, содержащем 6600+ строк. После раскрытия макросов при помощи m4 получается 12400+ строк чистого паскаля, некоторые из которых напоминают спрессованный мусор:

     procedure uint64_divmod (Machine: TForthMachine; Command: PForthCommand); begin with Machine^ do begin TUInt64((Pointer(TUInt(Machine.WP) + (0))^)) := TUInt64((Pointer(TUInt(Machine.WP) + (-2*SizeOf(TUInt64)))^)) mod TUInt64((Pointer(TUInt(Machine.WP) + (-SizeOf(TUInt64)))^));
                                                     TUInt64((Pointer(TUInt(Machine.WP) + (-2*SizeOf(TUInt64)))^)) := TUInt64((Pointer(TUInt(Machine.WP) + (-2*SizeOf(TUInt64)))^)) div TUInt64((Pointer(TUInt(Machine.WP) + (-SizeOf(TUInt64)))^));

                                                     TUInt64((Pointer(TUInt(Machine.WP) + (-  SizeOf(TUInt64)))^)) := TUInt64((Pointer(TUInt(Machine.WP) + (0))^));
                                                end; end;
     procedure uint64_shl (Machine: TForthMachine; Command: PForthCommand); begin with Machine^ do begin Dec(WP, SizeOf(TUInt64));
                    TUInt64((Pointer(TUInt(Machine.WP) + (-SizeOf(TUInt64)))^)) := TUInt64((Pointer(TUInt(Machine.WP) + (-SizeOf(TUInt64)))^)) shl TUInt64((Pointer(TUInt(Machine.WP) + (0))^))  end; end;

Я уже достаточно многое понял, и потому назрел глобальный рефакторинг. Первое, что я сделал, -- вынес из этого файла некоторые реализации команд DEmbro, раскидав их по тематическим файлам (20 получилось пока что). В результате число строк в файле удалось сократить с 6600+ до 3900+. После раскрытия макросов размер не сильно изменился, потому что я выносил команды, слабо использующие макросы.

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

m4: добавление префиксов и автогенерация setter/getter методов

2011-04-10T23:39:00.004+04:00

Часто в программе к некоторым переменным класса удобно выдать прямой доступ (только на чтение или и на чтение, и на запись). Если в языке нет механизма для автоматической генерации такого доступа, то приходится писать getter и setter методы, которые обеспечивают доступ к переменной.
public class Student {
    private String name ;
    public String getName() {
      return name;
    }

    protected int age = 18;
    public int getAge() {
      return age;
    }

    protected CatOrDogName favoriteCatOrDog ;
    public CatOrDogName getFavoriteCatOrDog() {
      return favoriteCatOrDog;
    }
    public void setFavoriteCatOrDog(CatOrDogName newFavoriteCatOrDog) {
      favoriteCatOrDog = newFavoriteCatOrDog;
    }

}

Писать для всех переменных такие getter/setter методы может быть весьма утомительно. Предлагаю решение для автоматизации этого процесса при помощи макропроцессора m4.

Первое, что нужно сделать, — написать макрос для добавления префиксов к идентификатору. Поля и методы в данном случае именуются слитными фразами, первое слово пишется маленькими буквами, у каждого следующего заглавная только первая буква. Чтобы к такому идентификатору добавить префикс, нужно поднять первую букву и сложить две строки.

Объявим макрос для сложения двух его параметров:
define(`CONCAT', `$1$2')

Тут всё предельно просто — возвращаем первый и второй параметры, пристыкованные вместе. Теперь напишем макрос для поднятия всех символов в строке. Для этого я задействую макрос translit. В качестве первого параметра он принимает строку, в качестве второго параметра — набор символов, и в качестве третьего параметра — ещё один набор символов. Каждый встреченный в строке символ из первого набора будет заменён на соответствующий символ из второго набора. Наборы можно указывать разными способами, я не особо в них вникал, а воспользовался примерами из документации. Наш макрос будет выглядеть так:

define(`UPCASE', `translit($1, `a-z', `A-Z')')

Теперь напишем макрос, который поднимает только первый символ входящего параметра. Для этого задействуем ещё три макроса: len(s) возвращает длину переданной строки, substr(s, first, count) извлекает из строки фрагмент длиной count, начинающийся с символа номер first (нумерация символов с нуля), и, наконец, eval вычисляет арифметическое выражение.
define(`FIRSTUP',   `CONCAT(UPCASE(substr($1,0,1)),
                            substr($1,1,eval(len($1) - 1)))')

Например, если теперь написать
FIRSTUP(veryLongName)
, то оно будет заменено на
VeryLongName

Осталось совсем немного для макроса, добавляющего префикс:
define(`ADDPREFIX', `CONCAT($1,FIRSTUP($2))')

Теперь перейдём к основной задаче. Я решил ввести следующие макросы:
PRIVATE(type, name, after) — поле приватное, для него определяется публичный геттер
PROTECTED(type, name, after) — доступ к полю наследуется, для него определяется публичный геттер
PUBLIC(type, name, after) — доступ к полю наследуется (но не публичен), для него определяются публичные геттер и сеттер.

Третий параметр after всех этих макросов нужен для написания явной инициализации полей. Реализация этих макросов технически проста:

define(`PRIVATE',
`  private $1 $2 $3;
    public $1 ADDPREFIX(`get', $2)() {
      return $2;
    }
')
define(`PROTECTED',
`  protected $1 $2 $3;
    public $1 ADDPREFIX(`get', $2)() {
      return $2;
    }
')
define(`PUBLIC',
`  protected $1 $2 $3;
    public $1 ADDPREFIX(`get', $2)() {
      return $2;
    }
    public void ADDPREFIX(`set', $2)($1 ADDPREFIX(`new', $2)) {
      $2 = ADDPREFIX(`new', $2);
    }
')

Самый первый пример в этом посте теперь можно сгенерировать следующим кодом:

public class Student {
  PRIVATE(String, name)
  PROTECTED(int, age, = 18)
  PUBLIC(CatOrDogName, favoriteCatOrDog)
}

Для красоты макросы PRIVATE, PROTECTED и PUBLIC я записал в несколько строк. Однако, на практике бывает полезно, чтобы компилятор выдавал строку с ошибкой в изначальном файле (а не в сгенерированном), для этого полезно записать определение этих макросов в одну строку.

Оператор switch

2011-04-06T13:00:00.004+04:00

Добавил оператор switch. До сих пор, правда, был лишь один случай, когда он был нужен (обработка windows-сообщений).

Трудно писать документацию на команды (вообще и на switch в частности). Не лениво, а непонятно как. Я без проблем могу объяснять как это использовать на практике, но что это и как это устроено, описать в несколько понятных абзацев не получается. А это в документации нужно описать.

Локальные переменные

2011-04-06T12:33:00.005+04:00

Вчера исправил баг в ядре, который мешал в полной мере заработать
локальным переменным.

Простые локальные переменные (типы int, uint, bool, ptr) объявляются так
(внутри команды):
| l1 l2 ... ln|
Они сразу снимают со стека начальные значения, к примеру после
1 2 3 | i j k|
в i окажется значение 1, в j окажется значение 2, в k окажется значение 3.

Чтение/запись переменных стилизовано под классический фортовский стиль. Если
name — название локальной переменной, то для неё определяются следующие команды

name@ — прочитать значение переменной, положить его на стек
name! — записать в name значение со стека

Помимо этих двух примитивных операций, определяются следующие сахарные:

name1+ — увеличить значение name на 1
name1- — уменьшить значение name на 1
name++ — положить значение name на стек и увеличить name на 1
++name — увеличить name на 1 и положить результат на стек
name-- — положить значение name на стек и уменьшить name на 1
--name — уменьшить name на 1 и положить результат на стек
name+ — прибавить name к вершине стека
name- — вычесть name из вершины стека
name* — умножить вершину стека на name
name+! — прибавить к переменной name значение с вершины стека
name-! — вычесть из вершины стека name и положить результат в name
name*! — умножить name на значение с вершины стека

Можно при необходимости добавить собственные операции с локальными переменными,
изменив по стандартной схеме файл, в котором локальные переменные реализованы.
Планируются и другие конструкции локальных переменных (для строк, для классов).

Несколько примеров использования локальных переменных:
// Функция Result = (a + b) * (b + c) * (c + a)
: func | a b c| a@ b+ b@ c+ c@ a+ * * ;
// Команда, печатающая числа от 100 до 1
: test 101 | i| begin --i while i@ . repeat ;

Контекстные параметры

2011-04-02T00:11:00.002+04:00

Часто в программе существуют объекты-менеджеры. Например, гуи-менеджер — объект,
при помощи которого осуществляется управление кнопками, окошками, полями ввода
и т.д. Чтобы создать кнопку, нужно указать в каком именно гуи-менеджере создаём.
Чтобы установить кнопке стиль, нужно этот стиль получить из гуи-менеджера.
  Button := GuiManager.CreateButton;
  Button.SetStyle(GuiManager.GetStyle('glamur'));
При этом в 99% программ название переменной (или свойства), содержащей ссылку на
менеджера, будет называться именно GuiManager.

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

Самое тупое решение — создать глобальную переменную GuiManager и пусть к ней
обращаются функции CreateButton, GetStyle и прочие. А что если в программе
нужно работать с несколькими менеджерами? Нужно просто в нужные моменты
менять значение глобальной переменной. Что делать, если нужно работать с
разными менеджерами из разных потоков? Переписать GuiManager с глобальной
переменной под зависящую от потока.

Хоть этот метод и решает поставленную задачу, он мне не нравится. Вместо него
напрашивается концепция «контекстных параметров». Её мне не удалось реализовать
на паскале, но я надеюсь, что получится реализовать в Lisp'е и DEmbro.

Идея вот в чём: у функции мы выделяем некоторый набор параметров и объявляем их
контекстными. Например:
  function CreateButton(context GuiManager: TGuiManager): TGuiButton;
Здесь мы указали, что параметр GuiManager контекстный. От этого мы не теряем
возможностей, функцию можно вызвать обычным образом:
  Button := CreateButton(GuiManager);
при этом выполнится она так же, как и обычная функция.

Отличие заключается в возможности опустить передачу параметра:
  Button := CreateButton();
При этом компилятор автоматически подставит GuiManager внутрь, обратившись
к идентификатору в текущей области видимости. Т.е.

  procedure DoSomething(GuiManager: TGuiManager);
    procedure DoSomethingDeep;
    var
      GuiManager: TGuiManager;
    begin
      Button := CreateButton(); // в CreateButton передастся локальная переменная
                                // функции DoSomethingDeep
    end;
  begin
    Button := CreateButton(); // в CreateButton передастся параметр
                              // функции DoSomething
  end;

Может даже так получится, что GuiManager — это функция, сама содержащая
контекстный параметр:
  var
    App: TApp;

  function GuiManager(context App: TApp): TGuiManager;
  begin
    Result := App.GuiManager;
  end;

  ....

  Button := CreateButton(); // эквивалентно CreateButton(GuiManager(App))

Теперь несколько слов о возможном синтаксисе в паскаль-семействе. Контекстные
параметры поведением очень похожи на параметры со значением по умолчанию. Чтобы
подчеркнуть это, возможно, что имеет смысл заменить синтаксис, использованный выше, на
такой:
  function CreateButton(GuiManager: TGuiManager = context): TGuiButton;

SetPixelFormat 3221684230

2011-03-30T07:12:00.003+04:00

Пытаюсь написать на DEmbro OpenGL-приложение.

Функция SetPixelFormat возвращает ошибку, GetLastError сообщет, что это ошибка C0070006 (или 3221684230 в decimal), а после чтения форумов узнал, что эта ошибка возникает в системе с nVidia видеокартой, если handle окна не принадлежит процессу (или процесс не имеет должных прав).

Это весьма печально, потому что я не понимаю, почему так должно получаться. Если написать на паскале соответствующий код, то всё будет нормально. Код на DEmbro ничем особым с точки зрения системы отличаться не должен. Единственное отличие -- то, что вызов системных функций происходит из асм кода, и тут что-то могло всплыть с правами, но эта теория выглядит не убедительно.

Самое обидное, что эта ошибка возникает именно в OpenGL и именно с nVidia-видеокартой. Т.е. если бы я использовал DirectX или ATI-видеокарту, то такой ошибки не возникло бы.

[UPDATE] Ура, справился с этим. Всегда так получается, что пока я наедине с собой ищу ошибку несколько часов, ничего не выходит. Как только опишу её кому-то — сразу осеняет и проблема решается. Пора спать.

DEmbro: документация, плавающая точка, и конфигурируемость

2011-03-20T19:34:00.001+03:00

Написал программу, генерирующую хелп в вики из документации в исходниках. Теперь
я могу прямо под функцией в коде описать что она делает, и потом документация
на неё автоматически может быть сгенерирвана в нужный формат. В дальнейшем можно
будет писать документации сразу на нескольких языках.

Пока что с самой документацией бардка, не успел ещё всё оформить.

Решил, что для чисел с плавающей точкой тоже, как и строкам, нужен отдельный стек.
В качестве этого отдельного стека я выбрал стек сопроцессора — получилось так,
программирование плавающих вычислений на DEmbro почти эквивалентно программированию
на ассемблере. Может показаться, что это как-то что-то усложняет, но это не так —
ассемблер сопроцессора очень гармонично вписывается в стековый стиль
программирования на DEmbro.

Осуществил свою главную задумку: теперь при создании DEmbro-машины доступно около
четырёх команд. Две из них служат для того, чтобы подключить остальные встроенные
команды. Это позволяет программисту самому решить какое подмножество команд DEmbro
выбрать для программирования. По умолчанию подключается файл «system.de», который
подключает весь функционал ядра.

Образцовым теперь выглядит файл для плавающих вычислений — он подключает команды
ядра, тут же содержит документацию на эти команды (не на все, но это вопрос
времени), и реализует недостающие полезные команды.

Простейшие примеры работы со строками

2011-03-01T21:03:00.005+03:00

Всё перечисленное уже работает, за исключением unicode->cp1251.

" expe" " rience" str+ // сложили две строки, получили experience
2 4 str-cut // оставили четыре символа, начиная со второго, получили peri (нумерация с нуля)
bdup str+ // сложили строку с самой собой, получили periperi
" rip" str^ // определяем символ, начиная с которого идёт первое вхождение rip в строке, получаем число 2
str# // узнали длину строки rip, т.е. 3
// Итого, на обычном стеке: 2 3
// На стеке строк: " periperi" " rip"
bdrop // скидывем строку rip со стека
str-del // удаляем три символа, начиная со второго, получаем peeri
utf8->unicode unicode->cp1251 // перекодировываем строку из utf8 в cp1251
" peeri" str= // проверяем равны ли строки, в данном случае получаем true
." Hello world!"cr // печатаем на консоль строку

DEmbro: стек блоков (для строк)

2011-02-28T04:23:00.006+03:00

24 дня (почти месяц) DEmbro был в ауте в связи с глобальным переписыванием ядра для поддержки отдельного стека для строк. Переписывание закончено, и теперь, фактически, получился немного другой язык.

Необходимость отдельного стека исходила из двух желаний
1) Сделать поддержку человечных строк (т.е. чтобы не нужно было заморачиваться с ручным отслеживанием за выделенной памятью, как в случае со строками с завершающим нулём), и можно было бы делать со строками всё что угодно: складывать, искать подстроки, вырезать участки и т.д.
2) Сохранить приличную скорость, характерную статически типизируемым языкам.

До недавнего времени я хранил строки в одном стеке с числами и указателями. Чтобы при копировании строк не копировать все символы (что является ИМХО не лучшей идеей, т.к. строка может занимать память неограниченно большого размера), в строке хранится счётчик ссылок на неё. Как только счётчик обнуляется, строка освобождается.

И тут начинается много проблем. Одна из самых существенных — при перехвате исключения, когда стек возвращается к некоторому исходному состоянию, нет возможности отследить где на стеке строки, а где числа (типы элементов стека нигде не хранятся, иначе это замедлило бы работу). Строки утекут, написать корректные исключения не представляется возможным.

С отдельным стеком эта проблема решается легко: нужно при срабатывании исключения откатить строковый стек, скинув у каждой лишней строки ссылку. Кроме того, в качестве бонуса, с новым стеком код стал заметно проще: существенно сократилось число манипуляций с основным стеком.

Кстати говоря, в этом же стеке будут находиться не только строки, но и любые другие элементарные типы переменной длины: длинные числа, например.

Из других нововведений появились:
1) Поддержка пространств имён (namespaces)
http://code.google.com/p/dforth/source/browse/trunk/release/units/core/voc.de#9
2) Возможность написания документации к командам непосредственно в исходном коде при помощи ключевых слов summary и detail:
http://code.google.com/p/dforth/source/browse/trunk/release/units/utils/parser.de
В REPL режиме на основе этого можно запрашивать инфу о командах при помощи вызова «help command», а в дальнейшем из этих же данных будет генерироваться документация в вики. Планируется сделать поддержку возможности написания документации на нескольких языках (что необходимо как минимум для функций из rtl).
http://code.google.com/p/dforth/source/browse/trunk/release/units/core/help.de#38
3) Поддержка строк произвольной кодировки, для этого строка может быть в одном из трёх состояний: ansi/wide/unicode.

Кодировки в названиях файлов

2011-02-15T02:54:00.000+03:00

Допустим, что в папке большое число файлов в неправильной кодировке, и вам нужно
найти какой-то файл. (Например, с такой проблемой вы столкнулись в папке
с фильмами в локальной сети.)

В уме догадываться как что называется — не вариант. Можно воспользоваться
командой dir: набираем
dir путь_до_папки > имя_какого-то_файла

Например:
dir \\172.16.0.22\Video\Films\ > d:\films.txt

После выполнения этой команды в файле films.txt окажется список всех файлов, а
его уже можно переконвертировать в своём любимом редакторе в нужную кодировку.

Callbacks в DEmbro

2011-01-02T18:26:00.003+03:00

Отлаживал последние полмесяца с перерывом на зачётную сессию возможность создания в программе на DEmbro коллбэков, т.е. функций, которые можно передавать во внешний мир. Пока что узкий круг функций (stdcall, каждый параметр и возвращаемое значение занимают 4 байта), но зато поддерживается, ура!

Проделана большая работа. Т.е. «функции» DEmbro несовместимы с обычными функциями в системе, для их поддержки требуется генерировать на лету машинный код-переходник, который перекладывает с системного стека параметры на стек параметров DEmbro. Очень много времени я потратил в Hex-редакторе, отлаживая генерируемый машинный код, теперь в нём даже немного могу увидеть ассемблерный код и отличаю «8b» от «b8».

Результатом этого стала программа, благополучно создающая окно в винде на чистом WinApi. Это означает, что уже возможно писать WinApi, OpenGL и прочие, не требующие каких-то сложных спец. возможностей, приложения.

Кодировки в vim'е (в том числе koi8-r для windows)

2010-12-18T04:42:00.007+03:00

Часто приходится сталкиваться с файлами в разных кодировках.

Если Вы открыли файл в виме и увидели вместо русских букв закорючки,
то скорее всего файл отображается в неверной кодировке. Чтобы вручную
выставить кодировку, следует набрать
:e ++enc=название_кодировки
Вот некоторые из возможных кодировок для кириллицы:

cp688 — основная DOS-кодировка
cp1251 — основная Windows-кодировка
utf-8 — UTF8-кодировка
koi8-r — основная Linux-кодировка

Более полный список см. «:help encoding-names».

Если вы используете windows, то «koi8-r» изначально не поддерживается. Чтобы
исправить это, следует скачать файл «iconv.dll» и кинуть в папку с exe'шником
вима (я качал отсюда).

Предположим другую ситуацию: вам нужно сохранить файл, перекодировав его в
другую кодировку. Для этого можно воспользоваться опцией «fileencoding»:
  :set fileencoding=название_кодировки
или же
  :w ++enc=название_кодировки имя_выходного_файла

Часто приходится работать с разными файлами, и хочется, чтобы
вим пытался при запуске как-то выбрать наиболее подходящую кодировку
из нескольких. Достигается это прописыванием опции «fileencodings» в файле
«.vimrc». К примеру, у меня прописано так:
  set fileencodings=utf-8,cp1251
Это означает, что вим попытается отобразить файл как utf-8, а если не получится,
то отобразит в cp1251.

Узнать список поддерживаемых кодировок можно вызовом
help encoding-names

Подключение библиотек

2010-12-06T15:57:00.001+03:00

Написал в DEmbro поддержку механизма подключения внешних библиотек с защитой от
повторов, оформил это в виде библиотеки :) Сейчас я уже на той стадии, когда
начинаю потихоньку писать RTL со всякими полезными вещами.

Вообще, хочу всё вынести в RTL, и оставить изначально всего одну команлу:
«builtin». Она будет подключать в программу встроенные в язык команды,
например, вот так:
builtin +
builtin -
builtin create

По умолчанию будет загружаться стандартный «system.de» файл, который будет
подключать все встроенные команды. Но их много, поэтому будет возможность написать
свой system.de, содержащий в себе необходимый для поставленной задачи
комплект. Это позволит мне не скупиться на встроенных «быстрых» (на машинных кодах)
командах, а с другой стороны будет возможность убрать всё ненужное.

Hex-константы и хедеры

2010-11-26T04:13:00.010+03:00

Не могу решить какую запись hex-констант на DEmbro выбрать в качестве основной. (Основной, потому что в языке будeт возможность для реализации любого способа.)

Во-первых, что лучше — обозначать hex-константу префиксом или постфиксом? Мне привычней префикс, но это лишь вопрос привычки, зато парсинг немного проще.

Логичней всего использовать букву h (принято в asm'ах, но у них это не префикс, а постфикс):
hFFF1

Однако, есть опасения, что это ненаглядно, и может с непривычки сливаться с другими буквами hex-константы, особенно если писать их в одинаковом регистре.

С++ стиль (префиксные символы 0x перед цифрами)
0xFFF1
неудачен тем, что на него требуется два символа, а хочется задействовать только один.

А Delphi-стиль (префикс $ перед цифрами)
$FFF1
хоть и не очень распространён и не логичен, выглядит наиболее удобным — особый символ, не сливающийся с цифрами.

Пока что я избрал первый вариант, посмотрим приживётся или нет.

Пишу тут заголовок для WinApi windows.de на DEmbro. Из-за многих недоработок языка выглядит непричёсанным, но всё по-взрослому: с переобозначением типов, объявлением констант, объявлением прототипов функций с автоматической их загрузкой в период выполнения (т.е. не при подключении библиотеки, а при вызове функции windows-load этой библиотеки). Когда требуется добавить новую функцию в хедер, достаточно прописать её прототип один раз, не нужно копипастить что-то в стиле
typedef ... (*SomeFunc_t)(....);
...
extern SomeFunc_t SomeFunc;
...
SomeFunc = (SomeFunc_t)GetProcAddress(libuser32, "SomeFunc");

Одна моя мечта сбылась *.* Йииехуууууу!

Разные файлы — разные настройки

2010-11-23T23:02:00.003+03:00

По мере того, как я плотнее программирую на нескольких языках, всё больше становится необходимо задавать под разные типы файлов совершенно разные настройки. Например, сворачивание текста (folding) в исходниках для Free Pascal я оформляю конструкцией REGION (для совместимости с IDE Delphi), а в DEmbro обычным вимовским образом.

Штатный вариант это сделать: поправить файлы filetype-настроек (синтаксиса, компилятора или другие подобные) — но почему-то не хочется в них разбираться, хочется всё просто описать в «.vimrc».

А в «.vimrc» это сделать так просто нельзя: опция filetype будет вычислена уже после выполнения «.vimrc», т.е. в «.vimrc» будет не доступна. А нам нужно внутри «.vimrc» сделать в случае одного filetype одни настройки, а в случае другого filetype — другие.

Один из трюков заключается в следующем: описываем настройки в виде функции:

function DEmbroMarker()
  set fdm=marker
  set commentstring=//%s
  set foldmarker={{{,}}}
endfunction

А потом, в самом конце, прописываем условное действие при запуске всех файлов:

au BufRead,BufNewFile *         if &ft == 'dembro' | call DEmbroMarker() | endif

Аналогично для другого типа файла (в моём случае, для pascal'я).

MessageBox

2010-11-23T03:52:00.002+03:00

Только что моя прога на DEmbro смогла вывести на экран виндовый message box. Доволен как слон.

В целом, темпы очень маленькие, много ленюсь.

Name typization

2010-11-15T11:26:00.007+03:00

Ночью, когда спал, придумал механизм типизированных имён.

Динамическая типизация — это когда переменная может принимать значение любого
типа. Как только с переменной нужно проделать какое-то действие (сложение, например),
интерпретатор узнаёт тип переменной, и в зависимости от этого выбирает операцию.
Это очень удобно, не нужно заботиться о явном указании типа. Но работает медленней.

Статическая типизация — это когда у каждой переменной заранее указывается тип,
и к моменту выполнения операции (сложения, например) понятно что нужно делать.
Но указывать типы переменных нужно везде. Это не очень удобно, и мне всегда
этим не нравилась статическая типизация.

[Upd] Всё, что идёт ниже, про упрощение статической типизации.

Я осознал, что бывают такие переменные, у которых всегда один и тот же тип.
Например, у меня переменные I и J всегда имеют тип Integer, переменные
Name и FileName тип TString, P тип Pointer и т.д. Было бы весьма удобно иметь
возможность указать привязанные к именам типы, чтобы потом их явно не
указывать. Как-то так:

typization I, J, N, M, K: Integer;
typization Name, FileName, Dir: TString;

procedure LoadFilesInDir(Dir);
var
  Files: TArrayOfString;
  I;
begin
  GetFilesInDir(Dir, Files);
  for I := 0 to High(Files) do
    LoadFile(Files[I]);
end;

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

К примеру, в математическом модуле, все переменные с именами M, H, Mat, Matrix будут
являться матрицами, V, A, B, Vec, Vector — векторами, Q, R, Quat и Quaternion —
кватернионами и т.д. Вот было бы хорошо, если бы можно было делать так

typization M, H, Mat, Matrix: TMat4f;
typization V, A, B, Vec, Vector: TVec3f;
typization Q, R, Quat, Quaternion: TQuat;

function Add3f(A, B): TVec3f;
function Dot3f(A, B): TVec3f;
function Cross3f(A, B): TVec3f;
function Len3f(V): Single;

function Apply3f(M, V): TVec3f; overload;
function Apply3f(Q, V): TVec3f; overload;

Возможно, что иногда даже можно бы было не объявлять переменную, компилятор сам
бы создал локальную с таким именем. Например, если в функции используется
переменная I, то скорее всего она локальная и имеет тип Integer (потому что этот
тип указан в typization секции).

procedure LoadFilesInDir(Dir);
var
  Files: TArrayOfString;
begin
  GetFilesInDir(Dir, Files)
  for I := 0 to High(Files) do
    LoadFile(Files[I]);
end;

DForth → DEmbro

2010-10-19T18:59:00.001+04:00

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

Во-первых, я решил переименовать язык с DForth в DEmbro, в связи с тем, что слишком уж много расхождений с обычным фортом.

Во-вторых, открыл отдельный wiki- и svn-сервер под проект.

В-третьих, на днях один мой знакомый изъявил желание помочь с оптимизациями.

Сейчас ведётся активная разработка подключения динамических библиотек (dll в windows'е).

Автоматизация в обычной жизни: исправление субтитров

2010-08-30T04:27:00.002+04:00

В одном из фильмов не загружались субтитры. Решил посмотреть что не так, файл с субтитрами выглядел так

00:01:40.12,00:01:41.34
Dear God

00:01:41.44,00:01:44.15
Cut it off! His arm - cut it off!

00:01:58.92,00:02:00.23
Is he dead?

00:02:00.32,00:02:03.07
- Are you drunk, Mr Price?[br]- I am, I am.

00:02:03.16,00:02:06.35
- Is he dead, the Colonel?[br]- Not dead yet. He has hope.

00:02:06.44,00:02:09.43
Hey! You two. Get him back. Back!

00:02:11.32,00:02:14.91
We're in! Do you hear? They cheer!

00:02:15.00,00:02:16.95
Cuidad Rodrigo is taken

00:02:17.04,00:02:19.63
Oh. He looks dead to me.
...

А чтобы субтитры прочитались в моём плеере (GOMPlayer), он должен был выглядеть так:

0
00:01:40.12 --> 00:01:41.34
Dear God

1
00:01:41.44 --> 00:01:44.15
Cut it off! His arm - cut it off!

2
00:01:58.92 --> 00:02:00.23
Is he dead?

3
00:02:00.32 --> 00:02:03.07
- Are you drunk, Mr Price?[br]- I am, I am.

4
00:02:03.16 --> 00:02:06.35
- Is he dead, the Colonel?[br]- Not dead yet. He has hope.

5
00:02:06.44 --> 00:02:09.43
Hey! You two. Get him back. Back!

6
00:02:11.32 --> 00:02:14.91
We're in! Do you hear? They cheer!

7
00:02:15.00 --> 00:02:16.95
Cuidad Rodrigo is taken

8
00:02:17.04 --> 00:02:19.63
Oh. He looks dead to me.
...

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

Чтобы заменить запятые на стрелочки, можно воспользоваться макросами в виме. В первой строке выполняем
 qw0f,cl --> <ESC>jjjq
Это создаст макрос на букве w, меняющий в текущей строке первую запятую на стрелочку и смещающий курсор на три строки вниз. Осталось теперь несколько раз набрать
 1000@w
и все запятые будут заменены на стрелочки.

Теперь перейдём к нумерации. Тут мы воспользуемся M4, а именно пригодится макрос incr, который предназначен для увеличения своего параметра на единицу. Например, incr(`17') выдаст 18.

Будем хранить в переменной count кол-во занумерованных строк:
 define(`count',`0')
а макрос current будет подставлять очередной номер субтитра и увеличивать count на 1:
 define(`current',`define(`count',incr(count))count')
Эти два определения нужно расположить в самом начале файла.

Теперь вставляем current перед описанием каждого субтитра — используем тот же приём, что и при замене запятых, только создание макроса будет выглядеть так (предполагается, что курсор находится на пустой строке):
 qwocurrent<ESC>jjjq

Осталось скормить это в m4:
 m4 subtitles.srt4 > subtitles.srt

Всё, теперь субтитры грузятся и работают.

Осталась совсем маленькая деталь — в субтитрах можно обнаружить команду [br]. Она предназначена для разбиения субтитров на несколько строк, однако, GOMPlayer это игнорирует и отображает её как текст. Чтобы заменить все вхождения [br] на разбиение строк, достаточно выполнить команду
 :%s/\[br\]/\r/g

DForth: продвижения 3

2010-08-28T05:43:00.000+04:00

Устроил полный рефакторинг. Почти готова возможность подключения внешних библиотек.

Сразу после запуска доступно 525 команд — вышло много комбинаторных взрывов с типизированными командами. В этом деле M4 очень помогает избежать копипаста.

DForth: продвижения 2

2010-08-16T18:00:00.000+04:00

Появились функции (т.е. объявление своих команд через двоеточие, в том числе immediate), работа с двумя видами строк.

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

Читаю потихоньку стандарт forth-94.

DForth: продвижения

2010-08-08T21:23:00.000+04:00

Написал генерацию шитого кода, его исполнение (первоначально была написана чистая интерпретация). Написал команды branch, ?branch, >mark и >resolve, позволяющие реализовывать условные и безусловные переходы. Когда добавлю возможность объявлять свои команды (т.е. функции) — средств будет достаточно, чтобы на самом DForth'е реализовать оператор if.

Научился создавать пустой исполняемый файл (который ничего не делает) для Win32. Убил на это три дня :)

Прочитал стандарт forth-83. Весьма примитивно, я ожидал чего-то бо́льшего. Но всё равно интересно.

Азы M4

2010-08-05T19:14:00.001+04:00

Всё описанное должно работать в GNU версии макропрепроцессора m4, в операционной системе Windows XP.

Скачать можно отсюда, в первую очередь требуются Binaries и Dependencies. После размещения m4.exe и regex2.dll в одну папку можно начать пользоваться.

Запуск m4.exe без параметров вызывает прогу в REPL-режиме. Чтобы выйти из m4, нужно набрать m4exit. В этом REPL режиме удобно отлаживать свои наработки.

Чтобы обработать файл, достаточно передать его имя в качестве параметра:
 m4 u1.pas4

При этом m4 выдаст результат в стандартный вывод. Стандартный вывод можно перенаправить в файл:
 m4 u1.pas4 > u1.pas

Если передать несколько файлов, то они будут последовательно выполнены так, как будто это единый файл.
 m4 u1.pas4 u2.pas4 > u.pas

Это было то, что касается запуска m4, теперь приступим к собственно использованию. m4 ищет в поступающем тексте макросы и исполняет их. Например, макрос __file__ заменяется на название текущего файла, а __line__ на номер текущей строки.

В m4 есть такое понятие, как цитата, по умолчанию цитаты должны быть заключены в кавычки (обратите внимание, что они разные)
 `это цитата'

К примеру, если у вас в тексте встречается __file__, которое не должно быть заменено на имя файла, то его нужно оформить в виде цитаты
 `__file__'
m4 при этом отбросит кавычки и останется только __file__.

При помощи макроса changequote можно сменить символы, отвечающие за кавычки:
 changequote({,})
После этого цитаты можно оформлять в виде:
 {__file__}

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

Вернём стандартные цитатные символы
 changequote(`,')

Собственные макросы объявляются при помощи макроса define. Первый переданный ему параметр задаёт имя макроса, а второй тело.
 define(`foo', `bar')

Макрос foo будет просто заменяться на bar. $1, $2, $3 и т.д. в теле макроса заменяются на переданные параметры. Например:
 define(`assign', `$2 := $1')
 assign(a+b, c)
выведет «c := a+b»

Изученного уже достаточно чтобы написать макрос assert для проверки истинности утверждения:
 changequote(~,")
 define(~assert", ~if not ($1) then begin Writeln('Assert error $1 in __file__:__line__') end")

Пример использования:
 assert(Obj <> nil);

M4

2010-08-04T23:21:00.001+04:00

Я вот пишу свою прогу для препроцессинга сурсов (dpp), а тут вдруг обнаружил программку M4:
http://lib.custis.ru/M4

Она предназначена для препроцессинга исходников на основе макросов. Т.е. именно то, чего мне так не хватает. Круто! Теперь буду её изучать.

DForth

2010-08-03T21:39:00.000+04:00

Недавно начал читать про язык Forth, мне понравились некоторые идеи, но как-то влом его досконально изучать. Поэтому я решил реализовать свой форт, под названием DForth. Пишу его на языке free pascal.

За сегодня написал основные команды работы со стеком для всех видов целых чисел, арифметические операции для них же, вывод их в консоль, функции сравнения и булевы операции. Это всё вылилось в 210 команд! Не хило так... И это я ещё не приступил ни к чему содержательному, совсем.

Написал REPL режим (интерактивный в консоли) и динамическую библиотеку для использования DForth в качестве скриптового движка.

Начал изучать как создаются exe-файлы в win32, благо это есть в исходниках fpc :) Поэтому скоро мой DForth станет одновременно компилятором, интерпретатором и скриптовым движком.

Обработка ошибок внешних библиотек

2010-07-31T16:16:00.001+04:00

Возможно, что вам приходилось когда-нибудь писать код создания окна на чистом WinApi. Наверно, он выглядел примерно так:

function CreateWindow(Width, Height : Integer; Fullscreen : Boolean; PixelDepth : Integer) : Boolean;
  // ...
begin
  // ...
  if (RegisterClass(wndClass) = 0) then  // Attemp to register the window class
  begin
    MessageBox(0, 'Failed to register the window class!', 'Error', MB_OK or MB_ICONERROR);
    Exit
  end;

  // ...
  h_Wnd := CreateWindowEx(dwExStyle,      // Extended window styles
                          'OpenGL',       // Class name
                          WND_TITLE,      // Window title (caption)
                          dwStyle,        // Window styles
                          0, 0,           // Window position
                          Width, Height,  // Size of window
                          0,              // No parent window
                          0,              // No menu
                          h_Instance,     // Instance
                          nil);           // Pass nothing to WM_CREATE
  if h_Wnd = 0 then
  begin
    MessageBox(0, 'Unable to create window!', 'Error', MB_OK or MB_ICONERROR);
    Exit;
  end;

  // Try to get a device context
  h_DC := GetDC(h_Wnd);
  if (h_DC = 0) then
  begin
    MessageBox(0, 'Unable to get a device context!', 'Error', MB_OK or MB_ICONERROR);
    Exit;
  end;

  // ...

  PixelFormat := ChoosePixelFormat(h_DC, @pfd);
  if (PixelFormat = 0) then
  begin
    MessageBox(0, 'Unable to find a suitable pixel format', 'Error', MB_OK or MB_ICONERROR);
    Exit;
  end;

  if (not SetPixelFormat(h_DC, PixelFormat, @pfd)) then
  begin
    MessageBox(0, 'Unable to set the pixel format', 'Error', MB_OK or MB_ICONERROR);
    Exit;
  end;

  // Create a OpenGL rendering context
  h_RC := wglCreateContext(h_DC);
  if (h_RC = 0) then
  begin
    MessageBox(0, 'Unable to create an OpenGL rendering context', 'Error', MB_OK or MB_ICONERROR);
    Exit;
  end;

  if not wglMakeCurrent(h_DC, h_RC) then
  begin
    MessageBox(0, 'Unable to activate OpenGL rendering context', 'Error', MB_OK or MB_ICONERROR);
    Exit;
  end;

  // ...
  Result := True;
end;

Можно заметить, что тут очень много копипастится код

MessageBox(0, 'Unable to «что не получилось»!', 'Error', MB_OK or MB_ICONERROR);
Exit;

Кроме копипаста этих двух строк, есть и второй копипаст: вместо «что не получилось» нужно везде прописывать название функции, в которой это не получилось. Как это можно бы было улучшить? Вынести в отдельную функцию нельзя, потому что Exit не умеет прыгать сразу на две функции вверх, а чтобы message box отобразил строку, нужно эту строку вбить вручную (не важно где, главное что эта строка должна быть вбита своими руками).

Конечно, в языке есть исключения, но WinApi не бросает никаких исключений специально для Free Pascal в случае штатных ошибок.

Как же быть? А никак — только копипаст. Те же беды с контролем ошибок в WinSock, DirectX и далее по списку.

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

(defmacro block-check-winapi (&body body)
  `(block NIL
      ,@(loop for f in body collect
            `(if (eql ,f 0)
                 (progn
                     (MessageBox 0
                                 (format NIL "Unable to ~a" ',f)
                                 "Error"
                                 (or MB_OK MB_ICONERROR))
                     (return NIL))))
      T))

Как всегда, для наглядности привожу пример того, во что эта конструкция разворачивается:

(block-check-winapi
  (RegisterClass wndClass)
  (CreateWindowEx dwExStyle
                  "OpenGL"
                  WND_TITLE
                  dwStyle
                  0 0
                  Width
                  Height
                  0
                  0
                  h_Instance
                  NIL))

(BLOCK NIL
  (IF (EQL (REGISTERCLASS WNDCLASS) 0)
      (PROGN
       (MESSAGEBOX 0 (FORMAT NIL "Unable to ~a" '(REGISTERCLASS WNDCLASS))
        "Error" (OR MB_OK MB_ICONERROR))
       (RETURN NIL)))
  (IF (EQL
       (CREATEWINDOWEX DWEXSTYLE "OpenGL" WND_TITLE DWSTYLE 0 0 WIDTH HEIGHT 0
        0 H_INSTANCE NIL)
       0)
      (PROGN
       (MESSAGEBOX 0
        (FORMAT NIL "Unable to ~a"
                '(CREATEWINDOWEX DWEXSTYLE "OpenGL" WND_TITLE DWSTYLE 0 0 WIDTH
                  HEIGHT 0 0 H_INSTANCE NIL))
        "Error" (OR MB_OK MB_ICONERROR))
       (RETURN NIL)))
  T)

Загрузка, ждите

2010-07-28T19:06:00.000+04:00

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

В случае с установщиком все понятно — установщику нужно скопировать определенный набор файлов, делаем это в цикле, а в самом конце каждой итерации обновляем полосу загрузки.

Но что делать, если в программе нужно выполнить кучу неоднородного кода (который нельзя так просто оформить в виде цикла), заставляющего пользователя ждать? Пример с запуском операционной системы очень хороший.

На Free Pascal я могу назвать три решения.
1) В лоб — после каждой строчки кода загрузки вызываем функцию перерисовки. Это можно сделать так:

for I := 0 to LinesCount - 1 do begin
 case I of
 0: <Line0>;
 1: <Line1>;
 2: <Line2>;
 ...
 end;
 RedrawLoading(I, LinesCount);
end;

Вполне приемлемое решение, кроме того, что при добавлении новой строки нужно не забыть увеличить LinesCount.

2) Использовать нити (threads, так же известные как «потоки») — в одной нити грузим, в другой обновляем экран. Решение мне не нравится тем, что ИМХО с нитями лучше лишний раз не связываться.

3) Написать класс, предназначенный для выполнения одного шага загрузки, имеющий одну абстрактную виртуальную функцию Execute(). Унаследовать от него разные типы шагов: копирование файла, загрузка библиотеки, загрузки картинки, проверка чего-нибудь и т.д. После этого перед загрузкой занести в нужной последовательности такие классы в массив, и в цикле после каждого Execute вызывать RedrawLoading(I, Length(Steps)). Очень громоздкое решение — городить его ради ерунды как-то не очень хочется.

Наиболее симпатичным является первое решение, за свою простоту. Но вручную это делать не хочется — вот было бы здорово, если бы компилятор это сделал сам!

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

(defmacro watch ((watch-func) &body body)
 (let ((op body))
 `(progn
 ,@(loop for i upto (- (* (list-length body) 2) 1) collect
 (if (evenp i)
 `(,watch-func ,(/ i 2) ,(list-length body))
 (let ((result `(,@(car op)))) (setf op (cdr op)) result)))
 (,watch-func ,(list-length body) ,(list-length body)))))

Функция watch-func как бы наблюдает за ходом выполнения кода body, поэтому макрос я назвал watch. Несмотря на то, что я попытался написать красивый код, получилось спагетти. Но поставленную задачу оно выполняет, вот лог нескольких тестов:

(watch (L) A B C D E F)

(PROGN (L 0 6) A (L 1 6) B (L 2 6) C (L 3 6) D (L 4 6) E (L 5 6) F (L 6 6))

(watch (L) A)

(PROGN (L 0 1) A (L 1 1))

(watch (L))

(PROGN (L 0 0))

По хорошему, нужно еще обезопасить L от многократных вычислений, это можно сделать конструкцией once-only.

В Free Pascal нормальной системы макросов нет. Поэтому аналогичную конструкцию я написал в моей утилитке dpp. Т.к. для того, чтобы достаточно точно интегрировать конструкцию в сам язык, нужно парсить программу на паскале, мне пришлось вводить несколько инородный синтаксис:

 #(watch (RenderLoading)
 (FGui := TGui.Create(FGraph, FWindow);)
 (FFontMan := TFontMan.Create(Graph);)
 (FScene := TCucuScene.Create(Graph);)

 (FStyle := TStyle.Create;)
 (FStyle.SetParam('font.primary', TStyleParamFont.Create(TFont.Create(FFontMan, 'data\font\c256.bit', -6)));)
 (FStyle.SetParam('color.primary', TStyleParamColor.Create(Vec4f(0.5, 0.5, 0, 1)));)
 (FStyle.SetParam('color.background', TStyleParamColor.Create(Vec4f(0.3, 0.0, 0.3, 1)));)
 (FGui.Root.Style := FStyle;)
 (FConsole := TGuiConsole.Create(FGui);)

 (FStart := GetTimer;)
 )

vim 7.3 beta

2010-07-24T11:29:00.000+04:00

Недавно вышла бета будущего vim 7.3.

Одно из интересных нововведений — вечное UNDO. Теперь вся история редактирования файла хранится не только в рамках текущей сессии, но и при перезапусках. Например, можно будет увидеть состояние файла годичной давности. Конечно, при использовании svn это не так актуально, но не всё ведь хранится в свн. А бэкапы делать лень.

По умолчанию фича отключена, чтобы ею воспользоваться, достаточно добавить в vimrc файл строку:

set undofile

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

set relativenumber

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

set colorcolumn=…

Где вместо … нужно указать через запятую номера столбцов, которые нужно подсветить. Я у себя выставил «set colorcolumn=81» чтобы видеть какие строки не влезли в 80 символов.

Вот как у меня выглядят последние две фичи:

dpp: персморт концепции

2010-07-24T00:50:00.000+04:00

Изначально я предполагал, что моя утилитка dpp для препроцессинга сурсов на паскале будет строчно-ориентирована. Т.е. ключевые строки программы (объявление класса, функции, слова «interface» и «implementation») должны были бы занимать одну строку, а dpp может только дописывать в конец некоторым строкам какой-то код.

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

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

А именно, код для dpp должен находится внутри блока #(…). Например, уже реализована конструкция

#(return A)

Которую dpp заменяет на

begin Result := A; Exit end

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

#(return A1 A2 … AN)

развернётся в

begin A1; A2; … A(N-1); Result := AN; Exit end

Теперь у меня серьезные проблемы с тем, что некоторые команды должны не только генерировать код прям на месте, но и добавлять какой-то код в другие части проекта. (К примеру, лямбда-функции должны добавлять свой код в implementation-секции модуля.) А это без предположения о строчном разбиении задача не минутная.

Но нет худа без добра, и возможно, что будет возможность писать макросы на лиспе, командой #(lisp …).