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

>На самом деле проблема есть и гораздо глубже, поскольку интерфейс ОТНЮДЬ не полностью формализует требования к чему-то.

Завязывай с тетраглюканом, речи о "формализации требований" в этой палате не идет.

>> То есть теперь мне надо завести 2 ветки для библиотеки libjopa: одну, в которой поправлена бага, а другую, в которой добавлена функция defecate() ? А если это нельзя или очень сложно сделать?

> Нет, зачем? Один объект может реализовывать несколько интерфейсов разом. Вы знаете про множетсвенно наследование в C++ или про интерфейсы в java?

Да всё я знаю, я вот только прошу Вас прикинуть, сколько гигабайт весило бы описание всех интерфейсов libc, если б их начинали записывать с самого начала.

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

> Мне кажется уже пора как-то формализовать выражение обратной совместимости либ. Ну например согласиться всем что должна быть статические переменные например CurrentVersion & СompatibleWithVersion

МУгу, может для либ на C это и прокатит. А как быть с другими языками?

> При том это полностью проблему не решит, а только 99.9, поскольку вроде несущественные изменения могут кого-то сильно затронуть ( пример: в php text2html вместо <br> стал ставится <br /> )

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

>Да всё я знаю, я вот только прошу Вас прикинуть, сколько гигабайт весило бы описание всех интерфейсов libc, если б их начинали записывать с самого начала.

Хм, раньше вы этого не просили, да и libc вроде как интерфейсов не содержит. С другой стороны хранить интерфейсы десятилетиями никто не рпедлагает, и я лишь привел вам способ решения проблемы, как и всегда устраняя одну проблему мы получаем новые, что не так?

>> Да всё я знаю, я вот только прошу Вас прикинуть, сколько гигабайт весило бы описание всех интерфейсов libc, если б их начинали записывать с самого начала.

> Хм, раньше вы этого не просили, да и libc вроде как интерфейсов не содержит.

Я развиваю идею. libc содержит функции(интересно, там есть pook() и defecate() ?) и этого достаточно, чтобы за ними как-то начинать следить.

> С другой стороны хранить интерфейсы десятилетиями никто не рпедлагает, и я лишь привел вам способ решения проблемы, как и всегда устраняя одну проблему мы получаем новые, что не так?

Сопутствующие проблемы оказались сильнее исходной :)

>Сопутствующие проблемы оказались сильнее исходной :)

Аргументируйте, пожалуйста, сей нетривиальный вывод.

Не надо ссылаться на русскую википедию. Русскоязычных специалистов мало, почти нет. Есть табуны шибко много о себе возомнивших самоучек, а настоящих специалистов в Computer Science просто и не готовят.

Так что всё там процитированное - полнейший бред. Читайте правильную, английскую википедию, там статьи не самоучки пишут, а нормальные люди.

>Слава Роботам уже наступила и людишки не нужны?

Компьютер должен работать, человек - думать (С)...кто-то там.

http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ib...

по моему вы все отступили от обсуждения языка

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

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

>Чтобы расписать поподробнее: вышла версия 1.0 библиотеки libjopa, на неё сослались программы AAA и BBB. Затем автор увидел, что в ней есть страшный баг, поправил его и выпустил libjopa 1.1. Но программы AAA и BBB продолжают юзать libjopa 1.0!

ну типа лежит такой в сети GlobalAssFramework v 1.0, в который входит libjopa, libhands, libhead, etc версий 1.0. потом программы ААА и BBB выходят, которые не юзают ничего, кроме libjopa.1.0. Поэтому в их манифестах ссылки только на libjopa. Потом автор патчит свою жопу, и выходит libjoba 1.1 (в составе GlobalAssFramework v 1.0 или 1.1 или1.2, как он там с головой и руками договорится). Выходит libjopa 1.1, на сайте появляется свежий манифест libjopa 1.1 в RSS, пакетный менеждер у автора ААА автоматом качает "вышла 1.1" через этот RSS, автор портирует изменения, и сам публикует в RSS анонс-манифест "вышла AAA v 0.1" .

Юзер, у которого установлена ААА v.0.0 с libjopa 1.0 и BBB v3.62 с libjopa 1.0 запускает кроном пакетный менеджер --sync. Тот качает RSS, видит, что появилась ААА v0.0 / libjopa v1.1, качает, устанавливает. В итоге, этот GlobalAssFramework достраивается в sandbox'е, в котором запускается соотв. программа. Для AAA v 0.1 подглючится libjopa v1.1, для BBB в sandbox подключится v1.0. Если BBB обновится на libjopa 1.1, то пакетный менеждер это узнает и сможет прибить libjopa v 1.0 как неиспользующуюся.

