Ada_Ru форум

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

Ada-2012 + Linux. Страница 3

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

Сообщения

14.05.2013 14:29, Leonid Dulman пишет:

 

 

Попробуй ADASTUDIO 2013.

VAD - простой visual ada developer

QT4ADA и QT5ADA позволяют использовать возможности QT plugin

то есть загружать DLL или SO

VTKADA поддерживаеи работу с 2D/3D объектами.

http:/users1.jabry.com/adastudio/index/html

Леонид

А где найти его?

Мне почему-то постоянно попадается ссылка на это (кстати, вашего же авторства): http://www.youtube.com/watch?v=CRHhwFHQYRQ

 

И ещё много всего на немецком. Я по-немецки как-то нихт шпрехен, ну совсем.

On Tue, 14 May 2013 21:00:52 +0400, you wrote:

 

14.05.2013 20:45, Dmitry A. Kazakov пишет:

 

Вообще, я Демьяна не люблю именно из-за deb-пакетов. RPM проще и удобнее на порядок (хотя тоже не подарок).

Для меня - наоборот. Особенно замечательное удобство и малое количество хорошо сгруппированных интуитивно понятных опций RPM.

 

Каких? Кроме

 

$ yum update

 

ничего знать не надо.

 

Другие преимущества Fedora

 

1. "coexistence" 32 и 64-бит библиотек. Debian все еще не дошел до этого, по-моему.

 

2. разумная схема имен пакетов. В Debian это просто безобразие какое-то.

3. функционирующий Gnome. Хотя если Вы заточены на Qt Вам это не важно. А я использую Gtk.

 

Особенно, если будете свои пакеты делать.

rpmbuild - просто майский цветок по сравнению с чудовищными скриптами Демьяна.

 

Делал ради интереса. Ничего "чудовищного". Вы, видимо, очень давно занимались пакетированием под Debian.

 

Постоянно. Я все свои GPL проекты пакую, и для того, и для другого. И содержу репозитории. Апдать Debian репозиторий - битва при пирамидах. До сих пор не нашел лучшего метода как все убить и залить заново.

 

У Федора один недостаток. Там GPS еще нету. А GPS - лучший IDE на сегодняшний день. Лучше даже чем MS Developing Studio.

 

Чем лучше Eclipse, к примеру?

 

Быстрее на порядок. Почти не вылетает. Гораздо удобнее для Ады. Eclipse использует VxWorks, для компиляции и сборки образа (VxWorks - монолит). Ничего хорошего.

 

Я к Eclipse нашёл поддержку Ada какую-то, но пока не ставил.

 

Да, есть у AdaCore такой "плохин".

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Tue, 14 May 2013 21:06:59 +0400, you wrote:

 

14.05.2013 20:32, Dmitry A. Kazakov пишет:

On Tue, 14 May 2013 18:06:47 +0400, you wrote:

 

13.05.2013 23:23, Dmitry A. Kazakov пишет:

On Mon, 13 May 2013 22:19:07 +0400, you wrote:

 

Т.е., с кроссплатформенностью относительно сборки и библиотек нет проблем?

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

 

Как, например, для разделяемых библиотеки. Под Linux проблем не будет. Под Windows - очень непросто, т.к. у GNAT с этим большие проблемы (Ada RTL не в DLL). А как, да, объектные библиотеки - в-лёт и никаких make.

А поподробнее: с DLL, что за проблемы?

У меня не срослась инициализация. Пустая DLL из функций должна работать.

Т.е., какие-то очередные проблемы с тем, что должно и не должно быть в DllMain?

Или нет?

 

Проблема в порядке того как это делается (elaboaration order). С C++, например, иногда неправильно. И подозреваю, что с Адой то-же.

 

Под VxWorks их просто нет, вообще.

С VxWorks я не работал ни разу. Хотел полюбопытствовать, но только скачал, а посмотреть руки не доходили. На практике пока мне не требовалось.

Вам повезло.

Почему?

Судя по всему, система не самая плохая...

 

Дело в удобстве. VxWorks - монолит с миллионом параметров и кусков включаемых через #define. Никто, кроме WindRiver не знает что они значат. Повернешь один, все или разваливается, или тормозит. Это - как минное поле. На которое каждый день надо выходить, и бегать трусцой.

 

В плане того, что это одна из основных структур, я вспомнил. Понятно, что есть коллекция, например. Но основе-то, как правило, лежит связанный список?

 

В Аде, обычно, достаточно простых массивов и контейнеров.

 

В остальном в нём присутствуют все необходимые современному

языку средства. Ну разве что сборка мусора отсутствует.

Т.к. она к таковым не разумеется принадлежит. Хотя, опять, для любителей где-то валялся сборщик Бёмера для GNAT-a. Ссылку не сохранил, по-гуглите, найдете.

А действительно нужен?

Мне не нужен. Но есть разные мнения. Я использую счетчики ссылок, если объекты живут в динамических scope-ах.

Ну надеюсь, в родных библиотеках есть уже готовые классы, в которых всё это реализовано?

 

Разумеется, и много, в разных видах. Я пользуюсь своей

 

http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc

 

GUI тоже на Ada? Какие библиотеки использовали?

Какая СУБД?

