Вышел язык програмирования Cobra 0.7.4

Предлагаю не называть. Предлагаю не выдумывать велосипедов.

http://en.wikipedia.org/wiki/Interpreter_%28computing%29

An interpreter may be a program that either

1. executes the source code directly

2. translates source code into some efficient intermediate representation (code) and immediately executes this

3. is invoked to explicitly execute stored precompiled code[1] made by a compiler which is part of the interpreter system

По этому определению, например, JVM без JIT - интерпретатор, но javac всё равно компилятор и JVM с JIT или AOT - компилятор. Отдельно и независимо от javac.

> А у германии было Поражение... и ничего, тоже живут, и ты знаешь получше нас... это тоже благодаря Поражению?

У них не поражение было, а освобождение от нацистской диктатуры. В которое (освобождение) и сам народ Германии вложился - в особенности немецкие коммунисты, которые вели войну с нацистским режимом.

> В фракталах не специалист.

Если бы только во фракталах. Ты ни в чем не специалист, ребенок.

> Кстати, конструктивизм не приемлет некоорые теоремы из матанализа, считая их недоказанными. Увы, за давностию лет не помню какие.

теорема об ограниченности на отрезке непрерывной функции

> Где описан алгоритм, позволяющий выяснить -- интерпретатор этот код, или нет?

Например, у Рейнольдса. Читать про операционные и денотационные семантики и про семантику интерпретатора.

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

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

>3. is invoked to explicitly execute stored precompiled code[1] made by a compiler which is part of the interpreter system

по одному этому пункту и дырка с шеллкодом -- интерпретатор. Просто "part of the interpreter system" -- снаружи, отдельно. Так что неоднозначное определение. Вот если все три пункта потребовать, чтобы выполнялись, то да, мухи -- отдельно, котлеты -- отдельно.

//dm

>> Так чем Ваш способ лучше?

> Мы с вами это уже обсуждали:

Следует полагать, что дискуссия зашла в тупик? :)

> gaa>То есть авторы сторонних поделок постоянно должны следить за изменениями в сопутствующих либах. И без этого ну никак не должна апгрейдиться используемая версия библиотеки?

> да. Окружение, в котором собирается программа, должно быть воспроизводимым. К чему приводит несоблюдение этого принципа наглядно видно при попытках откомпилировать в новом ядре Линукса старый софт с с куском в виде драйвера, под старую версию gcc/libc/ядра. Он просто не соберётся новым gcc или с новым ведром, в котором старый API выкинули.

Ну сам же в примере и показал, что нехорошие версии начинаются _именно_ из-за смены API. Вот у меня до недавнего времени в системе болталась libstdc++5 наряду с 6 и всё равботало.

> Кстати, на твоём примере с tkLOR: если ты написал рецепты сборки на словах, то чайник сможет и не воспроизвести твою мега-программу. А ebuild в этом смысле уже полезней и формальней, и -9999 даже переживёт не один релиз твоей нетлёнки :)

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

> ну ты обрисовал венду.НЕТ c его кучами версий. Я тут недавно перегрузился в венду поиграццо, посмотрел места нет, стал смотреть подробнее kdirstat'ом и офигел. Несколько версий фреймворков, целиком, ага.

Вот-вот!

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

В дебиане это и без маскировок нормально работает :)

> Для этого нужны полные манифесты на всё, "внутренний" интерфейс API конкретным приложением, распределённый пакетный менеджер со слотами и маскированными пакетами, нормальные фреймворки "снизу вверх", а не наоборот.

Конечно можно. Но надёжность этой системы никак не повысится. Если разве что весь софт не загнать в один репозиторий и не считать номер версии API по версии заголовочных файлов в рамках репозитория :)

>Следует полагать, что дискуссия зашла в тупик? :)

Вы проницательны. Но при случае можно будет продолжить.

>Вот у меня до недавнего времени в системе болталась libstdc++5 наряду с 6 и всё равботало.

lucky you :) а у меня на Генте при смене libexpat.so сменился soname, поломали API, хотя версия была минорная. Пришлось пересобирать revdep-rebuild -X чтобы линкер ссылки обновил в бинарниках. А если их запускать из враппера, в котором ссылки перед запуском корректно проставлять на нужные либы, для каждой программы своя версия lib, то могут одновременно работать и v5.0 и v5.5. Ну то есть, quick and dirty hack с симлинком я сделать не могу, потому что при этом ещё что-то может сломаться, но если этот симлинк перед запуском для одной конкретной программы будет проставляться, как именно ей надо (и будет у разных программ разный) -- это решит проблему.

