http://docwiki.embarcadero.com/RADStudio.....plications Вот чем мне нравится само существование Embarcadero, так это тем, что они как зеркало отражают говнистость того, что делается в Microsoft'е. То, есть, если у Microsoft всё снаружи красиво, распиарено, то опыт сторонних разработчиков высвечивает всё как есть. WinRT в теории классный, но под него сейчас нельзя делать приложения сторонними компиляторами — и вот результат, для отображения Live Tiles Embarcadero делает отдельное специальное приложение–прокси, сделанное так, как требуется Microsoft, плюс теневой сервис, и через всё это становится возможной работа нормальных, написанных не на выбранных неизменно дурным вкусом Microsoft языках, приложений. Мне, конечно, хочется всё то же для Ады, но Delphi тут как первопроходец, собирает все грабли, чтоб остальным легче идти было.

Всё же XE3 не обошёлся без новых фич в компиляторе. Теперь у любых типов (Integer, string, array of ...) можно определять хэлперы с методами. https://theroadtodelphi.wordpress.com/20.....inghelper/ http://www.deltics.co.nz/blog/?p=1207

http://crosskylix.untergrund.net/ CrossKylix - Kylix Crosscompiler for Delphi/Windows Я уже пришёл к выводу, что проще Windows эмулировать на остальных OS, чем Linux на остальных OS, но всё равно неплохо: > Of course CrossKylix isn't a real cross compiler. The only ones able to build a real cross compiler would be Borland themselves. Instead the official Kylix command line compiler is used in an emulated Linux environment. To do that, CrossKylix implements a loader for the Linux ELF binary file format. Once dcc is loaded into memory, it is executed in a debugger-like way, translating all Linux syscalls to native Win32 functions. To achieve this it wasn't needed to write a "real" Linux emulator, it was enough to emulate the memory functions and Linux syscalls needed by dcc and the shared objects it loads. > Prior versions of CrossKylix used to be based on the LINE project, which emulates Linux syscalls through the Cygwin Linux emulation layer. As Cygwin is a buggy beast, this caused quite a lot of frustration on my side, and gave CrossKylix several limitations. By rewriting the emulation engine in native Win32 code, LINE and cygwin and with them all those problems are now history.

Посмотрев разные коллекции для Delphi, решил пойти своим путём. И вот, почему: https://bitbucket.org/OCTAGRAM/delphi-cv...../wiki/Home

Интересную вещь откопал. Кажется, наконец–то то, что нужно: http://dunit.cvs.sourceforge.net/viewvc/.....ideattic=0 Не понятно, куда оно переместилось после удаления, но само наличие тестов плюс хороший дизайн API не могут не радовать. Сравнительные характеристики: Delphi 2009 Collections — не доступны до Delphi 2009, параметризуются типами (иногда недостаток), являются TObject, а не интерфейсами. ADSDL — набор нагенеренных инстанциаций DTL, но то, что нагенерено, не происходит от общего интерфейса. Например, все map — это абсолютно разные интерфейсы. Наконец, коллекции по ссылке — все интерфейсы, могут хранить интерфейсы, для базовых типов есть боксы, и ещё есть боксы для TObject, с владением и без. Интерфейсы коллекций наследуются от некоторых общих интерфейсов, в отличие от ADSDL. Кажется, теперь мне есть, куда считывать YAML

http://www.tindex.net/ Использую этот сайт как справочник, в каких именно версиях появились какие именно фичи Delphi.