Всякие. Обычно клиент хочет что-то конкретное: Oracle, MySQL, SQLServer. Мы под него подстраиваемся. Отсюда - ODBC.

Кхм. А без ODBC?

 

Есть и такие, почти для всех клиентов. Но ODBC гораздо удобнее, при всех своих недостатках. Особенно если 32 бита клиент говорит 64 битной базой или наоборот.

 

Средствами чего организуется сопряжение с оборудованием?

Протоколы всякие, EtherCAT, CAN/CANOpen, XCP, AK, DLMS, DMX, ModBus. Их - тьма.

Ради любопытства... А что насчёт драйверов?

 

Только NDIS и нужен, и то не всегда.

 

Вот есть у вас какой-то свой

специфический адаптер. Вы бы стали писать драйвер на Ada? Конечно мне это не потребуется, но всё-же.

 

Нет. DDK заточен на определенный язык. Вставлять куски Ада RTL в ядро, наверное можно, но много возни. Овчинка выделки не стоит. Драйвер он - маленький. Проблема не в драйверах а в протоколах, которые раздуты то невероятных размеров. Их я на Аде и пишу.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

14.05.2013 23:23, Dmitry A. Kazakov пишет:

On Tue, 14 May 2013 21:00:52 +0400, you wrote:

 

14.05.2013 20:45, Dmitry A. Kazakov пишет:

 

Вообще, я Демьяна не люблю именно из-за deb-пакетов. RPM проще и удобнее на порядок (хотя тоже не подарок).

Для меня - наоборот. Особенно замечательное удобство и малое количество хорошо сгруппированных интуитивно понятных опций RPM.

Каких? Кроме

$ yum update

Вы же говорили про dpkg..?

В случае yum, никто не мешает использовать aptitude (по аналогии) - ещё проще и удобнее.

Кстати, имеет curses интерфейс, что, при выборе пакетов весьма полезно (в отличие от yum, в адрес которого я вспомнил много тёплых слов, когда недавно ставил CentOS).

 

ничего знать не надо.

Ага. Пока ничего не сломалось.

 

Другие преимущества Fedora

 

1. "coexistence" 32 и 64-бит библиотек. Debian все еще не дошел до этого, по-моему.

Давным давно есть multiarch. У меня стоят 32-х битные библиотеки, которые требует, вроде, какая-то игра, Wine или нечто подобное.

 

http://wiki.debian.org/Multiarch

 

2. разумная схема имен пакетов. В Debian это просто безобразие какое-то.

В каком смысле?

 

3. функционирующий Gnome. Хотя если Вы заточены на Qt Вам это не важно. А я использую Gtk.

Ну, а Debian он, что, не функционирующий?

 

Особенно, если будете свои пакеты делать.

rpmbuild - просто майский цветок по сравнению с чудовищными скриптами Демьяна.

 

Делал ради интереса. Ничего "чудовищного". Вы, видимо, очень давно занимались пакетированием под Debian.

Постоянно. Я все свои GPL проекты пакую, и для того, и для другого.

Хм... И не знаете про multiarch...

В таком случае, раз уж речь зашла, возможно посмотреть на пример "чудовищности" скрипта?

 

И содержу репозитории. Апдать Debian репозиторий - битва при пирамидах.

Насчёт репозиториев не знаю. Мне сейчас как раз надо будет сделать, хоть и не из

своих пакетов, а из "родных" Debian-овских.

Единственное, что мне пока не нравится, - это необходимость придумать, как выдрать ПО по категориям из пула. К примеру, games для меня слегка лишние, а вот

adm нужен... В этом, конечно, расположение в каталогах по алфавиту мне не подходит.

 

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

С учётом того, что официальные репозитории постоянно обновляются, предположу, что метод есть: вряд ли майнтайнеры всё убивают и заливают заново. К тому же, насколько я понимаю, есть apt-ftparchive, который пересоздаёт индексные файлы...

Так что я честно не понимаю: в чём проблема с обновлением репозитория?

У Федора один недостаток. Там GPS еще нету. А GPS - лучший IDE на сегодняшний день. Лучше даже чем MS Developing Studio.

 

Чем лучше Eclipse, к примеру?

Быстрее на порядок. Почти не вылетает. Гораздо удобнее для Ады. Eclipse использует VxWorks, для компиляции и сборки образа (VxWorks - монолит). Ничего хорошего.

Хм... Но для Eclipse есть много инструментов для моделирования. Хотелось бы попробовать. Говорят, что ускоряет процесс. В Eclipse есть mylyn с множеством коннекторов (хотя и не знаю нужен ли он). В Eclipse есть дизайнеры интерфейсов (не разбирался, но подозреваю, что WindowsBuilder только для Java).

Кстати, а gnat-gps написана на Ada?

 

Я к Eclipse нашёл поддержку Ada какую-то, но пока не ставил.

Да, есть у AdaCore такой "плохин".

Что есть "плохин"?

14.05.2013 23:46, Dmitry A. Kazakov пишет:

Как, например, для разделяемых библиотеки. Под Linux проблем не будет. Под Windows - очень непросто, т.к. у GNAT с этим большие проблемы (Ada RTL не в DLL). А как, да, объектные библиотеки - в-лёт и никаких make.

А поподробнее: с DLL, что за проблемы?

