Ada_Ru форум

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

distributed systems//Re: [ada_ru] Материал дл я сайта: клиент-серверные приложения

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

Сообщения

teplouhov
distributed systems//Re: [ada_ru] Материал дл я сайта: клиент-серверные приложения
2005-09-10 12:03:55

Hello.

 

Я тут смотрю с "новыми" вещами в Аде для распределенных систем

народ уже разобрался, так что спрошу вот что - а как оно

коррелирует с другими решениями/технологиями?

 

Что и насколько более проработано чем в других технологиях?

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

то что уже сделано лучше - из Ады в ОС перенести или наоборот

стандартизировать то что уже изобретено в других местах)

 

А конкретно:

 

Распределенные вычисления:

==========================

есть mosix ОС - патч для линукса.

---------------------------------

 

http://sourceforge.net/project/showfiles.php?group_id=46729&release_id=136769

http://sourceforge.net/project/showfiles.php?group_id=46729&package_id=93767&release_id=224570

http://openmosix.sourceforge.net/

http://www.openmosixview.com/

- mosix

 

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

(их впринципе много, но обычно от 200 мег и выше)

 

http://www.purehacking.com.au/chaos/

http://www.purehacking.com.au/chaos/downloads.php

 

 

PVM - paraller virtual mashine

------------------------------

 

http://www.csm.ornl.gov/pvm/pvm_home.html

http://www.csm.ornl.gov/pvm/intro.html

 

различные кластеры и тп

-----------------------

 

Еще кластерные технологии попадаются

под именами "грид" и тп - один велосипед

от разных изобретателей ;)

 

 

Распределенные файловые системы:

================================

 

Red Hat GFS,

NBD и тп.

Особенно интересно что-то вроде виртуального

сетевого RAID - тоесть с избыточностью...

 

http://www.rhd.ru/docs/articles/gfs-storage/

- GFS

http://opengfs.sourceforge.net/

 

http://sources.redhat.com/cluster/

- Cluster Project Page

 

http://sources.redhat.com/cluster/gfs/

- GFS Project Page

 

 

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

Что и насколько более проработано чем в других технологиях?

Теория глобальной абстактизации ;)

 

(я это к тому что может не изобретать велосипеды, а использовать то что уже сделано лучше - из Ады в ОС перенести или наоборот

стандартизировать то что уже изобретено в других местах)

 

Всё, что перечисленно ниже есть не более, чем современные модные

течения. С точки зрения языка любая из этих технологий ложится под DSA и используется существующим программным обеспечением без необходимости его (программного обеспечения) модификации.

 

Такие вот дела...

 

Значительно интереснее то, что никто так и не заметил, что про AWS я совершенно забыл :( Надеюсь, что мне это напомнят.

 

 

--

Vadim Godunko

On Sat, 10 Sep 2005 21:17:32 +0400, Vadim Godunko <vgodunko@...> wrote:

teplouhov@... wrote:

 

Что и насколько более проработано чем в других технологиях?

Теория глобальной абстактизации ;)

 

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

то что уже сделано лучше - из Ады в ОС перенести или наоборот

стандартизировать то что уже изобретено в других местах)

 

Всё, что перечисленно ниже есть не более,чем современные модные течения.

 

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

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

и общей архитектуре не "один сервер - много клиентов",

а "много серверов - много клиентов". (Правда там обычно

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

один виртуальный, т.е. для клиента вся эта стая серверов

как бы один диск, так что пользовательское приложение

можно не усложнять)

 

С точки зрения языка любая из этих технологий ложится под DSA и

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

(программного обеспечения) модификации.

 

тоесть опять таки намек на всякие прослойки и использование средств ОС...

Большинство ОС сделано вообще лишбы как(или просто очень старые - как юникс),

так что мне такое отношение к ним не очень нравиться - по-моему проще

наоборот переделать ОС, тем более что в Ада часто есть встроенные

библиотеки с более качественной реализацией чем в ОС. (либо лучше

документировано - для многих вещей главное качество документации,

иначе и реализация не сильно-то и нужна, если не понятно как ей

пользоваться)

 

 

Меня вот что смущает - для того-же GFS и тп поделок патчи идут

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

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

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

то-то будет весело если что-то глюкнет)

Может можно подобные поделки с использованием чего-то

