[14:25:51] <ada_ru> (Максим)  отвечает (Максим) на <А кто-то уже пробова…>
Фабьян всё уже сделал! https://github.com/marketplace/actions/ada-actions-toolchain
[14:55:56] <ada_ru> (Максим) Если кому понравилась радиоуправляемая машинка на Аде, можно идти разгонять: https://old.reddit.com/r/programming/comments/fgyet0/making_an_rc_car_with_ada_and_spark/
[15:34:47] <ada_ru> (sergey_dukov)  отвечает (Denis) на <Помогите разобраться…>
Это действительно баг и 256М — магическое число этого бага.
[15:38:08] <ada_ru> (sergey_dukov) <прислал документ>
[15:44:04] <ada_ru> (sergey_dukov) Со строкой всё нормально, глюк в атрибутной функции "Output"
[15:51:12] <ada_ru> (Максим) Может они считают где-то размер в битах...
[15:54:36] <ada_ru> (I_vlxy_I)  отвечает (sergey_dukov) на <Со строкой всё норма…>
А она компилятором реализуется или это часть стандартной либы?
[15:57:38] <ada_ru> (sergey_dukov) Часть реализации пакета "Ada.Strings.Unbounded".
[15:59:13] <ada_ru> (I_vlxy_I) Хорошо
[15:59:31] <ada_ru> (I_vlxy_I) Значит можно легко понять что там не так
[15:59:36] <ada_ru> (I_vlxy_I) И пофиксить
[16:02:04] <ada_ru> (Denis) Со String тоже не работает
[16:03:28] <ada_ru> (nitrocerber) а 'Output разве не автоматически генерируются для каждого задаваемого типа?
[16:03:51] <ada_ru> (sergey_dukov) <прислал документ>
[16:10:27] <ada_ru> (sergey_dukov) Вообще то, согласно RM2012, Output формируется из атрибутной процедуры S'Write. Значит это глюк любого типа массива.
[16:19:57] <ada_ru> (sergey_dukov) Отсюда следует, что для организации дампов, лучше пользоваться S'Write. Цена — один цикл. Хотя восстановление не будет столь простым.
[16:35:25] <ada_ru> (sergey_dukov) И так, S'Write для Unbounded_String определяется в реализации "Ada.Strings.Unbounded".  Тогда может быть S'Output определяется в реализации Ada.Streams, но там вроде все определения абстрактные. Тогда остаётся что это баг действительно компилятора.
[16:43:15] <ada_ru> (I_vlxy_I) Хм. А где он? Если это баг компилятора, то он может стрелять не только в стандартной либе же?
[16:46:38] <ada_ru> (sergey_dukov) Так я об этом и говорю. По крайней мере он стреляет в организации дампа любого типа массива.
[16:47:41] <ada_ru> (I_vlxy_I) Надо бы глянуть а Асм и в gdb
[16:51:07] <ada_ru> (sergey_dukov) Я смотрел в gdb, но внутрь  S'Output не заходил. Сейчас попробую.
[16:55:32] <ada_ru> (I_vlxy_I) Ну, если ошибка в кодогенерации, то, по идее, компилятор должен был какой-то кривой пользовательский код сгенерить. А стандартная либа должна быть ок. В теории. Могут быть нюансы.
[17:08:20] <ada_ru> (sergey_dukov) Я определил, где глюк. Это системная библиотека.
package body System.Strings.Stream_Ops is
...
  │667            --------------------------
  │668            -- String_Output_Blk_IO --
  │669            --------------------------
  │670
  │671            procedure String_Output_Blk_IO
  │672              (Strm : access Ada.Streams.Root_Stream_Type'Class;
  │673               Item : String)
  │674            is
  │675            begin
 >│676               String_Ops.Output (Strm, Item, Block_IO);
  │677            end String_Output_Blk_IO;
  │678
