Ada_Ru форум

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

Ada GUI lib

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

Сообщения

Alexey Veselovsky
Ada GUI lib
2008-10-26 23:05:24

Есть ли какие-нибудь полностью Адские кроссплатформенные гуи-библиотеки?

Вообще, какие-то особенности проектирования с нуля на Аде

gui-библиотеки имеются? Ну, например обычным явлением в

GUI-библиотеках является глубокие иерархии наследования (иногда

глубина более десятка), широкое использование интерфейсов (ака чисто виртуальных классов в С++) и т.д. и т.п.. При этом обычно никак не используются дженерики/шаблоны. Вносит ли Ада-специфика какие-то

коррективы в эти правила проектирования (или сложившуюся практику?) gui-библиотек?

Alexey Veselovsky wrote:

Есть ли какие-нибудь полностью Адские кроссплатформенные гуи-библиотеки?

Боюсь что на сегодняшний день таковых нет. :-(

 

Вообще, какие-то особенности проектирования с нуля на Аде

gui-библиотеки имеются? Ну, например обычным явлением в

GUI-библиотеках является глубокие иерархии наследования (иногда

глубина более десятка), широкое использование интерфейсов (ака чисто виртуальных классов в С++) и т.д. и т.п.. При этом обычно никак не используются дженерики/шаблоны. Вносит ли Ада-специфика какие-то коррективы в эти правила проектирования (или сложившуюся практику?) gui-библиотек?

 

А это тема отдельного исследования - как можно использовать возможности языка для улучшения/упрощения/... GUI библиотеки. ;-)

On Thu, 27 Nov 2008 02:05:24 +0300, you wrote:

 

Есть ли какие-нибудь полностью Адские кроссплатформенные гуи-библиотеки?

 

Нет, и быть не может, т.к. графические примитивы не являются частью ОС, т.е. в отличие от стандартного ввода-вывода надо, либо общаться

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

 

Вообще, какие-то особенности проектирования с нуля на Аде

gui-библиотеки имеются? Ну, например обычным явлением в

GUI-библиотеках является глубокие иерархии наследования (иногда

глубина более десятка), широкое использование интерфейсов (ака чисто виртуальных классов в С++) и т.д. и т.п.

 

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

При этом обычно никак не используются дженерики/шаблоны.

 

В силу вредности и бесполезности оных...

 

Вносит ли Ада-специфика какие-то

коррективы в эти правила проектирования (или сложившуюся практику?) gui-библиотек?

 

Сложный вопрос. Принципиально, единственно что Ада действительно может предложить это мультизадачность. Реализация сообщений может быть сделана на рандеву. Widget могли бы иметь synchronized интерфейс. Это - плюс. Но, реально, это не пройдет, т.к. задачи и protected типы не подлежат наследованию.

 

В минусе - отсутствие множественного наследования и dispatch-а. Лепить это на интерфейсах будет исключительно муторно. Много cut-and-paste, generics полезут, короче, жуткое месиво получиться.

 

Основная проблема в том, что делать это по-новой в Аде имело бы смысл только тогда, когда результат имел бы качество дизайна принятого и ожидаемого от Ады. Т.е. строгую типизацию, проверки времени компиляции (параметров сообщения, например) и т.д. На настоящий момент, по моей оценке, Ада 2005 просто не позволяет этого достичь для GUI. Это совсем не значит, что GTK или Qt нельзя было бы написать на Аде. Просто, результат оказался бы мало чем лучше, в том смысле, что основные проблемы остались бы не решенными.

 

Отвечая на вопрос, нет, Ада корректив, к сожалению, не внесет.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

А как наследование может использоваться для композиции виджетов?

 

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

On Fri, 28 Nov 2008 09:33:56 +0100, you wrote:

 

Dmitry A. Kazakov wrote:

 

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

А как наследование может использоваться для композиции виджетов?

 

Например, когда child наследует стиль, свойства и атрибуты своего контейнера. Стили - гигантский геморрой.

 

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

 

Можно, но никто этого не делает. Например, в Windows API некоторые widget-ы перехватывают сообщения от своих компонент. Но это делается не

наследованием, а в ручную. Если надо перехватить сигнал, вешают hook и т.п. Все это - ужасно.

 

