← All posts tagged GNAT

OCTAGRAM
GNOME evolution ada Неприятные моменты C
Когда в команде Evolution всё шло наперекосяк. Нам тогда пришлось купить машину Solaris просто чтобы иметь возможность купить Purify; тогда не было Valgrind.
В Вилларибо просто компилируют бесплатным GNAT со включенными проверками, а в виллабаджо ищут, на каком бы платном Солярисе отладить под платным Purify

Ну да, почтовый клиент — это как раз та вещь, которую нужно делать «опасной бритвой», ведь там собрались не лошки, а все такие опытные брадобреи, уверенные, что у них-то получится не месиво, а элегантная программа, и почему бы для пущей уверенности не взять в заложники целостность почтовых архивов.
OCTAGRAM
FOSS ada Идёт какая-то прямо неделя принятия моих наработок в открытые проекты

I've uploaded JVM-GNAT for macOS, see
Thanks to you, I could put inside Java API files.
В оригинале документация и примеры для JGNAT не была рассчитана на проекты GPR, была устаревшая система по типу Search Directories в Делфях или include path в C, а привязки, хотя и генерировались разные, но использовались только те, что подключены. А я сделал проект, и привязки тоже проектом, и пока пытался собрать проект привязок, повылезали ошибки в случаях, когда для абстрактного метода стояла pragma Import вместо pragma Export, а также конфликты имён в разном регистре, которые генератор привязок сам не переварил. По результатам разруливания для всех стандартных Java API есть рабочие привязки. Это и приняли.

Пакет (Binding) Ada2012 Unicode NCURSES под Windows
Тут пригодился мой шаблон проекта

Работа Ada Web Server Client TLS через прокси починена
OCTAGRAM
Java SWING ada JGNAT CheerpJ Допилил CheerpJ и JGNAT друг под друга

Посмотреть можно здесь

Пока что вижу: насчёт многозадачности — правда. Я думал, это фишка простого Cheerp, а раз в простом Cheerp нету асинхронизатора, то это всё может работать только на SharedArrayBuffer и не везде. Но нет. Планировщик находится в loader.js от CheerpJ и, насколько я могу судить, работает. В том числе можно динамически подгружать классы, и они грузятся (с поддержкой AOT) по сети, и исполнение зелёного потока продолжается с момента остановки. EmScripten так не умеет, там только синхронным XHR можно с файловой системой работать, и только в Web Workers, в общем, без асинхронизатора это ни о чём.

Вместе со Swing там, похоже, даже движок текста свой подгружается. Антиалиасинг явно получше, чем в браузере. Но время запуска будь здоров. Хотя большая часть сейчас зависит от производителя. Если они там у себя что-нибудь подкрутят, васм внедрят, например, ведь Cheerp умеет, то есть, куда ужаться. Просто начинать с тем, что есть, а оно само будет улучшаться.
OCTAGRAM
ada 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. Даже в Делфи свой уже появился.
OCTAGRAM
ada GNAT Ada2020 Попробовал GNAT 2017. Пишут, что там Ada 2020 уже начата. Первое, что приходит в голову:
Current_Amount := @ + Amount_To_Read;… работает. Вроде там ещё был новый синтаксис агрегата для инициализации матриц функцией от индексов. Остальное либо уже сделано, либо не будет сделано в собственно языке по идеологическим причинам.

Что больше всего понравилось — так это то, что ASIS4GNAT, GNATCOLL, XMLAda и AWS предкомпилированы, а то как-то раньше тупо было. Раньше надо было ставить не входящий в комплект MSYS или MSYS2, ставить не входящий в комплект make, и на них собирать AWS, GNATCOLL и пр. И объяснять, как это делать, желающим пересобрать твою программу.
OCTAGRAM
Apple xcode Попробовал собрать приложение для теста (TextEdit) и обнаружил, что оно на Mac OS X 10.11 El Capitan даже не запускается, собрано под 10.12 Sierra. Ну ладно, подумал я, и попытался переключить SDK и цель на 10.11. А нету SDK для 10.11! Xcode может работать на 10.11, но собрать может только для 10.12.

