Ada_Ru форум

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

Совмещение языков

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

Сообщения

u0410u043du0434u0440u0435u0439u
Совмещение языков
2007-03-10 11:07:11

Добрый день (вечер, утро, ночь)!

 

Немного предистории:

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

создающих очередной сетевой "проЭкт". Процесс идёт медленно, но как ни странно идёт уже 3 года.

Последнее время остро встал вопрос кросплатформенности некоторых частей программы. Как вариант появилась идея писать эти части на ADA (оригинальность решения тут занимает не последнее место). В связи с чем...

 

Технический вопрос:

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

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

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

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

поддерживает 5 соглашений о вызовах.

 

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

(например DLL) на ADA.

 

Заранее Спасибо. (если конечно кто оветит)

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

ПС: что-то активность здесь не высока.

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

(например DLL) на ADA.

 

О каком именно компиляторе Ада идет речь? Если о GNAT, то в руководстве пользователя этому уделено немало внимания.

 

ВФ

On Sat, 10 Mar 2007 11:07:11 -0000, you wrote:

 

Технический вопрос:

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

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

поддерживает 5 соглашений о вызовах.

 

cdecl в Delphi против Convention C в Ada должно быть хорошо. Со строками может случиться легкий геморрой, но ничего такого, что потребовало бы серьезных усилий.

 

Хотелось бы разобраться с вопросом создания исполняемых модулей (например DLL) на ADA.

 

Нет проблем, только вот Borland не очень-то любит import libraries. Так, что с Delphi DLL могут и не случиться иначе, как статически, или через GetProcAddress. Но это не из-за Ada. А вообще, DLL - не portable...

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Спасибо за ответы.

Мне уже удалось написать DLL на ADA и подключить к Delphi программе с использованием соглашения stdcall.

Главное выяснил, что это возможно (и даже не так сложно как

ожидалось). Теперь можно со спокойной душой переходить на ADA и

изучать этот вопрос подробнее.

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

Ещё конечно хотелось бы узнать про строки произвольной длинны.

Из того что я видел варианты:

--Первый

Line: string(1..80);

begin

Get_Line(Line,Length);

Put(Line(1..Lenght));

end; --по моему это несколько сложновато

--второй

использование Unbounded_string, но судя по "Урокам Ады" там нужны нестандартные библиотеки (которых по ссылке нет).

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

Ну и в продолжение предыдущего вопроса:

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

существование термина "динамический массив" во всех случаях нужно определять размер массива зарание (в разделе объявлений).

Существует ли аналог Delphi функции SetLength(array,length)?

u0410u043du0434u0440u0435u0439u wrote:

 

Ещё конечно хотелось бы узнать про строки произвольной длинны.

Из того что я видел варианты:

--Первый

Line: string(1..80);

begin

Get_Line(Line,Length);

Put(Line(1..Lenght));

end; --по моему это несколько сложновато

--второй

использование Unbounded_string, но судя по "Урокам Ады" там нужны нестандартные библиотеки (которых по ссылке нет).

 

Как это? Unbounded_string - тип, определенный в стандартной

библиотеке. В чем именно проблема?

 

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

Ну и в продолжение предыдущего вопроса:

Я не нашёл динамических массивов. Судя по учебнику, несмотря на существование термина "динамический массив" во всех случаях нужно определять размер массива зарание (в разделе объявлений).

Существует ли аналог Delphi функции SetLength(array,length)?

 

Посмотрите пакет GNAT.Table. Но это - "закат солнца вручную".

 

В Аде сейчас есть всевозможные контейнеры, включая векторные.

u0410u043du0434u0440u0435u0439u wrote:

 

Хотелось бы разобраться с вопросом создания исполняемых модулей (например DLL) на ADA.

 

Мы успешно используем DLL на Ada в Linux-е совместно с основными программами на C++.

 

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

 

Если основная программа написана на Ada, то проблем с DLL быть не должно. Хуже, если основная программа об Ada ничего не подозревает. Здесь необходимо учитываить, что Ada программа имеет этап "предысполнения" (elaboration) и необходимо учесть, что оно корректно проведено для модулей в DLL.

 

