← All posts tagged Delphi

OCTAGRAM
Java com совместимость Bad class file: version 52.0 not supported
Да что ж вам неймётся-то по версиям скакать. Ну что не сидится на одной. Вот чем хорош COM и чем плоха Java, в COM совместимость десятилетиями держится, а тут каких-то несчастных четыре года отделяет, и уже инструментарий начинает отваливаться. В книге «Putting Metaclasses to Work» симуляция была специально реализована на Java, чтобы, как пишет автор, как можно надольше сохранить. В итоге компилятор DirectToSOM C++, библиотека SOM и прочее PE/COFF'ное запускается на современной Windows 10, а симуляция PMtW на современной JVM — нет. И на не очень современной 1.5 — тоже. Вообще надо какую-то древнюю находить, чтоб подошло тютелька в тютельку. Знал бы автор, как жестоко будут насмехаться над его потугами производители. Начиналось за здравие, столько надежд было.

И в Delphi CORBA IDL парсится утилитой не на Delphi, транслируемой в, как показывает практика, долгоживущий PE/COFF, а на Java, и тоже там совместимую версию надо постараться подобрать, собственно, почему эту фичу кроме особенно заинтересованных никто не смог увидеть в действии.

Предполагаю, что так пагубно влияет общая версия формата для интерфейса и реализации. Собственно, и нет разделения на интерфейс и реализацию. Новые фичи не могут просто сидеть и не высовываться в новых секциях и новых опкодах, на которые не любой инструментарий будет смотреть, им обязательно надо вылезать на самый верх, в общий номер формата, и там всё ломать.
OCTAGRAM
rpc IDL Modula3 ILU ISL Inter-Language Unification's Interface Specification Language (ILU ISL)

В копилку паскалеподобных IDL. ILU составляла конкуренцию CORBA и поддерживала OMG IDL, но он был там второсортным по отношению к ILU ISL, транслировался в него. ILU ISL, надо полагать, развивался под влиянием Modula-3, которая, в свою очередь повлияла на Delphi, поэтому есть некоторое сходство с той веткой потомков Паскаля. Служебные слова капсом, знак равно вместо "is" при определении типов, знак равно вместо присваивания при указании значения по умолчанию и значения константы. В отличие от CORBA, где практически никто не разбежался лепить везде wstring, как только он появился, хорошо, что в ISL обычный CHARACTER — 16-битный, хотя на сегодня это тоже стало мало.

Какого-то внутрипроцессного взаимодействия, как в SOM, реализовано не было, поэтому все поддерживаемые языки (Modula-3, Python, Java, Common Lisp, Perl 5, C, C++, Guile Scheme) каждый кто в лес, кто по дрова, живут своей жизнью и могут встретиться только по сети. На уровне синтаксиса поддерживается множественное наследование классов, но без межъязыкового ABI от этого мало толку.

Пишут, что вроде как на ILU работал протокол передачи гипертекста следующего поколения (HTTP-NG), вместо которого декаду спустя случился HTTP/2.
OCTAGRAM
Delphi ada Когда случился несчастливый релиз Delphi 8, несчастливый тем, что там был только .NET, меня бесили немутируемые строки. Раньше же как-то работало с мутируемостью, а вот теперь не работает, и всё тут, счётчика ссылок не хватает. Дополнить трассирующую сборку мусора счётчиком ссылок кому-то религия не позволила, и из-за этого теперь страдать.

Много лет спустя пишу на Аде и обращаю внимание на то, что пишу практически в стиле единственного присваивания, благо адский declare-begin-end позволяет, и благо, начиная с Ada 2012 всё больше вещей можно записать выражениями. В этом плане Делфи уступает даже 83ей Аде. По принципу наименьших прав большинство значений между declare и begin — константы, и строки — соответственно, тоже. Кроме того, хотя есть Делфи-подобные строки (Unbounded_String в стандартной библиотеке и Universal_String в Матрёшке Вадима Годунко) со счётчиком ссылок, быстрее всего работают строки, размещаемые на стеке. Это которые самый обычный type String is array (Positive range <>) of Character, по принципу действия похожий на вариадические массивы в C99 и alloca(). После размещения на стеке у них размер поменять нельзя, а, значит, и нет особого смысла им не быть константой. И так получилось разделение на де факто немутируемые обычные строки и мутируемые строки в динамической памяти, похоже на String и StringBuilder .NET.

