Сделал новый LGPL билд FFmpeg под винду(x64). По ссылке внизу, в архиве. Библиотеки FFmpeg скомпилированы как DLL, все зависимости вкомпилены в них статически, таким образом, можно считать никаких сторонних дополнительных зависимостей нет. В архив включены собственно исполняемые бинарники, DLL-ки, библиотеки импорта, необходимые для линковки с ними, хидеры, и документация.

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

Лицензия LGPL-v3 означает, что сборку можно использовать для коммерческих и приватных целей, а также распространять бинарники без необходимости открывать код и так далее. Естественно, по причине лицензии, некоторые кодеки и сторонние зависимости были удалены, например это libx264 и libx265. Но, им есть замена - libopenh264, kvazaar, и так далее. Кроме того, включены DXVA, D3D11VA, поддержка аппаратного ускорения Nvidia, Intel, и другие плюшки.

В архиве, в README.txt, все подробно описано.

https://static.lovesan.me/ffmpeg/ffmpeg-4.1.3-win64-lgpl.zip

Любая достаточно сложная программа на Javascript содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.

Нет, ну вы видели современную экосистему JS?

NPM, Webpack, Babel - метациклические компиляторы и интерпретаторы JS, на основе конфигов.

Vue/React/Angular - фреймворки с доменноспецифичными метаязыками и декларативными макросами поверх API браузеров.

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

Это адски тормозит, иногда просто не работает, и уж точно постоянно глючит. И забудьте про обратную совместимость. Просто забудьте.

Народ, у меня на работе фронт собирается медленнее, чем на прошлой работе собирался С++ код, представляющий собой огромную обвязку над FFmpeg.

Мы на работе стабильно раз в неделю тратим пару часов на починку очередной хероты из NodeJS инфраструктуры - ломается тупо каждую неделю, и это даже без апгрейдов, тупо на билд-серваке или локальной машине делается npm install - и привет (и слава б-гу, саму ноду не используем, ей только фронтенд компилируется).

И главное, все это говно на порядок сложнее в изучении и понимании, чем SICP, спецификация Common Lisp, Dragon Book и Ахо/Ульман - вместе взятые.

Про дебаг я вообще не говорю, в прошлый раз дебажа JS код, я чуть не ушел в запой.

Фронтендщики, хватит! Остановитесь!

Доколе можно так ненавидеть родной язык? Мат - часть русского языка.

Хватит строить из себя советскую интеллигенцию во втором поколении(i.e. не материшься == культурный).

Матом временами не то что ругались, а разговаривали - Пушкин, Лермонтов, Толстой, Достоевский, Есенин, Мандельштам, Пастернак, про Высоцкого вообще не говорю, и так далее. Современная культура же без мата вообще не возможна.

У нас достаточно правил чтобы по тем или иным причинам удалять посты не касаясь выбора лексического аппарата(например есть правила про оскорбления).

Хватит харрасить русский язык!

Свободу матюкам!

С++ 2018

Собственно в чем проблема? А проблема в том, что конкретному модератору не нравится когда оскорбляют его священную корову - плюсы.

Ага, провокация флейма, значит. А господин ТГ вообще в курсе что и весь ЛОР, и Development, в частности, только и живет тем - что тут и там разводит флеймы? И потому туда заходят.

Development - не quora, у нас тут всегда было место для общения.

Но видимо, некоторым сильно кое где жмет, когда их задевают за живое(т.е. за С++).

Не буду особо подводить итоги года, подведу лучше итоги C++ за 20 лет.

С тех пор как вышел стандарт C++98, утекло довольно много воды, поменялись мейнстримовые операционные системы, браузеры, базы данных, принципы и методы разработки ПО, и вообще, кто бы мог подумать что Microsoft станет одним из главных контрибьюторов в Open Source.

C++ все так же остается разрастающимся монструозным говном, однако в 98 году, у него была действительно важная область применения - системный софт для десктопных операционных систем. Сейчас область применения C++ - разве что поддержка всех тех сраных легаси систем, которые на нем когда-либо были, по недоразумению, написаны. Ну и конечно, социальные пособия умственно отсталым «программистам», которые не способны понять простой факт, что не все является гвоздем если у тебя в руках молоток, а переусложненное монструозное говно, представляющее из себя набор исключительно идиотских архитектурных недоразумений и просто случайных ляпов, не имеет смысла применять хоть где-то кроме как для перемножения матриц на стеке(уау, как круто перегрузили оператор сложения!) и то, если ваш проект не выходит за рамки «Мама, смотри, я написал треугольник на DirectX!».