[17:09:22] <ada_ru> (sergey_dukov) Файл s-ststop.adb
[17:10:48] <ada_ru> (I_vlxy_I) Опять это IO.. С IO у стандартной либы Ады все плохо. :-(
[17:11:04] <ada_ru> (sergey_dukov) А дальше разбираться мне как то в лом.
[17:15:58] <ada_ru> (sergey_dukov) Значит дело не в компиляторе, а в реализации обработки конкретного типа "string". И может быть для других массмвов этого бага может не быть.
[17:22:55] <ada_ru> (Максим) https://blog.adacore.com/android-application-with-ada-and-webassembly
[17:23:44] <ada_ru> (Максим) Мой блогпост, как с помощью Джавы затолкать Аду в андроид смартфон 😄
[17:35:36] <ada_ru> (I_vlxy_I) Кстати, львиная доля вот этого работает через вебасм: https://simulationcorner.net
[17:39:51] <ada_ru> (sergey_dukov)  отвечает (Максим) на <Мой блогпост, как с …>
Максим, может вы посмотрите приведённого выше исследования бага и как-то свяжетесь с AdaCore?
[17:40:27] <ada_ru> (nitrocerber) ну тикет уже открыт Денисом
[17:40:43] <ada_ru> (nitrocerber) а дальше как в сексе по телефону. ждите оргазма
[17:41:11] <ada_ru> (sergey_dukov) Ок
[17:41:40] <ada_ru> (I_vlxy_I)  отвечает (nitrocerber) на <а дальше как в сексе…>
Через полгода-год? :-)
[17:42:14] <ada_ru> (nitrocerber) Ну публичные билеты это из серии "ваш звонок очень важен для вас". Хотите быстрых фиксов - покупайте подписку)
[17:42:27] <ada_ru> (nitrocerber) Хотя их тоже чинят
[17:43:02] <ada_ru> (nitrocerber) просто время починки, естественно, не гарантируется.
[17:43:33] <ada_ru> (nitrocerber) Вот если когда-нибудь перетащат код компилятора на гитхаааааб.. сможете сами фиксить😂
[17:48:18] <ada_ru> (I_vlxy_I)  отвечает (nitrocerber) на <Вот если когда-нибуд…>
Тогда просто pr будут по году висеть :-)
[17:48:28] <ada_ru> (I_vlxy_I) Плавали, знаем :-)
[17:48:54] <ada_ru> (I_vlxy_I) Так то можно патчик сразу к репорту прикладывать :-)
[17:49:10] <ada_ru> (nitrocerber) ну если тесты проходят и передача прав подписана, то чо бы и не мерджануть
[17:49:33] <ada_ru> (nitrocerber) я чота из клиентских предложек мёрджил в аюнит тот же
[17:50:06] <ada_ru> (nitrocerber)  отвечает (I_vlxy_I) на <Так то можно патчик …>
тут геморройнее с подписыванием отказа от авторских прав. В гитхабе это прилеплено автоматыцки
[17:52:36] <ada_ru> (I_vlxy_I) Тем временем релизнулся gcc 9.3
[17:52:38] <ada_ru> (I_vlxy_I) https://gcc.gnu.org/gcc-9/changes.html
[17:53:01] <ada_ru> (I_vlxy_I) Смотрите какая няшная диагностика ошибок теперь к плюсов! Очень удобно читать.
[17:54:06] <ada_ru> (I_vlxy_I) Или gnat это тоже затронуло?
[17:54:32] <ada_ru> (I_vlxy_I) А, нет. Там улучшений нет.
[17:55:40] <ada_ru> (nitrocerber) ну вот ща его день в день всосут ога
[17:57:06] <ada_ru> (I_vlxy_I)  отвечает (nitrocerber) на <ну вот ща его день в…>
Ы? Дык gnat то тоже зарелизился же. Он же часть gcc
[17:57:16] <ada_ru> (I_vlxy_I) Правда новостей про Аду там нет :-(
[17:57:48] <ada_ru> (nitrocerber) fsfный?
[17:57:49] <ada_ru> (I_vlxy_I) Про фортран, go и D - есть, а про Аду нет
[17:57:57] <ada_ru> (I_vlxy_I)  отвечает (nitrocerber) на <fsfный?>
Ну да.
[17:58:03] <ada_ru> (nitrocerber) а так это парашка беспонтовая
[17:58:12] <ada_ru> (nitrocerber) отстающая от поезда в умственном развитии
[17:58:39] <ada_ru> (nitrocerber) то ли дело наш. срочно несите деняк
[18:01:39] <ada_ru> (I_vlxy_I)  отвечает (nitrocerber) на <а так это парашка бе…>
Дык gcc он в принципе fsfный :-)
[18:05:51] <ada_ru> (sergey_dukov) Интересно, что при реализации gnat-llvm AdaCore взяла исходники компилятора не с лицензией GPL, а FSF с репозитория GNU-GCC. Может теперь релизы исходников AdaCore не будет гонять туда-сюда (GPL ==> FSF и FSF <== GPL)?
[18:09:10] <ada_ru> (I_vlxy_I) Дык gnu-gcc это ж GPLv3 для компилятора
[18:09:31] <ada_ru> (I_vlxy_I) А раетайм-стандартную либу там и не понтировали
[18:21:45] <ada_ru> (Максим) ну они не могу сразу гадить в открытый репозиторий
[18:27:03] <ada_ru> (Максим)  отвечает (sergey_dukov) на <Я определил, где глю…>
--  Determine the size in BITS of the block necessary to contain
              --  the whole string.

              Block_Size : constant Natural := Item'Length * ET_Size;