Для Linux решение тривиальное - необходимо просто вызывать bind-ер с ключом автоматической инициализации (-a), для Windows это может не пройти, а может и пройти - просто не знаю - но по любому Windows имеет сообщение инициализации DLL, его описание можно встретить в Internet-е, и нужно будет написать C-шную программу строк в 20 вызывающую сформированную bind-ером подпрограмму предысполнения.

u0410u043du0434u0440u0435u0439u <marina-ala <at> yandex.ru> writes:

 

Спасибо за ответы.

Мне уже удалось написать DLL на ADA и подключить к Delphi

программе с

использованием соглашения stdcall.

Главное выяснил, что это возможно (и даже не так сложно

как

ожидалось). Теперь можно со спокойной душой

переходить на ADA и

изучать этот вопрос подробнее.

 

Вообще, интеграцию Delphi&Ada я затрагивал на Quality Central :

http://qc.borland.com/wc/qcmain.aspx?d=37791

 

Как умел, объяснил проблему, но, видимо, у Borland и их пользователей другие дела. Или это из-за того, что мало, кто принимает участие в QC? Недавно вот Delphi for PHP анонсировали. Вот, к чему всё идёт.

http://codegear.com/AboutUs/News/DelphiForPHP/tabid/239/Default.aspx Один голос всё-таки остался (не мой ;) ).

 

Последний ответ довольно точно IMHO обрисовывает картину :

 

Martin Müller at 12/27/2006 4:43:26 AM

 

Ivan,

 

you are absolutely right. But I don't believe that anybody not knowing Ada will realize that.

Including the guys from Borland.

 

Martin

 

После этого я разочаровался в успехе.

А сейчас я вообще пересел на Mac OS X,

Delphi:mac даже не начинали делать.

Хотя 2895 человек (на момент написания) даже подписались за это : http://www.petitiononline.com/mod_perl/signed.cgi?bdfmosx

 

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

Ещё конечно хотелось бы узнать про строки

произвольной длинны.

Из того что я видел варианты:

--Первый

Line: string(1..80);

begin

Get_Line(Line,Length);

Put(Line(1..Lenght));

end; --по моему это несколько сложновато

--второй

использование Unbounded_string, но судя по "Урокам Ады" там

нужны

нестандартные библиотеки (которых по ссылке нет).

 

Я лично делаю так :

declare

Line : String := Get_Line;

begin

Put_Line (Line);

end;

 

a-textio.ads Ada.Text_IO :

function Get_Line return String;

pragma Ada_05 (Get_Line);

[...]

10.03.07, u0410u043du0434u0440u0435u0439u<marina-ala@yandex.ru> написал(а):

 

Технический вопрос:

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

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

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

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

поддерживает 5 соглашений о вызовах.

 

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

(например DLL) на ADA.

 

если реч о gnat, то все сделано на базе гнусного gcc,

так что если от гнусных поделок не тошнит, то особых

проблем быть не должно ;) На крайняк исходники есть :))

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

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

от многих гнусных поделок)

 

 

Заранее Спасибо. (если конечно кто оветит)

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

ПС: что-то активность здесь не высока.

 

да все тут, на месте :)

 

а что траффик не большой, дак это наоборот очень хорошо,

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

то думаю многие спецы перестанут ее читать или просто отпишутся...

 

Vladimir

PS Кстати, об эхе - может быть имеет смысл сделать зеркало

на гугле групсах? Там поиск сразу под рукой ;)

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

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

u0410u043du0434u0440u0435u0439u <marina-ala <at> yandex.ru> writes:

Технический вопрос:

В учебниках описаны механизмы языка, призванные

обеспечить

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

примеров как это

сделать я не нашёл. В директивах компилятора

указывается язык с

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

например Delphi

поддерживает 5 соглашений о вызовах.

 

Проверить свои предположения я сейчас не смогу, но :

По-идее, в GCC-варианте Ады можно

использовать мощь ассемблерных шаблонов,

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

учтены.

 

План таков :

 

1) Экспорт функции Ada->Delphi

 

На Аде пишется такой Binding :

 

function MyFunc (Param1, Param2, Param3, Param4, Param5 : in Integer) return Integer;

pragma Inline (MyFunc);

-- реализация

[...]