В связи с этим вопрос - когда уже закопают труп?

Перемещено jollheef из development

Пыхотред

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

А чего это у нас, в нашем загончике, нет закрепленного пыхотреда?

Вот теперь есть(надеюсь, его закрепят).

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

В тред приглашаются все пыхобоги, пыходемоны, пыхофрилансеры, простые пыхари, и даже пыхоненавистники.

Обсудить есть много чего, начиная с различий версий, особенностей языка, CMS-ок, фреймворков, и заканчивая говнокодом.

<?php

http://winfaq.org.ru/forum/talks/14028344

https://github.com/Lovesan/clave

Такое. Красивый и удобный лисповый интерфейс к библиотекам FFmpeg. В процессе, но кое-что работает уже. Пока не хватает swresample и swscale, но скоро будет. Также, потом отдельной asdf-системой будет postroc, т.к. она загплена.

Еще с документацией пока проблемы, как впрочем и у самого ffmpeg.

Тестируется все на винде, под FFmpeg 3.2.4, собранный мной лично: https://static.lovesan.ru/ffmpeg/ffmpeg-3.2.4-win64-lgpl.zip

Но, в принципе, ничто не мешает работать и с линуксом, надеюсь я там правильные имена файлов so-шек вписал, в src/lib.lisp

UPD: Протестировал на ubuntu 16.04 с FFmpeg 3.3.2 (из ppa) - все отлично работает

Вот пример, типа, берем, и конвертируем любое медиа, поддерживаемое FFmpeg, и у которого есть звуковой поток, в mp3-файл.

(defun convert-audio-file (infile outfile)
  (declare (type string infile outfile)
           (optimize (speed 3) (space 0) (safety 0)))
  (clave:with-input-context (input infile)
    (clave:find-stream-info input)
    (clave:dump-format input :url infile)
    (multiple-value-bind
          (stream-index codecpar)
        (loop :for i :from 0
              :for stream :in (clave:format-context-streams input)
              :for codecpar = (clave:media-stream-codecpar stream)
              :when (eq :audio (clave:codecpar-codec-type codecpar))
                :do (return (values i codecpar))
              :finally (error "No audio stream found"))
      (let ((decoder (clave:find-decoder (clave:codecpar-codec-id codecpar)))
            (encoder (clave:find-encoder :mp3)))
        (clave:with-codec-context (inctx decoder codecpar)
          (clave:open-codec-context inctx)
          (clave:with-codec-context (outctx encoder)
            (clave:with-codec-context-slots
                (sample-format sample-rate channels channel-layout global-quality) outctx
              (setf sample-format (clave:codecpar-format codecpar)
                    sample-rate (clave:codecpar-sample-rate codecpar)
                    channels (clave:codecpar-channels codecpar)
                    channel-layout (clave:codecpar-channel-layout codecpar)
                    global-quality 1))
            (clave:open-codec-context outctx encoder)
            (clave:with-output-context (output :filename outfile)
              (let* ((outstream (clave:add-media-stream output encoder))
                     (outpar (clave:media-stream-codecpar outstream)))
                (clave:parameters-from-context outpar outctx)
                (clave:write-header output)
                (clave:dump-format output :url outfile)
                (clave:with-packet (packet)
                  (clave:with-frame (frame)
                    (loop :while (clave:read-frame input packet)
                          :when (= stream-index (clave:packet-stream-index packet)) :do
                            (clave:send-packet inctx packet)
                            (loop :while (clave:receive-frame inctx frame) :do
                              (clave:send-frame outctx frame)
                              (loop :while (clave:receive-packet outctx packet) :do
                                (clave:write-frame output packet))))
                    (clave:send-flush-frame outctx)
                    (loop :while (clave:receive-packet outctx packet) :do
                      (clave:write-frame output packet))
                    (clave:write-trailer output)))))))))))

Ну такое. Пишу значит стриминг, с возможностью записи в файл. Уже давно пишу, много где много чего понял про FFmpeg, несмотря на отсутствие документации, примеров, и постоянно меняющееся API.

Но такой все же вопрос. Вот допустим, мне приходят фреймы откуда-то, из проприетарного API, считай битмапы, я их конвертирую в YUV, создаю AVFrame, ставлю pts соответственно номеру кадра. Также, приходят семплы аудио из rtp демуксера. Надо это стримить, и временами, сохранять. Собственно, я это и делаю, но пока - особо без задней мысли просто складываю в контексты кодеков и муксеров.

