кроссплатформенные кроссязыковые библиотеки

библиотека на си и ffi из соответствующего языка

Библиотеку на питоне использовать в С++? Месье тонкий извращенец. Наоборот, вполне можно - PyQt тому пример. Из Perl можно библиотеки сишные подключать.

Vala вообще к gobject прибита.

Библиотеки написанные на C вообще можно прикрутить практически ко всему.

winrt основан на дотнете, сиречь виртуальной машине и имеет в основе байткод. Соответственно в ляликсе (да и в винде пожалуйста тоже) комбинируй по самое нехочу библиотеки Java, Scala, Groovy, JRuby, Jython etc.

чтобы библиотеку написанную на Python использовать в коде на Java, и вызывать из C++ и C# - вот такой вот адский микс? есть ли необходимость этого?

Как правило такое называется быдлокодерством.

Программы на С встраиваются относительно просто в любые языки кроме пожалуй Java и Perl

mono имеет простой совместимый интерфейс с С и поддерживает достаточно много живых реализаций.
С, С++, Python, Perl6, VB, Java, Boo(похож на статически типизированный Питон), Javascript, Lua, PHP и многие другие с помощью mono могут быть исполнены хоть на iOS хоть на Windows

Vala вообще к gobject прибита

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

Прошу прощения, но вам наверное известно о ICE, CORBA и т.п. где крупные модули на базе различных языков и платформ свободно взаимодействуют друг с другом? Как язык-то повернулся назвать это быдлокодерством?

Ясно что один проект и одну библиотеку всегда пишут на одном языке, а что если я хочу экспортировать <библиотеку на питоне> для использования и в C++ и в Java? Вот написали протокол сложный на базе питона, целая библиотека, и теперь появилась необходимость работать с этим из Ruby?

LORCode не работает, поэтому добавлю просто так

Пример сода на niecza Perl6 который взаимодействует с моно библиотеками


constant $DRAWING = «System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a»;
constant $FORMS = «System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089»;
constant Font = CLR::(«System.Drawing.Font,$DRAWING»);
constant MenuItem = CLR::(«System.Windows.Forms.MenuItem,$FORMS»);
constant Shortcut = CLR::(«System.Windows.Forms.Shortcut,$FORMS»);

# Application variables
my $filename;
my $modified = False;

# The TextBox does all the interactive text editing
my $textbox = CLR::(«System.Windows.Forms.TextBox,$FORMS»).new;
$textbox.Font = Font.new(«Mono», 10);
$textbox.Dock = CLR::(«System.Windows.Forms.DockStyle,$FORMS»).Fill;
$textbox.Multiline = True;
$textbox.WordWrap = False;
$textbox.AcceptsTab = True;
if @*ARGS { # Allow passing a file name from the command line
$filename = @*ARGS[0];
$textbox.AppendText(slurp $filename); # TODO: replace with the following:
# $textbox.Text = slurp $filename;
# $textbox.Modified = False;
# $textbox.DeselectAll;
# TODO: but these leave all the text *selected* :P
}
$textbox.add_TextChanged(&TextChanged);
$textbox.ScrollBars = CLR::(«System.Windows.Forms.ScrollBars,$FORMS»).Both;

# Define Menu and MenuItems
my $menuFile = MenuItem.new(«&File»);
$menuFile.MenuItems.Add(MenuItem.new(«&New», &New, Shortcut.CtrlN));
$menuFile.MenuItems.Add(MenuItem.new(«&Open», &Open, Shortcut.CtrlO));
$menuFile.MenuItems.Add(MenuItem.new(«&Save», &Save, Shortcut.CtrlS));
$menuFile.MenuItems.Add(MenuItem.new(«Save&As», &SaveAs, Shortcut.CtrlA));
$menuFile.MenuItems.Add(MenuItem.new(«E&xit», &Exit, Shortcut.CtrlQ));
my $menu = CLR::(«System.Windows.Forms.MainMenu,$FORMS»).new;
my $menuEdit = MenuItem.new(«&Edit»);
$menuEdit.MenuItems.Add(MenuItem.new(«&Undo», &Undo, Shortcut.CtrlZ));
$menuEdit.MenuItems.Add(MenuItem.new(«Cu&t», &Cut, Shortcut.CtrlX));
$menuEdit.MenuItems.Add(MenuItem.new(«&Copy», &Copy, Shortcut.CtrlC));
$menuEdit.MenuItems.Add(MenuItem.new(«&Paste», &Paste, Shortcut.CtrlV));
$menu.MenuItems.Add($menuFile);
$menu.MenuItems.Add($menuEdit);