У меня не срослась инициализация. Пустая DLL из функций должна работать.

Т.е., какие-то очередные проблемы с тем, что должно и не должно быть в DllMain?

Или нет?

Проблема в порядке того как это делается (elaboaration order). С C++, например, иногда неправильно. И подозреваю, что с Адой то-же.

Понятно... А если инициализацию делать отдельной функцией, а не в DllMain, проблем нет?

 

В плане того, что это одна из основных структур, я вспомнил. Понятно, что есть коллекция, например. Но основе-то, как правило, лежит связанный список?

В Аде, обычно, достаточно простых массивов и контейнеров.

А что такое "контейнер" в Ada?

Что, если мне требуется удаление/вставка элемента?

 

В остальном в нём присутствуют все необходимые современному

языку средства. Ну разве что сборка мусора отсутствует.

Т.к. она к таковым не разумеется принадлежит. Хотя, опять, для любителей где-то валялся сборщик Бёмера для GNAT-a. Ссылку не сохранил, по-гуглите, найдете.

А действительно нужен?

Мне не нужен. Но есть разные мнения. Я использую счетчики ссылок, если объекты живут в динамических scope-ах.

Ну надеюсь, в родных библиотеках есть уже готовые классы, в которых всё это реализовано?

 

Разумеется, и много, в разных видах. Я пользуюсь своей

http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc

"W: Не удалось получить

copy:/var/lib/apt/lists/partial/dmitry-kazakov.de_distributions_dists_sid_main_binary-amd64_Packages:

Хеш сумма не совпадает

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

E: Не удалось перестроить кэш пакетов"

 

Что я делаю не так?

 

И ещё, в чём вы делали документацию к библиотеке?

 

Вот есть у вас какой-то свой

специфический адаптер. Вы бы стали писать драйвер на Ada? Конечно мне это не потребуется, но всё-же.

Нет. DDK заточен на определенный язык. Вставлять куски Ада RTL в ядро, наверное можно, но много возни. Овчинка выделки не стоит. Драйвер он - маленький. Проблема не в драйверах а в протоколах, которые раздуты то невероятных размеров. Их я на Аде и пишу.

Т.е., минимальный драйвер на C, а всё остальное в пространстве пользователя на Ada..?

On 05/15/2013 09:21 PM, "Артём Н." wrote:

 

Кстати, а gnat-gps написана на Ada?

 

Да

А еще на питоне! :-)

 

 

On Wed, May 15, 2013 at 10:27 PM, Vadim Godunko <vgodunko@...> wrote:

On Wed, 15 May 2013 21:21:09 +0400, you wrote:

 

14.05.2013 23:23, Dmitry A. Kazakov пишет:

On Tue, 14 May 2013 21:00:52 +0400, you wrote:

 

14.05.2013 20:45, Dmitry A. Kazakov пишет:

 

Вообще, я Демьяна не люблю именно из-за deb-пакетов. RPM проще и удобнее на порядок (хотя тоже не подарок).

Для меня - наоборот. Особенно замечательное удобство и малое количество хорошо сгруппированных интуитивно понятных опций RPM.

Каких? Кроме

$ yum update

Вы же говорили про dpkg..?

 

Хорошо:

 

$ rpm -qa

 

Ничем больше не пользуюсь. Как оно на dpkg? А если без гугли?

 

В случае yum, никто не мешает использовать aptitude (по аналогии) - ещё проще и

удобнее.

 

$ apt-get update; apt-get upgrade

 

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

Кстати, имеет curses интерфейс, что, при выборе пакетов весьма полезно (в отличие от yum, в адрес которого я вспомнил много тёплых слов, когда недавно ставил CentOS).

 

Меня религиозные войны не интересуют. По-факту, у меня на обслуживание моих Debian машин времени тратится больше. А так, я не большой поклонник Linux-a (и окошек тоже).

 

2. разумная схема имен пакетов. В Debian это просто безобразие какое-то.

В каком смысле?

 

Заморочки с тем как вставить номер версии и релиза в имя. Комбинаторная задача на угадывание. Вроде как единственный работающий вариант:

 

libxxx-N.M_L_i386

libxxx-N.M-dev_L_i386

libxxx-N.M-dbg_L_i386

 

3. функционирующий Gnome. Хотя если Вы заточены на Qt Вам это не важно. А я использую Gtk.

Ну, а Debian он, что, не функционирующий?

 

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

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

С учётом того, что официальные репозитории постоянно обновляются, предположу, что метод есть: вряд ли майнтайнеры всё убивают и заливают заново.

 

Они добавляют, а у меня на хостинге места мало.

 

Так что я честно не понимаю: в чём проблема с обновлением репозитория?

 

Заменить пакет на другой, но с той же версией.

Кстати, а gnat-gps написана на Ada?

 

А как же? И сам GNAT разумеется тоже не Аде написан.

 

По моему мнению нет языка лучше для любых задач. Даже когда я с дуру писал bash скрипты, в итоге это выходило дороже, чем если бы я с самого начала писал это на Аде.

 

Я к Eclipse нашёл поддержку Ada какую-то, но пока не ставил.

Да, есть у AdaCore такой "плохин".

Что есть "плохин"?

 

plug-in

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Wed, 15 May 2013 22:14:30 +0400, you wrote:

 