function MyFuncBinding (Param5, Param4 : in Integer) return Integer; pragma Export (Stdcall, MyFuncBinding);

[...]

function MyFuncBinding (Param5, Param4 : in Integer) return Integer is Param1, Param2, Param3 : Integer;

begin

Asm ("", Volatile => True, Outputs =>

(Integer'Asm_Output ("=a", Param1),

Integer'Asm_Output ("=d", Param2),

Integer'Asm_Output ("=c", Param3)));

return MyFunc (Param1, Param2, Param3, Param4, Param5);

end MyFuncBinding;

 

Плюс, нужно было ещё какой-то ключик писать, чтоб inline разрешить.

А в Delphi Binding :

 

function MyFunc(Param1, Param2, Param3, Param4, Param5 : const Integer) : Integer;

external 'MyDLL' name 'MyFuncBinding';

 

При таком подходе MyFuncBinding должен быть не просто обёрткой,

а полноценной реализацией MyFunc, принимающей параметры в

родном для Delphi соглашении о вызове register.

3 первых допустимых параметра (не всегда 3 первых!) передаются

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

вызванная функция. Среди GNAT-поддерживаемых соглашений

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

(Fortran и COBOL для меня остаются загадкой)

Чаще всего, конечно, все параметры умещаются в регистрах.

За счёт этого производительность выше.

 

2) А теперь наоборот Delphi -> Ada

 

Delphi :

 

function MyFunc(Param1, Param2, Param3, Param4, Param5 : const Integer) : Integer;

// реализация

 

Ada :

 

function MyFuncBinding (Param5, Param4 : in Integer) return Integer; pragma Import (Stdcall, MyFuncBinding, "MyFunc");

[...]

function MyFunc (Param1, Param2, Param3, Param4, Param5 : in Integer) return Integer;

pragma Inline (MyFunc);

[...]

function MyFunc (Param1, Param2, Param3, Param4, Param5 : in Integer) return Integer is

begin

Asm ("", Volatile => True, Inputs =>

(Integer'Asm_Output ("a", Param1),

Integer'Asm_Output ("d", Param2),

Integer'Asm_Output ("c", Param3)));

return MyFuncBinding (Param5, Param4);

end MyFunc;

 

Здесь, наоборот, расчёт на то, что программа на Аде, используя привязку MyFunc, сама будет заранее готовить данные в нужные регистры (благодаря движку gcc), и вызывать Delphi-функцию как если бы её вызывала программа на Delphi.

adainit и adafinal, думаю, без всяких проблем пишутся в Delphi-привязки в секции Initialization и Finalization.

 

Интересное начинается, если делать более полный binding :

Конвертация Exception. Вот, где непаханное поле для фантазии!

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

строк Ады и строк Delphi.

 

Ссылки :

GNAT Pro User's Guide : Inline Assembler

http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_31.html

 

Delphi 5 Object Language Guide : Program Control

http://info.borland.com/techpubs/delphi/delphi5/oplg/control.html

Stdcall Calling Convention

http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gnat_ugn_unw/Stdcall-Calling-Convention.html

Vadim Godunko <vgodunko <at> rostel.ru> writes:

Как я понял, одним из основных аспектов является

разработка GUI. На

сегодняшний день для Ada уже существует несколько

продуктов. БОльшая

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

Значит, именно платформозависимые?

 

Посему вопрос о кроссплатформенном

GUI с родным внешним

видом на каждой платформе на сегодня на мой взгляд

закрыт. Причём и Gtk

и Qt включают собственные дизайнеры GUI вполне

приемлемого качества и

функциональности.

 

 

То, что я видел, с точки зрения массового пользователя,

родным внешним видом можно назвать лишь с некоторой

натяжкой.

 

http://ccfit.nsu.ru/~levashev/PIC/Private/GTK_First.PNG

http://ccfit.nsu.ru/~levashev/PIC/Private/GTK_Dialog.PNG

 

Я, правда, GTK-Wimp не пробовал ставить.

http://gtk-wimp.sourceforge.net/

Или это и было уже с Wimp'ом?

 

Qt тоже не идеален. Например, в Mac OS X, если у приложения

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

http://ccfit.nsu.ru/~levashev/PIC/Private/CyberDuck_Queue.png

А в Psi можно видеть, что заголовок заканчивается под названием,

а тулбар идёт ниже, в окне, и кнопочки объёмные.

http://ccfit.nsu.ru/~levashev/PIC/Private/Psi_SD.png

 

Вот ни с чем не спутаешь. Если Gtk или Qt на чужой платформе -

то это видно.

 

Пока что я разочарован тем, что видел. Больше, чем на

упомянутую приемлемость это не тянет.

 

Слишком разные у платформ парадигмы. Вот ещё пример :

На PC в обиходе управляющие комбинации с Control.

Control-C, Control-X, Control-F, и так далее.

В то же время на Маке, несмотря на то, что Control

на клавиатуре присутствует, его функции выполняет Command.

На Windows есть локальные акселераторы (это когда

буква подчёркнута, и на неё можно быстро Alt-буквой

перейти), та ещё головная боль при переводе, надо сказать.

Либо следовать Guidelines, либо просто не использовать эту фичу.

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

скорее мышкой ткнёт, чем нажмёт Alt и посмотрит, какая там буква. Что касается Java, то её поддержка GUI сравнительно лучше,

чем GTK и Qt на Маке.

Но просто так Write Once, Run Everywhere не достаточно.

Если во всех приложениях Command-N открывает новое окно или

документ, а комбинацию с Control едва где встретишь

(ну примерно как WinKey на PC), то при работе с muCommander (Java) нужно использовать их Control аналоги, что не есть естественно.

В качестве контрпримера приведу Azureus - Java BitTorrent клиент. Там всё правильно разведено. Недостатки, правда, тоже есть.

Например, в Mac OS X есть специальный контрол SearchBar.

И он повсюду:

http://ccfit.nsu.ru/~levashev/PIC/Private/SearchBar.png

В том числе, для поиска опций :

http://ccfit.nsu.ru/~levashev/PIC/Private/Opt_Search.png

А в Azureus именно там, где ему самое место, мы видим лишь

дешёвую имитацию :

http://ccfit.nsu.ru/~levashev/PIC/Private/Azureus%20Filter.png

 

Но спорить не буду, это приемлемо. Мне, неприхотливому,

по крайней мере.

 

И так много чего может всплыть.

На одних платформах одни фишки, на других - другие.

На Винде MDI, на Mac OS X меню сверху.

 

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

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

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

платформы отдельно.

 

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

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

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

так оно и должно быть.

 

Вариантов много. Есть, наоборот, вариант не упираться

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

так что бы на любой платформе одинаково выглядело.

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

 

Хорошая подборка движков :

http://www.hal9k.com/cug/links/subject35.htm

 

 

 

Если вернуться к теме, GUI один из аспектов,

но это не всё. Существует ещё много нерешённых

проблем.

 

Ада нормально себя чувствует только на Linux/BSD.

На двух стратегически важных платформах Win&Mac

возникают свои "особенности".

 

Это не говоря о том, что, для Windows нет

GPL версии x64 компилятора, а для Macintosh - i686 версии.

Вот и как в таких условиях защищать свои убеждения перед

плюсистами?

 

Для i686-apple-darwin8 я компилятор всё-таки нашёл, FSF версию :

http://homepage.mac.com/awreynolds/

И очень хорошо, что нашёл. GNAT ведь просто так не

забутстрепишь из исходников, это вещь в себе.

Можно было бы попробовать на эмуляции Rosetta взять powerpc версию компилятора для powerpc, скомпилировать powerpc

версию компилятора для i686, и только потом

i686 компилятор для i686. Ну и на что это похоже?

В игрушки только, извините, этими официальными

GPL Edition дистрибутивами и играть. Обидно! Всё могло

быть намного лучше.

На Interix бы ещё GNAT не помешал. Глядишь, через mixed-mode

прорубили бы окно в x64-windows.

 

Как вариант, для таких тяжёлых случаев (читай: систем без GNAT)

подошла бы LLVM версия GNAT. На безрыбье и рак-рыба.

Но, увы, LLVM, поддерживает только C/C++. (плюс другие,

специально для LLVM языки)

 

Пока писал, пришла в голову идея

GNAT->AdaMagic->LLVM

может быть, и сработает.

 

Плюс, отсутствие в Стандарте Unicode API для файлов и консоли.

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

получится. Можно как расширение Стандарта ввести, что

все те же функции, только с широкими строками должны

работать так, как интуитивно требуется.

Но что тогда делать с кучей написанного кода, который

по идее должен работать только с ISO Latin-1?

Ведь, следуя Стандарту, открыть файл с русским именем

невозможно, потому что кодировка Character ISO Latin-1.

 

http://www.adaic.org/standards/05rm/html/RM-A-1.html

 

A.1 The Package Standard

[...]

-- The declaration of type Character is based on the standard

-- ISO 8859-1 character set.

 

На практике, к счастью, GNAT-maid программы функционируют

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

состояния "не терпит отлагательства".

 

Программы на Аде, правда, попроще будет на Юникод переточить,

чем C++, но всё же. gnatprep нам будет в помощь,

чтобы версии со String, Wide_String и Wide_Wide_String создавать.

Я думаю, если бы такие компании, как Borland, нацеленные на

потребительские платформы, ну хотя бы Windows, занялись бы

этим, мы бы уже не страдали от этих проблем. Это и был смысл

моего отчёта.

 

Больше ни у кого таких затруднений не возникает?

Vladimir Teplouhov wrote:

10.03.07, u0410u043du0434u0440u0435u0439u<marina-ala@...> написал(а):

Технический вопрос:

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

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

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

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

поддерживает 5 соглашений о вызовах.

 

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

(например DLL) на ADA.

 

 

если реч о gnat, то все сделано на базе гнусного gcc,

так что если от гнусных поделок не тошнит, то особых

проблем быть не должно ;)

Считаю Вашу иронию неуместной. GCC линейка компиляторов, одна из лучших в мире.

Ее даже сравнивать не с чем.

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

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

Еще знаю есть Borland Delphi, MSVC, но они просто непереносимы. Лучший код они не генерируют. И ошибок там не меньше.

На крайняк исходники есть :))

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

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