>Но надёжность этой системы никак не повысится. Если разве что весь софт не загнать в один репозиторий и не считать номер версии API по версии заголовочных файлов в рамках репозитория :)

там не только заголовочные, всё целиком брать надо.

ну вот в DVCS всяких в качестве версии branch-а GUIDы, поэтому легко плодить branch'и. В 0install в качестве номера ревизии-версии либы-пакета можно брать GUIDы, поэтому можно поставить одновременно v5.0 и v5.5. И запускать сам софт из sandbox'а, который будет проставлять корректную ссылку на v5.0 или на v5.5, для программ AAA и BBB.

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

>> Вот у меня до недавнего времени в системе болталась libstdc++5 наряду с 6 и всё равботало.

> lucky you :) а у меня на Генте при смене libexpat.so сменился soname, поломали API, хотя версия была минорная. Пришлось пересобирать revdep-rebuild -X чтобы линкер ссылки обновил в бинарниках.

Рискую наткнуться на холивар, но мне кажется, что это проблема генты. Мне в моём Debian ни разу не приходилось сталкиваться с подобными проблемами. К тому же я видел в репозитории отдельно libssl0.9.7 и libssl0.9.8, что наводит на мысль, что это версии библиотеки с различными api для програм, как раз и рассчитанных на соответствующую версию. Хотя это никоим образом не защищает от криворукого мантайнера :)

> ну вот в DVCS всяких в качестве версии branch-а GUIDы, поэтому легко плодить branch'и. В 0install в качестве номера ревизии-версии либы-пакета можно брать GUIDы, поэтому можно поставить одновременно v5.0 и v5.5. И запускать сам софт из sandbox'а, который будет проставлять корректную ссылку на v5.0 или на v5.5, для программ AAA и BBB.

Проблема только в том, что этого Глобального Репозитория Для Всех Программ нет и не предвидится :)

>мне кажется, что это проблема генты.

собсно, да -- то, что в дебиане разгребает ментейнер, а остальные сидят на stable, в генте разгребает каждый -- сам себе ЗБ^H ментейнер, потому что портедж может обновиться в любой момент, включая промежуточный. Поэтому там проще починить самому отвалившееся или там кривой ебилд, чем ждать новых обновлений репозитория.

>Проблема только в том, что этого Глобального Репозитория Для Всех Программ нет и не предвидится :)

те же оверлеи дают конструктивный способ его построить :)

> собсно, да -- то, что в дебиане разгребает ментейнер, а остальные сидят на stable, в генте разгребает каждый -- сам себе ЗБ^H ментейнер

Ой, как там страшно :)

>> Проблема только в том, что этого Глобального Репозитория Для Всех Программ нет и не предвидится :)

> те же оверлеи дают конструктивный способ его построить :)

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

>А чем они лучше дебиановских виртуальных пакетов? Сорри, если путаю мокрое с красным.

виртуальные пакеты и в генте есть. В том смысле, что это метапакет вроде "весь гном" или "весь кде". Оверлеи -- в смысле, подключить альтернативный репозиторий и ставить всё из него. В самой системе и основной репе стабильный софт, а в левых репах -- testing.

>А чем они лучше дебиановских виртуальных пакетов?

Ничем. Это совершенно разные вещи. Оверлей -- "левый" репозиторий. Виртуальные пакеты тоже есть.

> виртуальные пакеты и в генте есть. В том смысле, что это метапакет вроде "весь гном" или "весь кде".

Это как раз метапакеты. Виртуальные -- это другое.

> Оверлеи -- в смысле, подключить альтернативный репозиторий и ставить всё из него. В самой системе и основной репе стабильный софт, а в левых репах -- testing.

Ясно, понял.

>> А чем они лучше дебиановских виртуальных пакетов?

> Ничем. Это совершенно разные вещи.

Понятно, спутал мокрое с красным :)

> Оверлей -- "левый" репозиторий.

Ааа, значит в дебе эта функциональность сидит в apt-е.