14.05.2013 23:46, Dmitry A. Kazakov пишет:

Как, например, для разделяемых библиотеки. Под Linux проблем не будет. Под Windows - очень непросто, т.к. у GNAT с этим большие проблемы (Ada RTL не в DLL). А как, да, объектные библиотеки - в-лёт и никаких make.

А поподробнее: с DLL, что за проблемы?

У меня не срослась инициализация. Пустая DLL из функций должна работать.

Т.е., какие-то очередные проблемы с тем, что должно и не должно быть в DllMain?

Или нет?

Проблема в порядке того как это делается (elaboaration order). С C++, например, иногда неправильно. И подозреваю, что с Адой то-же.

Понятно... А если инициализацию делать отдельной функцией, а не в DllMain, проблем нет?

 

Инициализацию генерирует компилятор. GNAT называет ее adainit и кладет в специальный файл, который он же и создает.

 

В плане того, что это одна из основных структур, я вспомнил. Понятно, что есть коллекция, например. Но основе-то, как правило, лежит связанный список?

В Аде, обычно, достаточно простых массивов и контейнеров.

А что такое "контейнер" в Ada?

 

Объект, содержащий другие объекты и остающийся при этом единым целым. Например, множество, bag, map и т.п.

 

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

 

Что, если мне требуется удаление/вставка элемента?

 

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

 

Разумеется, и много, в разных видах. Я пользуюсь своей

http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc

"W: Не удалось получить

copy:/var/lib/apt/lists/partial/dmitry-kazakov.de_distributions_dists_sid_main_binary-amd64_Packages:

Хеш сумма не совпадает

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

E: Не удалось перестроить кэш пакетов"

 

Что я делаю не так?

 

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

 

Вот за это я Debian и не люблю. Никогда не знаешь чего ожидать! Вечно - сюрпризы. Диагностика - ноль. Молча что-то делает, при этом лажает. А если ругается, то не по-делу.

 

Перезалил по-новому. Теперь как?

 

И ещё, в чём вы делали документацию к библиотеке?

 

FrontPage. Я в Doxygen не верю, если Вы про это. Кроме того, мне лично нужно писать "руками", чтобы еще раз переосмыслить, что я там натворил. Когда начинаешь описывать, смотришь совсем с другой стороны - боже мой, что за идиот! Где это? Где то? А почему не так? и т.п.

 

Вот есть у вас какой-то свой

специфический адаптер. Вы бы стали писать драйвер на Ada? Конечно мне это не потребуется, но всё-же.

Нет. DDK заточен на определенный язык. Вставлять куски Ада RTL в ядро, наверное можно, но много возни. Овчинка выделки не стоит. Драйвер он - маленький. Проблема не в драйверах а в протоколах, которые раздуты то невероятных размеров. Их я на Аде и пишу.

Т.е., минимальный драйвер на C, а всё остальное в пространстве пользователя на Ada..?

 

Да. Последний раз я писал драйвер лет 8 назад. То железо с которым мы имеем дело или через Ethernet подключается, редко через USB или COM, бывает, что через CAN. Обычно хватает стандартного драйвера или библиотеки

производителя (если CAN). Ну там, raw socket может случится. Только под Windows для этого драйвер и нужен. И то, потому, что эти уроды удалили поддержку raw socket, которая изначально была. Ну мы просто купили готовый NDIS, чтобы не париться. В Linux raw socket есть. А в VxWorks есть как отцепить стек и работать с голыми пакетами. Так что все на Аде, даже куски, зависящие от ОС.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

15.05.2013 23:15, Dmitry A. Kazakov пишет:

On Wed, 15 May 2013 21:21:09 +0400, you wrote:

 

14.05.2013 23:23, Dmitry A. Kazakov пишет:

On Tue, 14 May 2013 21:00:52 +0400, you wrote:

 

14.05.2013 20:45, Dmitry A. Kazakov пишет:

 

Вообще, я Демьяна не люблю именно из-за deb-пакетов. RPM проще и удобнее на порядок (хотя тоже не подарок).

Для меня - наоборот. Особенно замечательное удобство и малое количество хорошо сгруппированных интуитивно понятных опций RPM.

Каких? Кроме

$ yum update

Вы же говорили про dpkg..?

 

Хорошо:

 

$ rpm -qa

 

Ничем больше не пользуюсь. Как оно на dpkg?

А если без гугли?

$ man rpm

$ dpkg -l

 

В случае yum, никто не мешает использовать aptitude (по аналогии) - ещё проще и

удобнее.

 

$ apt-get update; apt-get upgrade

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

Ну не принципиально, что будет использовано: apt-* или aptitude. А конфликтующие

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

 

Кстати, имеет curses интерфейс, что, при выборе пакетов весьма полезно (в отличие от yum, в адрес которого я вспомнил много тёплых слов, когда недавно ставил CentOS).

Меня религиозные войны не интересуют.

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

выбрать зависимости, а для yum в CentOS придётся установить графический интерфейс.

 

По-факту, у меня на обслуживание моих

Debian машин времени тратится больше.

Вы не думали, что это из-за вашей привычки к Fedora?

 

А так, я не большой поклонник Linux-a

(и окошек тоже).

Что ж вы предпочитаете?

 

Кстати, Debian - это не Linux.

 

