Лидер сообщества Ubuntu представил стек для унификации GUI приложений

GObject - нужен для OOP ABI между языками.

Какое прямое решение? Прямое решение - это когда разрабы MSVC, FreePascal, GCC/g++, SunStudio, intel C++ возьмутся за руки и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

> Прямое решение - это когда разрабы MSVC, FreePascal, GCC/g++, SunStudio, intel C++ возьмутся за руки и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

Си++ ABI давно уже есть. Непонятно, правда, нафиг тебе поддержка MSVC - его под Линукс нету.

А как насчет не только С++, а еще поддержка ООП в языках где ООП нету, в скриптовых языках и прочем. Добавьте сюда FreePascal или еще что-то там.

GObject - универсальное ABI для всех языков.

> GObject - нужен для OOP ABI между языками.

и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

Майкрософтовцы хорошую идею ведь предложили, как ни крути - P/Invoke. В большинстве случаев не требуется из низкоуровневого языка вызывать высокоуровненвые методы. Обычно наоборот. И тут приходит на помощь P/Invoke. Бинарная совместимость ить нужна для легаси в основном. В плане реализации наработки есть у моны - бери, используй. Нет ведь, костылят-костылят...

Также прямое решение - это разные бэкенды для легаси-проектов. Т.е. имеем ява-подобную библиотеку классов, а транслятор, в зависимости от бэкенда для ГУИ, транслирует вызовы методов в ГТК, КДЕЛИБС, или ещё какое гниющее поделие. Когда легаси вымрут и десктоп для линукса унифицируются, можно иметь уже собственную реализацию.

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

акое прямое решение? Прямое решение - это когда разрабы MSVC, FreePascal, GCC/g++, SunStudio, intel C++ возьмутся за руки и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

> А как насчет не только С++, а еще поддержка ООП в языках где ООП нету

Зачем?

в скриптовых языках и прочем.

А, понятно. Еще один мечтатель.

GObject - универсальное ABI для всех языков.

GObject головного мозга.

> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++)

Pascal уже есть.

плюс компиляция в натив минуя всякие виртуальные машины.

Виртмашины сильно помогают в отладке, в диспетчеризации и в сборке мусыря. Другое дело, что они бывают плохие и медленные (Java) и хорошие и быстрые (Lua, новые движки JavaScript). Надо быстрые виртмашины.

Ну и, попробуйте Haskell.

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

Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

низкоуровневые библиотеки, самое ядро, вообще не должны использовать ООП. ООП должен быть уже на уровне биндингов

> В плане реализации наработки есть у моны - бери, используй.

Этого не будет, причины известны.

. Т.е. имеем ява-подобную библиотеку классов, а транслятор, в зависимости от бэкенда для ГУИ, транслирует вызовы методов в ГТК, КДЕЛИБС, или ещё какое гниющее поделие.

Вы плодите сущности (еще одну либу) на основе личной уверенности что Gtk или Qt гниют. А они нормально поживают. Унифицированность - враг конкуренции. И то и то - хорошо.

Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

Как в нативе сделать garbage collection? Вирутальные машины сделаны по причинам. Почему они большие? Потому что они универсальные - Java решат любую проблему программирования. Это полноценная платформа, на котором можно написать почти что угодно. Почему их такими большими сделали? Потому что корпорации, которые над ними работали не могут позволить себе тратить деньги на легковесные поделки, которые ничего не умеют. Они хотят сделать плафторму, про которую можно сказать «Она умеет все». Причем на всех платформах, быстро, безопасно и легко. В итоге раздулись они по размеру в ОЗУ, хоть и быстро работают.

> что они бывают плохие и медленные (Java)

Иди сюда и смотри http://shootout.alioth.debian.org/

Много там жабку обгоняют?

>> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++)

Pascal уже есть.

Угу, только комьюнити под него в линуксе довольно ограниченное количественно и качество, да к тому же «си-подобный синтаксис» уже стал стандартом де факто

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

С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;) Насчёт отладки спорновато. По-моему, одинаково процесс идёт.

> Как в нативе сделать garbage collection? Вирутальные машины сделаны по причинам.

http://www.digitalmars.com/d/

Почему они большие? Потому что они универсальные - Java решат любую проблему программирования.

Что такое «проблемы программирования» и как их решает Java и почему их «не решает» любой другой Тьюринг-полный ЯП без ВМ?

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

Нет. Потому что компания Sun и Гослинг в частности - феерические балбесы. А команда .Net тупо скопировала значительную часть их ошибок.

Никаких принципиальных причин делать ВМ столь монструозной и монолитной не было.

> Иди сюда и смотри http://shootout.alioth.debian.org/

Много там жабку обгоняют?