http://www.thomgerdes.com/2011/12/winrt-.....files.html Один из немногочисленных пока обзоров Windows Runtime. > The first thing I noticed is that Windows is doing a lot to break the API down into Namespaces, and for the most part each metadata file describes one namespace. So my first reaction was to put the contents of each metadata file into one Delphi unit. This doesn't quite work though because of a few things: One metadata file may actually contain multiple namespaces, one namespace might be included in several metadata files, and there are circular dependancies between types in the various metadata files. Не ожидал такого дерьма от Microsoft. Это же из C++, это должно быть похоронено, алё? Один файл – один модуль, имена одинаковые. Что опять за творчество восьмидесятых? > Generic Interfaces > Generics are used pretty heavily throughout WinRT. In the C++ language bindings, they end up translating down to a template class, and the pre-compiled headers actually have to parametrize every instance of a generic class. This is pretty ugly and it'd be much nicer to just declare the interface and have the compiler do the right thing. Delphi has a similar problem for similar reasons. Generic Interfaces are supported by the compiler, but the problem arises in that you cannot specify a GUID for parametrized instances of a given generic interface. So for now, I've had to create a unique interface for every parameterized interface in WinRT. А вот про Generics в API не знал. Здесь WinRT лучше, чем IBM SOM. Однако, > But how do you go about assigning a GUID to the interfaces? The answer lies in RoGetParameterizedTypeInstanceIID. Функция эта доступна только в Windows 8, из–за этого нельзя компилировать с других OS. Кстати, не проверял, но, может быть, было бы достаточно унаследовать GUID–интерфейс от не–GUID–ного generic interface. Ну или оставить generic interface as is, а получать его через Supported(), а GUID вычислять на целевой платформе. Впрочем, компилятор следующей версии Delphi наверняка изменится в такую сторону, что эти workaround станут не нужны. Что нравилось в Delphi, так это сращивание с компонентными технологиями Windows до такой степени, что использовать их из Delphi удобнее, чем из C++ и C# от Microsoft. Это же и её минус как плохо переносимого ЯП. Я раньше думал, это Borland додумался TDateTime сделать из Double. Ан нет, это из COM пошло. Ну хоть проблема 2000 не грозит на время существования Солнечной Системы. Плохо, что WinRT доступен только в Win8. Потребуется лет восемь, чтобы на нём можно было писать для массового пользователя. Лучше бы, наоборот, в 2001м году вместо .NET был бы выпущен WinRT, входил бы в обновления OS и был бы доступен везде, а .NET, наоборот, был бы доступен не ранее какой–нибудь версии Windows.

Реализую Tiered Vector на Delphi. Давненько не занимался алгоритмами, чувствуется.

Портирую приложение с Delphi 7 на XE2. Где было ANSI, там становится Юникод, ну и естественно, где–то от такого безоговорочного перехода ничего не изменится, а где–то, особенно, во всём, что связано с сетью, однобайтовые строки должны такими и остаться. Довольно полезен при миграции модуль AnsiStrings, в котором можно найти то, что в SysUtils осталось только для UnicodeString. Но вот ведь западло: AnsiStrings.Format умеет конвертировать UnicodeString, но сыплет exception при попытке использовать в роли %s WideChar, PWideChar или WideStrings: SysUtils AnsiString: Ansi SysUtils WideString: Wide SysUtils UnicodeString: Unicode SysUtils AnsiChar: A SysUtils WideChar: W SysUtils PAnsiChar: Ansi SysUtils PWideChar: Wide AnsiStrings AnsiString: Ansi AnsiStrings WideString: Format '%s' invalid or incompatible with argument AnsiStrings UnicodeString: Unicode AnsiStrings AnsiChar: A AnsiStrings WideChar: Format '%s' invalid or incompatible with argument AnsiStrings PAnsiChar: Ansi AnsiStrings PWideChar: Format '%s' invalid or incompatible with argument

http://tutorialsto.com/view/printview-28382.html Всегда терялся в догадках, как пересобрать rtl70.bpl, если в исходниках rtl.dpk нигде не видать, а писать с нуля хлопотно, и ошибиться можно. Его, оказывается, из IDE можно сгенерить автоматом. Как и многие другие недостающие .dpk