[18:27:50] <ada_ru> (Максим) Они умножают длинну строки на размер байта и вылазят за границы Natural
[18:28:54] <ada_ru> (I_vlxy_I) А почему оно не падает от этого?
[18:29:08] <ada_ru> (I_vlxy_I) Где рантайм проверки?
[18:29:15] <ada_ru> (I_vlxy_I) Где ошибки компиляции?!
[18:33:50] <ada_ru> (I_vlxy_I) А, это модуляторный тип?
[18:34:06] <ada_ru> (I_vlxy_I) :-(
[18:34:56] <ada_ru> (I_vlxy_I) Он какой-то обрезанный выходит тогда. Его диапазон - половина диапазона Integer’a.
[18:35:48] <ada_ru> (I_vlxy_I) Но в любом случае использование натурала тут - натуральная ошибка. Нужно юзать аналог size_t из с++
[18:36:36] <ada_ru> (Максим)  отвечает (I_vlxy_I) на <А, это модуляторный …>
нет, просто рантайм собирается без проверок 😛 он же всегда правильный!
[18:37:04] <ada_ru> (I_vlxy_I)  отвечает (Максим) на <нет, просто рантайм …>
O_O
[18:37:30] <ada_ru> (I_vlxy_I) Ну, ок. Это хорошо. Значит тут все также как и в знакомом мне мире плюсов
[18:37:47] <ada_ru> (I_vlxy_I) Включённые проверки - это дебаг. А на проще все выключают.
[18:50:23] <ada_ru> (sergey_dukov) Я давно каждый год занимаюсь собственной сборкой MINGW64 (при каждом выпуске GNAT GPL/Community 20xx). Так AdaCore предлагала немного пачнутый стандартный gcc и каталог "ada" в нём заменяла на свою новую версию. Причём инициализационные коды в нём значительно отличались (не только строками версий). Но коды в gcc они ранее сами же и поставляли. Раньше AdaCore пользовалась версией gcc исключительно 2.95. Начиная с версии GNAT 2018 она изменила политику — 2018 —> 7.3.1, 2019 —> 8.3.1. Если так продолжать, то скоро версия в gnat обгонит gcc (сейчас версия gcc в репозитории 10,0). Может теперь AdaCore будет просто помещать коды компилятора в репозиторий GNU при выпуске новых версий системы GNAT XXXX 20xx?
[18:52:01] <ada_ru> (I_vlxy_I) А она не помещает? Она ж регулярно отдаёт обратно изменения.
[18:53:14] <ada_ru> (Максим) В адакоре бакенд всегда позади, а фронтэнд впереди репозитория FSF
[18:54:24] <ada_ru> (Максим)  отвечает (sergey_dukov) на <Я давно каждый год з…>
А вы не смотрели в сторону msys2? Там все скрипты сборки в открытом доступе, и можно присылать свои патчи. Есть Ада в более менее хорошем состоянии
[18:56:42] <ada_ru> (sergey_dukov) Значит в репозитории GNU всегда будет последняя версия компилятора ADA или нет?
[18:57:56] <ada_ru> (Максим) Нет, последняя версия всегда будет у АдаКоры, ведь они ее пилят и им нужно время для перехода/перепиливания/проверки работы с новым бакендом
[19:00:11] <ada_ru> (Максим) Вот сделали они 2019 на 8.3.1 и раздали клиентам, а FSF выпустил 9.0. Нужно время чтобы переделать на 9.0, а клиентам нужно в каждый момент времени иметь возможность отдать исправленный 2019, который на 8.3.1
[19:02:16] <ada_ru> (I_vlxy_I) Но ведь адакор не единственный источник патчей во фронт Ады? Теоретически ведь а fsf могут принимать патчи со стороны
[19:04:04] <ada_ru> (Максим) теоретически
[19:08:32] <ada_ru> (mister_alexander)  отвечает (I_vlxy_I) на <Но ведь адакор не ед…>
Да, но мэйнтейнеры адского фронтенда - чуваки из adacire
[19:08:54] <ada_ru> (mister_alexander) я как-то засылал им патч, на что мне сказали, что у нас уже есть фикс на эту проблему, но мы пока его не отсылали
[19:09:13] <ada_ru> (I_vlxy_I)  отвечает (mister_alexander) на <Да, но мэйнтейнеры а…>
То есть патч просто не пропустят?
[19:09:28] <ada_ru> (mister_alexander) Если захотят не пропустят)
[19:09:33] <ada_ru> (I_vlxy_I) Значит надо форкать :-)
[19:23:19] <ada_ru> (sergey_dukov) MSYS2 — это CYGWIN. Это не нативные коды. И в нём нет всего  набора утилит которые присутствуют в GNAT Community. Собственно я занимаюсь тем, что создаю навороченные сборки MINGW64 с последней версией компилятора GNAT, с максимально-возможной поддержкой количества языков программирования, системных библиотек и утилит. И пытаюсь всё это адаптировать под Windows, и чтоб было удобно разрабатывать эффективные программы для Windows. Все говорят о кроссплатформенности, я же двигаюсь в противоположном направлении.
[19:27:05] <ada_ru> (Максим) Ну можно добавить в msys2 чего ему не хватает.
[19:33:54] <ada_ru> (Максим) Мне кажется, что объединив усилия можно добиться большего, чем поодиночке.
[19:39:13] <ada_ru> (Максим) Вот единственная ошибка, которая сильно мне мешает в msys2, и кажется её начали исправлять! https://github.com/msys2/MINGW-packages/pull/6178
[19:45:59] <ada_ru> (sergey_dukov) Я когда то пытался собирать пакеты в CYGWIN для CYGWIN. Это у меня плохо получалось. И с бинарными кодами в CYGWIN тоже сплошная чехарда. Не думаю что в MSYS2 ситуация лучше. MINGW64 я собираю с нуля, чтоб исключить зависимость от версий системных библиотек. Так что версии библиотек у меня всегда консистентные. И всё же MINGW несколько проще. А кардинально изменять MSYS2 я не могу по той причине что им пользуюсь.
[19:52:06] <ada_ru> (Максим) в msys2 ситуация лучше, мне кажется.
[20:08:57] <ada_ru> (sergey_dukov) У меня MSYS2 установлен в минимальной конфигурации. Только то что нужно для работы в MINGW. Когда то я установил в работающий MSYS2 новую версию библиотеки ncurses (7.0 вместо 6,0) и меня MSYS2 слетел. Т.е в MSYS2 очень дохлый менеджер пакетов, который не отлавливает конфликтов версий. Ну а генерить MSYS с нуля, — это уж слишком! К тому же не очень понятно как это сделать.
[20:19:20] <ada_ru> (Максим) ясно, значит вы всётаки пробовали msys2...
[20:26:16] <ada_ru> (sergey_dukov) При установке пакетов Automake и Autoconf я всегда пользуюсь компилятором gcc из MSYS2.
[21:33:26] <ada_ru> (I_vlxy_I) Эх, винда...
[21:55:09] <ada_ru> (mister_alexander) Винда - огонь!
[22:03:51] <ada_ru> (I_vlxy_I)  отвечает (mister_alexander) на <Винда - огонь!>
Да. Постоянно подгорает.