от многих гнусных поделок)

 

Советую Вам воздержаться от непродуманных оценок софта.

Dmitriy Anisimkov wrote:

код они не генерируют. И ошибок там не меньше.

 

На крайняк исходники есть :))

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

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

от многих гнусных поделок)

 

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

Весь Линукс сделан на лицензии GPL. И куча народа на нем работает, и сервера держит.

И поделками это назвать я думаю нельзя. Это софт промышленного качества.

12.03.07, Dmitriy Anisimkov<anisimkov@ada-ru.org> написал(а):

Vladimir Teplouhov wrote:

> 10.03.07, u0410u043du0434u0440u0435u0439u<marina-ala@yandex.ru>

написал(а):

>

>> Технический вопрос:

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

>> совместимость с другими языками. Но конкретных примеров как это

>> сделать я не нашёл. В директивах компилятора указывается язык с

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

>> поддерживает 5 соглашений о вызовах.

>>

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

>> (например DLL) на ADA.

>>

>

> если реч о gnat, то все сделано на базе гнусного gcc,

> так что если от гнусных поделок не тошнит, то особых

> проблем быть не должно ;)

Считаю Вашу иронию неуместной. GCC линейка компиляторов,

одна из лучших в мире.

 

а я разве что-то говорил конкретно про gcc? ;) Впрочем давно

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

