LINUX.ORG.RU

Сериализация, десериализация данных и _кода_, с уклоном на кросплатформенность. Какой язык предложите?


0

0

python, Java, .NET - отметаются, моно - может быть, если оно умеет, с C# пока не сталкивался. В общем задача на много времени вперёд(несколько лет как минимум), поэтому языки типо JS, lua и прочего - отметаются. По этой же причине вопрос этот решаться будет неспешно, так как ещё финансирование не созрело. Принимаются только те языки, которые можно назвать зрелыми и универсальными. Не обязательно, чтобы поддержка была такая однозначно простая, как у динамических языков. Можно и с костылями, но всё же тащить с собой скажем gcc - не особо хочется:), хотя и можется. Также жизненно необходима интеграция(человеческая, а не марсианская) с С, так как на нём предполагается ядро и все базовые компоненты и это не обсуждается. Язык же с сериализацией кода будет работать поверх этой созданной платформы. Рассматриваю пока в качестве кандидатов: C(не совсем удобно, но привычно, хотя в некоторых случаях придётся тащить большой багаж), perl5(почти идеальный вариант и по портируемости и по удобству, но производительность - это проблема), perl6(тоже что и предыдущий, но более идеальный, однако производительность паррота пока говно, и не ясно будет ли толковый JIT, ну и ещё ракудо не созрел),CommonLisp(кажется, что идеал, в виде sbcl, но это язык с которым у меня нет опыта, однако это не проблема. Производительность видимо не проблема, раз компилируемый. Вопрос сразу к лисперам, как оно там, при значительном динамическом обновлении рабочего кода, ничего?).

Отдельно замечу, что проект будет по архитектуре чем-то напоминать emacs, другое предназначение совсем, но по архитектуре похоже. То есть 90% кода предполагается делать на том самом языке с сериализацией кода. Зачем это нужно? - для динамического обновления приложения, изменения его логики на лету и тд. Для данного приложения это жизненно необходимо. В отличие от емакса будет более модульно, из микрокомпонент, но это не суть важно, в контексте сабжевой задачи можно считать просто, что 10% кода это некая программа на С, которая загружает некоторый кусок(90%) на другом языке и общается с ним. Что порекомендует всезнающий олл? Вопрос прежде всего к тем, кто имеет не теоретические, а практические знания.

PS: фанатов языков прошу не беспокоить, до известного предела я готов посмотреть на какие-то варианты, но только до известного предела.

★★

Ответ на: комментарий от anonymous

>На одном из google summer of code был патч, добавляющий поддержку тредов под виндой, другое дело, что он не очень кошерный был, видимо.

[плачь Ярославны] на данном этапе «кошерной» поддержки тредов под офтопиком не может быть «по определению», ибо sbcl использует не «родные», а «posix-совместимые» системные вызовы... Разве что либу pthread прикрутить... Короче: на треды под офтопиком в sbcl можно смело «забить» на ближайшее время.

yyk ★★★★★ ()

Только что понял, что глупость сморозил про сложность сериализации кода. Конечно же, можно отправлять и хранить fasl'ы.

На одном из google summer of code был патч, добавляющий поддержку тредов под виндой, другое дело, что он не очень кошерный был, видимо.

Патча для тредов как такового и не было. Был полунедопиленный патч ebx-threads от A.Bridgewaters, который на GSoC'е вроде как планировалось добавить в mainline, но этого так и не произошло; по сути, этот GSoC так ничем и не закончился.

P.S. в этом вашем SBCL байткод хоть есть, или по сети сырцами обмениваться?

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

dmitry_vk ★★★ ()
Ответ на: комментарий от yyk

>[плачь Ярославны] на данном этапе «кошерной» поддержки тредов под офтопиком не может быть «по определению», ибо sbcl использует не «родные», а «posix-совместимые» системные вызовы... Разве что либу pthread прикрутить... Короче: на треды под офтопиком в sbcl можно смело «забить» на ближайшее время.

s/плачь/плач/