Почему не делают? Потому, что для того, чтобы обработчики и сигналы образовывали свои иерархии, надо чтобы они существовала параллельно с иерархией widget-ов и были связаны с ней. Помимо очевидной необходимости иметь multiple-dispatch, надо также делать и другие сложные и непонятные вещи. И нет такого языка программирования, который бы такое позволял. Гораздо более простые штуки, и то нельзя:

 

type Integer_Array is array (Positive range <>) of Integer;

subtype Positive is Integer range 1..Integer'Last;

subtype Positive_Array is Integer_Array а дальше что? Стоп машина.

Системы типов и в Аде, и в других языках зависли на полдороги, к чему, не скажу, сам не знаю.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

On Fri, 28 Nov 2008 09:33:56 +0100, you wrote:

 

Dmitry A. Kazakov wrote:

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

А как наследование может использоваться для композиции виджетов?

 

Например, когда child наследует стиль, свойства и атрибуты своего контейнера. Стили - гигантский геморрой.

 

Т.е. речь идёт не об иерархии наследования классов, а об иерархии объектов и "наследовании" значений атрибутов контейнера. Это интересная штука и в некоторых случаях реально полезная.

 

Что касается стилей (имею в виду возможность изменения внешнего вида виджетов, не затрагивающих поведения), то Motif имеет ограниченную поддержку такой функциональности и позволяет использовать файлы ресурсов для преодоления ограничений; Qt позволяет задать стиль или css-like style-sheet для приложения в целом и для конкретного виджета и его потомков; про Gtk+ просто не знаю подробностей, но наверняка там что-то подобное быть должно.

 

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

 

Можно, но никто этого не делает. Например, в Windows API некоторые widget-ы перехватывают сообщения от своих компонент. Но это делается не

наследованием, а в ручную. Если надо перехватить сигнал, вешают hook и т.п. Все это - ужасно.

 

Речь опять идёт об иерархии объектов а не классов?

 

Почему не делают? Потому, что для того, чтобы обработчики и сигналы образовывали свои иерархии, надо чтобы они существовала параллельно с иерархией widget-ов и были связаны с ней. Помимо очевидной необходимости иметь multiple-dispatch, надо также делать и другие сложные и непонятные вещи. И нет такого языка программирования, который бы такое позволял.

А зачем multiple-dispatch? Что означает "обработчики и сигналы

образовывали свои иерархии"?

Vadim Godunko wrote:

Alexey Veselovsky wrote:

Есть ли какие-нибудь полностью Адские кроссплатформенные гуи-библиотеки?

Боюсь что на сегодняшний день таковых нет. :-(

 

Нет, я похоже обманул. Подробности нужно искать где-то в районе канала IRC именуемого кажется #ada на сервере freenode (точнее к сожалению сейчас не скажу). Там народ используя OpenGL как базовую библиотеку пытается изобрести GUI библиотеку целиком на Ada. У них имеется даже некоторый прогресс.

On Fri, 28 Nov 2008 10:55:23 +0100, you wrote:

 

Dmitry A. Kazakov wrote:

On Fri, 28 Nov 2008 09:33:56 +0100, you wrote:

 

Dmitry A. Kazakov wrote:

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

А как наследование может использоваться для композиции виджетов?

 

Например, когда child наследует стиль, свойства и атрибуты своего контейнера. Стили - гигантский геморрой.

 

Т.е. речь идёт не об иерархии наследования классов, а об иерархии объектов и "наследовании" значений атрибутов контейнера.

 

Где разница?

 

Это интересная

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

 

Что касается стилей (имею в виду возможность изменения внешнего вида виджетов, не затрагивающих поведения), то Motif имеет ограниченную поддержку такой функциональности и позволяет использовать файлы ресурсов для преодоления ограничений; Qt позволяет задать стиль или css-like style-sheet для приложения в целом и для конкретного виджета и его потомков; про Gtk+ просто не знаю подробностей, но наверняка там что-то подобное быть должно.

 

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

 

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

 

Можно, но никто этого не делает. Например, в Windows API некоторые widget-ы перехватывают сообщения от своих компонент. Но это делается не

наследованием, а в ручную. Если надо перехватить сигнал, вешают hook и т.п. Все это - ужасно.

 

Речь опять идёт об иерархии объектов а не классов?

 

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

Почему не делают? Потому, что для того, чтобы обработчики и сигналы образовывали свои иерархии, надо чтобы они существовала параллельно с иерархией widget-ов и были связаны с ней. Помимо очевидной необходимости иметь multiple-dispatch, надо также делать и другие сложные и непонятные вещи. И нет такого языка программирования, который бы такое позволял.

 

А зачем multiple-dispatch?

 

Widget класса A'Class принимает события с параметром из класса B'Class. Ясно, что обработчик должен зависеть от обоих типов. Я уж не говорю про rendering widget-а на графическом контексте - это классический пример.

Что означает "обработчики и сигналы

образовывали свои иерархии"?

 

Сигнал распространяется пока не обрабатывается. Цепочка обработчиков этого сигнала - типичная иерархия. Сами сигналы, тоже должны быть

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

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

А как наследование может использоваться для композиции виджетов?

Например, когда child наследует стиль, свойства и атрибуты своего контейнера. Стили - гигантский геморрой.

 

Т.е. речь идёт не об иерархии наследования классов, а об иерархии объектов и "наследовании" значений атрибутов контейнера.

 

Где разница?

 

Для меня разница весьма значима. Иерархия наследования классов есть статическая составляющая программы. А вот "наследование значений" есть способ динамического поведения программы.

 

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

 

Стили есть искусство, а искусство есть бардак ;-) Нет стилей - нет и бардака.

 

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

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

 

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

Можно, но никто этого не делает. Например, в Windows API некоторые widget-ы перехватывают сообщения от своих компонент. Но это делается не

наследованием, а в ручную. Если надо перехватить сигнал, вешают hook и т.п. Все это - ужасно.

 

Речь опять идёт об иерархии объектов а не классов?

 

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

 

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

граничные состояния для каждого порождаемого сигнала. Это как-то может помочь?

 

Почему не делают? Потому, что для того, чтобы обработчики и сигналы образовывали свои иерархии, надо чтобы они существовала параллельно с иерархией widget-ов и были связаны с ней. Помимо очевидной необходимости иметь multiple-dispatch, надо также делать и другие сложные и непонятные вещи. И нет такого языка программирования, который бы такое позволял.

А зачем multiple-dispatch?

 

Widget класса A'Class принимает события с параметром из класса B'Class. Ясно, что обработчик должен зависеть от обоих типов. Я уж не говорю про rendering widget-а на графическом контексте - это классический пример.

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

 

Что означает "обработчики и сигналы

образовывали свои иерархии"?

 

Сигнал распространяется пока не обрабатывается. Цепочка обработчиков этого сигнала - типичная иерархия. Сами сигналы, тоже должны быть

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

 

Хорошо, а как в таком случае дать опеределение понятию "класс сигналов"? Какие сигналы составляют один класс?

On Fri, 28 Nov 2008 14:14:25 +0100, you wrote:

 

Dmitry A. Kazakov wrote:

 

Наследование используется для реализации widget-ов, но не для композиции оных (parent-child widget), и не для обработчиков событий. С этим - беда. Особенно, с последним.

 

А как наследование может использоваться для композиции виджетов?

Например, когда child наследует стиль, свойства и атрибуты своего контейнера. Стили - гигантский геморрой.

 

Т.е. речь идёт не об иерархии наследования классов, а об иерархии объектов и "наследовании" значений атрибутов контейнера.

 

Где разница?

 

Для меня разница весьма значима. Иерархия наследования классов есть статическая составляющая программы. А вот "наследование значений" есть способ динамического поведения программы.

 

Ни разу не встречал. Все многочисленные и безобразные программы для графического набрасывания оболочек основаны на обратном - сугубо статичных отношений компоновки widget-ов. Все укладывается в схемы или record типа (разнотипные компоненты фиксированного числа), или array типа (однотипные компоненты переменного числа).

 

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

 

Стили есть искусство, а искусство есть бардак ;-) Нет стилей - нет и бардака.

 

Так я уже согласен! GUI - для молокососов. Взрослые дяди используют консоль, а еще лучше, телетайп. Жаль, заказчики этого не понимают... (:-))

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

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

 

Так ведь описания типов в Аде - декларативны! Потому я и говорю, что стили должны описываться иерархией наследования.

 

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

 

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

Можно, но никто этого не делает. Например, в Windows API некоторые widget-ы перехватывают сообщения от своих компонент. Но это делается не

наследованием, а в ручную. Если надо перехватить сигнал, вешают hook и т.п. Все это - ужасно.

 

Речь опять идёт об иерархии объектов а не классов?

 

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

 

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

 

Это почему? Диалог всегда преобразовывает щелканье по кнопке ОК в сигнал Commit. Где тут динамика?

 

При наличии кода

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

 

Это противоречило бы идеологии Ады - разделению интерфейса и реализации. Я бы хотел иметь контракты сигналов автоматически получаемые при наследовании и композиции widget-ов. Со статической проверкой их реализаций средствами языка. Всякие там "lint"-ы - проявление плохого дизайна языка/библиотеки.

Почему не делают? Потому, что для того, чтобы обработчики и сигналы образовывали свои иерархии, надо чтобы они существовала параллельно с иерархией widget-ов и были связаны с ней. Помимо очевидной необходимости иметь multiple-dispatch, надо также делать и другие сложные и непонятные вещи. И нет такого языка программирования, который бы такое позволял.

А зачем multiple-dispatch?

 

Widget класса A'Class принимает события с параметром из класса B'Class. Ясно, что обработчик должен зависеть от обоих типов. Я уж не говорю про rendering widget-а на графическом контексте - это классический пример.

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

 

А я не очень уверен, что есть такая необходимость. Осмелюсь предположить, что 1-n publishing сигналов - следствие существующего бардака. При более организованной системе это могло бы стать строго 1-1. (Я вспомнил все случаи когда я навешивал несколько обработчиков destroy на один widget. Все были либо от нужды, либо от беса.)

 

Что означает "обработчики и сигналы

образовывали свои иерархии"?

 

Сигнал распространяется пока не обрабатывается. Цепочка обработчиков этого сигнала - типичная иерархия. Сами сигналы, тоже должны быть

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

 

Хорошо, а как в таком случае дать опеределение понятию "класс сигналов"? Какие сигналы составляют один класс?

 

Ну например, сигналы rendering-а. Сигналы изменения состояния программно. Сигналы изменения состояния пользователем. Сигналы посылаемые widget-ом типа А. Сигналы им принимаемые. Много чего можно придумать.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Fri, Nov 28, 2008 at 11:02:22AM +0100, Vadim Godunko wrote:

 

Vadim Godunko wrote:

Alexey Veselovsky wrote:

Есть ли какие-нибудь полностью Адские кроссплатформенные гуи-библиотеки?

Боюсь что на сегодняшний день таковых нет. :-(

 

Нет, я похоже обманул. Подробности нужно искать где-то в районе канала IRC именуемого кажется #ada на сервере freenode (точнее к сожалению сейчас не скажу). Там народ используя OpenGL как базовую библиотеку пытается изобрести GUI библиотеку целиком на Ada. У них имеется даже некоторый прогресс.

 

 

Я думаю Вадим говорит о Lumen:

 

lumen: Lumen is a graphical user interface library written in Ada, modeled in part on GLUT and moreso on PUI. It is cross-platform by virtue of the fact that it uses OpenGL for all its display functions. It is in very early stages yet; a preliminary web site is at

http://www.niestu.com/software/lumen/

Alexey Veselovsky writes:

 

 

Есть ли какие-нибудь полностью Адские

кроссплатформенные гуи-библиотеки?

 

Одна из основных -- GWindows, ядро GNAVI. GNAVI для Ada

как Lazarus для Free Pascal. По крайней мере, были времена,

когда это ещё было так.

 

Сейчас GNAVI вроде как не очень развивается.

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

компоненты его живут второй жизнью, теперь уже без GNAVI.

 

Gautier de Montmollin не так давно аннонсировал GWenerator

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ 45fbadfd12cd06b0/467fa7ae1e11cb46?lnk=raot

 

GWenerator (как я понял) преобразует Windows ресурсы в

програмный код, создающий этот интерфейс:

 

http://sourceforge.net/forum/forum.php?forum_id=894053

 

Each time you save a GUI design from (say) Visual Studio or

ResEdit, GWenerator produces automatically the corresponding

Ada code using GWindows objects.

 

Разработка завязывается на Windows (не знаю, насколько сильно),

но сама GWindows имеет бэкенды GTK и Carbon (Carbon в зачаточном

состоянии), так что, может быть, будет работать кроссплатформенно.

Ещё из известных RAPID: http://rapid.martincarlisle.com/

 

В качестве бэкендов Tk, Gtk, Java, .NET (позволяет

компиляцию на управляемые платформы)

 

День добрый!

GWindows в сочетании GNATCOM используются у нас давно, является основным интерфейсом в текущих проектах. Собираем с ключами -gnatws -gnat95. Для Ada-2005 не проходит, конфликт с "interface". Исправить наверное можно но не хватило времени, используем пока в рамках Ada-95.

 

With best regards

Sergey Kirkorov www.mediascan.by

Email: ksiby@...

----- Original Message -----

From: Ivan Levashew

To: ada_ru@yahoogroups.com

Sent: Wednesday, December 24, 2008 11:14 AM

Subject: [ada_ru] Re: Ada GUI lib

 

 

Alexey Veselovsky writes:

 

>

> Есть ли какие-нибудь полностью Адские

> кроссплатформенные гуи-библиотеки?

>

Одна из основных -- GWindows, ядро GNAVI. GNAVI для Ada

как Lazarus для Free Pascal. По крайней мере, были времена,

когда это ещё было так.

 

Сейчас GNAVI вроде как не очень развивается.

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

компоненты его живут второй жизнью, теперь уже без GNAVI.

 

Gautier de Montmollin не так давно аннонсировал GWenerator

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ 45fbadfd12cd06b0/467fa7ae1e11cb46?lnk=raot

 

GWenerator (как я понял) преобразует Windows ресурсы в

програмный код, создающий этот интерфейс:

 

http://sourceforge.net/forum/forum.php?forum_id=894053

 

> Each time you save a GUI design from (say) Visual Studio or

> ResEdit, GWenerator produces automatically the corresponding

> Ada code using GWindows objects.

 

Разработка завязывается на Windows (не знаю, насколько сильно), но сама GWindows имеет бэкенды GTK и Carbon (Carbon в зачаточном состоянии), так что, может быть, будет работать кроссплатформенно.

Ещё из известных RAPID: http://rapid.martincarlisle.com/

 

В качестве бэкендов Tk, Gtk, Java, .NET (позволяет

компиляцию на управляемые платформы)

 

 

 

 

__________ NOD32 3353 (20080813) Information __________

 

This message was checked by NOD32 antivirus system.

http://www.eset.com

Sergey Kirkorov writes:

 

GWindows в сочетании GNATCOM используются у нас давно, является основным интерфейсом в текущих проектах. Собираем с ключами -gnatws -gnat95. Для Ada-2005 не проходит, конфликт с "interface". Исправить наверное можно но не хватило времени, используем пока в рамках Ada-95.

 

Можно-можно. Interface, насколько я помню, по отдельности не встречается, только вместе с GNATCOM, так что строка GNATCOM.Interface заменяется (в том числе в генераторах) на GNATCOM.COM_Interface. А ещё из мейкфайлов нужно убрать ключ -gnatg. И всё.

�����-�����. Interface, ��������� � �����, �� ����������� �� �����������, ������ ������ � GNATCOM, ��� ��� ������ GNATCOM.Interface ���������� (� ��� ����� � �����������) �� GNATCOM.COM_Interface. � ��� �� ���������� ����� ������ ���� -gnatg. � ���.

 

������, � ���� �� �����-������ ��������� �������� ��� ������������ ������ ��������? ���������� ������������� � �����-������ IDE.

Alexey Veselovsky wrote:

 

Кстати, а есть ли какие-нибудь доступные средства для рефакторинга адских программ? Желательно интегрируемые в какую-нибудь IDE.

 

Кое что есть в GPS.

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

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