Надо понимать, что на шутауте тестируют числодробилки. Числодробление в жабе разогнали на ура, факт. Это всё очень мило и приятно. Но от попыток использовать на десктопе жабные приложения (Vuze, Eclipse, Netbeans) меня подташнивает до сих пор (2 Ггц Core2Duo, 3 Гб памяти).

Жаба быстро работает. Она очень медленно всё подгружает. Ну и с гуями там всё не сильно радостно.

> Что такое «проблемы программирования» и как их решает Java и почему их «не решает» любой другой Тьюринг-полный ЯП без ВМ?

Вы видели библиотеку классов Java SE? А Java EE? А JavaFX? Когда кто-то говорит, что Qt - самая мощная платформа, я смеюсь

> Как в нативе сделать garbage collection? Вирутальные машины сделаны по причинам

Так же сделать, как и сделаны виртуальные методы в С++. Программа хранит в себе небольшой прекомпилированный оптимизированный набор внутренних структур, которые располагают информацией о типах (в с++ же есть RTTI). Типы хранят набор смещений, по которым хранятся ссылки на объекты в куче. Каждый объект хранит в себе ссылку на такую структуру-тип. Только этого уже достаточно для реализации compacting gc. В плане стека для скорости можно сделать исключение, и там сделать partly-консервативный GC, т.е. все сканируемые значения стека считаются ссылками по умоланию и в результирующей сборке by compacting gc игнорируются.

Настраиваем опции. У вас много ОЗУ? Делаем -Xbatch и вперед.

С гуями в жабе - очень мощно. Swing - хоронит и QtGui, и Gtk, и Cairo. Если вам не нужна его мощность, то можно юзать в жабе байндинги. Приложения на java-gnome очень легковесные. Я пробовал.

> да к тому же «си-подобный синтаксис» уже стал стандартом де факто

Сам факт предложения питона в данном стеке говорит о том, что «си-подобный» быдлосинтаксис уже давно не догма.

С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;) Насчёт отладки спорновато. По-моему, одинаково процесс идёт.

Нативный код отлаживается только когда к нему отладчик присосан. Код в виртуальной машине ВСЕГДА работает в «отладочном» режиме. Если у пользователя на другом конце планеты что-то где-то упало - он заведомо сможет предоставить вменяемый трэйсбэк.

С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;)

Где я писал «незаменимо»? Помогает. Перемещающий сборщик без ВМ будет писать довольно затруднительно.

> С гуями в жабе - очень мощно. Swing - хоронит и QtGui, и Gtk, и Cairo.

Мне пофиг кого он там хоронит. Я как пользователь говорю. Все жабные приложения уже выглядят ещё не мерзотно (5-10 лет назад), но всё ещё неуютно.

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

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

> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

ты только что написал про D. уборка мусора там тоже есть, кстати. Это тем, кто начинает кричать, что нельзя организовать ГК без виртуальной машины.

> Все жабные приложения уже выглядят ещё не мерзотно (5-10 лет назад), но всё ещё неуютно.

Мне Nimbus больше нравится, чем стандартная тема Ubuntu и темы в Windows

> Если у пользователя на другом конце планеты что-то где-то упало - он заведомо сможет предоставить вменяемый трэйсбэк.

Опять мимо :) -rdynamic (в ELF'е, насчёт PE не знаю) + backtrace_symbols_fd + сигналирование тебе в помощь. Когда моё поделие на си сегфолтит, оно рисует полный стектрейс. Для этого виртуальная машина опять не нужна.

Какие ключи именно вы для этого указываете? Хочу попробовать

> Все эти свистелки и перделки реализуемы в нативе, причём с оверхедом максимум в пару сотен кб машинного кода.

Ну реализуйте. Потом заметите, что у вас по факту получилась собственная ВМ.

> Когда моё поделие на си сегфолтит, оно рисует полный стектрейс.

Даже когда оно затерло стек вызовов? Сказки.

Ну хотябы когда не затерло. Это тоже хорошо. Устал запускать для этого под valgrind. Программа тормозит сильно.

>> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

ты только что написал про D. уборка мусора там тоже есть, кстати. Это тем, кто начинает кричать, что нельзя организовать ГК без виртуальной машины.

забыл упомянуть «стройная, унифицированная библиотека классов», чего не скажешь о Д.

> Си++ ABI давно уже есть.

Дай пруф, я не в курсе.

Причем человек еще вычеркнул MSVC, на котором компилируют ой какую часть софта. Нормальный тулкит должен каким то образом дружить и сдругими компиляторами. А то программа на одном билде Qt падает с другим билдом Qt. Для Gtk-приложений это анекдот, но для Qt - суровая реальность.

> Даже когда оно затерло стек вызовов? Сказки.

Назови случаи, когда оно затирает стек вызовов.

Вот пример из моего фреймворка, вставил в функцию кривой указатель в release-mode (безымянные функции, потому что static):

Unhandled: 'cfAccessViolationException_ID: Attempt to read or write protected memory'

Thread: 'Main'.

Stacktrace:

./cf[0x8053f36]

[0x66a410]

./cf(window_OnLoad+0x47)[0x804e03b]

./cf(cfWindow_Show+0x2a5)[0x80524b9]

./cf(__cfMain+0xd7)[0x804e226]

./cf(main+0x20)[0x804e143]

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x2eeb56]