Весь Xcode прежней версии качать неохота было, качнул только утилиты командной строки. Поставил. Поставились. Теперь компилятор для 10.11 есть. А SDK нету. Так уж и быть, качнул Xcode 7.3.1. Поставил. Теперь есть и компилятор, и SDK для 10.11. Но только для них (не считая забекапленной 10.12, конечно). Странно, а вроде раньше по-другому было. В те дни, когда я думал, что 10.6.8 — потолок, я поставил Xcode 3, и там были 10.4u, 10.5, 10.6, то есть, начиная от самой первой x86’ой до самой последней поддерживаемой. А тут одна.

Вычитал такое:
I can copy MacOSX10.11.sdk from another host, but presumably Apple has something else in mind here.
Just to be clear, Apple policy since Xcode 7 has been to only distribute the newest SDK with Xcode.app.

Так, теперь понятно, как Эппл пасёт чебурашек. Ставим разработчиков в дурацкое положение, когда они не могут просто взять и собрать для минимальной достаточной версии OS, как это делается на Windows, со слабым связыванием опциональных фич. Если не предпринимать специальных действий, если не писать на Delphi, C++ Builder или GNAT Ada, а именно из Xcode, то получаются приложения с неоправданно завышенными системными требованиями. Пользователи вынужденно обновляют ОС и/или железо, Эппл собирает кассу, разработчикам с этого пирога ничего не перепадает.

Однако нашёл ещё такое и такое. То есть, несмотря на ужимки Эппл, возможность собирать как лучше для людей имеется.

И это отличный источник входных файлов для BridgeSupport и анализатора, которым я также собираюсь прочесать GNUStep (до и после отравления TGC) и Cocotron на предмет пересечения. Где что появилось, где устарело, где изчезло. Пока что это мутная толща воды, и в неё надо забуриться.
OCTAGRAM
Linux Delphi arc совместимость Посмотрел немного на Delphi для Linux. Компилятор командной строки называется dcclinux64.exe. И там ARC для ссылок на объекты, что было бы очень круто, если не отсутствие поддержки ARC в компиляторах для Windows и Mac OS X. Ну покажите мне такого человека, которой будет писать из-под Винды (и не из-под чего другого) на Линукс (и не подо что другое). Потому что если в целевых платформах затёсывается хоть одна не-ARC, это во всём общем коде становится нельзя положиться на его наличие, всюду вылезают лестницы try-finally, то есть, ARC, считай, что и нет, наоборот, только геморроя добавляется предусматривать постоянно оба случая.

Это напоминает поведение хозяина, который, чтобы собаке было не так больно, режет ей хвост по частям. Linux уже там, а Windows и Mac OS X — ещё здесь. Ожидается, что и Windows будет там, но ещё нет, и пока крутитесь, как хотите.

Для Delphi обычно параллельно выпускается комплементарный C++ Builder, зеркалирующий в C++ особенности Delphi вроде свойств объектов, неявных метаклассов или пресловутого ARC, и синхронизирующий ABI вплоть до наследования классов между языками. Но для Linux я никакого такого компилятора не увидел. Нет bcclinux64.exe, и из IDE, если создать новый консольный проект, нельзя выбрать целевую платформу Linux. Немного неожиданно, ведь кроме одного все компиляторы C++ Builder основаны на clang и LLVM, в том числе для Android, который почти Linux.

Забавно, что для Win32, наоборот, есть сразу два компилятора, bcc32.exe без ARC и bcc32c.exe с ARC. Там тоже режут хвост по кусочкам, но начинают с другого конца. Ох, копец.