Но внимание вопрос, как лучше синхронизировать потоки? И в файл, и в RTP стрим? Закладываться на количество сэмплов аудио? На количество фреймов видео? На системное время? Какие есть стратегии синхронизации, чтоб и в реалтайм стриме, и в файле у меня не было рассинхрона, особенно если потоки - долгоживущие? Что делать если соурсы битмапов и аудио - на время пропадают - например какие-то устройства, их генерирующие, падают? Итд.

Подскажите чо как

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

Отличие синьора-помидора на C++ от мидла в том, что последний уже знает что C++ говно, но еще не знает, почему.

Внимание, вопрос уровня синьора-помидора. Дан код. Объясните, почему другой синьор-помидор обосрался, написав его? Где может обосраться пользователь?

Задачу не будем усложнять, допустим, у нас single producer - single consumer предполагается.

#ifndef __BLOCKING_QUEUE_HPP__
#define __BLOCKING_QUEUE_HPP__

#include <cstdlib>
#include <mutex>
#include <condition_variable>

template<typename T>
class BlockingQueue
{
private:

    struct QueueNode
    {
        T val;
        QueueNode * next;
    };

    QueueNode *_first, *_last;
    std::mutex _cs;
    std::condition_variable _cv;
    bool _abort;
    int _count;

public:

    BlockingQueue()
    {
        _first = _last = nullptr;
        _abort = false;
        _count = 0;
    }

    ~BlockingQueue()
    {
        Flush();
    }
    
    BlockingQueue(const BlockingQueue& rhs) = delete;

    void operator=(const BlockingQueue& rhs) = delete;

    bool Put(const T& val)
    {
        std::unique_lock<std::mutex> lock(_cs);

        if(!_abort)
        {
            QueueNode * node = (QueueNode*)malloc(sizeof(QueueNode));
            if (node)
            {
                new (&node->val) T(val);
                node->next = nullptr;
                if (_last)
                    _last->next = node;
                else
                    _first = node;
                _last = node;
                ++_count;
                _cv.notify_one();
                return true;
            }
        }
        return false;
    }

    bool Get(T& val)
    {
        std::unique_lock<std::mutex> lock(_cs);

        for (;;)
        {
            if (_abort) return false;

            QueueNode * node = _first;
            if (node)
            {
                _first = node->next;
                if (!_first) _last = nullptr;
                --_count;
                val = node->val;
                node->val.~T();
                free(node);
                return true;
            }
            else
            {
                _cv.wait(lock);
            }
        }
    }

    int Count()
    {
        return _count;
    }

    void Flush()
    {
        QueueNode *node, *tmp;

        std::unique_lock<std::mutex> lock(_cs);

        for (node = _first; node; node = tmp)
        {
            tmp = node->next;
            node->val.~T();
            free(node);
        }

        _first = nullptr;
        _last = nullptr;
        _count = 0;
    }

    void Abort()
    {
        std::unique_lock<std::mutex> lock(_cs);
        _abort = true;
        _cv.notify_one();
    }

    void Start()
    {
        std::unique_lock<std::mutex> lock(_cs);
        _abort = false;
        _cv.notify_one();
    }
};

#endif // __BLOCKING_QUEUE_HPP__

Вопрос номер два - назовите хотя бы один язык программирования с подобными проблемами.

Давно не писал. Извините за кросспост, конечно, но вот вылезла такая мысль, хочется поделиться.

--- А вы в курсе, что в РФ нет высшего образования? Только профессиональное, и то, конечно учит так себе, но какое есть.

Нет, правда, знаете, если перестать лицемерить, и посмотреть на образование в РФ под таким углом, многое встает на свои места.

Ну не высшее это образование, и наверное, никогда им не было. Высшее образование готовит кого? Ученых. Все эти лицемерные степени в РФ, типа, бакалавра - это смешно просто. Бакалавр - тоже ученый, а кто в РФ бакалавры? Читать писать научили - хорошо, чертежи рисовать - вообще отлично. Но, на это и рассчитано. Давайте только бакалаврами перестанем их называть, и магистрами, и так далее. Институт аспирантуры, все знают, тоже давно сгнил, и его вообще надо убрать.

И сразу отпадают всякие вопросы, типа нужно ли высшее образование или нет. Да, наверное, нужно, но профессиональное тоже нужно.

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