2. разумная схема имен пакетов. В Debian это просто безобразие какое-то.

В каком смысле?

Заморочки с тем как вставить номер версии и релиза в имя. Комбинаторная задача на угадывание. Вроде как единственный работающий вариант:

libxxx-N.M_L_i386

libxxx-N.M-dev_L_i386

libxxx-N.M-dbg_L_i386

Да, в этом плане, не очень удобно.

 

3. функционирующий Gnome. Хотя если Вы заточены на Qt Вам это не важно. А я использую Gtk.

Ну, а Debian он, что, не функционирующий?

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

Я не использую Gnome (по моему мнению, он достаточно отвратителен, по автору форка Mate, предполагаю - тоже).

 

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

С учётом того, что официальные репозитории постоянно обновляются, предположу, что метод есть: вряд ли майнтайнеры всё убивают и заливают заново.

Они добавляют, а у меня на хостинге места мало.

Сорри, а причём тут *репозиторий*?

 

Так что я честно не понимаю: в чём проблема с обновлением репозитория?

Заменить пакет на другой, но с той же версией.

Зачем?

 

По моему мнению нет языка лучше для любых задач.

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки. Например, решение каких-нибудь диф. уравнений лучше делать в чём-то Matlab-подобном или всё-таки на Ada?

 

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

 

Даже когда я с дуру писал

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

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

 

Я к Eclipse нашёл поддержку Ada какую-то, но пока не ставил.

Да, есть у AdaCore такой "плохин".

Что есть "плохин"?

plug-in

o.O А почему "плохин"?

16.05.2013 01:49, Dmitry A. Kazakov пишет:

On Wed, 15 May 2013 22:14:30 +0400, you wrote:

 

14.05.2013 23:46, Dmitry A. Kazakov пишет:

Как, например, для разделяемых библиотеки. Под Linux проблем не будет. Под Windows - очень непросто, т.к. у GNAT с этим большие проблемы (Ada RTL не в DLL). А как, да, объектные библиотеки - в-лёт и никаких make.

А поподробнее: с DLL, что за проблемы?

У меня не срослась инициализация. Пустая DLL из функций должна работать.

Т.е., какие-то очередные проблемы с тем, что должно и не должно быть в DllMain?

Или нет?

Проблема в порядке того как это делается (elaboaration order). С C++, например, иногда неправильно. И подозреваю, что с Адой то-же.

Понятно... А если инициализацию делать отдельной функцией, а не в DllMain, проблем нет?

 

Инициализацию генерирует компилятор. GNAT называет ее adainit и кладет в специальный файл, который он же и создает.

Кхм, т.е. бывает, что вылетают ошибки, даже, если пользователь ничего не пишет в

DllMain?

 

Что, если мне требуется удаление/вставка элемента?

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

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

массива, его придётся перераспределять, тратить время...

 

Разумеется, и много, в разных видах. Я пользуюсь своей

http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc

"W: Не удалось получить

copy:/var/lib/apt/lists/partial/dmitry-kazakov.de_distributions_dists_sid_main_binary-amd64_Packages:

Хеш сумма не совпадает

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

E: Не удалось перестроить кэш пакетов"

 

Что я делаю не так?

 

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

 

Вот за это я Debian и не люблю. Никогда не знаешь чего ожидать! Вечно - сюрпризы. Диагностика - ноль.

Это не про Debian.

 

Молча что-то делает

Unix-way?

 

при этом лажает.

Честно говоря, как правило, человек.

 

А если ругается, то не по-делу.

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

 

Перезалил по-новому. Теперь как?

Гут. :-)

 

И ещё, в чём вы делали документацию к библиотеке?

FrontPage. Я в Doxygen не верю, если Вы про это.

Не, о Doxygen я даже не подумал.

Честно, я думал о чём-то вроде Tex. :-]

А графики тоже там же?

 

Кроме того, мне лично

нужно писать "руками", чтобы еще раз переосмыслить, что я там натворил. Когда начинаешь описывать, смотришь совсем с другой стороны - боже мой, что за идиот! Где это? Где то? А почему не так? и т.п.

Но говорят, что:

1. Слишком сложно содержать документацию актуальной коду.

2. Если каждый раз переосмысливать, времени не хватит ни на что.

3. Неплохо бы создавать код из документации (а не документацию из кода)...

Вот есть у вас какой-то свой

специфический адаптер. Вы бы стали писать драйвер на Ada? Конечно мне это не потребуется, но всё-же.

Нет. DDK заточен на определенный язык. Вставлять куски Ада RTL в ядро, наверное можно, но много возни. Овчинка выделки не стоит. Драйвер он - маленький. Проблема не в драйверах а в протоколах, которые раздуты то невероятных размеров. Их я на Аде и пишу.

Т.е., минимальный драйвер на C, а всё остальное в пространстве пользователя на Ada..?

Да. Последний раз я писал драйвер лет 8 назад. То железо с которым мы имеем дело или через Ethernet подключается, редко через USB или COM, бывает, что через CAN. Обычно хватает стандартного драйвера или библиотеки

производителя (если CAN). Ну там, raw socket может случится. Только под Windows для этого драйвер и нужен. И то, потому, что эти уроды удалили поддержку raw socket, которая изначально была.