Если вдруг ограничиться только Линуксом, только Делфи (без комплементарного Делфям C++, но всё остальное, конечно, можно, включая Аду GNAT и комплементарный Аде G++), и только из-под Виндоуз, тогда всё супер. Хоть в чём-то Делфи становится лучше Ады. А так — копец.
OCTAGRAM
JavaScript ada RAII AdaMagic При преобразовании в C++ адские контролируемые типы проецируются на struct, при этом у них нет ни деструктора, ни перегруженной операции присваивания. Вместо этого компилятор оставляет в локальных контекстах rts_master_record, на которые навешиваются все контролируемые типы. Полагаю, это такое тяжёлое наследие ATC, на который в последних версиях компилятора GNAT, допустим, уже забили. Однако, в браузере, даже если я сам не использую ATC, вдруг то, что я написал, долго работало, и юзер нажал «остановить скрипт» — вот, пожалуйста, случился ATC. И AdaMagic сможет из этого выпутаться, при возврате управления понять, что и где нужно освободить. А на обычных платформах современный GNAT скомпилирует без этих штучек.
OCTAGRAM
ada llvm emscripten asmjs AdaMagic Экспериментирую с AdaMagic и emcc. За основу взят rtl.windows. Все скомпилированные файлы пришлось выкинуть, так как это не LLVM биткод. Настроил в %ADA_MAGIC%\SITE\config по аналогии:
be_exec_name = C:\Program Files\Emscripten\emscripten\1.35.0\emcc
linker_exec_name = C:\Program Files\Emscripten\emscripten\1.35.0\emcc
Выкинуть пришлось
be_required_flag = -mno-cygwin
linker_required_flag = -mno-cygwin

Перекомпиляция адского RTL запускается так:
cd C:\GNAT\AdaMagic-2016-07-22\AdaMagic\windows\rtl.emscripten
adacgen -ke -ga src\.bdy src\.spc
del *.tmp.bc

Результаты:
Total: 325 files compiled. 287 successful, 38 unsuccessful.
Те, что unsuccessful, содержат всякие платформозависимые штучки, их портировать надо вручную или обойтись без них. И ещё там есть несколько чисто сишных исходников. Надо ещё с этим поэкспериментировать. Может, за основу лучше rtl.linux взять? В Linux вместо kernel32 glibc, а в emscripten, предположительно, для libc аналоги функций будет проще найти, чем для kernel32.
OCTAGRAM
C++ C ada AdaMagic Был такой компилятор AdaMagic, умел транслировать Ada в C и C++. Там ещё и в Java компиляция была, но это и сейчас есть в GNAT. Потом SofCheck был куплен AdaCore, и этот компилятор пропал из поля зрения. Однако, его продают под другим брендом тут. Его там завернули в какой-то AppCOE на базе Eclipse, но всё это можно развернуть, выкинуть лишнее и докопаться до самых важных файликов, adacgen.exe и adabgen.exe. На них навешена типа защита. Типа — потому что там, во-первых, есть отладочная информация, во-вторых, неиспользуемые функции не выбрасываются. Очень пригодилась мне такая неиспользуемая функция, как write_license_file, например.

Файл license_key.txt генерить научился, зашифрованные DES файлы типа libadartl.a.enc, разшифровал, для PDF пароль нашёл, поставлю qpdf и тоже разшифрую, впрочем, PDF в открытом виде можно и так скачать с сайта. Сейчас пишу инструкции, чтобы мои действия можно было повторить со следующими версиями. Вообще, не похоже, чтобы новый владелец-индиец разбежался развивать этот компилятор, он, скорее, вокруг достраивает всякие OS абстракторы на C, так что смысла большого обновляться не вижу, но тем не менее. Если думать на тему использования вместе со всякими emscripten, то от libadartl.a толку не очень много, но на всякий случай оно есть. С самим компилятором надо ещё разбираться. Он по умолчанию работает в режиме Ada->C->GCC, но в GCC есть GNAT, который гораздо лучше, и если кто-то заинтересовался AdaMagic, как я, то сценарий изпользования у него будет позабористее, и надо читать доки.