# The form is the main application window
my $form = CLR::(«System.Windows.Forms.Form,$FORMS»).new;
$form.Size = CLR::(«System.Drawing.Size,$DRAWING»).new(600,400);
$form.Menu = $menu;
$form.Controls.Add($textbox);
setformtitle();
CLR::(«System.Windows.Forms.Application,$FORMS»).Run($form);

Да, кстати, есть ещё Google Protobuffers, тоже есть некое описание на некотором языке, и оно отображается в C++ Python и Java, с работал с этим protobufs...

Не совсем так... А как же тогда обычные С++ проги там допускаются? Равно как и JS? Мне кажется это не совсем так.

В общем, почитал, кажется нашел ответ на свой вопрос... Что нет такого кроссплатформенного решения, в котором подобное генерировалось бы просто так само собой.

Везде надо применять специальные меры, причем что Google Protobuffers (с этим я работал), что Facebook Thrift и прочие реализации обычно подразумевают некий обобщенный формат, который затем уже компилируется к тому или иному языку, т.е. обычный RPC. Так что ясно.

winrt основан на дотнете, сиречь виртуальной машине и имеет в основе байткод.

В основе WinRT - COM и нативный код.

В основе WinRT - COM и нативный код.

угу, именно так

кстати, изучаю сейчас Facebook/Apache Thrift... после Google Protobuffers мне кажется это более простая вещь, да и результирующие классы не такие геморные как у Protobuffers

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

Хотя, если вынести это в отдельный модуль, то будет не так зависимо.

Остаётся моно, в которм можно писть и на Java и на C# и на Python и на Lua и затем общаться без RPC

а что если я хочу экспортировать <библиотеку на питоне> для использования и в C++ и в Java?

Только RPC.

А встраивание и Jyton?

Просто, если мы говорим о линуксе, то там Py уже встроен по умолчанию, jyton и java репы хранят. Таким образом встраивание вполне вариант

Для использования в Си++?

Ну API стандартизировано и для С++ у питона, а для полной работоспособности там там по-моему только dev пакет нужен

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

Ну API стандартизировано и для С++ у питона

То есть ты предлагаешь для использования из Си++ встроить в программу Python, а для использования из Явы - Jython?

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

Ну а почему нет

Ты пробовал использовать API python-библиотеки из Си++? Не API Python, а именно API, экспортируемый библиотекой.

для RPC то же дополнительные приблуды понадобятся

Они, скорее всего, уже готовы. И пишутся раз и навсегда.

Согласен что дергать API библиотеки через PyObject не самое удобное занятие, хотя опять же, если мы рассматриваем локальный случай тогда лучше d-bus с разделением на процессы, а не городить сложные системы с сетевым прицелом.

Согласен что дергать API библиотеки через PyObject не самое удобное занятие

Это еще мягко говоря.

если мы рассматриваем локальный случай тогда лучше d-bus

dbus - это уже RPC. Делать RPC чисто локальным - глупо, мы поимеем весь гемор от перехода на RPC, но никаких профитов.

Признаю что был неправ, когда освежил данные про D-Bus

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

перебор, но куда деваться? как вызывать Java из C++ и JavaScript?

но хочу сказать что GPLный ZeroC ICE хорошо, но лицензия аяяй, но там есть ценная вещь - быстрый вызов методов если на одной машине работает, что-то там я помню сделали для C++-версии, я не уверен, но слышал

