Ada_Ru форум

Обсуждение языка Ада

Re: [ada_ru] Re: Совмещениеязыков

Оставить новое сообщение

Сообщения

Vladimir Teplouhov
Re: [ada_ru] Re: Совмещениеязыков
2007-03-14 09:13:44

14.03.07, Ivan Levashew<OCTAGRAM@mail.ru> написал(а):

Vladimir Teplouhov <Vladimir.Teplouhov <at> gmail.com> writes:

...

> получается что интерфейс тупо 1:1 переносить на

> другую платформу

> вообще нельзя!

 

+1

 

> Вот смотри. Допустим у нас на PC на F8 удаление, а на F5 копирование.

> И все к этому привыкли. А на другой платформе? А там

> может быть

> все что угодно, хорошо если просто по-другому, а если

> окажется наоборот? :)

...

 

Microsoft Office:mac, отдаю должное Microsoft, не является

прямой калькой MSO:Win. Но всё же :

Например, перемещение в начало строки -

на PC - Home

на Mac - Command-Left

Пользуется себе яблочник кучей програм, в них всё именно так.

А в Word:mac 2004 вдруг откуда-то Home. Вот именно, что

руки тянутся не к Home/End, неудобно только из-за одной программы

менять привычки.

 

то есть какой-то дрейф к общему среднему :) все-же наблюдается?

Думаю так оно и должно быть...

 

...

Прям хоть ставки делай - кто при таком подходе быстрее

освоит Win x64 : Delphi или GNAT?

 

64 бита нужно только для сложных вычислительных задач.

(не думаю что кто-то писал их на дельфи, и уж тем более не будет мигрировать)

Думаю соответствующие либы для Ады появятся(если еще не появились)

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

самого компилятора и с нормальным синтаксисом, чего не скажешь про паскаль.

 

Нет, правда, неприятно, когда software, претендующее

на статус 64-bit compatible, на поверку оказывается 64bit

лишь в *NIX. (В случае Delphi 64-бит только в .NET)

 

да я думаю для интерфейсов и 16 будет сильно много :)

Не, правда - строковые типы удобнее, а скорость тут уже давно не важна...

 

...

Надо что-то делать!

 

Я считаю, нужно начать с GNAT runtime. Если оно не будет

 

ты эта.. хлебни валерьянки, успокойся :)

Нафиг так кардинально копать?

 

Конечно, если есть какая-то супер-идея, способная все кардинально

изменить, тогда может и стоит что-то глубоко менять. Ну а если нет,

то не стоит делать еще одну поделку - и так хлама столько,

что ценные проекты среди него не найдешь...

 

С рунтайм не спеши - адакоре думаю над этим работает :)

Нам оно потом достанется на халяву ;)

(единственно что может быть имеет смысл это сделать ради

обхода GPL ограничений нового компилятора, но раз это еще

не сделали, думаю не сильно многим это и надо...)

 

Ну а дельфи и тп поделки, если их не пытаться применять не по назначению :),

в общем-то для своих целей вполне подходят. Главное что они тоже

есть, и практически на халяву :) (даже если покупать лицензии,

то это все равно на порядки дешевле чем писать все с нуля)

Так что насчет совмещения дельфи или C# для интерфейса,

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

Главное что все готовое и почти на халяву, да еще и хоть как-то

развивается... Сделать только минимальный стык. Причем думаю

лучше как-то их максимально изолировать друг от друга - в общем

линковать в одну кучу мне их не хотелось бы в целях надежности

да и проблем меньше - мало ли чего там может перепутаться :) на этапе

линковки 2х никогда вместе толком не тестированных систем... Короче говоря,

скрещивать надо стараясь тем не менее поддерживать максимальную

изоляцию друг от друга. Да, можно еще заглянуть в архив рассылки - мы тут

вроде уже как-то обсуждали это насчет интерфейсов... Если сделать

стык на уровне какой-то модели вроде каналов связи, то получается куча

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

 

 

Вот над чем стоит подумать - коли уж какая-то унификация между

разными платформами уже идет, то может быть имеет смысл сделать

какой-то проект, который бы поддерживался(точнее говоря сразу делался

для всех платформ) на всех платформах и решал проблемы совместимости