Таким образом, теперь есть компилятор Ada->C/C++, с помощью которого можно целиться во всякие дурацкие, но иногда нужные платформы, хостится он либо на Windows, либо на Linux, а через эмуляторы можно потенциально запускать из ещё большего набора OS. По плану выложить на форум только для зарегистрированных пользователей. Раз и навсегда адвокаты языков программирования, для которых на всех платформах есть транслятор, уедят.
OCTAGRAM
ada tdm Поставил компилятор Ады через TDM web-установщик. Довольно просто установилось. Библиотека GMGPL, Win64 поддерживается, прикольно, но контейнеры в стандартной библиотеке старой версии, не поддерживают конкурентное чтение, как это было ещё в далёком GNAT GPL 2015. Ну и GNATCOLL, к которому я привык, тоже GPL, так что для не-GPL надо к чему-то другому привыкать.
OCTAGRAM
время posix ada GNAT FILETIME Разобрался с конвертацией времени. Как выясняется, в 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 тоже? Давайте проверим:
OCTAGRAM
время ada GNAT В GNAT Ada.Calendar.Time реализован как Long_Long_Integer в наносекундах, а 0 — это 2150й год. Правда, The Ada Epoch отсчитывается всё же от 1901го года, где ещё хватает разрядов для представления настолько малых чисел. И високосные секунды там учитываются (в отличие от времени UNIX и JavaScript), но мы, конечно, не можем знать, сколько их накопится к 2150му году, поэтому с их учётом адский «0» будет на несколько секунд позже Нового 2150го Года.
OCTAGRAM
GCC x86_64 amd64 mingw64 SEH SEH_Init

On x86_64 windows exception mechanism is no more based on a chained list of handlers addresses on the stack. Instead unwinding information is used to retrieve the exception handler (similar to ZCX GCC mechanism). So in order to register an exception handler we need to put in the final executable some unwinding information. This information might be present statically in the image file inside the .pdata section or registered through RtlAddFunctionTable API. Currently the GCC toolchain does not generate the .pdata information for each function. As we don't need to handle SEH exceptions except for signal handling we are registering a "fake" unwinding data that associate a SEH exception handler to the complete .text section. As we never return from the handler, the system does not try to do the final unwinding using the pdata information. The unwinding is handled by the runtime using either the GNAT SJLJ mechanism or the ZCX GCC mechanism. The current implementation is using the RtlAddFunctionTable.

Here is for information purposes the equivalent using a static .pdata section: …

Теперь понятно, что имеет в виду @vt под «знает, как компилировать под Windows». Если считать Microsoft законодателем мод, то что-то в этом есть, хотя как по мне, — скорее вкусовщина. По-любому, без брандмауэров исключений никакой работы с COM не делается, так что какая разница, что внутри.
OCTAGRAM
web Яндекс TLS Обнаружил, что в IceDragon (FireFox) ru.wikipedia.org резолвится не в 91.198.174.192, а в 5.189.172.38 с невалидным самоподписанным сертификатом
/C=AQ/ST=East Antarctica/L=Lake Vostok/O=XYZ/OU=Microbe Division/CN=xyz-httpserver-uates.com/emailAddress=dev@null

Ни про этот IP, ни про xyz-httpserver-uates.com полезного не нашёл.

Потом протёр глаза и увидел, что домен в браузере на самом деле ru.wikipedia.net.ru, а вовсе не org, который я начал ковырять в командной строке nslokoup, ping, openssl s_client, и перекинул меня на этот домен Яндекс через третью ссылку по запросу "GNAT LLVM". Весь этот wikipedia.net.ru принадлежит какому–то «XYZ», и с DNS серверами q1.jjputx.com и q2.jjputx.com та же история.
OCTAGRAM
programming unicode ada GNAT Обнаружил, что 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?), сочувствую тем, кто вынужден этой пакостью пользоваться.
OCTAGRAM
Delphi indy Поделал веб–сервер на Delphi 7 и Indy. URL–декодеры норовят сконвертить текст в свой долбаный ANSI и завопросить всё нафиг. Юникодных аналогов StrReplace нет, приходится конвертить в UTF8 и обратно. Коннектор к базе данных, как выясняется, тоже конвертит всё в ANSI и вопросит всё нафиг.

Заказчик хотел возможность копипастить код из обычного приложения в web. Решил это тем, что сделал пул из Data Module. Каждый Data Module содержит все соединения к базе данных, отправлялки e-mail и прочие компонентики, скопипащенные из обычного. Для каждого запроса берётся экземпляр этого Data Module, и в нём запускается специальный метод, который все эти компонентики теперь может использовать. Опасался, что из неосновного потока что–нибудь будет работать неправильно, но вроде полёт нормальный.