Fatal: Required package 'rtl' not found Долгое время было не понятно, почему сборщик, который проставляет свою ревизию и ревизию проекта в RESOURCEINFO, при одинаковых и повторяемых, казалось бы условиях, вдруг перестаёт работать под предлогом того, что ни один runtime packages не может быть найден. При этом, если собрать из IDE, то проект соберётся, и сам сборщик начинает работать. И на пару недель этот полтергейст исчезает. rhash --tth --recursive на пару с diff -Nu подтвердили мою догадку: с файлами в Program Files\Delphi7 действительно что–то происходит. .dcp могут куда–то исчезать, а Delphi 7 IDE их пересобирает

Откопал DEEX, был такой синтаксический расширитель для Delphi. Идея была в том, чтобы сделать карту из строки в record, а потом, по сценарию, мы бы добавили как есть результат работы DEEX в наши проекты, а сам DEEX не использовали бы. Но даже это оказалось задачей не на пару минут, так как устроен DEEX непонятно, домашняя страница удалена, очень мало информации в Интернете. Тем не менее, он работает, и довести до конца удалось. Для того, чтобы желающим воспользоваться DEEX было проще в будущем, выложил этот проектик: https://bitbucket.org/OCTAGRAM/deex-example Пользуясь случаем, хочу обратить внимание на библиотеку Another Delphi Structures Library того же автора, которая по сути результат применения DEEX ко всем основным комбинациям контейнеров DTL и типов данных (Integer, Double, Char, String, Pointer, TObject, IUnknown), причём, в отличие от Delphi 2009 Collections, доступны как TObject–версии, так и интерфейсовые, автоматически удаляющие себя. http://sourceforge.net/projects/adsld/

https://bitbucket.org/OCTAGRAM/delphi-yaml YAML парсер уже немного работает!

https://bitbucket.org/OCTAGRAM/delphi-yaml/ Залил на BitBucket свои небольшие наработки по создании привязки к libyaml на Delphi. Пока сырое

http://rvelthuis.de/articles/articles-cobjs.html Пробую libyaml заинтерфейсить из Delphi 7. libyaml заточен под autotools. Накатал прокси для gcc, ld, ar, которые в окружении msys худо–бедно косят под одноимённые утилиты, но вызывают bcc32, ilink32 и tlib из Borland C++ 5.5 free command line tools. До конца не собралось, лень совершенствовать прокси, но дальше объектников мне всё равно не нужно. Код довольно чистый и по размерам объятный, так что кое–что удалось воплотить. Я раньше таким способом серьёзные библиотеки не линковал. Всякие aspell подключались как dll'ки, JPEG и PNGImage сделаны кем–то другим, и я в код раньше не всматривался. Для себя я только во времена Borland Pascal линковал продукт работы binobj, а также tasm, но это всё не то. Итак, я создал чистый юнит, и добавил в него $L для всех 8 .obj. Не компилируется, жалуется на unresolved externals, среди которых всякие _malloc, _realloc, _free, _strdup и прочие стандартные, которые, как выясняется, нередко дописываются прямо на Delphi так, чтобы они использовали тот же менеджер памяти, что и Delphi. Некоторые особо хардкорные вещи с varargs импортируются из msvcrt.dll. У меня всё из разных мест. Есть возможность из Delphi немного изменить реализацию. Например, в libyaml используются fread и fwrite, но ничего кроме этого с файлами не делается, и я предоставил такую реализацию, которая читает и пишет в Classes.TStream вместо FILE*. Далее, среди unresolved externals числятся также и все внутренние зависимости. То есть, если я объявляю procedure _yaml_траляля(ололо); cdecl; external;, это решает проблему. Сложно сказать, чей косяк. В C с импортами в заголовках всё тяжело. Связывание может быть статическим, динамическим, при динамическом связывании заголовок может подключаться как при компиляции собственно dll, так и при компиляции программ, её использующих, и эти три варианта использования нужно умножить на варианты компиляторов, чтобы получить многообразие ключевых слов для экспорта. autotools предоставляют для этих целей автоматически подобранные defin'ы, но libyaml их не использует, а применяет свой костылик, который не описывает мой случай. Я пытался менять хедер, но то ли я не подобрал ключевое слово, то ли в Delphi 7 так и должно быть, внутренние связи между .obj мне пришлось все объявить в паснике, который эти .obj подключает, и только тогда всё собралось. Тонкую привязку я уже почти сделал, а эти внутренние зависимости как раз неотъемлемая часть тонкой привязки. Странно, но если сделать TLIB'ом .lib, Delphi его не подключит. Только одиночные .obj. http://www.gunsmoker.ru/2009/04/proengin.....i-lib.html GunSmoker, когда подключал статическую библиотеку к Delphi, собирая динамическую, не так уж и прогадал. http://interix-wgcc.sourceforge.net/ — gcc-мимикрирующая оболочка для MSVC, довольно продвинутая. Downloads куда–то делся, но можно скачать исходники.