писать сразу и без глюков?

 

 

 

Такие вот дела...

 

Значительно интереснее то, что никто так и не заметил, что про AWS я

совершенно забыл :( Надеюсь, что мне это напомнят.

 

ну, это если собирать вообще все что работает более чем на одном

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

отличается от того что у GFS внутри, хотя не исключено что можно

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

разная, особенно в кластерных вычислениях. (общего тут разве

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

можно попробовать использовать(хотя AWS написан "в лоб" насколько

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

что на подобных средствах можно было бы сделать его быстрее) и тп)

 

Vladimir

PS Кстати, а не кажется, что обсуждение подобных технологий

следовало бы как бы вынести за рамки языка? (тем более что та-же

корба насколько я понял Аде даже не родственник - просто один

из очередных проектов, реализацию которого сделали в тч и на Аде)

Бонусы - будет больше заинтересованного народу, в тч и те кто

пишет на чем-то другом(ну, или пишет только статейки ;) )...

PPS Ну а специфических вещей для каждого конкретного

языка есть обычно очень не много...

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Vadim Godunko wrote:

 

teplouhov@... wrote:

Что и насколько более проработано чем в других технологиях?

Теория глобальной абстактизации ;)

 

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

то что уже сделано лучше - из Ады в ОС перенести или наоборот

стандартизировать то что уже изобретено в других местах)

 

сё, что перечисленно ниже есть не более, чем современные модные

течения. С точки зрения языка любая из этих технологий ложится под DSA и

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

(программного обеспечения) модификации.

 

Такие вот дела...

 

Значительно интереснее то, что никто так и не заметил, что про AWS я

совершенно забыл :( Надеюсь, что мне это напомнят.

В AWS встроен SOAP протокол. Мы на работе для удаленного взаимодействия клиентов и сервера пока не использую навороченные протоколы. Как то HTTP+XML обходимся (AWS на серверной стороне работает).

 

Судя по последним исходникам PolyORB там есть какая то связка с AWS. Подробностей не знаю, просто из любопытсва заглядывал в исходники.

teplouhov@... wrote:

 

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

вроде yacc и тп для описания протоколов(или не заметил? ;)

Тот-же http на спецязыке можно описать быстрее чем "в лоб" писать

код для его реализации).

А ведь еще в 70е были разработаны спецязыки для описания

протоколов и тп. (описание упрощается на порядки, и, главное,

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

автоматически - надо только прописать реакцию что и через

сколько времени делать и тп)

 

Да, так было. Но на сегодняшний день имеет место быть отказ от автоматического создания анализаторов. Обусловленно это сложность контроля автоматически сгенерированного кода.

 

В openH323 кстати пытались использовать какой-то ASN, но правда

сильно на пользу им не пошло - точно знаю что потом находили

и патчили несколько довольно трудноуловимых глюков(причем под

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

вроде юниксовый вариант, а виндовый нет ;) )...

 

ASN.1? А что есть его библиотека на Ada? Где?

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Sun, 11 Sep 2005 21:29:05 +0700, anisimkov <anisimkov@...> wrote:

Vadim Godunko wrote:

teplouhov@... wrote:

 

 

Что и насколько более проработано чем в других технологиях?

 

 

Теория глобальной абстактизации ;)

 

 

 

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

то что уже сделано лучше - из Ады в ОС перенести или наоборот

стандартизировать то что уже изобретено в других местах)

 

сё, что перечисленно ниже есть не более, чем современные модные

течения. С точки зрения языка любая из этих технологий ложится под DSA и

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

(программного обеспечения) модификации.

 

Такие вот дела...

 

Значительно интереснее то, что никто так и не заметил, что про AWS я

совершенно забыл :( Надеюсь, что мне это напомнят.

 

 

В AWS встроен SOAP протокол. Мы на работе для удаленного взаимодействия

клиентов и сервера пока не использую навороченные протоколы. Как то

HTTP+XML обходимся (AWS на серверной стороне работает).

 

Судя по последним исходникам PolyORB там есть какая то связка с AWS.

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

 

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

вроде yacc и тп для описания протоколов(или не заметил? ;)

Тот-же http на спецязыке можно описать быстрее чем "в лоб" писать

код для его реализации).

А ведь еще в 70е были разработаны спецязыки для описания