понято не правильно... Ну да ладно, мне наверно следует в след

раз понятней писать, проехали :)

gcc конечно хорошая штучка - всмысле обкатки. Проверено на миллионах

кроликах и доработано тысячами напильников :) Врядли такое массовое

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

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

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

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

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

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

развития)...

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

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

а может быть это из-за Ц) Конечно хорошо что исходник есть, но

польза от этого

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

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

опечаток), не то что пытаться прикручивать чего-нить новенькое... (хотя если

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

но скажем так - такая работа меня бы совсем не прикалывала :) Вот поковыряться

в gnat куда как приятнее :) )

Кстати если вернуться к исходному вопросу - насколько я понимаю при

скрещивании

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

взят из gcc и

все-же на Ц, со всеми вытекающими... Впрочем если это любительский проект то

может это и не так важно - вероятность нарваться на глюк в этом месте

не высока,

вполне возможно что обойдется все штатными средствами. На крайняк можно

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

 

Ее даже сравнивать не с чем.

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

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

 

это эффект естесственной монополизации ;)

умный менеджер не будет тратить миллиарды на изобретение

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

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

где изобретение велосипеда по-моему ставиться первой целью :)

(кстати а судят о GNU по любительским поделкам - их просто больше на порядок)

 

Еще знаю есть Borland Delphi, MSVC, но они просто непереносимы. Лучший