сразу внутри. Причем варианта тут два - либо коммерческий проект,

либо BSD лицензия - чтобы и коммерсанты могли его слопать. По крайней

мере проблем с не совместимостью и переносом будет меньше...

 

...

В одиночку-то я GNAT runtime на WinAPI не перелопачу.

То ли на sf.net проект открыть?

 

если он будет интересен только любителям,

то думаю(если вообще кто-то поддержит за бесплатно) получится

еще одна кривая игрушка, да и по срокам когда оно появится это

может быть уже не актуально...

Вот если его можно будет использовать в том числе и для каких-то

коммерческих(не обязательно платного софта - софт может быть например GPL,

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

 

Vladimir

PS ща тут нам напомнят про X-виндус(который мелкософту даже не родственник :) )

и что мы тут велосипед изобретаем :) Может быть и так. Но у делфи есть

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

и не очень хотят переучиваться(тем не менее интерфейсы у них получаются

вполне пригодные для программ на продажу), так что их можно будет

задействовать(и не дорого :) ) с пользой в бизнесе

на коммерческих(в тч и шароварных) программах, ну а самому не тратить

на эту ерунду время и лучше вылизывать основный модуль на Аде...

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

и вперед, дальше в общем-то работа вполне распараллеливается.

Vladimir Teplouhov wrote:

Так что насчет совмещения дельфи или C# для интерфейса,

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

Главное что все готовое и почти на халяву, да еще и хоть как-то

развивается... Сделать только минимальный стык. Причем думаю

лучше как-то их максимально изолировать друг от друга - в общем

линковать в одну кучу мне их не хотелось бы в целях надежности

да и проблем меньше - мало ли чего там может перепутаться :) на этапе

 

Передо мной стоит аналогичная задача. Как бы мне не хотелось в распределенной системе все написать на одном языке, дабы не дублировать библиотеки, но все сходится к тому, что интерфейс будет на Java со связкой с серверными частями через Corba. Прошу прощения за оффтопик, но выглядит так, что jvm вне конкуренции для интерфейсов, дает возможность использовать одни и те же библиотеки в толстых кроссплатформенных самообновляемых клиентах на базе java web start, на jvm сотовых телефонов и сервлетах для тонких веб клиентов на базе Tomcat. Серверная часть наверняка будет на Ада, вопросы производительности для меня до сих пор встают остро :-) , jvm не подоходит.

 

Теоретический есть два пути, как можно решить ту же задачу в рамках одного языка. Первый, написать сервер на java и с помощью gcj скомпилить в выполняемый машинный код, но здесь это обсуждать не уместно. :-) Второй, теоретический Ada и Java очень похожи. Существовали компиляторы платные, которые могли компилить Ada в java byte code со всеми вытекающими отсуда плюшками по созданию кроссплатформенных интерфейсов. И казалось бы, есть GNAT ада компилатор на базе gcc. Есть gcj java компилятор на базе gcc в том числе в java byte code. Кажется надо совсем немного, чтобы скрестить одно с другим с возможностью компиляции Ada в java byte code и широкая дорога по реализации приложений клиент-сервер целиком написанных на Ada будет открыта. :-)

 

-- Olleg Samoylov

>64 бита нужно только для сложных вычислительных задач.

>(не думаю что кто-то писал их на дельфи, и уж тем более не будет >мигрировать)

Промышленную программу расчёта электрических режимов можно считать за "серьёзные вычисления" ?

Если да то тот кто писал сидит в соседнем кабинете;

 

Так что насчет совмещения дельфи или C# для интерфейса,

>и Ады для всего остального думаю можно и позаниматься.

>Главное что все готовое и почти на халяву, да еще и хоть как-то

>развивается... Сделать только минимальный стык. Причем думаю

>лучше как-то их максимально изолировать друг от друга

я конечно не спец в програмировании таких вещей, но ...

Ada-пакет с набром функций вроде (нарисовать окно, нарисовать кнопку) и dll-кой Ada_win_interface.dll подойдёт?

Для Linux такойже пакет с тем же названием и набором функций.

Второй, теоретический Ada и Java очень похожи. Существовали компиляторы платные, которые могли компилить Ada в java byte code со всеми