SBCL вообще не использует системные вызовы, а работает через libc под линуксом и (msvcrt + стандартный набор dll'ек) под виндой.

Кошерная поддержка тредов под виндой заключается всего лишь в паре аспектов: поддержка TLS, поддержка остановки/продолжения нитей для сборщика мусора, да прерывание нити своим кодом. Все это довольно кошерно (правда, с парой вывертов) реализуется через виндовое API.

dmitry_vk ★★★ ()
Ответ на: комментарий от dmitry_vk

>s/плачь/плач/

упс....

SBCL вообще не использует системные вызовы


ну может s/вызовы/функции/? Я про файлы/потоки/прочий ввод/вывод: построено на posix-e :(

yyk ★★★★★ ()
Ответ на: комментарий от yyk

в sbcl-devel не так давно был «развёрнутый ответ» (искать лень) по поводу поддержки тредов под виндой, так вот там и было сказано, что помимо самих тредов надо перейти на на «родной» I/O и что-то там ещё... В общем, можно не ждать :(

yyk ★★★★★ ()
Ответ на: комментарий от dmitry_vk

>Кошерная поддержка тредов под виндой заключается всего лишь в паре аспектов

Что-то из-за этой «пары аспектов» уже несколько лет поддержку винды до ума довести не могут, видимо, под виндой никому sbcl не нужен.

anonymous ()
Ответ на: комментарий от dmitry_vk

Конечно же, можно отправлять и хранить fasl'ы.

Только работать будет в пределах единственной сборки SBCL.

mv ★★★★★ ()
Ответ на: комментарий от yyk

> на данном этапе «кошерной» поддержки тредов под офтопиком не может быть «по определению», ибо sbcl использует не «родные», а «posix-совместимые» системные вызовы... Разве что либу pthread прикрутить...

Это следует понимать так, что переписать sbcl на другую модель потоков абсолютный анриал? ;))

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

>Это следует понимать так, что переписать sbcl на другую модель потоков абсолютный анриал? ;))

Нет, но виндовый порт изначально был «падчерицей» среди прочих. «Настоящих буйных мало, вот и нету вожаков»... =) Т.е. делать практически некому

yyk ★★★★★ ()
Ответ на: комментарий от yyk

>ну может s/вызовы/функции/? Я про файлы/потоки/прочий ввод/вывод: построено на posix-e :(

Нашли тут проблему :) posix-обертки на файлы/ввод-вывод пишутся довольно просто. В общем, все, кроме тредов, под виндой в SBCL работает.

Что-то из-за этой «пары аспектов» уже несколько лет поддержку винды до ума довести не могут, видимо, под виндой никому sbcl не нужен.

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

так вот там и было сказано, что помимо самих тредов надо перейти на на «родной» I/O и что-то там ещё...

Это в порядке виш-листа. Т.е., конечно хорошо бы поддерживать асинхронный ввод-вывод, но не смертельно.

dmitry_vk ★★★ ()
Ответ на: комментарий от mv

>Только работать будет в пределах единственной сборки SBCL.

Там же только требование на совпадение версии SBCL'а вроде?

dmitry_vk ★★★ ()
Ответ на: комментарий от dmitry_vk

>posix-обертки на файлы/ввод-вывод пишутся довольно просто.

1. зачем писать ,если часть posix-функций и так поддерживается?

2. если таки переписывать IO - то это не так ужи и мало. Можно посмотреть в clisp сколько пришлось там «нагородить» из-за полноценной поддержки различного (posix/win32) IO. Хотя clisp, наверное, не показатель: есть ещё ECL и clozure, но я их давно не «ковырял»

В общем, все, кроме тредов, под виндой в SBCL работает.


да обратного ни кто и не утверждал ;)

Это в порядке виш-листа. Т.е., конечно хорошо бы поддерживать асинхронный ввод-вывод, но не смертельно.


Это не смертельно. Но это не 100% поддержка тредов. Как-то так =)

yyk ★★★★★ ()
Ответ на: комментарий от dmitry_vk

>Там же только требование на совпадение версии SBCL'а вроде?

если в версию входит и платформа - вроде так

yyk ★★★★★ ()
Ответ на: комментарий от dmitry_vk

Там же только требование на совпадение версии SBCL'а вроде?

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

mv ★★★★★ ()
Ответ на: комментарий от yyk

>Это не смертельно. Но это не 100% поддержка тредов. Как-то так =)

Что вы вкладываете в «100% поддержка тредов»?

dmitry_vk ★★★ ()
Ответ на: комментарий от dmitry_vk

>Что вы вкладываете в «100% поддержка тредов»?

Фибры, например.

anonymous ()
Ответ на: комментарий от dmitry_vk