код они не генерируют. И ошибок там не меньше.

 

ну с закрытыми потенциальными покойниками :) все понятно - все-же

как-то не гуманно сравнивать технологии и ресурсы разного уровня...

(открытые технологии просто на пару порядков эффективнее,

но из-за бардака и не организованности гнусников коммерсантам

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

внутри и позолоченных снаружи велосипедах)

 

Но местами я смотрю тот-же дельфи прочно держит свои хоть и не большие ниши.

Как ни странно :)

 

> На крайняк исходники есть :))

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

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

> от многих гнусных поделок)

>

Советую Вам воздержаться от непродуманных оценок софта.

 

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

ковыряние в навозе(который почему-то называется исходниками :) ) и тд и тп?

 

По-моему уже давно пора к open source добавить требование хорошего

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

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

исходник лучше чем плохой :)

 

Vladimir

PS советую пообщаться с другими программистами(а не гнусники

как ни странно все еще есть, причем их даже очень много :) ) и послушать

что они думают о гну.

(выбери случайно десяток-другой проектов на том-же sf.net и посмотри

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

туда случайно и какое может быть мнение у народа :) Как ты уже наверно

догадался, вероятность случайно попасть в пром. проект уровня gnat

очень не большая - их просто небольшой процент по сравнению с любительскими)

Впрочем я уже перестал сильно расстраиваться по этому поводу - теперь

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

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

подальше и тихо смотреть и прикалываться как чел тратит свое время

на ковыряние в бесперспективных коммерческих песочницах :}

(какая я ехидная пакость, да? :) )

Но мне все-же жалко что много в общем-то не плохих программистов

из-за этого не участвуют в open source - могли бы и пригодиться...

 

PPS и кстати линукс плохой пример - там конечно есть хорошие GPL модули,

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

а не полуфабрикатном наборе халявных запчастей) большинство известных

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

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

чаще сделаны в стиле "подделка под винды", IMHO. Слава виндуса

покоя не дает чтоли :) А ведь могли бы что-то новое лучше придумать вполне...)

Это тоже не способствует рекламе GNU.

Vladimir Teplouhov wrote:

 

(кстати а судят о GNU по любительским поделкам - их просто больше на порядок)

 

Так судят только любители. Их тоже - на порядок больше. Пусть себе судят.

Такие суждения интересны лишь любителям.

 

В индустрии действуют совсем другие законы. Там не судят - там оценивают

и просчитывают, а также пробуют и тестируют. И не любители, а профессионалы.

 

По-моему уже давно пора к open source добавить требование хорошего

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

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

исходник лучше чем плохой :)

 

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

И - зачем и почему станет? И еще - на какие шиши станет?

Vladimir Teplouhov wrote:

12.03.07, Dmitriy Anisimkov<anisimkov@...> написал(а):

 

Vladimir Teplouhov wrote:

 

Вы, Господин Теплоухов как я вижу склонны к неуместной и необоснованной критике.

А по сути вопроса, топика сказали пару слов, да и то ничего конкретного. Как будто пытаетесь флейм спровоцировать, да ?

Maxim Reznik <yeo <at> mail.zp.ua> writes:

 

 

On Sun, Mar 11, 2007 at 07:13:11PM +0000, Ivan Levashew wrote:

[skip]

План таков :

[skip]

 

Не пугайте меня! Зачем регистры? Простого pragma Export

(Stdcall, ...)

должно хватить.

 

Ну вдруг нужно будет? Может, для одного callback понадобится Ada

процедуру использовать, тогда callback на Stdcall менять придётся. И всё, что ему по сигнатуре подходило. Либо обёртку на Delphi

