← All posts tagged programming

"А в прочем в памяти машины вручную догмы прописать ещё возможно (и не сложно). Вот только бы компьютер не сломать..." поют программисты в повести Аргонова. Похоже он знает толк в ERP'шниках.

Захотелось мне поговорить про Forth. Один из наиболее частых аргументов против Forth'а — невозможность оптимизации на современных полурегистровых машинах (в amd64 16 регистров общего назначения, а в ia64 целых 128!). Вторым аргументом является неизбежность побочных эффектов (работы с стеком). Я попытаюсь объяснить, как отчасти избавится от этих недостатков.
В качестве базы я возьму rx core — ядро RetroForth до 9'ой версий включительно. Низкоуровневых слов в rx core всего 31 штука. В rx core (как и в большинстве классических фортов) используется два стека (первый называется stack, второй — return stack) и хип. Также замечу, что из 31'ого слова только 5 работают с return stack'ом (при этом они не работают с хипом) и только 4 работают с хипом.
Рассмотрим следующее выражение в обратной польской записи «2 3 4 +». Если рассматривать его как работу со стеком, то оно не берёт ничего, и кладёт в стек 2 числа. Т.е. его можно рассматривать как функцию от 0 параметров, возвращающую пару значений. Аналогично форт-выражение «dup *» это функция от 1 параметра с единичным возвратом. Теперь важно заметить, что все стандартные слова, кроме if-семейства и then, можно описать в таком виде (значит и их композицию тоже). Единственным тонким местом является выражение «if бла бла бла then». Если бла бла бла изменяет размер стека, то теряется детерминированность результатирующего слова и его уже не выразить не прибегая к стеку.
Ну и наконец пример. В rx core выражение «dup *» откомпилируется во что-то такое (rx core держит верхушку стека в eax, использует esi как указатель стека):
mov [esi-4], eax
lea esi, [esi-4]
mul dword [esi]
add esi, 4
В оптимизирующем компиляторе же (параметры лежат в eax, ecx, edx, возврат там же):
call dup ( если dup inline, то mov ecx, eax )
imul eax, ecx
P.S. Сразу извиняюсь за корявости

forthfreak.net и forthfreak.net Человек реализовал в несколько строк алгебраические типы данных (с паттерн-матчингом, зачем они без него?) и привёл примеры использования. Всё генерится на этапе компиляции, так что никаких рантайм оверхедов. Всё-таки форт превосходный язык

Был сегодня на собеседовании в JetBrains. Ощущения отвратительные. Во-первых HR'ы страдают манией димпломированного специалиста (при этом очень пиарили Computer Science Club, с которым они взаимодействуют, непонятно совершенно кто там будет выдавать бакалавра и магистра, не ПОМИ РАН же). Во-вторых, несмотря на явные заявления о их илитности и непригодности должностей Java-программистов в других местах, им явно нужен раб. Прямые намёки на то, что работать у них и заниматься наукой одновременно невозможно. В-третьих я имел неосторожность сказать слово «хаскель» (но я не говорил, что его знаю, ибо правда не знаю), и налетели на него как мухи на тухлое мясо. В-четвёртых гоняли меня по плюсам (это был мой единственный вин) и по алгоритмам (o_O никогда не занимался олимпиадным программированием)
Подытоживая — есть ли какой-нибудь мануал по общения с HR'ами?

Почему любая жуйкоблядь считает охуенно интересным постить свой сраный быдлокод, и считает его дико красивыми, концептуально интересными и все такое? Типа, охуеть, вот моя тулза умеет xmpp, давайте заскриншотим и выложим. Пиздец.
inspired by #1334278

Из незанятых букв латинского алфавита для названия языка программирования остались H, I, N, O, P, U, V и W (про все кроме X и Y знает википедия, они вполне гуглябельны). Расхатываем, товарищи