И вопросы - нужна ли вышка программистам. Нет, конечно, опять же, не нужна. Профессиональное образование, наверное, нужно, но программирование это такое дело что можно и самому научиться, и доказать знаниями и ачивками свои таланты и без прохождения колледжа. И опять же, Java, в колледжах - ну почему бы и не учить, полезное дело все-же.

Собственно, т.н. ВУЗы в РФ это по сути, колледжи и есть. Давайте наконец перестанем лицемерить, и переименуем их. Учат там профессиям, а не науке. Не высшее это образование, нисколько. Даже если готовят физиков-ядерщиков - ну увольте, готовят то просто инженеров по обслуживанию АЭС, а не Капиц. А сами текущие т.н. колледжи, в которых готовят рабочих, вообще надо переименовать в профориентированные школы, которыми они по сути и являются.

Все, что подведомственненно министерству образования - высшим образованием не является.

А что, тогда, скажете, высшее образование? Да нет его в РФ, еще раз. Высшее образование - это такое образование, которое готовит ученых. У-че-ных, еще раз. Бакалавр - младший научный сотрудник. Магистр - старший научный сотрудник. PhD/Кандидат/Доктор - еще выше. Соответственно, если мы в РФ хотим высшее образование - его надо создавать абсолютно с нуля, с полного. На базе Академии Наук. У которой, тоже, конечно, сейчас проблем много, но наука - там, и вышка - там и должна быть. Соответственно, надо и оставлять эту дебильную затею с т.н. национально-исследовательскими университетами. Если там что-то и есть, по науке, сейчас, то надо это что-то, пока оно живо, вынести из под опеки колледжей, и передать академии наук, и на основе этого и строить высшее образование.

Случилось чудо. Не прошло и полгода, как мне наконец удалось собрать ffmpeg под win64 со всеми зависимостями, кроме GPL-нутых, проприетарных, и сломанных. Т.е. с LPGL-v3 лицензией.

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

Кроме того, билд даже немного круче официального - там в частности поддерживается ускорение с помощью DirectX 11.

Вот полный дистрибутив, лицензии там тоже есть. Ну и README.

https://static.lovesan.ru/ffmpeg/ffmpeg-3.2.2-win64-lgpl.zip

А вот типа пример, как с помощью нехитрых приспособлений(типа, еще с SDL2), libav* можно превратить в аудио/видео плеер:

https://gist.github.com/Lovesan/e29d815586ea20642d85875d47cefe03

Перемещено tailgunner из development

Собственно,обновил Ubuntu Server на наших серверах до 16.04 LTS

Через некоторое время начал замечать что запросы выполняются по 10 секунд.

Полез смотреть. А там...

Ну вобщем вот:
http://www.archivum.info/ubuntu-bugs@lists.ubuntu.com/2016-01/01499/(Bug-1518...

Но это ладно, полез значит дальше смотреть интернет на эту тему, и обнаружил, что эта проблема висит ГОДАМИ.
https://bbs.archlinux.org/viewtopic.php?id=144702
i915, kswapd0, 100% CPU

Вот и все у них так!

Ну и вот костыльное временное решение если что:

#!/bin/bash
if [[ $EUID -ne 0 ]]; then
    >&2 echo 'Superuser access required'
    exit 1
fi
echo 1 > /proc/sys/vm/drop_caches

Привет.

Как известно, текущая стандартная библиотека Common Lisp устарела, много необходимого в ней просто нет, реализации предоставляют разрозненные наборы фич, а в репозиториях куча полуподдерживаемых библиотек.

Поэтому я тут решил потихоньку пилить новую стандартную библиотеку для CL. По образу и подобию недавно заопенсорсенного .NET Base Class Library.

https://github.com/Lovesan/CLR

Код либо адаптируется из существующих библиотек - благо лицензии в основном позволяют, либо переписывается на CL из библиотек других языков.

Важный момент - это не синтаксический сахар и не простое распихивание символов по модулям, как в том же cl21, это именно стандартная библиотека.

Сейчас у меня там совсем небольшое количество кода, и в качестве бэкенда пока только SBCL и винда, но вот неполный список планирующихся фич:

• Унифицированные *features*
• Разнообразные распространенные утилиты, вроде with-gensyms итд
• Унифицированный интерфейс MOP
• Треды, примитивы синхронизации, атомарные операции, тред пулы, таски/фьючи
• Асинхронное высокопроизводительное IO, включая работу с сетью
• Легковесный FFI
• Различные коллекции, в том числе lock-free. Унифицированный интерфейс коллекций.
• Кодировки, регулярные выражения, i18n, L10n
• Работа с датой и временем
• Унифицированные механизмы сериализации
• Работа с XML и JSON
• Работа со сжатием данных
• Стандартная система логирования
• Для винды - интеграция с COM по подобию .NET, работа с виндовыми сервисами