делать подходящую, либо на Аде.

 

Моё дело предложить.

 

А если (не дай Бог) и правду выйдет Делфи под Мас, че с

этими регистрами

потом делать :)

 

Перетачивать генератор привязок. Вообще, там, конечно, поинтереснее будет, если вспомнить, что кроме Intel Mac остались ещё Power Mac'и.

Но, я думаю, не выйдёт. С XCode и GPS вместе взятыми проблематично конкурировать.

Это только если существующий код под Mac хорошо пойдёт - тогда

существующая база поддержит.

 

По мне, так от cocoa-gnat

http://code.google.com/p/cocoa-gnat/

больше прямой пользы будет.

12.03.07, Dmitriy Anisimkov<anisimkov@ada-ru.org> написал(а):

Vladimir Teplouhov wrote:

> 12.03.07, Dmitriy Anisimkov<anisimkov@ada-ru.org> написал(а):

>

>> Vladimir Teplouhov wrote:

>>

Вы, Господин Теплоухов как я вижу склонны к неуместной и необоснованной

критике.

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

 

ну дак это кому как ;)

 

Как будто пытаетесь флейм спровоцировать, да ?

 

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

во-вторых, мне это точно не надо

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

во всех этих спорах вроде не безизвестных C vs pascal ;) и тп в общем-то

вся информация хорошо известна обоим сторонам - весь вопрос в подходе

и отношении к различным "мелочам". Если для кого-то вопросы вроде надежности

или затрат времени на ковыряние во всяком кривом хламе.. ой пардон нАиКрУтеЙших

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

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

на грабли и ехидно хихикать :) )... В любом случае спорить собсно не о чем,

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

что важно,

или пофиг.

 

Вот и для вас я смотрю многие важные вопросы "мелоч". Хотя впрочем это ваше

личное дело(или проблемы :) ). Вот только не надо тут пытаться защищать

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

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

этих "мелочей" - это будет гораздо полезней. А рассказывать что там все круто

мне не надо - я и сам прекрасно знаю сколько это стоит. И даже знаю сколько

на этом можно заработать(если б не знал - не ковырялся бы во всяком

навозе ;) )...

Тем не менее, я не буду врать и говорить как там все круто. Да, отдельные

элементы есть, даже в целом все неплохо обкатано, но тем не менее большинство

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

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

(подход когда машина якобы сама без спеца должна все делать - по опыту

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

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

загрузить даже при помощи напильника), ни до действительно open подхода(без

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

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

Так что давайте все-же не будем врать или путать разные вещи. Если просто

код обкатан и хорошо работает, то это одно, а вот если у него исходник написан

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

и не надо это путать или врать что все хорошо...

 

Вот что. Если есть желание с кем-нить поспорить о крутизне линукса или

еще какого полуфабриката, то предлагаю сделать это с пользой. Есть вот

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

оно круто :) (мне рассказывать не надо - я как уже говорил цену знаю,

просто мне некоторые "мелочи" и эта тусовка вокруг мягко говоря не нравятся)

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

те которые

делали некоторые гнусные поделки :) ), а если о "профессионализме" судить

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

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

зарабатывают больше ;)

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

Ну дак как, позвать? ;)

 

Vladimir

Vladimir Teplouhov wrote:

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

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

Провокацией флейма я считаю охаивание чего либо в рассылке новостей, В данном случая я вижу с Вашей стороны охаивание GPL исходников.

Спорить на эту тему я не собираюсь. Я просто предупреждаю Вас что за провокацию

флейма можно вылететь из группы.

во всех этих спорах вроде не безизвестных C vs pascal ;) и тп в общем-то вся информация хорошо известна обоим сторонам - весь вопрос в подходе и отношении к различным "мелочам". Если для кого-то вопросы вроде надежности или затрат времени на ковыряние во всяком кривом хламе.. ой пардон нАиКрУтеЙших

исходниках :) мелоч,

 

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

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

или пофиг.

 

Вот и для вас я смотрю многие важные вопросы "мелоч".

Это Вашы домыслы, я даже слово Мелочь не употребил.

Далее дискутировать не вижу смысла. Доказывать мне нет нужды Вам ничего.

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

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