В каком-то смысле вернулся к тому, с чего начинал, с поправкой на то, что Unbounded_String как значение вполне себе пригоден для хранения в записях, массивах и контейнерах, в отличие от.
OCTAGRAM
JSON yaml libyaml Переоценил я libyaml. Думал, универсальный движок и для JSON, и для YAML, но обнаружились нюансы.

Почему-то сложно оказалось добиться от libyaml форматированного JSON. Что-то я смутно припоминаю, что там чуть ли не реконструировать весь синтаксис оригинального документа можно было вместе с пробелами и табуляциями. Настолько можно всем порулить. И не нашёл, где это было. Надо отступы в поточный синтаксис (соответствующий подмножеству JSON) добавить, и никак. Только в блочном синтаксисе отступы есть. Хакнул libyaml, получил такое:

[4.0, "abc"
, {"x": -5.0, "z": 20.0
}
]

Скаляры где-то в другом буфере копятся. Если пытаться делать переносы перед ними, то перед «, {"x"» становится больше переносов.
OCTAGRAM
objectiveC BridgeSupport Всё же я погорячился насчёт BridgeSupport XML как аналога IDL/TLB/SOMIR для Objective-C. Например:

<function name='NSStringFromClass'>
<arg type='#'/>
<retval type='@'/>
</function>

Здесь видно, что на вход должен идти потомок NSClass, но это по историческим причинам. Видимо, не всегда в Objective-C поддерживались метаклассы, и ссылки на классы, как в Delphi, были разных типов со ссылками на объекты. Кроме NSClass, другие классы и протоколы чести попасть в кодирование типов не удостоились, а каким-то другим образом имена не пробрасываются. Вот, например, в данном примере потеряна информация о том, что результат — ссылка на NSString.Таким образом, это даже хуже, чем CORBA TypeCode, которые мне не нравились за то, что там терялась информация о пространстве имён класса и структуры.

Вот ещё пример метода NSString:

<method selector='getCString:maxLength:encoding:'>
<arg c_array_length_in_arg='1' index='0' type_modifier='o'/>
<retval type='B'/>
</method>

Я здесь вообще не могу понять, какого типа первый и второй аргумент. o значит out. А больше тут ничего и нету. А есть ещё третий, NSStringEncoding, между прочим.

Внимательно всмотрелся в кодирование типов на предмет char32_t, char16_t или wchar_t. Нету! А что же тогда будет возвращать NSString, если читать её по кусочкам? Пошёл смотреть сигнатуру метода в NSString.h:
— (unichar)characterAtIndex:(unsigned)index;А в Foundation.bridgesupport такого метода тупо нету. Интересный вопрос, почему. Если бы он как-то ставился в игнор, я бы его увидел в исключениях BridgeSupport\exceptions\Foundation.xml, но там тоже нету. Впрочем, учитывая, что
typedef unsigned short unichar;… я бы должен был увидеть S, формально не отличимый от unsigned short, и только эвристически, зная, что программисты становятся идиотами, экономящими два байта, только когда работают со строками, и что-то очень редко, работая с целыми числами и даже массивами из них, думают, ой нет, 4 байта-то многовато будет, надо два, понять, что S следует проецировать на Standard.Wide_Character в языке Ада и System.WideChar в языке Делфи, а не Interfaces.Unsigned_16 или Interfaces.C.unsigned_short в языке Ада и System.Word в языке Делфи.

Подводя итог, парсер для Objective-C придётся делать. Или делать clang -ast-dump или GCC-XML, если там Objective-C поддерживается, а BridgeSupport — вспомогательный инструмент.

Впрочем, довольно полезный с учётом того, что там промаркировали c_array_length_in_arg и модификаторы in, out, in out, имеющие синтаксическую поддержку в таких сравнительно более продвинутых нативных языках программирования, как Делфи и Ада. Первое в языке Делфи называется «открытыми массивами», а в языке Ада недоопределённые массивы — вообще органичная часть языка, ведь самые обычные строки там такие, и передача их как аргумент — это просто частный случай того, что можно сделать. Ну и когда сишную звёздочку не понятно, проецировать ли на in out, out или именно на указатель, это весьма раздражает. Если спроецируешь на in out или out, то нельзя без хаков передать null в языке Ада или nil в языке Делфи, а в некоторых API это можно и нужно, а в некоторых API — нельзя, и если язык мешает это сделать без хаков, то это к лучшему. Проекция на указатель более универсальна, но по сравнению с окружающим кодом, который нередко вообще без указателей, выглядит как что-то инопланетное.
OCTAGRAM
Delphi ada Почему-то компилятор жутко тупит над производными типами. Вот, например, type TDateTime = type Double. Логично сделать так:

TDateTime(SysUtils.StrToFloat(…))Ан нет, E2089 Invalid typecast. Может, проблема в том, что результат StrToFloat — Extended, а не Double?
TDateTime(Double(SysUtils.StrToFloat(…)))Всё равно E2089 Invalid typecast. Да как же так? Сам ты инвалид!

Что самое удивительное, работает, если приведение типа НЕ ДЕЛАТЬ:
SysUtils.FormatDateTime(…, SysUtils.StrToFloat(…))Вот так компилируется и само приводится сквозь все Extended, Double и TDateTime, хотя я бы сильно не хотел, чтоб число с плавающей точкой случайно могло стать OLE датой/временем.

Ещё это сильно мешает привязки делать. По привычке возьмёшь напишешь type TPluginItem = type Pointer, и начинает тебе компилятор мозг выедать на ровном месте, а на неровном — соответственно, не выедать. Плюнешь, переделаешь в указатель на пустую запись с уникальным именем. Вот теперь получился указатель, который «не похож» на произвольно взятый другой указатель, но, к сожалению, всё ещё похож на указатель, чего лишний раз не хотелось бы, и от чего производный тип должен был спасти. Гипотетически для непохожести можно завернуть ещё дополнительно в запись, но тогда может сломаться работа с внешней библиотекой, ибо Delphi получает запись-результат всегда через дополнительный указатель, даже если она меньше размера двух указателей, как предписано stdcall. И тем более результат с плавающей точкой таким образом не приедет через регистр сопроцессора.

А вот на Аде берёшь и пишешь type OLE_Date_Time is new Long_Float или type Plugin_Item_Type is new Address, и работает это именно так, как ожидаешь. Одно в другое случайно не сконвертируется, а по требованию — всегда пожалуйста, без этих дурацких непонятных ошибок. И, конечно, на Аде, когда пишешь пакет, можно просто написать в публичной части type Plugin_Item_Type is private, и всё, внутреннее устройство для внешнего мира становится непрозрачно. Если нужно, функции конвертации из/в Address можно написать в дочернем пакете, чтоб глаза не мозолило в родительском. А то в Delphi, C и C++ вечно свалка в пространстве имён, хочется закрыться руками от падающих отовсюду в пространство имён гор мусора.
OCTAGRAM
Delphi OpenSSL indy Решил не так давно делать веб-запросы в программе на необновлённом Indy. Кто его знает, этого заказчика, сможет он свежую поставить или нет. Узнал много нового. Оказывается, обычная библиотека OpenSSL к Indy не подходит, потому что там требуются некоторые функции специально для Indy вроде SSL_CTX_set_options_indy. Думаю, раз она в комплект не входит, надо скачать её с сайта Indy. А вот и нет! Где библиотека, где патч, интересные люди, однако.

Полазив по форумам, нашёл такую ссылку. Скачал самую свежую. Не подошло. Методично качал другие версии с конца, потом методом дихотомии, потом тупо взял самую старую версию. Смотрел в ФАРе, есть там эти долбаные нестандартные функции или нет. Нету. Нигде. Заглянул в архив и там прямо явно видно версии с Indy в названии. Наверное, оно. Скачал 0.9.8l. Не подошло. Скачал 0.9.8h. Не подошло. Действительно, если смотреть, что там внутри, то префиксы _indy видать, но это не всё, что нужно. Оказывается, IdSSLOpenSSLHeaders10.pas там не для красоты, и без него не работает. Я ведь хотел, чтоб Indy не пересобирать, думал, на интерфейс к новым функциям можно забить, а оказывается, что там и основной интерфейс переделан, поэтому каких-то нестандартных функций нет. Впрочем, пересобирать весь Indy не пришлось, достаточно было положить только этот файлик под правильным именем в директорию проекта, он заменил собой предустановленный dcu и нормально скомпоновался с остальными модулями.

Потом выяснилось, что хотя в Delphi 2007 версия Indy 10, но если бы я на сайте Indy зашёл в Indy 9, то там была бы ссылка на SSL Support DLL's, а оттуда — на Fulgan. Если б знал, что там всё настолько плохо, попробовал начать с WinInet. Авось его неумение в SNI проканает.
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
Apple BridgeSupport Как же не люблю, когда всё пропадает из Интернета. Ну было же великое событие, появление BridgeSupport, до которого описание было только в заголовочных файлах Objective-C и не было аналога COM TLB, SOM.IR и т.п. Для Qt что-то такое уже было, для Gtk+ было, и только Cocoa была последней крепостью. И эта крепость пала. Всё это было в Mac OS X 10.5 Leopard, а у меня был Mac OS X 10.4 Tiger, но я следил за этими событиями, в частности, ставил MacPorts, и через него всё замечательно ставилось и на Тигре тоже. Недальновидные разработчики не могли придумать ничего лучше моста в Python и Ruby. Чуть более дальновидные на его основе сделали взамен устаревшего встроенного моста Cocoa-Java новый RoCocoa. И совсем то, что доктор прописал, было в первую очередь поступить с этой метаинформацией как в COM TLB, то есть, конечно же, привязки для Delphi и Ada, а уж потом всякие скрипты-шкрипты.
OCTAGRAM
Linux Delphi Раньше я видел в действии только Делфи для Мак ОС Десять. Скомпилировал при помощи dccosx.exe консольный «Привет, мир!», всё прошло успешно, но на Мак ОС Десять, правда, не запустилось, потому что у меня был Тигр, а надо было хотя бы Леопард. Кому надо, зачем надо, так хорошо без него всё было, но как обычно, просто надо, и всё тут. На XP Safari 5 можно было установить, а на более новый Тигр — всего лишь Safari 2. И FireFox 26 на XP против FireFox 3.6 на Тигре. Про Делфи XE2 можно было сказать: «И ты, Брут?» Но примечательно, что компилировалось это всё дело без доступа к Мак ОС Десять, ни к Тигру, ни к Леопарду, ни к какой.

А вот на Линуксе я же помню, что вылезает, если с ЦентОСа на Дебиан перенести бинарник. Сразу то символ в glibc не той версии, то сегфолт, то ещё что-нибудь не заладится. Интересно, как с этим новый Делфи справляется. Ведь ему же не дают полапать конфигурацию операционной системы разработчика, и он не может к ней глубоко привязаться, как это любит делать всё автотулзовое и вообще чуть ли не всё линуксовое.

Собственно, пока я окончательный бинарник так и не смог получить, а только .o. То есть, так же просто, как с Мак ОСом, уже не работает. Если пытаться что-то сделать из IDE, хотя бы Build или Compile, без Run, при любом раскладе IDE требует подключить к paserver на Linux, а если нет, то и компилировать не будет. Попытался задействовать в качестве платформы paserver «Bash на Ubuntu», то есть, WSL, и не смог скопировать paserver туда. Помедитировал на вывод mount и ls / в этом bash, не нашёл ничего похожего на файловую систему Windows. Это действительно параллельная Вселенная. Можно, конечно, на сайт залить, а потом wget'ом скачать, но решил дождаться установки Creators Update, а пока пойти другим путём.
OCTAGRAM
Linux Delphi ada Почитал сорцы в linuxrtl, бросилось в глаза MarshaledAString вместо PAnsiChar. Открыл System.pas, нашёл там при включенном NEXTGEN такое:
_PAnsiChr = _PAnsiChar;
MarshaledAString = _PAnsiChr;
При этом _PAnsiChar не объявляется, то есть, он встроенный. Без NEXTGEN _PAnsiChr = привычному PAnsiChar. Напрашивается мнение, что из MarshaledAString пытаются лепить типа-не-указатель, который надо класть в System.TMarshal. Судя по тому, что WriteLn(X) и X[0] := '2' компилируются, природа этого типа пока ещё не совсем замаскирована.

Также огорчило, что до сих пор нет нормальных 32битных символов и строк. В языке Ада они уже 12 лет как появились как неотъемлемая часть стандарта. Как можно идти на Линукс без 32битных строк? В API открытых библиотек Юникод, сколько я видел, любой libidn возьми, всегда представлен 32битными строками. Открыл System.pas, увидел там type UCS4Char = type Cardinal для всех платформ, где Cardinal — это беззнаковое 32-битное целое, а type … = type … в Делфи делает новый тип, не совместимый со старым без приведения типа, аналог адского type … is new …

Ещё посмотрев по сторонам, нашёл StdDefTypes.inc , а в нём — type wchar_t = Int32

Ни методов TMarshal, ни попыток аналогично скрыть указатель вроде Marshaled32String, ничего такого. Высокопоставленные китайские чиновники с именами из иероглифов за пределами BMP, а также все причастные, которым текст с этими именами надо обрабатывать, не одобряют это.
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
Apple objectiveC YellowBox Эмпирически выясняю, что нужно, чтобы запустить приложения под YellowBox, по возможности не устанавливая их. Самый свежий — это WebObjects, проверяю на нём. Опытным путём установлено, что перед тем, как запускать программы, нужно запустить все 4 служебных процесса в таком порядке:
%NEXT_ROOT%\Library\System\machd.exe -d
%NEXT_ROOT%\Library\System\nmserver.exe -d
%NEXT_ROOT%\Library\System\WindowServer.exe
%NEXT_ROOT%\Library\Frameworks\AppKit.framework\Resources\pbs.exe

Причём, обычный установщик YellowBox ставит первые два как службы (также можно вручную установить ключиком -install с правами админа) с указанием зависимости, а последние два — ставит в автозагрузку каждому пользователю, отсюда и их порядок после служб. Между последними двумя порядок либо не критичен, либо они как-то ждут друг друга, тут сложно понять. Ключик -d позволяет запустить службы как обычные процессы, таким образом, не требуя прав админа.

С точки зрения возможности выбрать в качестве кроссплатформенного движка не какой-нибудь дебильный Qt, Gtk+ или ещё куда ни шло VCL, wxWidgets и иже с ними, а всё же что-нибудь, основанное на спецификации OpenStep, это фиговенький, но всё же вариант для Windows. Сдаётся мне, Cocotron-то во многом получше будет, но там инструменты разработки кросскомпилируют с Mac OS X, да ещё с каким-то движком Objective-C, будто бы отличным от всех остальных, которые можно найти в природе. Что касается GNUStep, то эти ребята, когда я прочитал, как они «сделали» ARC, у меня просто волосы дыбом встали. Они додумались Boehm GC впихнуть в движок для всех программ без разбора. Если оно там теперь так и осталось неизвлекаемое, GNUStep начиная с этого момента можно считать безнадёжно сломанным, непригодным для серьёзной разработки. Надо отследить ревизию, в которой эти умники насвинячили, игнорировать всё, что было после, а то вдруг там начали появляться программные ошибки, а я считаю циклы владения безусловно программными ошибками, нарушением причинности, и, может быть, в таком виде от GNUStep ещё будет какая-то польза.

Необходимость разрабатывать кроссплатформенно плюс плохое качество библиотек, обычно берущихся для этого, плюс проблемы с реализациями OpenStep на не-Windows платформах — всё это поспособствовало тому, что я надолго ушёл из фронтенда на сервера и никак не могу вернуться, кроме как заработков на Delphi VCL Windows. А хочется.
OCTAGRAM
Delphi ada В Делфи нет встроенной безопасной функции, обратной Ord, для произвольных перечисляемых типов. Чтоб, если я поделал арифметику и намылился привести тип обратно, программа не тихо проглотила ошибку, а сразу настучала, куда следует.

TestValue := TCalDayOfWeek(20);Такой оператор молча проглотил ошибку, что меня как адиста, конечно, возмущает.
TestValue := dowMonday + 20;Такой оператор не компилируется, но направление мысли было верным. Ещё немного подумав, я нашёл ближайший аналог на Делфи:
TestValue := dowMonday;
Inc(TestValue, 20);
В этом случае бросается ERangeCheckError, что и требовалось.

На Аде я бы написал TCalDayOfWeek'Val (выражение) без необходимости во временной переменной.

Но в языке Ада, наоборот, нет такого всеядного Inc, как в Делфи. Как адаисту, мне кажется, что это чаще разумно, чем нет. Если перечисляемый тип гоняется в число и обратно, пусть это всё в явном виде будет написано. А вдруг написан бред? Когда всё потенциально бредовое требуется в явном виде расписать, заметить бредовость легче.
OCTAGRAM
Delphi arc ada RAII objectiveC ARC forbids Objective-C objects in structs or unionsА Objective-C, оказывается, не так крут, как я думал. Хотя, казалось бы, какие проблемы. Везде в других местах (и в C++ тоже) такое работает.
OCTAGRAM
Delphi ada контейнеры В обоих языках появились конструкции для удобного перебора коллекций. for-in-do в Делфи и for-of-loop в языке Ада. Но в языке Ада можно и нужно возвращать ссылочный тип, и под такой перебор не нужно объявлять переменную, а в Делфи — нужно, и нужно именно затем, что оно всё будет при переборе постоянно копироваться и уничтожаться, хоть там какой развесистый record внутри. Но зато при переборе стандартного System.Generics.Collections.TDictionary в Делфи перебираем пары ключ-значение, а при переборе стандартного Ada.Containers.Hashed_Maps — только сами значения.
OCTAGRAM
Delphi ada Заметил, что новые формы вызовов событий содержат const перед Sender: TObject. Действительно, ведь так оно и должно быть при ARC. В Делфи при работе со сложными структурами итого получается 4 режима передачи параметра: «» (ничего), «const», «var», «out». Им условно соответствуют адские режимы «» (ничего), «in», «in out», «out», но «» (ничего) — это на самом деле пропущенное указание режима «in», а делфёвому «» (ничего) нет прямого аналога. Режим «» (ничего) в Делфи — это когда вызывающий передаёт параметр, а вызываемый может его по своему усмотрению поменять. Всё бы хорошо, но для счётчика ссылок это не очень здорово, в большинстве случаев лишний раз зря тревожить, а это строки, COM-интерфейсы, массивы, да много всего. И повелось перед такими параметрами ставить в Делфи «const», а в силу лени — не ставить, где не надо. Пока не было ARC, для ссылок на объекты как раз было не надо, а теперь раз, и стало надо. В старом коде во всяких TNotifyEvent этого уже не поменять, и без того совместимость поломали знатно. Только в новых сигнатурах обработчиков получается писать как правильно.
OCTAGRAM
Delphi ada Взял для разнообразия новый проект. Вот никогда не фанател от упрощённого стиля Windows 10. В Мак ОС Десять до сих пор кажется эстетичной Аква, а безальтернативная упрощёнка — это что-то мимо. Но, поди ж ты, оказывается, это востребовано. Хотят в этом стиле. А ещё хотят, чтоб в этом стиле и на Семёрке работало. Всё указывает на выбор Делфи как инструмента реализации. Они там давно (кажется, в XE2) встроили стилизацию и научились мимикрировать под элементы управления, обычно наблюдаемые только в Метро. Решающий вклад тут вносит, что со времён Делфи 2006 возобновлена раздача базовой версии на шару. Без этого приходилось постоянно иметь дело с натленной Делфи Семь, как у легальных пользователей, так и у пиратов, и нового софта не появлялось, соответственно, интересных заказов — тоже.

По этому поводу получил возможность забуриться в свежий Делфи Токио. И сравнить с Адой. Первым делом зашёл в настройки проекта посмотреть, как там дела по умолчанию со включениям проверок времени выполнения. Негусто. Всё выключено. Никак видеокодеки опять пишем или на Розеттакоде секундами меряемся. Часы моего времени на отладку дороже, поэтому всё врубил. Во всяком случае, всё, что смог, а было там только три галочки. Но совсем как в Аде писать всё равно не получилось. Не хватило ещё проверки указателя на null-nil до того, как пытаться по нему пройти. На Аде я могу забуриться внутрь сложного JSON значения, а если где-то что-то не нашлось, вылететь по известному исключению в обработчик, который ничего не сделает. В Делфи, по крайней мере, в стандартной библиотеке, если не брать мои CVariants, такая история не работает. Ну или лучше не пользоваться. «X.Values['ObjectKey'] as TJSONString» запросто может оказаться nil, и если дальше у него получить Value, то вылетает исключение Access Violation с доступом к первым байтам виртуальной памяти. Чё-т как-то не очень такое ловить. Лучше б что-то языковое бросалось ДО попытки вызвать метод через такой указатель.

Освежил воспоминания, почему @akastargazer так радовался, что в Обероне не надо так париться управлением памятью. Как адаисту со стажем, мне это было не очень понятно, что там париться, и зачем решать эти проблемы таким изуверским способом, а тут вот оно всплыло. За каждый TJSONObject и TJSONPair трясёшься, чтоб он только не утёк, если на полпути исключение вылетит. Всё огораживаешь в try-finally-FreeAndNil-end, всем значениям, которые могли бы при прочих равных быть промежуточными, даёшь имя переменной. В GNATCOLL.JSON такого страха не было, и в моих делфёвых CVariants такого страха нет. Там RAII и счётчик ссылок внутри. Но столбовой дорогой это до сих пор не стало.
OCTAGRAM
Delphi embarcadero FMSoft uniGUI UniGUI Web App Development
Присмотрел на сайте Embarcadero семинар, который мне удобен по времени. Заранее поставил отметку «Пойду».
Start Date: Jun 22 2017 at 19:00То есть, по универсальному времени это час ночи 23 июня, а по барнаульскому — 8 утра 23 июня. То есть, сейчас уже 10 минут как идёт. А куда заходить-то, алё?

На почте пусто, по ссылке пусто. У FMSoft или uniGUI каких-то Твиттеров не наблюдается как резервного средства оповещения. В официальных фейсбуке и твиттере Делфи про вебинар нет. Копец.
OCTAGRAM
Delphi ada Общая платформа исполнения приложений как последний шанс для Delphi и Ada
В обстановке, когда всякие разработчики нет-нет, да и «забудут» то про Delphi, то про Аду, Платформа — это соломинка, за которую делфистам и адаистам нужно ухватиться и держаться. Платформа предполагает целый комплекс мер по мотивации разработчиков использовать именно её, а не что-то другое. Тут и импортозамещение, и экспорт в сценарные языки программирования, более лёгкий, чем в SWIG, и многое другое, и попутно такие компоненты становятся доступны в Delphi и Ada с относительно удобным программным интерфейсом.