протоколов и тп. (описание упрощается на порядки, и, главное,

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

автоматически - надо только прописать реакцию что и через

сколько времени делать и тп)

 

В openH323 кстати пытались использовать какой-то ASN, но правда

сильно на пользу им не пошло - точно знаю что потом находили

и патчили несколько довольно трудноуловимых глюков(причем под

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

вроде юниксовый вариант, а виндовый нет ;) )...

 

 

Vladimir

PS Кстати, о птичках ;)

Тут такая мысль насчет условной компиляции и тп - а нельзя

ли для этого использовать pragma, которая задает имена файлов

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

патчей и тп?

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

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

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

объем будет не большой), где платформо-зависимым модулям

прописаны просто разные имена/каталоги - далее обычная

компиляция такого пакета потянет уже за собой компиляцию

нужного варианта модулей и тп... Или фокус не пройдет? :}

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, Sep 12, 2005 at 08:34:19AM +0400, Vadim Godunko wrote:

А ведь еще в 70е были разработаны спецязыки для описания

протоколов и тп. (описание упрощается на порядки, и, главное,

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

автоматически - надо только прописать реакцию что и через

сколько времени делать и тп)

 

Да, так было. Но на сегодняшний день имеет место быть отказ от

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

 

Ух ты. А по подроднее можно? Это что, теперь таблицы

лексического анализатора теперь руками писать надо? :-)

 

Проще чем программка сгенеренная yacc/flex и найти

трудно: символ зачитал, состояние поменял, повторил.

Или это не в ту тему?

--

Vadim Godunko

--

Maxim Reznik

Maxim Reznik wrote:

 

Да, так было. Но на сегодняшний день имеет место быть отказ от автоматического создания анализаторов. Обусловленно это сложность контроля автоматически сгенерированного кода.

 

Ух ты. А по подроднее можно?

См. GNAT. См. C++ из GCC 4.1. Все они отказались от использования yacc.

 

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

 

Это что, теперь таблицы

лексического анализатора теперь руками писать надо? :-)

 

А почему бы и нет? ;) Таблицы конечно писать глупо, но вот использовать подход, аналогичный используемому в GNAT - можно запросто.

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

hi,

 

Vadim Godunko wrote:

 

Maxim Reznik wrote:

Да, так было. Но на сегодняшний день имеет место быть отказ от автоматического создания анализаторов. Обусловленно это сложность контроля автоматически сгенерированного кода.

Ух ты. А по подроднее можно?

См. GNAT. См. C++ из GCC 4.1. Все они отказались от использования yacc.

 

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

imho, Ты не совсем прав. Можно даже сказать, что совсем не прав ;-)

 

Средства автоматической генерации трансляторов в настоящее время

используются и весьма интенсивно. Причем, существуют инструментальные

пакеты для "сквозной" генерации полновесных трансляторов

(от семантического анализатора, до кодогенератора).

 

Просто, в одних случаях выгоднее или разумнее ограничиться

ТОЛЬКО применением средств автоматической генерации,

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

на стадии макетирования транслятора, с последующей ручной

доработкой.

 

Касательно таких поделок как GCC и GNAT, на данный момент времени,

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

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

Применялись ли такие средства ранее (в начале разработки GCC и/или GNAT)?

Сказать сложно. Возможно, что и нет, поскольку, зрелые и эффективные средства

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

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

 

Alex

On Mon, 12 Sep 2005 08:34:19 +0400, Vadim Godunko <godunko@...> wrote:

 

teplouhov@... wrote:

 

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

вроде yacc и тп для описания протоколов(или не заметил? ;)

Тот-же http на спецязыке можно описать быстрее чем "в лоб" писать

код для его реализации).

А ведь еще в 70е были разработаны спецязыки для описания

протоколов и тп. (описание упрощается на порядки, и, главное,

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

автоматически - надо только прописать реакцию что и через

сколько времени делать и тп)

 

Да, так было. Но на сегодняшний день имеет место быть отказ от

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

контроля автоматически сгенерированного кода.

 

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

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

(ошибок дак меньше должно быть - один раз отладил конвертор,

и все)

 

А вот когда программу приходиться писать руками,

тогда только Ада и тп хороши, но и исходник как правило

получается раза в 2-3 больше чем на том-же Ц.

 

Еще правда один плюс есть - читаемость получше,