Хе-хе, они боролись с червями. :-)

 

Ну мы просто купили готовый

NDIS, чтобы не париться. В Linux raw socket есть. А в VxWorks есть как отцепить стек и работать с голыми пакетами. Так что все на Аде, даже куски, зависящие от ОС.

Через библиотеку?

On Thu, 16 May 2013 21:55:46 +0400, you wrote:

 

15.05.2013 23:15, Dmitry A. Kazakov пишет:

 

По-факту, у меня на обслуживание моих

Debian машин времени тратится больше.

Вы не думали, что это из-за вашей привычки к Fedora?

 

Не думаю. Начинал-то я со Slackware. А к Fedora привычки быть не может. Они, мерзавцы, с каждой версией все равно все меняют. Все на новых местах, все по-другому конфигурируется. Что работало раньше, не работает.

А так, я не большой поклонник Linux-a (и окошек тоже).

Что ж вы предпочитаете?

 

Под VMS было приятно работать. Жаль, что DEC коньки отбросил. Все у них было лучшее на свете, и софт, и железо. Это их и сгубило. Негативный отбор.

Кстати, Debian - это не Linux.

 

А что?

3. функционирующий Gnome. Хотя если Вы заточены на Qt Вам это не важно. А я использую Gtk.

Ну, а Debian он, что, не функционирующий?

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

Я не использую Gnome (по моему мнению, он достаточно отвратителен, по автору форка Mate, предполагаю - тоже).

 

Все же лучше чем KDE. В свое время я OpenLook любил (это под первым Solaris-ом).

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

С учётом того, что официальные репозитории постоянно обновляются, предположу, что метод есть: вряд ли майнтайнеры всё убивают и заливают заново.

Они добавляют, а у меня на хостинге места мало.

Сорри, а причём тут *репозиторий*?

 

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

 

Так что я честно не понимаю: в чём проблема с обновлением репозитория?

Заменить пакет на другой, но с той же версией.

Зачем?

 

Из-за зависимостей. Если я делаю новую версию пакета A, а от него зависит B, то я не меняю версию B. Я знаю, что это не хорошо, но иначе это слишком много работы. По-этому я пакую зависимые пакеты заново и перезаливаю их.

По моему мнению нет языка лучше для любых задач.

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

 

Да, есть такая ложная теория...

 

Например, решение

каких-нибудь диф. уравнений лучше делать в чём-то Matlab-подобном или всё-таки на Ada?

 

Сомнительно. Я не специалист по теории управления, но у нас в конторе они есть. Тот софт, который мы делаем мог бы поддерживать код генерируемый MATLAB Workshop. Идея сделать plug-in к MATLAB-у, ASCET-у, Modelica и т.п. давно у нас болтается. Но ребята делающие регуляторы говорят, что им проще писать регулятор на нормальном языке, чем в MATLAB-е. MATLAB хорош для инженеров, которые совсем не могут, и не хотят писать.

 

Я к Eclipse нашёл поддержку Ada какую-то, но пока не ставил.

Да, есть у AdaCore такой "плохин".

Что есть "плохин"?

plug-in

o.O А почему "плохин"?

 

plug-in - плохин, созвучно. Никакого тайного смыла.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Под VMS было приятно работать. Жаль, что DEC коньки отбросил. Все у них было лучшее на свете, и софт, и железо. Это их и сгубило. Негативный отбор. >

И Modula-3! Нет, реально, исходники на Модуле-3 приятно читать, те самые,

DEC'овские. Ну и вообще их компилятор, набор тулзов и либ, как то удивительно продуман, все там в тему.

On Thu, 16 May 2013 22:12:01 +0400, you wrote:

 

16.05.2013 01:49, Dmitry A. Kazakov пишет:

On Wed, 15 May 2013 22:14:30 +0400, you wrote:

 

14.05.2013 23:46, Dmitry A. Kazakov пишет:

Как, например, для разделяемых библиотеки. Под Linux проблем не будет. Под Windows - очень непросто, т.к. у GNAT с этим большие проблемы (Ada RTL не в DLL). А как, да, объектные библиотеки - в-лёт и никаких make.

А поподробнее: с DLL, что за проблемы?

У меня не срослась инициализация. Пустая DLL из функций должна работать.

Т.е., какие-то очередные проблемы с тем, что должно и не должно быть в DllMain?

Или нет?

Проблема в порядке того как это делается (elaboaration order). С C++, например, иногда неправильно. И подозреваю, что с Адой то-же.

Понятно... А если инициализацию делать отдельной функцией, а не в DllMain, проблем нет?

 

Инициализацию генерирует компилятор. GNAT называет ее adainit и кладет в специальный файл, который он же и создает.

Кхм, т.е. бывает, что вылетают ошибки, даже, если пользователь ничего не пишет в

DllMain?

 

Я не знаю точно как это GNAT это делает. Описание мутное. Знал-бы то починил. Так как не горело, копаться не стал.

 

Что, если мне требуется удаление/вставка элемента?

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

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

массива, его придётся перераспределять, тратить время...

 