вытекающими отсуда плюшками по созданию кроссплатформенных интерфейсов. И казалось бы, есть GNAT ада компилатор на базе gcc. Есть gcj java компилятор на базе gcc в том числе в java byte code. Кажется надо совсем немного, чтобы скрестить одно с другим с возможностью компиляции Ada в java byte code и широкая дорога по реализации приложений клиент-сервер целиком написанных на Ada будет открыта. :-)

 

Подождите до середины весны, возможно у AdaCore появится кое-что в этом плане...

 

ВФ

14.03.07, Olleg<olleg_s@mail.ru> написал(а):

Vladimir Teplouhov wrote:

> Так что насчет совмещения дельфи или C# для интерфейса,

> и Ады для всего остального думаю можно и позаниматься.

> Главное что все готовое и почти на халяву, да еще и хоть как-то

> развивается... Сделать только минимальный стык. Причем думаю

> лучше как-то их максимально изолировать друг от друга - в общем

> линковать в одну кучу мне их не хотелось бы в целях надежности

> да и проблем меньше - мало ли чего там может перепутаться :) на этапе

 

Передо мной стоит аналогичная задача. Как бы мне не хотелось в

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

 

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

из чего угодно в любой код ;)

 

идейка была тут прокатиться на халявку - есть игрушки вроде того-же дельфи

или C# где уже есть куча всего готового для написания некоторых задач

вроде тех-же менюшек. То есть не изобретать велосипед, а тупо использовать

все готовое, но при этом полностью не переходить на эти песочницы.

(к тому-же они пожалуй послабее будут Ады)

 

библиотеки, но все сходится к тому, что интерфейс будет на Java со

связкой с серверными частями через Corba. Прошу прощения за оффтопик, но

выглядит так, что jvm вне конкуренции для интерфейсов, дает возможность

использовать одни и те же библиотеки в толстых кроссплатформенных

самообновляемых клиентах на базе java web start, на jvm сотовых

телефонов

 

кстати все никак руки не доходят попробовать JGNAT для сотовиков применить.

Может уже кто-то пробовал? Всмысле я имею ввиду может уже какие

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

это дело если еще нету...

 

и сервлетах для тонких веб клиентов на базе Tomcat. Серверная

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

пор встают остро :-) , jvm не подоходит.

 

Теоретический есть два пути, как можно решить ту же задачу в рамках

одного языка. Первый, написать сервер на java и с помощью gcj скомпилить

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

Второй, теоретический Ada и Java очень похожи. Существовали компиляторы

платные, которые могли компилить Ada в java byte code со всеми

 

почему платные? JGNAT вроде тоже GPL. Правда его вроде забросили поддерживать.

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

можно вполне обойтись...

 

вытекающими отсуда плюшками по созданию кроссплатформенных интерфейсов.

И казалось бы, есть GNAT ада компилатор на базе gcc. Есть gcj java

компилятор на базе gcc в том числе в java byte code. Кажется надо совсем

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

java byte code и широкая дорога по реализации приложений клиент-сервер

целиком написанных на Ada будет открыта. :-)

 

есть еще один вариант - аналогичный код от C#.

Он изначально планировался как транслируемый в нативный перед запуском,

так что потерь производительности почти нету. И есть более свежий чем JGNAT

компилятор Ады в этот код - MGNAT... Правда там исходников в несколько

раз больше чем в обычном компиляторе Ады, так что если что ковыряться больше ;)

 

Из бонусов что этот код поддерживается фирмами - вполне можно ожидать

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

и C# можно пытаться использовать как промежуточные - для них наверняка

будут готовые трансляторы и интерпретаторы под массу платформ.

 

Vladimir

14.03.07, Vasiliy Fofanov<fofanov@act-europe.fr> написал(а):

> Второй, теоретический Ada и Java очень похожи. Существовали компиляторы

> платные, которые могли компилить Ada в java byte code со всеми

> вытекающими отсуда плюшками по созданию кроссплатформенных интерфейсов.

> И казалось бы, есть GNAT ада компилатор на базе gcc. Есть gcj java

> компилятор на базе gcc в том числе в java byte code. Кажется надо совсем

> немного, чтобы скрестить одно с другим с возможностью компиляции Ada в

