to post messages and comments.

← All posts tagged GNAT

У AdaCore обновилась страница загрузки GNAT
На один дебилизм стало меньше. Раньше у них выбор начинался с года, а потом шли платформы. Если в каком-то году нет платормы, то её даже в списке не было. Потом сделали, чтоб было, но серого цвета. Это касается всяких экспериментальных платформ типа LEGO NXT MindStorm, на смену которому пришёл ARM для голых досок. А также JVM и CLI, которые кроме гуглострадальцев (AppEngine) оказались почти никому не нужны, когда есть нормальные (нативные) компиляторы. Если всё же хочешь скачать, перебирай разные года, пока не найдёшь нужный. Сейчас, если зайти в more platforms, все платформы в списке можно выбрать, и сам выбирается наибольший год выпуска.

Я бы ещё SPARK до 2012го года включительно отдельно выделял, потому что в старом СПАРКе аннотации для верификатора в комментариях специального вида пишутся, и это совместимо с, например, MapuSoft AdaMagic, BTC ObjectAda, BTC Apex Ada, Janus Ada, Irvine и пр. застрявшими между Ada 95 и Ada 2005, а аннотации SPARK 2014 пишутся в аспектах, которые поддерживает только GNAT. Понятно, что AdaCore не сильно заинтересованы в поддержке конкурентов.

Ещё заметил, что на страницу загрузки теперь можно попасть, не оставляя свой email.

Теперь, наверное, самым ожидаемым был бы кроссплатформенный пакетный менеджер с онлайн базой данных. Это было бы логичным продолжением линии развития gnatmake => gprmake => gprbuild+gprinstall. Даже в Делфи свой уже появился.

Попробовал GNAT 2017. Пишут, что там Ada 2020 уже начата. Первое, что приходит в голову:
Current_Amount := @ + Amount_To_Read;… работает. Вроде там ещё был новый синтаксис агрегата для инициализации матриц функцией от индексов. Остальное либо уже сделано, либо не будет сделано в собственно языке по идеологическим причинам.

Что больше всего понравилось — так это то, что ASIS4GNAT, GNATCOLL, XMLAda и AWS предкомпилированы, а то как-то раньше тупо было. Раньше надо было ставить не входящий в комплект MSYS или MSYS2, ставить не входящий в комплект make, и на них собирать AWS, GNATCOLL и пр. И объяснять, как это делать, желающим пересобрать твою программу.

Разобрался с конвертацией времени. Как выясняется, в GreyLink DC++ время хранится совсем не в том формате, в котором я подумал, а в FILETIME. Также выяснилось, что и FILETIME в Windows, и time_t в POSIX могут быть как с високосными секундами, так и без. FILETIME, похоже, с високосными секундами не встречается, но тут пишут, что это не исключено. time_t согласно POSIX.1 тоже не должен поддерживать их:
IEEE Std 1003.1-1988 (``POSIX.1'') legislates that a time_t value of 536457599 shall correspond to "Wed Dec 31 23:59:59 GMT 1986." This effectively implies that POSIX time_t's cannot include leap seconds and, therefore, that the system time must be adjusted as each leap occurs.… но я смотрю на маны posix2time и time2posix и вижу, что совместимость с POSIX где-то может быть сломана в угоду монотонности времени. Всегда надо уточнять, с високосными секундами время или нет, иначе будет разъезжаться на 25 секунд, и с каждым годом всё больше. Вот, допустим, MySQL поддерживает високосные секунды в полях TIMESTAMP, если работать с этими значениями через функцию UNIX_TIMESTAMP. Но как мы уже выяснили, подлинный UNIX time_t не содержит високосных секунд, значит, это может быть только модифицированный. И если вы создаёте значение инструментом, который не вставляет эти секунды, у вас время начнёт разъезжаться. Вот в JavaScript по стандарту временная шкала нелинейная, как и в POSIX.1. Но если POSIX.1 где-то нарушается, то, может быть, и EcmaScript тоже? Давайте проверим:

В GNAT Ada.Calendar.Time реализован как Long_Long_Integer в наносекундах, а 0 — это 2150й год. Правда, The Ada Epoch отсчитывается всё же от 1901го года, где ещё хватает разрядов для представления настолько малых чисел. И високосные секунды там учитываются (в отличие от времени UNIX и JavaScript), но мы, конечно, не можем знать, сколько их накопится к 2150му году, поэтому с их учётом адский «0» будет на несколько секунд позже Нового 2150го Года.

Обнаружил, что GNAT уже давно автоматически использует UTF-8 как однобайтовую кодировку, а не ANSI (управляется переменной среды GNAT_CODE_PAGE). В смысле, использует её для I/O, в частности, имён файлов, где и был камень преткновения, поскольку у таких модулей, как Ada.Directories, аргументы в однобайтовых String, а не двухбайтовых Wide_String или четырёхбайтовых Wide_Wide_String. Кодировка исходников управляется -gnatW, в юникодных кодировках можно давать идентификаторам имена не на латинице и писать строковые литералы, но такие литералы должны быть достаточно широкими, потому что String по стандарту жёстко Latin-1, а всё русское требует минимум Wide_String. Есть, правда, вариант, при котором компилятор думает, что он парсит исходник в Latin-1, а он — в UTF-8 или ANSI, но как–то это не правильно, мне кажется. Идентификаторы не получится юникодные написать, и широкие строковые литералы, наоборот, будут коцаться.
Восемь назад на Windows такие строки было особо некуда деть, кроме платформозависимого Win32Ada. Нет, можно, конечно, было подключить Ada.Wide_Wide_Text_IO и пошпарить Юникодом в тексте файла, но имя файла при этом будет ограничено ANSI. Эту дырку GNAT закрыл давно. Есть у процедур открытия файла строковый параметр Form, смысл которого по стандарту определяется компилятором, и в GNAT его можно было использовать для того, чтобы указать, что имя файла — в UTF-8, а не ANSI. Так что, сконвертировав имя файла в UTF-8, можно даже было и открыть его. А вот Ada.Directories было более проблемным, там никаких параметров Form не было, чтоб отказаться от этого проклятого ANSI. Понятно, что были и Матрёшки, где диктатура четырёхбайтовых строк, не дожидаясь, когда стандарт избавится от однобайтового наследия, но состояние стандартной библиотеки тоже важно.

Попутно, пока искал, поиск выдавал мне, как обстоят дела у других разработчиков
But the problem is MSVC only accept UTF8+BOM and MinGW only UTF8-BOM
note that MinGW use UTF-8 for sources, while VC8 use ANSI
Если этот «хорошо подходящий для Windows» компилятор до сих пор форсит ANSI в исходниках (кто будет ставить BOM для UTF-8?), сочувствую тем, кто вынужден этой пакостью пользоваться.

Farewell Robert...
It fills me with with great sadness to announce that Robert Dewar passed away yesterday at home, surrounded by his family. His passion for Ada and software engineering, which was the driving force behind the GNAT compiler, was no more evident than in his discussions with customers, on community forums, with his students at NYU, and in the presentations he gave at numerous conferences. He will leave a big, big hole in many peoples' lives not least here at AdaCore. RIP Robert and thank you for everything.