Придумал муторную, но красивую задачу на стыке computer science и математической логики. Широко известно (в узкий кругах, коз), что в рамках логики предикатов первого порядка отнюдь не все задачи вида «выяснить выводимо ли суждение A из суждения B» вычислимы. На данный момент существует сравнительно небольшой список базовых алгоритмов для решения частых случаев этой задачи (наиболее эффективные из них включены в состав дескрипционной логики).
Это всё навело меня на мысль — почему бы не переписать тех же бурбаков целиком не используя ни слова вне логики предикатов и не проверить на вычислимость известными алгоритмами каждый переход. В итоге получается красивая задача, довольно неопределённой сложности, давайте подумаем какие могут быть результаты (в порядке уменьшения вероятности их получения):
1. Получение новых примеров вычислимых переходов (скучновато, но очень полезно, расширить логический язык до того, что он сможет вывести всю математику до начала XX века (пусть и через призму середины оного), это не хухры мухры)
2. Ничего, то есть значит, что современная реализация DL сможет вывести всю математику к вышеуказанному периоду. Этот результат может дать стимул в развитии ИИ, например
3. Бурбаки пропустили важные аксиомы или допустили набор ошибок (несомненно что-то такое есть, но ошибки, если и есть, вряд ли будут критическими)
4. Нахождение перехода, верного, но про который можно доказать, что он не вычислим. Шокирующий факт, по сути доказывающий то, что полноценный ИИ на привычных нам машинах невозможен, он просто не сможет делать то же, что и люди
По-моему красивая штука и ей бы можно было заняться какому-нибудь прикладному математику. А может уже занимались, но я не знаю?

Сегодня выдался довольно плодотворный день — в порыве настройки xmonad написал довольно убогий, но оригинальный eventHandlerHook и свой собственный layout.
Но давайте по-порядку. Когда просматриваешь картинки с помощью feh возникает следующая проблема — если окно изменяет размер (например при просмотре галлереи), то окно перемещается в (0,0), что очень неприятно. У этой проблемы есть решение — запускать feh для каждой картинки по-отдельности, но решение сверхресурсоёмко, к сожалению. Наверное был бы идеальным вариант в духе urxvtd, но на данный момент такого решения не существует, а патчить feh как-то не хочется. Я пошёл по другому пути — при запросе окна на изменения параметров смотреть не feh ли это, и если да, то размер изменять, но по прежнему центрировать. В итоге получился вот такой вот хук:
myHandleEventHook :: Event -> X All
myHandleEventHook e@(ConfigureRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do
cname <- fmap resClass $ io $ getClassHint dpy w
ws <- gets windowset
wa <- io $ getWindowAttributes dpy w
bw <- asks (borderWidth . config)

let screenWidth = displayWidth dpy (defaultScreen dpy)
screenHeight = displayHeight dpy (defaultScreen dpy)

if (cname == "feh")
then do io $ configureWindow dpy w (ev_value_mask e) $ WindowChanges
{ wc_x = div (screenWidth — (ev_width e)) 2
, wc_y = div (screenHeight — (ev_height e)) 2
, wc_width = ev_width e
, wc_height = ev_height e
, wc_border_width = fromIntegral bw
, wc_sibling = ev_above e
, wc_stack_mode = ev_detail e }
when (member w ws) (float w)
io $ sync dpy False
(return (All False))
else (return (All True))
myHandleEventHook _ = return (All True)
Во-вторых я вспомнил о том, что давно хочу вертикальные табы для работы с браузером. Это наглядно, удобно и довольно экономно. Там есть что допилить (например прокрутку и древовидность), но оно и сейчас годно к употреблению: goo.gl и rghost.ru
Используется оно просто: vtabLayout = noBorders (vtabbed 200 LeftT myShrinkText myTheme)
P.S. Обещался ещё @L29Ah сделать горизонтальные мультитабы. Это сложнее, но, надеюсь, что руки дойдут

Нашёл кое-что интересное — open-std.org Заметка описывает то, как type-generic сделан в gcc (и заодно с clang'е), а также предлагает новый, менее гибкий, но более красивый способ реализации. К сожалению несмотря на то, что этот макрос позволяет реализовать простейший полиморфизм, он никак не спасает от необходимости дублировать код
Внимание вопрос! Какие существуют средства для такого дублирования? Я сам использую X-Macro (и видимо продолжу использовать, если не найду годной альтернативы). К сожалению его использования связано с трудностями внедрения его в модульное программирование. Трудой способ (им. товарища ЛексЗеро) — sed'ать файлы с шаблонами, а также файлы-пользователи и прописывать всё в make файле. Это вариант плох, по той причине, что в Си система сборки дифференцирована от непосредственно программы, а так мы делаем лишнее связывание сущностей. То есть хотелось бы иметь чисто компиляторный вариант