но это впринципе можно хоть к ассемблеру комментариев

добавить и отформатировать чтобы читалось...

 

 

(кстати, как там в gnat называется кодогенератор?

Что-то приколоться чтоли - прикрутить вместо кода

генератор текстов на Ц, вот классный вестч будет

для "комплектации" GPL - исходники-то типа есть,

даже чуть-чуть исправить сможете сами(ну, чтобы

суппорт не напрягали по всяким там глюкам ;) ),

а вот развивать дальше уже врядли ;}

Кстати, в C# после декомпиляции получается

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

компоненты, которые извращают все названия и тп

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

уже почти все готовое и круче есть ;))) )

 

 

В openH323 кстати пытались использовать какой-то ASN, но правда

сильно на пользу им не пошло - точно знаю что потом находили

и патчили несколько довольно трудноуловимых глюков(причем под

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

вроде юниксовый вариант, а виндовый нет ;) )...

 

ASN.1? А что есть его библиотека на Ada? Где?

 

OpenH323 на Ц++, а asn насколько я понял используют

для конвертации своих описаний в код C++ - уже народу

и на Ц++ лень руками писать ;) (причем не "линейный"

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

насколько я понял) Как представлю что в этом

чуде потом еще и глюки искать придется, так сразу

тянет поискать какие-нить либы по проще ;)_

 

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

если уже есть работающее и отлаженное - чаще ведь нужен

только .exe для обработки, сами-то эти препроцессоры

в состав программы обычно не входят.

 

Вот что бы действительно хорошо бы переписать - дак это

линуксячий загрузчик, а то там дока на него никакая,

а исходник еще страшнее ;) Кстати как насчет генерации

подобного кода gnat? (pragma no_run_time; знаю что есть,

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

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

 

Vladimir

PS Кстати, может нормальный дистрибут юникса сделаем?

А то у меня такое ощущенье что весь этот хлам который

идет под видом дистрибутива системы(хотя причем тут

система не понятно - системных файлов в том-же дубиане

и 1% не будет - все остальное хлам устаревших версий

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

мелкософтом ;) чтобы саму идею open source

позорить - типа исходники-то есть, но и они вам

не помогут ;) В общем медленно и верно делают

из юникса винды, фантазии-то видать на большее

чем содрать не хватает...

Корочу думаю так - ядро + sh + BusyBox, и вся система.

Далее конечно придется сильно напрячся сбором доки

со всех углов интернета, бо сделать в той линуксячей

тусовки это похоже не кому было :) Ихнии дурацкие

и глюкавые породии на базу данных вроде apt-get и тп

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

Ну и на все остальное вместо всяких перловок и пр

хлама думаю можно попробовать BUSH (ака AdaScript,

посмотрим что за птица... Если че, на него вроде

и исходники есть, и напильник :) ) Весь остальной

хлам похоже свободен - это уже должны быть

тематические сборники софта/проектов, а не хлам

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

А, ну gcc и тп похоже еще можно в базовый набор

записать(хотя это часть сборника на тему программирования),

коли уж сама система и софт опенсорсные...

Из системы надо бы все системные фичи вкрутить

сразу - всякие примочки вроде badMem, поддержку

кластеров, disk editor и тд и тп, вот это точно

можно отнести к системе, а в дистрах этого вообще

даже нет...

Ну и комплект всяких архиваторов и тп софта

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

на случай если он не грузиться(что обычно и бывает,

тестировались эти сборники хлама даже меньше чем

винды, так что даже до док не доберешься...

Прям как в том анекдоте - "пока плавать не научитесь,

воду не нальем!" ;) ).

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 12 Sep 2005 14:44:07 +0400, Vadim Godunko <godunko@...> wrote:

 

Maxim Reznik wrote:

 

Да, так было. Но на сегодняшний день имеет место быть отказ от

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

контроля автоматически сгенерированного кода.

 

Ух ты. А по подроднее можно?

См. GNAT. См. C++ из GCC 4.1. Все они отказались от использования yacc.

 

Причины две, во-первых, в реальной жизни иногда невозможно прямо сейчас

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

 

скорее всего просто потому что он тормоз, ну и песочница, со своими заскоками ;)

 

Да и реализация, "я тебя слепила, из того что было..." ;)))

 