>Что вы вкладываете в «100% поддержка тредов»?

Отсутствие «неплатформозавизимых» ограничений.

Или так: когда _любая_ mt-программа (напомню - мы про sbcl :), не прибитая гвоздями к (к примеру) linux, сможет работать и под альтернативной осью.

yyk ★★★★★ ()
Ответ на: комментарий от dmitry_vk

>> Я про файлы/потоки/прочий ввод/вывод: построено на posix-e :(

Нашли тут проблему :) posix-обертки на файлы/ввод-вывод пишутся довольно просто.


Ваще-то виннт поддерживает позикс 1. )))

LamerOk ★★★★★ ()
Ответ на: комментарий от mv

Ну почему же? Само понятие JIT не значит байткод. Да, часто оно так и есть. Но сам механизм подразумевает компиляцию по месту. Что в случе динамически сгенерированного кода в программе в sbcl и происходит. Просто без лишних сущностей типо байткода, но сам процесс похож.

ixrws ★★ ()
Ответ на: комментарий от ixrws

Википедия считает иначе: «In computing, just-in-time compilation (JIT), also known as dynamic translation, is a technique for improving the runtime performance of a computer program.»

Да и по логике, JIT-компиляция происходит в момент использования/вызова, а в SBCL компиляция происходит сразу, при определении функции/метода/whatever.

dmitry_vk ★★★ ()
Ответ на: комментарий от anonymous

tcl был вычеркнут в стартовом сообщении? Нет. А значит к чему упрёки? Предложение интересное, рассмотрим.

ixrws ★★ ()
Ответ на: комментарий от anonymous

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

ixrws ★★ ()
Ответ на: комментарий от dmitry_vk

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

ixrws ★★ ()
Ответ на: комментарий от ixrws

>tcl был вычеркнут в стартовом сообщении? Нет

вычеркнешь из-за скорости вместе с прочими...

yyk ★★★★★ ()

Лисперы конечно молодцы. SBCL-SBCL, только одно не работает, другое криво работает, третье надо напильником пилить.

на rsdn кое-кто пытался применять эрланг в embedded

Ну я видел статьи как успешно справлялся + и под виндой полноценно пашет + под армы пашет как надо топик стартеру, а не как некоторые.

arhibot ()
Ответ на: комментарий от arhibot

> Лисперы конечно молодцы. SBCL-SBCL, только одно не работает,

другое криво работает, третье надо напильником пилить


Так можно сказать абсолютно обо всём.

archimag ★★★ ()
Ответ на: комментарий от archimag

На протяжении последних 3 страниц так говорят об SBCL.
На армах пашет? - нет
На винде пашет? - нет

О чем вообще может идти дальше разговор? Если топик стартеру нужно и первое и второе.

arhibot ()
Ответ на: комментарий от ixrws

эрланг очень хорош:
1. горячая замена кода.
2. хорошо продуманная и
протестированная система
восстановления
после сбоев и ошибок.
3. есть возможность писать
модули на с и ява

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

sbcl хорош, но большого проекта
я бы ему не доверил

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

h1t ()
Ответ на: комментарий от h1t

> sbcl хорош, но большого проекта

я бы ему не доверил


Почему?

archimag ★★★ ()
Ответ на: комментарий от yyk

вычеркнешь из-за скорости вместе с прочими...

скорости чего? если использовать Tcl как программный клей для связывания модулей, написанных на C (со всеми вытекающими динамическими плюшками), то никаких проседаний по скорости не будет

конечно, если мерять производительность в сферических фракталах в вакууме - тогда не вопрос; только кому они нужны?

jtootf ★★★★★ ()
Ответ на: комментарий от h1t

>требуется жесткое тестирование.
dialyzer и TypEr хорошее подспорье.

arhibot ()
Ответ на: комментарий от jtootf

Дело в том, что клеем будет выступать архитектура подобная по духу DBus, которая будет намеренно применяться для избавления от языковой зависимости на всё время существования проекта. Поэтому вопрос стоит не в связывании, а использовании языка для написания кода, для которого производительность критична. В одном из предыдущих постов я уже писал, что рабочий код по потреблению ресурсов будет напоминать вебсервер, потоковую данных и в этом духе. Подробнее объяснить сейчас не могу, но суть в том, что язык, на порядок отличающийся по скорости исполнения от С не может использоваться. Вы много видели реализаций видеокодеков, алгоритмов сжатия на интерпретируемых языках?
Если же вопрос ставить о клее, то скорее будет выбор в сторону Java для всего проекта, но это выходит за рамки топика.