Также, в качестве отдельных модулей/asdf-систем:

• Унифицированная работа с базами данных по примеру JDBC и сотоварищей
• Работа с безопасностью и криптографией
• Фреймворк для тестирования кода
• итд

Пилю пока один, но community effort был бы очень к месту. Желающие - присоединяйтесь.

по мотивам Ищу гуру Си программирования

Входит Вопрощающий:

Всем привет.
Есть тут свободные полгода
В которые хотел бы я программы изучать,
Даю вам это знать.
Пока что начал только Java лишь учить
По книге, впрочем, и дошёл до ООП,
Вы подскажите, это правильно, иль надобно тем книгам сгнить?
Хотел бы выбрать я ЯП и направление,
Что позволяло бы работать на фрилансе,
А также, у людей чтоб вызывалось изумление.

Входит ЛОРовец:
Двадцатник баксов в час, или забудь о нас

Входит Новенький:
You're welcome.
Давай свои контакты - отпишу.
Ведь мне не жалко помогать, один чёрт одиночество последнее недели
Так разъедает душу мне, что еле я дышу.

Входит Наркоман:
K&R расскажет, и покажет
Тебе всё милый друг,
Ну а коль что вдруг непонятно станет, то значит в голове недуг.
Ведь суть проста: конструкций мало, новых слов десятка два.
И сей язык освоишь быстро.
Хочу предупредить я, правда, что сам язык не цель твоя,
Ведь цель должна учится на ошибках.
Важнее знать не то, что как вам делать сударь,
Важнее путь тернистый, полный ям, и отроколов
Вам пройти и знать тропинку по которой надобно идти таким путем
Чтобы все ямки обойти.
И к сожаленью, или, может, к счастью, тропинку ту лишь одному тебе дано найти.
Ведь мудрый путник лишь укажет, в какую можно сторону идти.

Входит Зевака:
Внесите царя.

Входит Лавсан:
Я хоть не Царь, но знаю всё про Си, давай, спроси

Вопрощающий:
Жду контакта.

Входит Некто:
Будут вопросы - кастуй, или пиши на мыло.
И мыло можно, если что, найти в LKML и ffmpeg-develop.

Входит Царь:
О Наркоман, а почему нули,
Которые смешать с навозом в три счета,
Так много кукарекают о том, о чем не понимают ничерта?

И ладно, я бы понял, если ты бы что-то мог,
Но тыж не смог, дак почему ж несмогший путник,
Который тонет в луже иль болоте,
Иль где-то на задворках недовуза, тот пыжиться кого-то направлять?
Куда ты их направишь? Ты желаешь, их повернуть развитие всё вспять?
Ведь что ты можешь,
Как кроме повторять приевшиеся шутки,
и предлагать приевшиеся книжки,
Ответь, мальчишка?
И удиви меня своим вопросом.

Вопрощающий:
Увы, нет у меня таких вопросов
(И тут же поникает носом)

Входит Эдди: (лавсану)
Ты царь?

Лавсан:
Кто такой царь?

Новенький (лавсану):
Он твой последователь.
Вон, четырьмя постами выше.
И, потише,
Сейчас начнется развлеченье.

Эдди (лавсану):
А, раз не царь ты, то ведь Си не знаешь!
К тому же, зачем еще и о Царе тут вопрошаешь?

Царь (вопрошающему):
Причем тут удивительные.
Когда хотите вы спросить что-либо, то естественно,
Что на пространные вопросы,
Не менее пространные я буду вынужден вам отвечать ответы,
Поймите ж это.

Поэтому, Царя должны вы право заинтриговать,
Чтобы смог он для себя обосновать
Полезность траты времени на ху**оса.
Вот смысл моего вопроса.
Зачем царю писать куда-то, без причины?
Не есть ли это признак вроде Эдди дурачины?

Входит Аноним:
Какое-то собранье зебр в треде.
И странно, все стихами говорят.
Похоже, что попал я в Ад.

ЗАНАВЕС.

(cons cat (cons other-cat nil))

Как можно заметить, отсутствие коробки с котом не является ни коробкой, ни котом, но одновременно и тем, и тем.

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

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

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

Отсюда:

Третья Теорема Лавсана (о бесполезности статической типизации)

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