> java byte code и широкая дорога по реализации приложений клиент-сервер

> целиком написанных на Ada будет открыта. :-)

 

Подождите до середины весны, возможно у AdaCore появится кое-что в этом

плане...

 

кстати, а что есть для распараллеливания? (кластерные вычисления и тп)

PVM кем-нить поддерживается?

(для PVM есть масса готовых дистров линукса - кластер подымается в общем-то

без проблем)

 

да, еще вопрос по случаю - а для обхода битых ячеек помяти?

(для одного из вариантов ядра линукса был такой патч,

но как всегда начали за сдравие, а потом похоже никому не надо чтоли - поиграли

и бросили)

 

Vladimir

14.03.07, Marina-Ala<marina-ala@yandex.ru> написал(а):

>64 бита нужно только для сложных вычислительных задач.

>(не думаю что кто-то писал их на дельфи, и уж тем более не будет

>мигрировать)

Промышленную программу расчёта электрических режимов можно считать за

"серьёзные вычисления" ?

Если да то тот кто писал сидит в соседнем кабинете;

 

я тут наверно не точно выразился

 

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

несколько разные вещи - для многих программ производительность

уже давно вполне достаточно и напрягаться ради ускорения в общем-то не зачем

 

кстати во многих игрушках некоторые подпрограммы для графики

не такие уж и простые... Раньше, когда ресурсов было мало, написать

хорошую(да и вообще работоспособную :) ) реалтаймовую программу

мог только хороший хакер, а нынче есть готовые библиотеки и аппаратная

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

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

а снаружи интерфейс практически не влияет - просто на прорисовку одного

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

внутри(практически для каждой точки). Так что переделка интерфейсов на 64

практически ничего к этому не даст - вполне достаточно чтобы только эти

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

 

 

> Так что насчет совмещения дельфи или C# для интерфейса,

>и Ады для всего остального думаю можно и позаниматься.

>Главное что все готовое и почти на халяву, да еще и хоть как-то

>развивается... Сделать только минимальный стык. Причем думаю

>лучше как-то их максимально изолировать друг от друга

я конечно не спец в програмировании таких вещей, но ...

Ada-пакет с набром функций вроде (нарисовать окно, нарисовать кнопку) и

dll-кой Ada_win_interface.dll подойдёт?

Для Linux такойже пакет с тем же названием и набором функций.

 

я думаю что лучше другая модель - есть программа-интерфейс,

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

Пускай всякие окошки рисует и кнопки обрабатывает интерфейсная

часть(и на разных платформах по-разному), а в программу уже посылает

только готовый код комманды, которые уже будет одинаковы везде.

То есть сама вычислительная часть может быть вообще перенесена

без изменений, а интерфейсы можно будет менять даже внутри одной

платформы. Важно только придумать как стыковать с миниумом

извратов вроде вызовов процедур из подпрограммы меню и тп...

 

Vladimir

 

>есть программа-интерфейс,

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

 

Да но программа интерфейс не может быть пакетом Ада. Она должна быть Delphi exe. В таком случае саму ада программу надо располагать в win dll.

 

Тут придёться разрабатывать правила взаимодействия каждый раз индивидуально. В общем случае писать обработчики событий в ада dll, а в интерфейсной программе просто повторять.

 

procedure TForm1.Button1Click();

begin

Ada_program.Button1Click;

end;

15.03.07, Marina-Ala<marina-ala@yandex.ru> написал(а):

 

>есть программа-интерфейс,

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

 

Да но программа интерфейс не может быть пакетом Ада.

 

почему не может? Теоретически можно написать что угодно и на чем угодно,

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

функций, ни возможностей ассемблерных вставок(таких нынче практически

нет уже)...

 

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

в некоторых случаях может оказаться проще воспользоваться чем-нить

готовым вроде того-же дельфи или C# - есть и куча готовых библиотек(или как

их нынче модно называть - компонентов :) ), и люди которые ничего

кроме этих песочниц не знают и знать не хотят - вот и пускай ковыряются :)

(причем со временем когда появится Ада-проект это легко будет заменить)

 

Она должна быть Delphi exe. В таком случае саму ада программу надо

располагать в win dll.

 

какой из вариантов лучше утверждать не возмусь - это как раз и стоило