>А чистить неиспользуемые либы кто будет?

распределённый пакетный менеджер

>А баги в старых править?

автор программы/библиотеки

>Программам, которые используют только pook() на какую версию библиотеки ссылаться?

на любую, совместимую с нужной версией интерфейса

> ( пример: в php text2html вместо <br> стал ставится <br /> )

ну и кого это может "сильно затронуть"? унылых парсеров на ассемблере, которые грузят <br> movsd'ом?

>На самом деле проблема есть и гораздо глубже, поскольку интерфейс ОТНЮДЬ не полностью формализует требования к чему-то.

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

>Угу, может для либ на C это и прокатит. А как быть с другими языками?

а в чём тут может быть проблема, например, с Tcl?

>Ну за этим вообще чрезвычайно сложно уследить. Однако, примерно такой же уровень надёжности имеется и сейчас, когда версия API хранится в имени пакета, а новые версии пакета полностью заменяют старые.

если soname изменился, проблем особых нет. Запускать из враппера с LD_PRELOAD= конкретная версия_библиотеки, версии все есть в манифестах. Новые и старые версии библиотек лежат рядышком. Если soname не изменился, то да, в той же Gentoo придётся revdep-rebuild делать. Если исходники есть на всё , так проблем вообще нет никаких.

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

>> Сопутствующие проблемы оказались сильнее исходной :)

> Аргументируйте, пожалуйста, сей нетривиальный вывод.

Исходная проблема: новая версия библиотеки может поломать совместимость. Сейчас она оставлена на совесть автора и мантайнера.

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

> пакетный менеждер у автора ААА автоматом качает "вышла 1.1" через этот RSS, автор портирует изменения, и сам публикует в RSS анонс-манифест "вышла AAA v 0.1" .

> Для AAA v 0.1 подглючится libjopa v1.1, для BBB в sandbox подключится v1.0. Если BBB обновится на libjopa 1.1, то пакетный менеждер это узнает и сможет прибить libjopa v 1.0 как неиспользующуюся.

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

А если автор забъёт на свой продукт? Или под машину попадёт? Или по какой-то другой причине не станет проверять, совместима ли его поделка с новой версией libjopa?

Ну всё, готовьтесь к увеличению размера установленной системы в 100 раз как минимум. И так сейчас возникают ситуации, когда приходится иметь по паре версий либ(например, у меня стоят одновременно питоны версий 2.4 и 2.5), так, следуя Вашим словам, ещё будут стоять 2.4.1, 2.4.2 и т.д. И конца-края этой помойке не будет :)

>> Угу, может для либ на C это и прокатит. А как быть с другими языками?

> а в чём тут может быть проблема, например, с Tcl?

В том, что нет единого способа проверить эти версии для всех языков. Ибо в том же tcl статических переменных, как предлагалось, нет вообще.

>> Ну за этим вообще чрезвычайно сложно уследить. Однако, примерно такой же уровень надёжности имеется и сейчас, когда версия API хранится в имени пакета, а новые версии пакета полностью заменяют старые.

> если soname изменился, проблем особых нет. Запускать из враппера с LD_PRELOAD= конкретная версия_библиотеки, версии все есть в манифестах. Новые и старые версии библиотек лежат рядышком. Если soname не изменился, то да, в той же Gentoo придётся revdep-rebuild делать. Если исходники есть на всё , так проблем вообще нет никаких.

Угу, только вместо одной версии будет лежать 100. Ну ничё, юзер докупит винт побольше, оперативы пару планочек и процессор пошустрее ;)

>> Программам, которые используют только pook() на какую версию библиотеки ссылаться?

> на любую, совместимую с нужной версией интерфейса

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

>> Слава Роботам уже наступила и людишки не нужны?

> Компьютер должен работать, человек - думать (С)...кто-то там.

Как раз лозунг межделмаша. Н компутер пока что не в состоянии думать _лучше_ человека.

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

Да ты чо? А просто думать компьютеры уже умеют, да?

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

> Да ты чо? А просто думать компьютеры уже умеют, да?

Нет, просто некоторые люди уже разучились это делать или делают с отрицательным эффектом ;)

Зачем это нужно? оно ж deprecated! Решением министра УМВС сорцы Cobra были изьяты, а у всех скачавших - отформатированы винты. Причиной этому послужило(дальше слышно стук в дверь...)...

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