ixrws ★★ ()
Ответ на: комментарий от ixrws

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

//вчерашний анон с эрлангом

anonymous ()
Ответ на: комментарий от anonymous

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

ixrws ★★ ()

>Зачем это нужно? - для динамического обновления приложения, изменения его логики на лету и тд. Для данного приложения это жизненно необходимо.

Smalltalk

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

Какая реализация наиболее адекватна по производительности и кросплатформенности?
PS: Боюсь по количеству маргинальных языков этот тред скоро зашкалит, ну ничего, прорвёмся.

ixrws ★★ ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

ixrws ★★ ()
Ответ на: комментарий от ixrws

> Какая реализация наиболее адекватна по производительности и кросплатформенности?

Как ни крути, а кроме жабы под ваши задачи ничего не подходит.

anonymous ()
Ответ на: комментарий от ixrws

>Описать то, что делается полностью не могу, в силу ряда причин.

NDA так NDA, нам то что.

язык должен обладать достаточной производительностью, чтобы на нём можно было писать реализацию кодеков, алгоритмов шифрации и компрессии

(список из двух десятков языков)

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

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

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

//уже пьяный анон с эрлангом

anonymous ()
Ответ на: комментарий от yoghurt

> Smalltalk

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

anonymous ()
Ответ на: комментарий от anonymous

Где-то там выше в коментах уже писал, что этот вариант рассматривается, но только как 100% кода проекта на жабе. То есть это параллельный вариант, поэтому в данном топике и не обсуждаем:)

ixrws ★★ ()
Ответ на: комментарий от anonymous

>Это фантастика - на голом железе чтоль?? Или там специфическая обвязка, навроде аппаратных кодеков?. Я, может, сильно ошибусь, но компиляторов высокоуровневых языков окромя С под это дело почти нету.

Конечно фантастики не нужно, нужно сопоставимо с С, об этом и писал уже. То есть на армах 400-500 вполне себе компрессуется и кодируется-декодируется. Да, не hd, да, даже не нормальное по меркам писюков разрешение и не нормальные по меркам всё тех же писюков кодеки. Но тем не менее. Скажем даже на фрираннере или n810 можно смотреть видео в софтовом виде, без задействия аппаратного ускорения. Понятное дело, что никто даже не думает декодировать hd на слабеньких армах:)

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


В общем то на предыдущих страницах, может быть не так чётко как хотелось бы, я уже писал, что в силу разделения всей системы на маленькие компоненты задача может быть достигнута даже с помощью обычного С + таскать компиллер с собой. Но вопрос в элегантности решения, объём кастылей при решении этого на С будет офигенский. Отсюда вопрос сабжевый и вышел. Обновление кода в любом случае необходимое условие, но его можно с помощью усилий делать даже и на машинных кодах:)

ixrws ★★ ()
Ответ на: комментарий от ixrws

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

anonymous ()
Ответ на: комментарий от ixrws

Какая реализация наиболее адекватна по производительности и кросплатформенности?

Есть коммерческий Gemstone/S - для больших распределенных приложений самое оно. Под виндой, говорят, работает. Под линуксом тоже (GLASS - их замена LAMP).

Есть коммерческая VisualWorks - не работает под виндус, линукс, макос и некоторыми прочими юниксами.

Из OSS - есть вещь-в-себе Squeak (которая работает почти везде, в т.ч. на айфонах, портирование на андройд - в процессе) и близкий к скриптовым GNU Smalltalk, который работает почти везде, где доступна GNU Lightning.

Производительность - довольно-таки интересный вопрос :) Если сравнивать с С - то туго. Если с Питоном - то обычно быстрее. Gemstone/S обещает большую производительность, но он дорогой. Squeak не шибко резвый, GST побыстрее. VW Не использовал.

Вот такие пироги

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

Опечатка по Фрейду

>VisualWorks - не работает

s/не работает/работает/

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

И, да, забыл добавить, что нет такого языка «Smalltalk», отсюда совместимость между реализациями оставляет желать лучшего.

Хотя, Seaside как образцовый фреймворк доступен для большинстве диалектов

yoghurt ★★★★★ ()
Ответ на: комментарий от ixrws

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.