бы обсудить с учетом самых различных вариантов и платформ

 

и совсем не обязательно dll или линковать все в одну кучу - полно

программ которые неплохо как-то живут и в виде нескольких резидентных exe

(тот-же гуглевый паук например от локального поисковика)

 

в винде есть куча всяких разных функций, вроде событий, сервисов и тп хрени.

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

система когда изменяется какой-то файл и тд и тп. Но чем дальше в лес,

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

очень бы не хотелось - вот эту всю лабуду думаю лучше оставить в модуле

интерфейса, а наружу вытаскивать че-нить более совместимое и переносимое...

 

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

В общем случае писать обработчики событий в ада dll, а в интерфейсной

программе просто повторять.

 

procedure TForm1.Button1Click();

begin

Ada_program.Button1Click;

end;

 

да не, тогда уж проще взять че-нить готовое на тему x-windows ;)

(тут у кого-то были наработки по подобному подходу - думаю ребята

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

какие-нить готовые кусочки под GPL перепадут :) )

 

при таком делении возни все равно много с обработкой всяких кликов,

кнопочек-пимпочек, ;) окошек и прочей муры.

 

 

Я думаю попробовать поделить на части немного в другом месте - на уровне

готовых комманд (с точки зрения проектирования по всем правилам выгоднее

делить на части в самом тонком и простом месте - меньше будет связей и

связанных с этим сложностей), в этом месте и связей меньше и они проще.

Пускай рисует менюшки, прочие шкуры ;) и обрабатывает клики сам

модуль интерфейса, причем делает внутри это как хочет(все равно на разных

платформах разные механизмы и даже способы обращения к системе).

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

Ну например при нажатии меню file : save модуль интерфейса вызывает

SendCmd("SaveFile") или SendCmd(SaveFileCode),

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

через какой-то интерфейс или даже как вариант по каналу связи. Кстати

не обязательно

кликать - эта команда вполне может посылаться и по таймеру например,

если включен режим автосохранения...

Из бонусов - это легко разделить и запускать хоть на одной машине,

хоть по каналам связи управлять машиной в другом месте. Ну и самое

главное - всегда можно будет легко к любой программе прикрутить как GUI,

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

заменить внешний вид интерфейса конечно...

 

Структуру описания меню думаю тоже можно стандартизировать и прикрутить

к ней поисковик - нынче модно стало делать такую идиотскую структуру

меню, что проще искать в какое подменю эти уроды засунули нужную

функцию сразу поисковиком по ее названию или описанию...

 

Vladimir

PS да, и какие-то общие рекомендации(или правила) не мешало

бы выработать - например, динамические меня запретить нафиг совсем

как опасное и вредное извращение и тп. Причем такие возможности

сразу отрезать нафиг на уровне отсутствия возможности/поддержки чтобы

всяким идиотам и вредителям было не повадно их использовать там где

нафиг не надо, коли уж своих мозгов не хватает понять где это уместно

а где нет...

Vasiliy Fofanov wrote:

Подождите до середины весны, возможно у AdaCore появится кое-что в этом

плане...

 

Любопытно. Можете поделится слухами и сплетнями об этом?

 

-- Olleg Samoylov

Любопытно. Можете поделится слухами и сплетнями об этом?

 

Дело в том что мы довели до ума JGNAT, и обсуждается вариант выпустить его как один из портов в готовящемся релизе GPL 2007. Но пока решение не принято.

 

ВФ

15.03.07, Vasiliy Fofanov<fofanov@act-europe.fr> написал(а):

> Любопытно. Можете поделится слухами и сплетнями об этом?

 

Дело в том что мы довели до ума JGNAT, и обсуждается вариант выпустить

 

если не секрет, какой объем работ потребовался для этого?

(или там было еще расширение функциональности?)

 

Vladimir

PS это я просто прикидываю во что может вылиться использование

заброшенных опенсорсных проектов - то есть ли доводить до ума самим...

если не секрет, какой объем работ потребовался для этого?

(или там было еще расширение функциональности?)

 

Это невозможно оценить, потому что работа велась параллельно с разработкой компилятора для .NET. Разделить мух с котлетами не получится.

 

ВФ

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти