Ada_Ru форум

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

qtada,gprbuil and xmlada ��� Debian, Ubuntu and Gentoo Linux

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

Сообщения

sma
qtada,gprbuil and xmlada ��� Debian, Ubuntu and Gentoo Linux
2002-01-01 03:45:40

Кстати! Имеется ли в природе более-менее внятный мануал по QtAda?

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

С самим Qt я знаком поверхностно, прочитал книгу, скомпилировал и запустил пару-тройку тестовых примеров на CPP.

По моему, чтобы юзать QtAda надо весьма плотно освоить Qt на С. А стоит ли игра свеч?

К тому же сама Qt-шная идея предпроцессора AMOC в корне противоречит концепции языка Ada.

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

В этом смысле GtkAda оказался гораздо проще, выражения на ней не такие ‘пятиэтажные’ как на QtAda.

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

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

Во вторых, В освоении GtkAda особенно помог дизайнер glade-2, который также имеется в дистрибутиве.

По тому как он генерирует текст проще всего научиться GtkAd-e.

В третьих, какой-никакой, есть манулал по которому более-менее можно понять что делает тот или иной пакет.

Хотя и своих непоняток хватает.

С уважением, =Михаил=

sma

По поводу AMOC и громоздкости QtAda.

Лично мне ‘навес’ над Адой некого инородного метасредства в виде AMOC не нравится, кстати, не только мне. Сам Ада компилятор постоянно ругается по этому поводу предупреждениями: warning: unrecognized pragma “Q_Slot” и warning: unrecognized pragma “Q_SIgnal”. Кстати, кто скажет как это отключить – буду благодарен.

По поводу громоздкости. Лаконичность самого языка Ада весьма на грани. Перегружать его дополнительно пятиэтажными выражениями – значит окончательно покончить с читабельностью и удобоваримостью исходного кода. Использование USE-выражений несколько спасает дело, но на начальном этапе освоения QtAda когда не понятно что от куда это только окончательно запутывает ситуацию.

=Михаил=

 

Кстати! Имеется ли в природе более-менее внятный мануал по QtAda?

Как бы примеры в комплекте и описание в документации.

 

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

 

:-(

 

С самим Qt я знаком поверхностно, прочитал книгу, скомпилировал и запустил пару-тройку тестовых примеров на CPP.

 

По моему, чтобы юзать QtAda надо весьма плотно освоить Qt на С. А стоит ли игра свеч?

 

Да, действительно требуется знание API Qt. Стоит ли, не стоит ли - дело сугубо личное.

 

К тому же сама Qt-шная идея предпроцессора AMOC в корне противоречит концепции языка Ada.

 

Почему? Amoc это не препрецессор, а полноценный компилятор, не трогающий пользовательский код никоим образом, но производящий специальную

информацию для внутреннего пользования.

 

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

 

Громоздкость здесь достаточно вымышленная, предназначеная в первую очередь для того, что бы было понятно откуда берётся тот или иной тип, подпрограмма. Если вписать несколько use-ов, то всё будет на порядок проще выглядеть, но понять это неподготовленному человеку и без

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

01.01.2002 06:45, sma пишет:

 

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

 

Еще примеры использования QtAda можно посмотреть тут.

http://qtada.svn.sourceforge.net/viewvc/qtada/trunk/examples/

 

Планируется перенести все Qt-шные примеры с С++ на аду.

 

К сожалению сейчас времени нет совсем ими заниматься,

но если вы желаете - присоединяйтесь.

Заодно и глубже изучете QtAda.

 

-- Best regards,

Alexander Basov.

On 01/01/2002 01:35 AM, sma wrote:

 

По поводу AMOC и громоздкости QtAda.

 

Лично мне ‘навес’ над Адой некого инородного метасредства в виде AMOC не нравится, кстати, не только мне. Сам Ада компилятор постоянно ругается по этому поводу предупреждениями: warning: unrecognized pragma “Q_Slot” и warning: unrecognized pragma “Q_SIgnal”. Кстати, кто скажет как это отключить – буду благодарен.

 

pragma Warnings (Off);

 

PS. Кстати, вот несколько полезных ссылок:

 

1. Документация на Qt:

 

http://doc.trolltech.com/4.6/

 

2. Документация на QtAda

 

http://www.qtada.com/documentation/qtada-3.1.0/qtada_ugr/index.html

3. Tutorial, перенесённый в QtAda один-в-один; исходные коды в

examples/tutorial:

 

http://doc.trolltech.com/4.4/tutorials-tutorial.html

 

4. Примеры использования весьма специфических возможностей QtAda

находятся в каталоге examples/qt_ada. Тут можно найти пример

взаимодействия многопоточных программ с нитью GUI, пример загрузки созданных в Qt Designer форм в Ada программу.

 

PPS. Для чтения документации всё же лучше пользоваться Qt Assistant-ом.

sma

[KOI8-R] Имею настраиваемый пакет Izo_Pak собственного производства для графического представления данных со спецификацией:

generic

Fname : String; -- имя файла

Channels : Integer; -- число каналов

Screen : Integer; -- ширина экрана

package Izo_pak is

Пакет отображает некую телеметрическую информацию на экране. Проблема в том, что в процессе работы программы эти параметры хотелось бы менять по ходу дела. Хотелось бы типа ‘ дереализовать’ старый пакет и создать новый с новыми параметрами, например так:

Izo : access Izo_Pak := new Izo_Pak (Fname => “aaa.pcm”, Channels => 3, Screen => 1024); -- такое, естественно, не нихрена работает.

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

С уважением =Михаил=

On 05/21/2010 02:30 PM, sma wrote:

 

[KOI8-R] Имею настраиваемый пакет Izo_Pak собственного производства для графического представления данных со спецификацией:

 

generic

 

Fname : String; -- имя файла

 

Channels : Integer; -- число каналов

 

Screen : Integer; -- ширина экрана

 

package Izo_pak is

 

Пакет отображает некую телеметрическую информацию на экране. Проблема в том, что в процессе работы программы эти параметры хотелось бы менять по ходу дела. Хотелось бы типа ‘ дереализовать’ старый пакет и создать новый с новыми параметрами, например так:

 

Izo : access Izo_Pak := new Izo_Pak (Fname => “aaa.pcm”, Channels => 3, Screen => 1024); -- такое, естественно, не нихрена работает.

 

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

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

 

Я немного не понимаю скрытого смысла использования здесь настраиваемого пакета... :-( Не проще ли использовать обычный пакет? Или создать соответствующий тип и объявить подпрограммы его обработки?

sma

Ø Я немного не понимаю скрытого смысла использования здесь настраиваемого пакета... :-( Не проще ли использовать обычный пакет? Или создать соответствующий тип и объявить подпрограммы его обработки?

Дело в том, что в обрабатываемом файле могут быть данные из нескольких каналов. Хотелось бы в параметрах настройки задать число каналов CHANNELS и реализовать настраиваемый пакет:

type Chan_Type is array (1 .. CHANNELS) of Integer_16;

package Dio is new Ada.Direct_IO (Chan_Type);

File : Dio.File_Type;

Chan : Chan_Type;

Dio.Open (File, Dio.In_File, “aaa.pcm”);

Dio.Read (File, Chan);

В статическом режиме это прекрасно работает. Т.е. включаю настраиваемый пакет в раздел определений некой процедуры. Запускаю процедуру, пока процедура выполняется – всё нормально. Однако, моя программа итеративная. Процедура должна вернуть управление и прекратить существование. :( Вместе с процедурой накрывается и настраиваемый пакет ):

Попытался поместить настраиваемый пакет в тело задачи и использовать задачу в качестве графического сервера. Однако, столкнулся с проблемой передачи данных по ссылке в задачу (в частности - дискриптора окна (Object : access Gtk_Widget_Record’Class))

В конце – концов вообще отказался от использования настраиваемого пакета (Абыдна!) и решил проблему средствами пакета Ada.Streams.Stream_IO.

Type Buf_Type is array (Natural range <>) of Integer_16;

Buffer : Buf_Type;

File : Ada.Streams.Stream_IO.File_Type;

File_Stream : Ada.Streams.Stream_IO.Stream_Access;

use Ada.Streams.Stream_IO;

Buffer := new Buf_Type (1 .. CHANNELS);

Open (File, In_File, “aaa.pcm”);

File_Stream := Stream (File);

Read_Buffer (File_Stream, Buffer.all);

Идею взял из раздела стандарных примеров (у меня на ПК - c:\GNAT\2009\share\examples\gnat\stream_io)

Вывод :( Чёта идея пакетов оказалась не так хороша как казалось на первый взгляд ):

=Михаил=

On Mon, 24 May 2010 11:39:20 +0400, you wrote:

 

Дело в том, что в обрабатываемом файле могут быть данные из нескольких каналов. Хотелось бы в параметрах настройки задать число каналов CHANNELS и реализовать настраиваемый пакет:

 

type Chan_Type is array (1 .. CHANNELS) of Integer_16;

 

package Dio is new Ada.Direct_IO (Chan_Type);

 

Плохая идея иметь разные форматы файлов. Но можно:

 

type Chan_Type is array (Positive range <>) of Integer_16;

...

subtype My_Channel_Now is Chan_Type (Size);

package Dio is new Ada.Direct_IO (My_Channel_Now);

В статическом режиме это прекрасно работает. Т.е. включаю настраиваемый пакет в раздел определений некой процедуры. Запускаю процедуру, пока процедура выполняется – всё нормально. Однако, моя программа итеративная. Процедура должна вернуть управление и прекратить существование. :( Вместе с процедурой накрывается и настраиваемый пакет ):

 

Но файлы-то остаются? Очень плохая идея.

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

(Object : access Gtk_Widget_Record’Class))

 

Не вижу проблемы. Gtk объекты всегда ссылочные, т.е. передавать надо Gtk_Widget (=access Gtk_Widget_Record’Class), предварительно делая на него Ref. На выходе задачи - Unref. И не забывать, что из задачи нельзя вызывать ничего из Gtk напрямую.

 

В конце – концов вообще отказался от использования настраиваемого пакета

 

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

 

(Абыдна!) и решил проблему средствами пакета Ada.Streams.Stream_IO.

 

Ada.Direct_IO (Integer_16);

 

ничем не хуже.

Вывод :( Чёта идея пакетов оказалась не так хороша как казалось на первый взгляд ):

 

Мораль: всегда используйте ОО. Вместо пакета - тип. Вместо настройки - ограничение (подтип) или производный тип.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

sma

Плохая идея иметь разные форматы файлов.

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

Не вижу проблемы. Gtk объекты всегда ссылочные…

С задачными типами я пока не совсем разобрался. Проблема как раз в том, что параметры задаче, вроде как, нельзя передавать по ссылке. К тому же, работать с Gtk из задачи большой геморрррой. Тупиковая ветвь, которую я быстро отбросил.

Мораль: всегда используйте ОО. Вместо пакета - тип. Вместо настройки - ограничение (подтип) или производный тип.

Несколько экстремиское заявление. На мой взгляд, эта задача как раз самая-что-ни-на-есть подходящая для generic- пакетов. И в статическом режиме она работает прекрасно. Если бы с пакетами можно было бы проделывать нечто такое:

Pak : access My_Pak := new My_Pak (Channels => 5);

То все мои проблемы динамической актуализации пакетов были бы решены.

=Михаил=

On Mon, 24 May 2010 16:35:01 +0400, you wrote:

 

Не вижу проблемы. Gtk объекты всегда ссылочные…

 

С задачными типами я пока не совсем разобрался. Проблема как

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

по ссылке.

 

Параметры = дискриминанты или аргументы вызова точки входа? И те и другие могут быть access типом. Проблема в том, что объект не должен умирать до его ссылки. Следовательно, варианты:

 

1. Статически ссылаться на объект в объемлющем задачу или ее тип контексте 2. Копировать объект (т.н. marshaling)

3. Сбор мусора, например из Gtk, или Simple Components, или "пальцами рук"

Мораль: всегда используйте ОО. Вместо пакета - тип. Вместо настройки - ограничение (подтип) или производный тип.

 

Несколько экстремиское заявление.

 

Угу. Использование Ады - чистый экстремизм. Есть С, есть его препроцессор, Бейсик, PHP, наконец...

 

На мой взгляд, эта задача как раз

самая-что-ни-на-есть подходящая для generic- пакетов.

 

Нет таких задач. Все, что люди придумывают в ответ, попадает в категорию: "мы не можем сделать это нормально, или Ада не может этого, вот мы и решили сделать generic-ами".

 

И в статическом режиме она работает прекрасно.

 

А в реальном режиме - нет.

 

Если бы с пакетами можно было бы

проделывать нечто такое:

 

Pak : access My_Pak := new My_Pak (Channels => 5);

 

То все мои проблемы динамической актуализации пакетов были бы решены.

 

Нет, они бы только начались. Реализация My_Pak - статический пакет, содержащий статические вещи типа типов, других пакетов и т.п., который именуется динамическим объектом. Это не может работать.

 

Прочтите ваш код и сравните с

 

X : Object_Type (Channels => 5);

 

Зачем изобретать заведомо не работающие конструкции, когда все уже есть? Pattern (не люблю это слово) - взять штуку и динамически ее ограничить. Это и есть то, зачем дискриминантные типы введены в Аду.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

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

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