Так ведь сценарий использования контейнера известен заранее и под него выбирается реализация. Часто элементы добавляются по одному а удаляются очень редко или все вместе. Реализация контейнера может использовать список массивов или действительно список, но Вы этого не видите. Вы используете сам контейнер. Список, именно как список, используется редко. Я вот добавил списки в свою библиотеку, и почти никогда их не использую. Кроме того, списки это очень неудобно в использовании. Gtk их постоянно применяет, т.к. он на С написан, и это жуткий геморрой.

 

И ещё, в чём вы делали документацию к библиотеке?

FrontPage. Я в Doxygen не верю, если Вы про это.

Не, о Doxygen я даже не подумал.

Честно, я думал о чём-то вроде Tex. :-]

 

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

 

А графики тоже там же?

 

Графики: Word 2003 + MicrografX

 

Кроме того, мне лично

нужно писать "руками", чтобы еще раз переосмыслить, что я там натворил. Когда начинаешь описывать, смотришь совсем с другой стороны - боже мой, что за идиот! Где это? Где то? А почему не так? и т.п.

Но говорят, что:

1. Слишком сложно содержать документацию актуальной коду.

 

Врут.

 

2. Если каждый раз переосмысливать, времени не хватит ни на что.

 

То, что не осмыслено и делать-то не надо.

 

3. Неплохо бы создавать код из документации (а не документацию из кода)...

 

В принципе, код на Аде сам по-себе документация. Это было одной из идей, создатели языка руководствовались. Отсюда некоторая многословность и избыточность.

 

Но, пользовательская документация и документация разработчика это - огромная разница. У них различные цели и задачи. Пользовательскую документацию сгенерировать нельзя.

 

Ну мы просто купили готовый

NDIS, чтобы не париться. В Linux raw socket есть. А в VxWorks есть как отцепить стек и работать с голыми пакетами. Так что все на Аде, даже куски, зависящие от ОС.

Через библиотеку?

 

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

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

16.05.2013 22:33, Dmitry A. Kazakov пишет:

On Thu, 16 May 2013 21:55:46 +0400, you wrote:

 

15.05.2013 23:15, Dmitry A. Kazakov пишет:

 

По-факту, у меня на обслуживание моих

Debian машин времени тратится больше.

Вы не думали, что это из-за вашей привычки к Fedora?

Не думаю. Начинал-то я со Slackware. А к Fedora привычки быть не может. Они, мерзавцы, с каждой версией все равно все меняют. Все на новых местах, все по-другому конфигурируется. Что работало раньше, не работает.

Это нормально. Fedora - тестовая площадка (капитан Очевидность тут где-то рядом проходил).

 

А так, я не большой поклонник Linux-a (и окошек тоже).

Что ж вы предпочитаете?

Под VMS было приятно работать. Жаль, что DEC коньки отбросил. Все у них было лучшее на свете, и софт, и железо.

Насчёт железа - не знаю. Насчёт софта... Я наполовину поставил OpenVMS, но руки не дошли с ней разобраться.

Установка далеко не из самых лёгких. Не очень привычная система именования файлов.

Насчёт того, что "самая лучшая и безопасная" - это не так. Просто мало копали (но кое-что нашли).

 

Чем реально она хороша?

 

Это их и сгубило. Негативный отбор.

Как понять?

 

Кстати, Debian - это не Linux.

А что?

Универсальная ОС.

https://www.linux.org.ru/news/debian/2585919

 

 

3. функционирующий Gnome. Хотя если Вы заточены на Qt Вам это не важно. А я использую Gtk.

Ну, а Debian он, что, не функционирующий?

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

Я не использую Gnome (по моему мнению, он достаточно отвратителен, по автору форка Mate, предполагаю - тоже).

Все же лучше чем KDE.

Мне KDE больше нравится: под ним хотя бы что-то возможно делать. Но, вообще, помимо них есть много всяких ВМ и даже DE, типа LXDE, например...

В свое время я OpenLook любил (это под первым

Solaris-ом).

$ apt-cache search openlook

olvwm - OpenLook virtual window manager

 

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

С учётом того, что официальные репозитории постоянно обновляются, предположу, что метод есть: вряд ли майнтайнеры всё убивают и заливают заново.

Они добавляют, а у меня на хостинге места мало.

Сорри, а причём тут *репозиторий*?

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

 

Так что я честно не понимаю: в чём проблема с обновлением репозитория?

Заменить пакет на другой, но с той же версией.

Зачем?

Из-за зависимостей. Если я делаю новую версию пакета A, а от него зависит B, то я не меняю версию B. Я знаю, что это не хорошо, но иначе это слишком много работы. По-этому я пакую зависимые пакеты заново и перезаливаю их.

...

 

По моему мнению нет языка лучше для любых задач.

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

 

Да, есть такая ложная теория...

Почему ложная?

 

 

Например, решение

каких-нибудь диф. уравнений лучше делать в чём-то Matlab-подобном или всё-таки на Ada?

 

Сомнительно. Я не специалист по теории управления, но у нас в конторе они есть. Тот софт, который мы делаем мог бы поддерживать код генерируемый MATLAB Workshop. Идея сделать plug-in к MATLAB-у, ASCET-у, Modelica и т.п. давно у нас болтается. Но ребята делающие регуляторы говорят, что им проще писать регулятор на нормальном языке, чем в MATLAB-е. MATLAB хорош для инженеров, которые совсем не могут, и не хотят писать.

 