нравится еще мне Apache/Facebook Thrift, мощнее чеч Protobuffers от Google потому можно описать сервисы так, что методы можно вызывать синхронно, т.е. работать с удаленным объектом или на другом языке как со своим родным, можно и асинхронно

я почему задумался на эту тему, потому что некросовт наступает со своим ненужным winrt, но идея интересная, но у нас в UNIX-like есть кроссплатформенный аналог этому безобразию :)

поимеем весь гемор от перехода на RPC, но никаких профитов

А как же возможность писать на любом языке независимо от того что мы вызываем? ЕМНИП это был один из широко разрекламированных профитов в локальных RPC.

интересно, есть ли пример локальных RPC (помимо D-Bus, который собирались и даже реализовали, запихать в ядро Linux), которые используют не loopback, а что-то другое на локальной машине в целях ускорения вызова метода и вообще для снижения нагрузки...

Любой язык умеет взаимодействовать с библиотеками на C. Многие умеют с C++. Те, что для JVM, отлично взаимодействуют между собой, аналогично в мире Mono.

....

=> PROFIT. Проблема по большей мере надумана.

... и аналогично с Mono: C#, JScript, IronRuby, IronPython, Nemerle, IronLisp, IronScheme, Clojure.NET, Java (и всё, что на ней и/или умеет исполняться под JVM)...

libpython и 100500 оберток к нему позволят тебе это сделать с C++. С Java можно идти тем же путем, что и в C++, но проще просто заюзать Jython. Аналогично с Ruby, с тем лишь отличием, что, в отличии от Jython, JRuby гораздо более готов к продакшену.

ненене, когда изначально тебе надо связать какую-то ОДНУ библиотеку, которую ты хочешь написать лишь один раз, например на C++, вызывать из питона и многих других

иногда бывает так надо...

нравится еще мне Apache/Facebook Thrift, мощнее чеч Protobuffers от Google потому можно описать сервисы так, что методы можно вызывать синхронно, т.е. работать с удаленным объектом или на другом языке как со своим родным, можно и асинхронно

Это всетаки разные вещи, protobuf - просто способ эффективной сериализации, thrift - целый стек для реализации связи между какими-нибудь компонентами.

ZeroMQ

на локальной машине этот zeromq через что работает?

бенчмарки есть?

http://www.boost.org/doc/libs/1_50_0/libs/python/doc/ - взаимодействие в обе стороны.

Java из C++ - нет проблем. http://stackoverflow.com/questions/819536/how-to-call-java-function-from-c

Java из Javascript - Rhino.

// и в контексте RPC: почему никто про msgpack не вспомнил?

На локальной машине любой RPC работает.

ZeroMQ - самый «легкий и быстрый» среди всех MQ. И его, кстати, можно использовать с protobuf.

соответственно его и с Thrift можно использовать, ибо что за сериализатор который не умеет в память выдавать, я таких не знаю :)

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

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

То же самое возможно между языками, использующими jvm как целевую платформу. Друг друга они могут использовать свободно, но для других языков придется подключать отдельные прослойки. Нативный код на С/С++ может работать с jvm и наоборот.

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

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

Мсье крупный эксперт по гетерогенным платформам? Ну-ну.

Проблема не надумана - просто, похоже, в твоем опыте не было сотни полторы проектов написанных на всём (Java, C#, F#, Python, C++, VB(A)... + 100500 сторонних продуктов), причем значительная часть проектов требует своего кластера для работы - и всю эту кучу-малу надо как-то интегрировать в одно целое.

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

Смеешься? А... ты всего про один проект...

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

В принципе, из того, что пробовал. OTP/JVM/.NET - интероперабельны С/FreePascal - совместимость объектных модулей. CLISP имеет как минимум одностороннюю связь с JVM/.NET

из talks

Ссыклу отвечать не буду.

Ты быдло и дерьмо.

в твоем опыте не было сотни полторы проектов написанных на всём (Java, C#, F#, Python, C++, VB(A)... + 100500 сторонних продуктов)

В моем опыте был один проект, написанный на asp.Net под апач с модулями на делфи. Проблевался, больше не хочу.

А... ты всего про один проект...

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