С вашей логикой, юзайте си или асм и не лезте в фреймворки ибо они озбыточны изначально, и очень много информации на "совести автора и менйтейнеров".

>Ваше решение: таскать за собой опупеннейшую кучу информации оверсиях и совместимости.

В каком месте она "опупенейшая"?

При решении первым способом вам придется ждать новой версии программы, при втором вам ждать ничего не придется.

>Ну я уже писал, что придётся тогда хранить постоянно растущий список совместимых версий интерфейса.

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

> При решении первым способом вам придется ждать новой версии программы, при втором вам ждать ничего не придется.

Первый -- это Ваш? Да, там придётся ждать новой версии. А что делать, если автор попал под машину? Выкидывать программу? Или таскать за собой ненужные зависимости?

>> Ну я уже писал, что придётся тогда хранить постоянно растущий список совместимых версий интерфейса.

> Зачем его хранить? Вы хотите поддерживать все музейные программы выпущеные за сто лет, илы вы будете менять интерфейсы по три раза надень?

Когда последний раз изменялась програма ls? Следуя Вашей логике, она уже "музейная" и её поддерживать не надо.

А она зависит от libc, в которой постоянно что-то меняется(месяца не проходит без выхода новой версии, следовательно интерфейся, не так часто, но изменяются).

>ДА ВАШУ МАТЬ!!!!! У ДОТНЭТА НЕТ! ПОНИМАЕШЬ? НЕТ И НИКОГДА НЕ БЫЛО ВИРТУАЛЬНОЙ МАШИНЫ!!!!

А ЧТО ЖЕ ТОГДА ТАКОЕ CLR, КАК НЕ ВИРТУАЛЬНАЯ МАШИНА?!!!

>>ДА ВАШУ МАТЬ!!!!! У ДОТНЭТА НЕТ! ПОНИМАЕШЬ? НЕТ И НИКОГДА НЕ БЫЛО ВИРТУАЛЬНОЙ МАШИНЫ!!!!

>А ЧТО ЖЕ ТОГДА ТАКОЕ CLR, КАК НЕ ВИРТУАЛЬНАЯ МАШИНА?!!!

Я тебе отвечу за YogSagot-a : он считает что CLR это рантайм. 

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

Вот пример, почему я считаю что С++ это в основном компилятор:

// g++ -static -static-libgcc -o test1 static_test1.cxx
#include <iostream>

int main(int argc, char** argv)
{
    for( int i=0; i<argc; i++ )
        std::cout << "arg #" << i << " is " << argv[i] << "\n";
}

// g++ -static -static-libgcc -o test2 static_test2.cxx
#include <stdio.h>

int main(int argc, char** argv)
{
    for( int i=0; i<argc; i++ )
        printf("arg #%d is %s\n", i,  argv[i]);
}

_______________________________________________

$ ls -l test*
-rwxr-xr-x  1 user user 1069267 Mar  8 15:47 test1
-rwxr-xr-x  1 user user  510517 Mar  8 15:40 test2

>Я тебе отвечу за YogSagot-a : он считает что CLR это рантайм.

Почитал http://en.wikipedia.org/wiki/Runtime и http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C... и не нашел разницу. В чем отличие рантайма от виртуальной машины?

> В чем отличие рантайма от виртуальной машины?

VM - это такой подвид рантайма, который (помимо прочего) умеет интерпретировать инструкции виртуальной машины (JVM в случае Java). А в .NET интерпретация CIL (формата стандартного кода промежуточного представления программ) официально нет, из-за чего всякие и орут о том, что "у .NET нет VM".

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

Сколько раз вам, ламерам, указывать на mono --aot?

Ламеры не знают, что такое интерпретатор. Ламеры раздражают.

>Первый -- это Ваш?

Первый это ваш и там все "оставлено на совесть мейнтейнера и автора", нешто память вас подводит.

>Когда последний раз изменялась програма ls? Следуя Вашей логике, она уже "музейная" и её поддерживать не надо.

ls использует интерфейсы, ну нифига себе.

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

С каких то пор в libc появились объекты ООП?

> А ЧТО ЖЕ ТОГДА ТАКОЕ CLR, КАК НЕ ВИРТУАЛЬНАЯ МАШИНА?!!!

А ЧТО ЖЕ ТОГДА ТАКОЕ ВНУТРЕННИЙ ФОРМАТ AST В GCC КАК НЕ ВИРТУАЛЬНАЯ МАШИНА?!!!!