./cf[0x804de51]

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

http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

-rdynamic

Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.

Но оно у меня не отображает static-функций. Но это си. В случае реализации отдельного языка ничто не мешает ему линковать static-функции как неstatic, т.е. добавлять имя в образ. И тут ВМ совсем не нужна :)

>> Си++ ABI давно уже есть.

Дай пруф, я не в курсе.

Тебя в гугле забанили?

http://www.delorie.com/gnu/docs/gcc/gcc_110.html:

«Starting with GCC 3.2, GCC binary conventions for C++ are based on a written, vendor-neutral C++ ABI that was designed to be specific to 64-bit Itanium but also includes generic specifications that apply to any platform. »

> Ну реализуйте. Потом заметите, что у вас по факту получилась собственная ВМ.

Не отличайте runtime от virtual machine? В С++ есть vtbl, таблицы исключений, опциональный RTTI. И С++ от этго не стал ВМ внезапно. Рантайм станет ВМ только тогда, когда он начнёт опираться на байткод и иметь все нужные инструменты для работы с ним. А в моём предложении байткода нет.

>> Даже когда оно затерло стек вызовов? Сказки.

Назови случаи, когда оно затирает стек вызовов.

Указатель на автоматическую переменную (или alloca) + выход за границу массива; просто неинициализированный указател, направленный в стек.

Но это вилами по воде. Пишите, когда напишете приложение на GCC, которое будет юзать классы из библиотеки на С++, которая написана на MSVC. Или наоборот.

>> С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;)

Где я писал «незаменимо»? Помогает. Перемещающий сборщик без ВМ будет писать довольно затруднительно.

С чего вы взяли? Как я уже сказал, нужен RTTI (который есть в с++) и интеграция потоков в райнтайм (ЕМНИП, это есть даже в glibc) для останова всех потоков. Заметьте, glibc и с++ ВНЕЗАПНО не считаются ВМ.

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

>>> Даже когда оно затерло стек вызовов? Сказки.

Назови случаи, когда оно затирает стек вызовов.

Указатель на автоматическую переменную (или alloca) + выход за границу массива; просто неинициализированный указател, направленный в стек.

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

> Пишите, когда напишете приложение на GCC, которое будет юзать классы из библиотеки на С++, которая написана на MSVC. Или наоборот.

Ну, собери мне Линукс-приложение компилятором MSVC, я посмотрю, что можно сделать.

А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Именно. Простым memcpy часто бывает если не правильно размер задать.

> Хах, это если только писать на голом си вручную

Ну ты похвалялся, как круто у тебя Си-приблуда показывает бэктрейс, не?

> Ну, собери мне Линукс-приложение компилятором MSVC, я посмотрю, что можно сделать.

Во-первых я привожу пример просто другого компилятора, несмотря на то, что без ABI на винде вам будет грустно. Будете все ваши либы с нуля на MSVC компилить, чтобы его оттуда могли использовать. Но если послушать ваши выкрики «не нужно!» по поводу разработки под винду и даже с ними согласиться, то разве правильное техническое решение не должно учитывать все ситуации, даже такие. Они взяли и решили проблему разных компиляторов.

А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Я уверен, что это возможно. Основа заложена. Конечно этот обьект должен быть тоже GObject, что будет обеспечено инфраструктурой связи. Но в основном связь наоборот. И тогда все прекрасно.

> С чего вы взяли? Как я уже сказал, нужен RTTI (который есть в с++) и интеграция потоков в райнтайм (ЕМНИП, это есть даже в glibc) для останова всех потоков.

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

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

>> Хах, это если только писать на голом си вручную

Ну ты похвалялся, как круто у тебя Си-приблуда показывает бэктрейс, не?

Нет :) Там человек утверждал, что для вывода адекватного бектрейса обязательно наличие ВМ. У него свет клином сошёлся на слове «ВМ» :)

> Там человек утверждал, что для вывода адекватного бектрейса обязательно наличие ВМ.

Враньё.

Я утверждал, что ВМ _может гарантировать_ вывод адекватного бэктрэйса. Конечно, и без неё можно худо-бедно обойтись. Но полноценное решение как-то привлекательнее.

> Будете все ваши либы с нуля на MSVC компилить, чтобы его оттуда могли использовать.

Э? Библиотеки на чистом Си вроде бы совместимы у MSVC и GCC. Ну а для Си++ GObject просто нерелевантен.

А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Я уверен, что это возможно.