Yacc это называет кажись Shift Conflict и никакого его решения не

предоставляет.

 

LR(1) тама вроде было, тоесть одну лексему наперед он таки просматривает,

а больше и не надо в большинстве случаев.

 

А по поводу всяких извращений - там их есть :)

Например, спец лексема error - можно писать правила с ее использованием

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

желании обойти можно, но это надо уже извращаться и разбираться

как эта диковинка внутри сделана, а там ой ;)

 

 

Это что, теперь таблицы

лексического анализатора теперь руками писать надо? :-)

 

А почему бы и нет? ;) Таблицы конечно писать глупо, но вот использовать

подход, аналогичный используемому в GNAT - можно запросто.

 

А там как?

Раньше было модно тупо в лоб по буквам разбирать - например, в RT-11 на

PDP-11 таблицы команд не было - разбирал тупо в лоб, по буквам. Тоесть

просто прога на асме - проверяем какая там буква, и сравнение и условный

переход. Оно конечно круто и быстро все, но писать такое руками и отлаживать

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

из-за ресурсов...

Турбо паскаль этим тоже баловался - лексику там такой-же фигней

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

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

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

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

 

Vladimir

PS Прикольнее штучки вроде той adf+sdf или как там ее, в общем где кроме

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

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

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

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

легко конвертировать по правилам и саму формулу или алгоритм, так что

меняется вообще все, а не просто простейшая оптимизация как при компиляции...

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 12 Sep 2005 14:44:07 +0400, Vadim Godunko <godunko@...> wrote:

Maxim Reznik wrote:

 

Да, так было. Но на сегодняшний день имеет место быть отказ от

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

контроля автоматически сгенерированного кода.

 

Ух ты. А по подроднее можно?

См. GNAT. См. C++ из GCC 4.1. Все они отказались от использования yacc.

 

Причины две, во-первых, в реальной жизни иногда невозможно прямо сейчас

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

Yacc это называет кажись Shift Conflict и никакого его решения не

предоставляет.

 

кстати надо будет найти оригинальные исходники и доку на yacc - это просто

песня... Я в общем его хочу занести в коллекцию примеров как не надо

писать исходники :) Очень поучительно... Там в общем ни нормальных

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

что и как там сделано в реализации.

 

 

Это что, теперь таблицы

лексического анализатора теперь руками писать надо? :-)

 

А почему бы и нет? ;) Таблицы конечно писать глупо, но вот использовать

подход, аналогичный используемому в GNAT - можно запросто.

 

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

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

пролог, или любая другая синтаксическая песочница), так что впринципе

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

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

тупо интерпретировать эти правила на ходу хоть полным перебором

по исходной текстовке ;) (кстати это не совсем прикол - иногда может

быть оправдан и такой подход, в общем это хоть и медленно, но зато более

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

 

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

и протоколов, а так-же GUI/меню и клиент-серверных дел и DSL свалить

в одну кучу - между ними слишком много общего, к тому-же похоже

что для них подход на базе DSL очень хорошо подходит...

 

 

А вот обсуждение corba думаю стоит подумать в перспективе перенести

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

заинтересуется... Кстати, тут с ходу по нему вот такой обзор

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

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

(технически если не найдется серьезного готового раскрученного

места где его обсуждают возможно есть смысл сделать это как

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

кто-нить придет)

http://www.optim.ru/cs/1998/4/corba/corba.asp

- Основы CORBA

 

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

чем он лучше или хуже других еще вопрос спорный - это уже надо

конкретно рассматривать в каждом конкретном случае, заранее

его записывать в что-то "более правильное" для Ады или вообще

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

 

Кстати, а кто что думает насчет ее IDL? (если есть точные ссылки

на хорошие описания и исходники реализаций то не откажусь :) )

Так в общем первое впечатление - песочница, которая хорошо

пойдет в качестве примера как не надо делать DSL ;)

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

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

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

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

В общем в подобных случаях думаю есть смысл подумать насчет

реализации таких описаний напрямую на Аде и тп, хотя стоит

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

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

http://www.optim.ru/cs/1998/4/corba/corba.asp

- Основы CORBA

 

Достаточно хорошо устаревший вариант :(

 

В настоящее время что такое BOA знают разве что динозавры (которые давно вымерли)

 

 

Кстати, а кто что думает насчет ее IDL? (если есть точные ссылки на хорошие описания и исходники реализаций то не откажусь :) )

 