Вот так понимаешь, насколько хорош AWS. В нём просто нет этих перекодировок, неожиданно происходящих то тут, то там. Да и зоопарк из String, Wide_String, Wide_Wide_String, Unbounded_String, Unbounded_Wide_String, Unbounded_Wide_Wide_String в стандартной библиотеке, оказывается, не так уж плох. Можем работать со строками с любой шириной символа, не будучи вынужденными перекодировать их в UTF-8. По крайней мере, самые базовые операции всегда есть. И библиотеки многие либо работают с последовательностями байтов, либо с юникодом, который появился достаточно давно, в Ada 95 и был в GNAT изначально. Не париться про существование ANSI несколько проще, хотя и всё ещё не так просто, как в node.js, когда console.log() без дополнительных танцев с бубном просто выводит Юникод на любой OS.
OCTAGRAM
Linux Windows10 Х11 Потестил, как работает подсистема Linux в Windows 10. Гораздо лучше, чем SFU в Windows XP/2003. Нет веселья типа слом совместимости между SFU в Windows XP/2003 и SUA в Windows 7/2008, нет ограничения на выпуск OS, как это было в Windows 7. На моём самом днищенском выпуске всё замечательно заработало. И база пакетов, ну вся от Ubuntu. Взял, да поставил gnat-gps с компилятором. Во времена SFU это было ой как геморройно, и я так и не сделал. А ведь есть ещё и кросскомпиляторы для разработки под MIPS. Раньше и подумать нельзя было, чтобы кто–то собрал кросскомпилятор с Windows на Linux-MIPS для роутеров и приставок, скажем. Или с Mac OS X на Linux-MIPS. Как–то вот не было такого, зато на Linux готовые кросскомпиляторы всегда были в изобилии, и теперь они доступны на самых днищенских версиях Windows 10 почти любому желающему.

Теперь бы ещё понять, а появился ли, наконец, нормальный X11 сервер для Windows, который, как в Mac OS X, сам синхронизирует свою раскладку клавиатуры с системной? У меня есть настроенный XMing, но раскладка не фонетическая и переключение по Ctrl-Shift, а у меня по Alt-Shift-{1,2,3}, и я не хочу лезть в настройки X11. Мне эти настройки нужны только по части как настроить волшебную печеньку, это само не сделается, так как подсистемы разные, в отличие от Mac OS X, где X11 сервер и приложения ищут печеньку в одном месте.
OCTAGRAM
programming ada Конец адского мандата
Когда–то Ада была обязательна при выполнении проектов для минобороны США, ну а попутно это двигало смежные индустрии.

Это однозначно положительно сказывалось на качестве этих проектов, но вредило языку. Производители инструментария знали, что они могут сделать до некоторой степени любую фигню, и если она пройдёт тесты на сертификацию, то получит право на бренд «Ада», и огромной куче фирмёшек, работающих на оборонку, придётся приткнуться к одному из таких производителей. А производитель может однажды вложившись, снимать сливки, и адаистов такая ситуация напрягала. Например, первый транслятор Ada в машинные коды GNAT появился в результате гранта минобороны, а до этого делали интерпретатор байт–кода, и хватит. Это уже потом пошли ObjectAda, PowerAda, AdaMagic, Irvine, и мы сейчас знаем Ada только как язык, компилируемый в машинные коды (JVM и .NET не очень приживаются за ненадобностью).

Ну что ж, теперь в 2016м году плоды конкуренции в полной мере пожаты. Из реализаций современного стандарта остался только один, но качество инструментария и впрямь довольно неплохое. Я наблюдаю это с 2005го года, и вижу, как качество GPS неуклонно возрастало, переболев детскими болезнями.

Однако, додики, оставшись без законодательных ограничений, свалили с Ады и пишут всякие Flash runtime и CLR отнюдь не на Аде, и поэтому у них там баги без конца.

И непонятно, как бы это разрулить, чтоб всеобщее счастье было. Может, надо периодически вводить–снимать мандат, чтоб балансировать между плохими средствами разработки и плохим ПО.