Я к Eclipse нашёл поддержку Ada какую-то, но пока не ставил.

Да, есть у AdaCore такой "плохин".

Что есть "плохин"?

plug-in

o.O А почему "плохин"?

 

plug-in - плохин, созвучно. Никакого тайного смыла.

Ну, слава богу. :-)

On Thu, 16 May 2013 22:59:15 +0400, you wrote:

 

Под VMS было приятно работать. Жаль, что DEC коньки отбросил. Все у них было лучшее на свете, и софт, и железо. Это их и сгубило. Негативный отбор.

И Modula-3! Нет, реально, исходники на Модуле-3 приятно читать, те самые, DEC'овские.

 

Я читал их исходники ядра RSX-11 на MACRO-11 ассемблере как роман. Вот люди писали!

 

Ну и вообще их компилятор, набор тулзов и либ, как то

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

 

DEC Ada, DEC C - конфетки были! LSE - лучший редактор-IDE. Мир праху!

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Ну и вообще их компилятор, набор тулзов и либ, как то

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

>

DEC Ada, DEC C - конфетки были! LSE - лучший редактор-IDE. Мир праху! >

Ну, Модула-3, те самые исходники, до сих пор жива в общем то :-)

А чем LSE был замечателен?

On Thu, 16 May 2013 23:01:54 +0400, you wrote:

 

16.05.2013 22:33, Dmitry A. Kazakov пишет:

Это их и сгубило. Негативный отбор.

 

Как понять?

 

Буквально. Бейсик - самый плохой язык, Интел - самая плохая архитектура. Окошки - самая плохая ОС. Они же самые популярные.

 

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

 

Да, есть такая ложная теория...

Почему ложная?

 

Тезис 1. Специализированные языки не применимы в изоляции от областей где они не работают.

 

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

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Thu, 16 May 2013 23:25:21 +0400, you wrote:

 

А чем LSE был замечателен?

 

Полностью программируемый (я например написал для него селекцию и копирование колонок). Контекстный help. Поддерживал все языки

программирования. Расширял вызовы стандартных функций и системных вызовов. Поддерживал интегрированный символический отладчик. Замечу что исполнение до точки останова или до изменения переменной или локации шло со скоростью работы программы без отладчика, т.к. было реализовано путем защиты памяти. Имел журнал. Поддерживал 4 пользовательских сеанса в 1Мб оперативной памяти.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov пишет:

 

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

http://www.texmacs.org/tmweb/home/screenshots.en.html

:-)

Я, правда, очень давно пользовался. Но просто и удобно.

 

1. Слишком сложно содержать документацию актуальной коду.

Врут.

В плане?

 

3. Неплохо бы создавать код из документации (а не документацию из кода)...

В принципе, код на Аде сам по-себе документация. Это было одной из идей, создатели языка руководствовались. Отсюда некоторая многословность и избыточность.

Но, пользовательская документация и документация разработчика это - огромная разница. У них различные цели и задачи. Пользовательскую документацию сгенерировать нельзя.

Говорят, что говорят вот про это:

http://www.literateprogramming.com/

1. Имеет ли смысл?

2. Имеет ли смысл, применительно к Ada?

 

<big><offtopic>

On Thu, 16 May 2013 23:01:54 +0400, you wrote:

 

16.05.2013 22:33, Dmitry A. Kazakov пишет:

Это их и сгубило. Негативный отбор.

 

Как понять?

 

Буквально. Бейсик - самый плохой язык

Здесь я с вами не соглашусь.

Насчёт популярности:

 

http://www.silicontaiga.ru/home.asp?artId=10750

 

http://orencode.info/forum/showthread.php?mode=hybrid&t=3647

 

http://habrahabr.ru/post/137833/

 

BASIC там нет вообще. VisualBasic тянется не за счёт мифического "негативного отбора", а исключительно за счёт платформы, которая на него завязана.

Интел - самая плохая архитектура.

o.O Intel? В каком плане?

 

Окошки - самая плохая ОС. Они же самые популярные.

https://www.youtube.com/watch?v=e8M6S8EKbnU

Смотрите первый комментарий там.

Ранняя реклама, включая MS-DOS, настолько же истерична и крайне агрессивна.

Рекламу Linux, как правило, не смотрят:

https://www.youtube.com/watch?v=0USp7nSzTPY

 

При том, несмотря на кучу недостатков, у Unix и подобных грамотно разработанная архитектура. Там, где думают, приходят к выводу, что windows использовать невыгодно (взять хотя бы тот же Microsoft, который для пользователей проводит "Get The Facts", при этом, сам использует Linux).

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

возможности выбрать, работает то, что навязывают.

Потому Windows и шире распространена.

 

У VMS тоже, полагаю, куча недостатков была.

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

кодами, один интерпретатор и графическая среда, одно ядро и отсутствие драйверов

к множеству оборудования.

И, при всём этом, дикая цена за лицензию.

 

Так что, насчёт некоего "отрицательного отбора", - сомневаюсь.

 

</offtopic></big>

 

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

 

Да, есть такая ложная теория...

Почему ложная?

Тезис 1. Специализированные языки не применимы в изоляции от областей где они не работают.

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

 

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

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

Нет?

Новое сообщение:
< Страницы: 1 2 3 4 5

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