>> Первый -- это Ваш?

> Первый это ваш и там все "оставлено на совесть мейнтейнера и автора", нешто память вас подводит.

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

>> Когда последний раз изменялась програма ls? Следуя Вашей логике, она уже "музейная" и её поддерживать не надо.

> ls использует интерфейсы, ну нифига себе.

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

> С каких то пор в libc появились объекты ООП?

Первая отмотка треда бесплатная: Не ваше ли сообщение было, где говорилось, что любая библиотека реализует какой-то интерфейс и его, следовательно, можно занумеровать?

>Первая отмотка треда бесплатная: Не ваше ли сообщение было, где говорилось, что любая библиотека реализует какой-то интерфейс и его, следовательно, можно занумеровать?

У вас включается троллинг на слово "любая"? Тогда выключайте его

http://www.linux.org.ru/jump-message.jsp?msgid=2560187&cid=2564107

Исходное сообщение, исходная проблема. Перечитайте весь тред.

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

> Сколько раз вам, ламерам, указывать на mono --aot?

> Ламеры не знают, что такое интерпретатор. Ламеры раздражают.

Ты даже русский не осилил. Читай: с *частью* от CLR

А то что твой интерпретатор можно слинковать с прогой и потом называть runtime -- никого не интересует.

Вопрос который я поставил -- можно ли в бинарник статически засунуть *половину* от CLR например? И ключики пожалуста... вон для gcc я ключики написал.

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

Какое странное определение интерпретатора.

>>Когда последний раз изменялась програма ls? Следуя Вашей логике, она уже "музейная" и её поддерживать не надо.

>ls использует интерфейсы, ну нифига себе.

ls действительно использует интерфейс libc.

strace ls . <...> fstat64(3, {st_mode=S_IFREG|0644, st_size=25081, ...}) = 0 old_mmap(NULL, 25081, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001800 <...>

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9...

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

> Какое странное определение интерпретатора.

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

Дело в том, что нельзя все строго разделить на компиляцию и интерпретацию. Вон printf ИНТЕРПРЕТИРУЕТ форматную строку. И что, после этого С -- интерпретатор? Я бы сказал что С это 1% интерпретации и 99% компиляции.

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

> Какое странное определение интерпретатора.

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

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

> Какое странное определение интерпретатора.

Сам прекрасно знаешь как трудно провести четку грань между к. и и.

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

А еще основная практически неприятная особенность и. -- то что в памяти висит куча ненужных либ (в т.ч. сам JIT). Вот к ней ПРАКТИЧЕСКИ и сводятся недостатки и. (так как JIT к-ю научились уже неплохо делать).

> http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9.. .

Сюрприз! Интерфейс бывает не только у ОО программы.

Вот libcurl написана и вызывается на С -- у нее что, нет интерфейса? А попробуй передай ей что-то не то?

>Сюрприз! Интерфейс бывает не только у ОО программы.

Сер, я речь веду именно об ООП интерфесах, если бы вы читали мои посты то узнали бы это из http://www.linux.org.ru/jump-message.jsp?msgid=2560187&cid=2564275

То что вы называете интерфейсом полностью зовется API.

http://en.wikipedia.org/wiki/Interface_%28computer_science%29

An interface defines the communication boundary between two entities, such as a piece of software, a hardware device, or a user.

По русски не так точно, но все же: Интерфе́йс (от лат. inter — между и лат. face — поверхность) — это семантическая и синтаксическая конструкция в коде программы, используемая для специфицирования услуг, предоставляемых классом или __компонентом__.

И что, вас еще раз ткнуть в то место где я говорил об интерфейсах из ООП, или вам это не поможет?

> Сер, я речь веду именно об ООП интерфесах > То что вы называете интерфейсом полностью зовется API.

хорошо, так как же быть с теми прогами, которые юзают не ОО интерфейсы, а API (например libc API)?

или будем прятаться за термином?

А GObject тоже имеет C API, и что, после этого у него нет проблем ОО интерфейсов???

> знаешь как трудно провести четку грань между к. и и.

Причем тут компиляция? Кто-то сомневается, что в .NET есть компиляция? А интерпретация - это исполнение кода без генерации в ходе этого нового "родного" кода процессора. Вот как раз такой режим у .NET отсуствует (если верить MS).

> То что вы называете интерфейсом полностью зовется API.

API == Application Programming Interface, _интерфейс_ прикладного программирования.

Так что меньше апломба. любезный :)