Classes.TBits в Delphi действительно позволяет хранить биты компактно и удобно с ними обращаться, вот только вытащить и загрузить обратно сырые байты нельзя совсем

http://stackoverflow.com/questions/47224.....-tools-api _Как добавить поддержку нового языка программирования в RAD Studio IDE?_ > Чтобы добавить language personality в IDE, вам нужно связаться с RAD Studio R&D team и получить специальное разрешение от компании на доступ к непубличным пакетам, интерфейсам и API. > > Из коробки нет способа добавить language personality в RAD Studio

DCCOSX.EXE собрал Hello World как по маслу, но на Mac OS X 10.4 он не запустился. Какая–то команда динамического загрузчика не поддерживается. Надо бы настоящий мак купить с новой OS, а то ничего нового уже не работает. Вообще, обидно, что то, что компилируется и запускается под Windows 2003ей, не работает на Mac OS X 2005го года.

Чем больше имею дело с Delphi, тем лучше вспоминаю, что мне так нравилось в Аде. Хит сезона: в Delphi файл считается принадлежащим проекту (отображается в IDE), если в dpr написано uses ... in '....pas'. IDE при этом отсчитывает путь от файла проекта, но если компилировать с командной строки, то модуль ищется относительно текущей директории, причём, search path игнорируется напрочь. Забавно, компилятор устраивает наличие .dcu в search path, но .pas ищется только относительно текущей директории. Этот GUI-CLI псевдодуализм всплывает не по отдельности, а в комплекте с ещё одним: группа проектов, созданная в IDE, по синтаксису является makefile, и, действительно, можно запустить make -B -f MyProjectGroup.bpg, и группа проектов скомпилируется, но только до тех пор, пока все проекты в той же директории, что и группа проектов. Ах, да, чуть не забыл, есть же ещё такая штука как .res файлы, которая генерится и компилируется IDE неявно и автоматически. Казалось бы, проблему можно решить, создав в явном виде .rc файлы. Проект Delphi может содержать не только .pas файлы, но и .rc файлы (.pas и .rc — это всё, что может быть в .dpr). IDE отображает .rc файлы как относящиеся к проекту, если они подключаются {$R '....res' in '....rc'}, и собирает их автоматически. Однако, dcc32 так не умеет. Совсем. На этот раз ему нужен только .res, и как–то по–простому впилить компиляцию ресурса, чтоб работало и из make, и из IDE, если открыть группу проектов, уже не получается. Заколебал этот псевдодуализм, когда IDE и консольные утилиты работают с одними и теми же форматами, но очень по–разному. Ах, да, не забыть .dof для IDE и .cfg для компилятора с этим их синхронным редактированием. А как в Аде? Есть GNAT Project с расширением .grp. GPS (GNAT Programming Studio), gnatmake и gprmake все работают с одним и тем же форматом, и ведут себя одинаково. Компилятор знает, какие модули в проекте. IDE тоже это знает, и информация поступает из одного места по одному и тому же алгоритму. А ещё вместо того, чтобы в настройках проекта пихать в search path для модулей и объектных файлов конкатенацию путей до всех зависимостей, можно из одного проекта подключить другой проект. Добавление зависимости, удаление зависимости — всё произойдёт в одном месте, и и компилятор, и IDE поймут это одинаково. В Delphi что–то похожее есть только для runtime packages.