Дискач.

Всем более-менее опытным программистам, работавшим с энтерпрайзом, четко известен следующий эмпирический закон:

Девятое Правило Гринспуна, о котором он сознательно предпочел умолчать

Любая более-менее крупная программа на Java или C# является программой на XML

Вобщем, в один прекрасный день, работая на C#, я написал на XML-конфиг некоторых приблуд для UI. Это смотрелось настолько элегантно и красиво, и кастомизировалось настолько проще, по сравнению с обычным хардкодом, что я долго лелеял идею о том чтобы воткнуть подобное еще куда-либо в проект.

Не так давно, такой шанс появился, и я перевел в декларативное описание на XML воркфлоу основных бизнес-процессов системы.

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

А что если эти два конфига объединить в один XML?

Ой, стойте, но тогда ведь получается, что туда же можно перенести и разнообразные простые валидаторы и предикаты действий по бизнес-логике? Описание геттеров/сеттеров и простой арифметики - не такое уж сложное занятие, тем более проект и так в System.Reflection по уши.

Черт! Но вообще-то ведь и сложные тоже не проблема - ведь они явлются в 99% случаев не более чем SQL/HQL-запросами, которые никто не мешает хранить в конфигах.

Ух, а ведь если подумать еще - то туда же можно перенести и сами действия по бизнес-логике, не так ли?

Но ведь можно пойти и дальше. Из XML можно вообще-то говоря даже и генерировать модель данных для всей логики системы! И ведь это не просто бредовая идея - такое отчасти давно уже делается стандартными средствами .Net-платформы, например тем же Entity Framework.

И тут я задался вопросом - а зачем нам тогда вообще большая часть кода на C#? Сторонние библиотеки мы ведь точно так же можем вызывать из интерпретатора XML.

Вон оно как все отлично то выходит.

Хм, правда что-то эта модель несколько, скажем так, раздулась.

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

И тут меня осенило. Где-то я это уже видел. Может быть в одной книжке, давно забытой на полке? Или в старой статье семьдесят мохнатого года?

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

Итак:

Вторая Теорема Лавсана

Каждый XML-программист (то есть любой продвинутый java/c#-программист) в конечном итоге доходит до лиспа, просветляется и плачет.

Дискач.

В Петербурге, 28го ноября, пройдет очередной IT Global Meetup. http://piter-united.ru/itgm/itgm.html

В числе участников - лисперы, во главе со мной и Мишей Глуховым(rigidus)

Мы двое, соотвественно, точно будем выступать и представим доклады.

Хотелось бы узнать, желает ли кто-нибудь еще вместе с нами подготовить какой-либо доклад на тему лиспа? Уже требуется подтвердить программу, так что дайте знать как можно скорее.

Значит, я с бодуна вот что придумал.

Универсальный Критерий Угребищности Систем Общего Назначения. (Теорема лавсана)

Система Общего Назначения является Угребищной тогда и только тогда когда она не является Метациклическим Интерпретатором.

Другими словами: Система, не способная к построению Метасистемы в рамках самой себя, то есть не способная к описанию и изменению самой себя в своих же терминах, и при этом являющаяся Системой Общего Назначения(в какой-либо области), Угребищна.

Обратное, естественно, неверно. Если Метасистему Системы Общего Назначения можно описать другой системой, это совершенно не значит что она Угребищна, и более того, в таком случае не существовало бы концепции бутстрапа, а значит и Метациклических Интерпретаторов вообще.

Чем, в контексте языков программирования, это отличается от просто тьюринг-полноты?

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

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

Примеры, сначала метациклических интерпретаторов:

• Универсальная машина Тьюринга
• RASP-машина
• Реляционная модель данных
• Лисп

А вот скажем примеры систем, соответствующих критерию:

• Среднестатистический современный регистровый процессор
• Большинство языков программирования, особенно со статической типизацией.
• Большинство NoSQL моделей данных или скажем иерархических моделей данных, вроде файловых систем

В частности, давайте посмотрим на C#. C# не является метациклическим интерпретатором, т.к. термины языка не являются его же объектами.

Отчасти, это компенсируется платформой .Net, для которой термины C#(но не все) объектами таки являются(System.Reflection, грядущий Roslyn и т.д.), отчасти, в самой малой степени, фичей nameof() из C# 6, но это все только отчасти.

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

Дискач.

UPD. Собственно, отличнейшую статью нашел на эту тему: http://weblog.raganwald.com/2006/11/significance-of-meta-circular_22.html