Это возможно _реализовать_, если кто-то напишет мост между GObject и объектной моделью Питона. Точно так же можно написать мост между GCC C++ ABI и MSVC ABI (если MSVC появиться на Linux).

GObject - это объекная модель, которую можно использовать в Си, не более (а можно и не использовать).

> Угу, управление выполнением кода вам понадобится.

Единственное управление - это останов потоков. Всё.

И изоляция от чужого нативного кода, не подлежащего перемещаемому GC

М? Вы знаете, как в compacting-gc выделяется память вообще? Она предвыделяется большущими сегментами по n МБ. Вероятность того, что нативная память каким-то образом overlapped с managed - равна нулю, если вы об этом. Мы прогоняем сборщик мусора только по таким сегментам. Мы никаким образом не пересекаемся с native-памятью. Алсо, никто не мешает завести отдельную кучу. Проверка на вхождение абсолютно lightweight-задача.

P/invoke-ссылки из managed-объектов в native-объекты просто не располагаются в таблицах смещений ссылочных объектов. Т.е. ссылки на нативную память ещё в compile-time определяются как «value types» и gc просто не берёт их в расчёт (у нас же не консервативный GC который ничего не знает о типах!).

А вот в случае со стеком, ссылкам в стеке для скорости лучше вести себя как Boehm-GC, т.е. если присходит ложное срабатывание, то ничего плохого не происходит, мы просто отсрочиваем сборку данного объекта (кем бы он ни был), тем самым не повреждая ничго.

> Они взяли и решили проблему разных компиляторов.

Виндовое решение разных компиляторов и, даже, языков называется .Net. Там очень много известных недоделок C++ пофиксили. При этом искусственно создали новые.

> GObject - это объекная модель, которую можно использовать в Си, не более (а можно и не использовать).

Это модель из которой потом автоматически генерируются байндинги на ваш С++, пайтон и прочее

>> GObject - это объекная модель, которую можно использовать в Си, не более (а можно и не использовать).

Это модель из которой потом автоматически не генерируются байндинги на ваш С++, пайтон и прочее

fxd

Или предъяви уже генераторы байндингов для Питона и Си++.

> Swing - хоронит и QtGui, и Gtk, и Cairo.

Нельзя так не любить людей >_<

>вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++)

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

>Нормальный тулкит должен каким то образом дружить и сдругими компиляторами

что как раз и подтверждает нормальность Qt (gcc, icc, msvc, sun studio, aCC). Если у каких-то компиляторов нет интероперабельности (пример - gcc и msvc), это не вина тулкита

>Вы видели библиотеку классов Java SE? А Java EE? А JavaFX? Когда кто-то говорит, что Qt - самая мощная платформа, я смеюсь

Но Qt нативно => удобно на десктопе, JIT-компиляция эффективна только при большой продолжительности работы приложения

Да и на мой взгляд в QtGui многие вещи сделаны продуманнее, чем в Swing (хотя определенное сходство очевидно)

>И инкрементальную сборку уже требует исторический момент.

имхо, скорость компиляции - дело десятое по сравнению со скоростью выполнения

> имхо, скорость компиляции - дело десятое по сравнению со скоростью выполнения

Инкрементальная сборка мусора, дорогой товарищ. Речь о ней.

>Инкрементальная сборка мусора

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

> А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Это и так работает. Например, в программе на PyGTK можно написать модель для TreeView (IconView, ComboBox) отнаследовавшись от существующей модели или просто реализовать интерфейс TreeModel и эта модель будет нормально вызываться/использоваться самим GTK.

(Аналогично работают объекты в лиспе с cl-gtk2).

>> А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Это и так работает. Например, в программе на PyGTK можно написать модель для TreeView (IconView, ComboBox) отнаследовавшись от существующей модели или просто реализовать интерфейс TreeModel

Потому что кто-то постарался и написал байндинги для Python для GTK // К.О.

А вот произвольный объект Python ты через GObject не вызовешь, так что про «ABI» говорить не приходится.

Потому что кто-то постарался и написал байндинги для Python для GTK // К.О.

А вот произвольный объект Python ты через GObject не вызовешь, так что про «ABI» говорить не приходится.

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

>> А вот произвольный объект Python ты через GObject не вызовешь, так что про «ABI» говорить не приходится.

А вот те, кому хватает непроизвольных объектов, те и работать будут. а вам удачи в передаче произвольных объектов.

Мне это не нужно, но всё равно спасибо.

Знаетет, это возражения из разряда: [i]Ворд гораздо лучше ТеХа

Какой полет фантазии.

. Все жабные приложения уже выглядят ещё не мерзотно (5-10 лет назад), но всё ещё неуютно.

ё! ну не правда же... смотрим на xmind и люто-бешено удивляемся

> ё! ну не правда же...

У меня сложилось именно такое мнение.