Сложно обсуждать IDL. Я его не очень люблю, поскольку привык думать в понятиях Ada. Однако после приобретения некоторого опыта отмечу, что его использование идет очень легко, только изредко и в исключительных ситуациях заплывая в тупики, которые тем или иным способом разруливаются.

Однако у нас на IDL разрабатываются только интерфейсы взаимодействия подсистем, а подсистемы проектируются целиком и полностью на Ada.

hi,

 

teplouhov@... wrote:

 

Раньше было модно тупо в лоб по буквам разбирать - например, в RT-11 на

PDP-11 таблицы команд не было - разбирал тупо в лоб, по буквам. Тоесть

просто прога на асме - проверяем какая там буква, и сравнение и условный

переход.

 

хм... а сейчас разве работа сканера строится иначе?

 

Alex

On Wed, 14 Sep 2005 12:49:56 +0300, Oleksandr Havva <alex@...> wrote:

teplouhov@... wrote:

 

Раньше было модно тупо в лоб по буквам разбирать - например, в RT-11 на

PDP-11 таблицы команд не было - разбирал тупо в лоб, по буквам. Тоесть

просто прога на асме - проверяем какая там буква, и сравнение и условный

переход.

 

хм... а сейчас разве работа сканера строится иначе?

 

на yacc или рекурсивке это было бы в сотни раз медленнее,

плюс ко всему были бы скорее всего и куча таблиц, если

оптимизировать то можно и без них обойтись... К тому-же

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

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

(хотя построение такого генератора думаю возможно - на базе

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

не тупой yacc с алгоритмической реализацией)

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Tue, 13 Sep 2005 20:46:53 +0400, Vadim Godunko <vgodunko@...> wrote:

teplouhov@... wrote:

 

http://www.optim.ru/cs/1998/4/corba/corba.asp

- Основы CORBA

 

Достаточно хорошо устаревший вариант :(

 

ну, зато на халяву ;)

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

на день работы если не больше... (скорее всего есть и более свежие

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

Ну и кое-какие представления все-же дает, лучше чем ничего.

 

Тоесть это я к тому, что если выносить обсуждения подобных вещей

в более подходящие места то это дает кое-какую экономию и бонусы ;)

 

...

 

Кстати, а кто что думает насчет ее IDL? (если есть точные ссылки

на хорошие описания и исходники реализаций то не откажусь :) )

 

Сложно обсуждать IDL. Я его не очень люблю, поскольку привык думать в

понятиях Ada. Однако после приобретения некоторого опыта отмечу, что его

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

ситуациях заплывая в тупики, которые тем или иным способом разруливаются.

 

Однако у нас на IDL разрабатываются только интерфейсы взаимодействия

подсистем, а подсистемы проектируются целиком и полностью на Ada.

 

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

правил или таблицы состояний как и для описания синтаксиса. При этом

думаю экономия будет аналогичная - на порядки по размеру исходника

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

исходник - меньше ошибок. Причем как по мне дак это самый кардинальный

способ борьбы с глюками - нет программы - нет и ошибок ;)))

 

Ну а IDL насколько я понял просто конвертор из одного формата в другой,

ничего общего с yacc-подобными вещами - они штучки совсем другого типа

и похоже более высокого уровня.

Кстати, а он(IDL) вообще-то нужен, как впечатления? Всмысле что

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

если все части на одном языке... Насколько я понял этот аппендикс

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

в разные языки - если части системы на разных языках то это хороший

способ синхронизации и борьбы с такими глюками(хоть и сам язык

уродский ;) ).

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

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

IDL в CORBA играет очень важную роль. Описание на нём является машинно и языково независимым описанием интерфейса некоторого сервера. Это

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

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

 

(У меня была ситуация, когда сервер был реализован на Ada под Linux, а клиент потом написан на Delphi под Windows. И всё прекрано работало.)

Для IDL существет подобие ASIS, именуемое репозиторием интерфейсов (Interface Repository). Интерфейс IR так же описан на IDL и позволяет провести анализ любого элемента описания. Кроме анализа на основании информации, полученной от IR и с использованием интерфейса динамического вызова (DII - Dinamic Invocation Interface) и Dynamic Any можно

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

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

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