Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

Интеграция внешней объектной системы в Delphi на примере IBM SOM
Один из моих проектов реализует поддержку SOM в Delphi. Разработка начиналась на Delphi, пришлось часть привязок делать вручную и не так красиво, в процедурном стиле, без проверки типов. Используя эти привязки, был написан генератор привязок в объектном стиле, а затем и сам генератор был переписан на новые привязки, став подтверждением их работоспособности. Ради красоты пришлось хакнуть объектную систему Delphi, и, может быть, вам будет интересно, как это вообще можно делать.

@OCTAGRAM:
OCTAGRAM

Раздраконил свой генератор привязок до такого состояния, что уже заработала программа, использующая исключительно новые привязки. Это пример для старых привязок, а это — для новых. В старых привязках SOMObject — это указатель на запись, а все остальные классы — синонимы SOMObject, то есть, контроля типов нет. В старых привязках, чтобы узнать тип аргумента, нужно было в процедурном стиле написать ParameterDef__get_type, а вот имя аргумента объявлялось в Contained, поэтому Contained__get_name, а так как вручную мне лень синонимы везде прописывать, то только по таким именам работало. В новых привязках генератор собирает все методы класса в одну общую кучу, и всё работает достаточно очевидным образом с вызовом методов через точку. И даже атрибуты CORBA спроецировались на свойства Delphi. Поскольку в Delphi жалкое одиночное наследование, генерить список методов требуется каждый раз сначала, и именно это и делается, зато потом удобно.

Работает это посредством того хака, что создаются объекты SOM, а Delphi думает, что это объекты Delphi. Так как с точки зрения Delphi методы статические, Delphi не лезет в VMT, делает статический вызов, в нём написан код, который направит вызов в SOM, и оно там пойдёт куда надо. Ещё немного пошаманил, чтобы волшебным образом работали классовые функции. Классовые функции могут вызываться как у объектов, и тогда Delphi пытается взять из объекта VMT по нулевому смещению, а может — непосредственно у класса, и тогда берётся статический адрес VMT. Учитывая, что с точки зрения Delphi классы друг от друга не наследуются, отличить эти случаи не сложно. Нужно просто сравнить Self со своим именем, и если да, то нас вызвали через имя класса, и класс-объект нужно искать одним способом, а если нет, то нас вызвали как метод объекта, и надо ещё раз разъименовать Self, и там будет лежать указатель на класс-объект.

Немного подкрутил, чтобы в результате метода SOMObject.somGetClass учитывался метакласс. Была мысль вообще все методы метакласса спроецировать на классовые функции и процедуры, но потом посмотрел, сколько там всего в SOMClass, и решил, что не надо. Тем более, что в SOM.IR публично показан только один метакласс, SOMMSingleInstance. Но даже ради него подкрутил, чтобы у метода SOMObject.somGetClass возвращался именно указанный метакласс, а не просто SOMClass. Кстати, так получается, что с точки зрения языковой проекции метаклассы не могут так просто наследоваться. То есть, умом-то мы понимаем, что компилятор SOM гарантирует совместимость метаклассов, но вот во что это спроецировать, открытый вопрос. Если мы наследуемся от двух классов с разными метаклассами, то метакласс потомка будет заведомо принадлежать пересечению множеств потомков каждого метакласса, и что, для этого динамически создаваемого метакласса тоже создавать привязки? А там по цепочке ещё для метаклассов более высокого порядка может потребоваться автоматическое создание. Одно дело — когда движок SOM это создаёт, и другое дело — когда генерится текст. Я решил, что этого делать не нужно, а раз так, то даже, если был класс A с указанием метакласса M_A, и от него наследуется класс B, то, если B не укажет явно тот же метакласс, что и A, в его привязках будет опять обычный SOMClass.

Естественно, все методы обычного TObject не будут работать. Я эту проблему пытаюсь решить, скрывая их при помощи reintroduce в private. Только операция as портит картину. Её не спрячешь, но хотя бы заменил методами, приводящими тип вверх и вниз. Вот так, с небольшой порцией магии создаётся впечатление, что SOM в Delphi как родная. Классы, методы, свойства.

@OCTAGRAM:
OCTAGRAM

В #2807187 я выяснил, что в Delphi самое сложное — это неразрывный блок type. Все отложенные определения типов к концу блока должны случиться. Поэтому (с точки зрения, где сложнее и рискованнее) поддержка SOM начинается с Delphi, а в самом проекте SOM-Delphi — с блока type. Вот, чего удалось добиться: SOMIRTest.DumpOut.pas. Компилятору Delphi сейчас не хватает только реализации методов, но это уже совсем другое дело. Это не блок type. Пока я тут прыгал с EF на IRF, у меня тут достаточно текстовых заготовок осталось, чтоб написать методы.

Что удалось выяснить: в доках было чётко написано:
For this reason, the use of the -u compiler flag requires that all of the types mentioned in the IDL source file must be fully defined within the scope of the compilation. Warning messages from the SOM Compiler about undefined types result in actual error messages when using the -u flag.То есть, как раз то, что мне не оказалось неприемлемым в EF в купе с невозможностью обработать информацию из нескольких IDL за один проход. Однако, каким-то образом ссылки на отсутствующие классы всё же попали в SOM.IR, на той строке, куда я решёткой поставил ссылку.

Среди расширений CORBA TypeCode kind: внешние типы (tk_foreign), указатели (tk_pointer), циклические ссылки (rk_self). Удалось сделать такую эвристику, чтобы внешние типы по максимуму были определены не сами по себе, а только через указатель. Вот, например, Emitter Framework любит поработать с FILE* из VisualAge C++ RTL. Нашлись методы, которые «указательность» воплощают не через tk_pointer, а через режим аргумента in out, и заставляют алгоритм-таки объявить внешний тип явно. Там тоже немного подкрутил, в Delphi как раз есть синтаксис аргументов "var X" и "out Y" без указания типа. Из четырёх осталось два автоматом объявленных как явные указатели (somId и va_list), и так оно и есть в их случае.

Нашлись и недостатки по сравнению с EF. В EF есть комментарии, а в IRF — нет. Без комментариев уже доки не погенерить, например. Martin Iturbide, владельцу edm2.com, пригодилось бы, он у себя на wiki размещает. Ещё в EF все типы конкретно определены, а в IRF всё делается через CORBA TypeCode. Все пользовательские типы видны как объекты TypeDef, но потом, когда эти типы используются, в CORBA TypeCode видно только конечный результат с учётом всех подстановок. Сохраняются имена только у сложных типов, таких, как записи, перечисляемые и внешние типы, но они содержат не полный идентификатор, то есть, от корня, а просто имя, и его приходится эвристически разрешать, если хотим, чтобы всё было красиво, и эта эвристика, вообще говоря, заведомо менее надёжна. Таким образом, будет не лишне иметь эмиттер, работающий аналогично IR emitter, собирающий всё в одном месте, но просто побольше информации.

@OCTAGRAM:
OCTAGRAM

Откопал по наводке Vcl.Grids.StackAlloc. К сожалению, оно там только в implementation, но по мотивам можно найти и другие реализации

@OCTAGRAM:
OCTAGRAM

VisualAge C возвращает структуру CORBA Any из двух указателей в EDX:EAX, а Delphi считает, что надо через скрытый указатель действовать. Оба считают, что это stdcall.
Вообще, IBM, наверное, на все, какие только можно, грабли наступили в своём ABI:
Импорт/экспорт структур данных между DLL
cdecl varargs
Смешение cdecl и stdcall в одной библиотеке импорта для C
enum, которые внезапно оказались байтового размера
Теперь ещё структуры в результатах

@OCTAGRAM:
OCTAGRAM

SOMIRTest.DumpOut.pas
Ну вот, уже как-то повеселее пошло. Зря не начал сразу с SOM IR. Я тут подсчитал, с учётом крюка через Emitter Framework я вручную написал привязки для почти половины классов (37/75). Классы Emitter Framework чем-то похожи на Interface Repository. И там, и там есть модули (пространства имён), интерфейсы (классы), операции (методы), typedef, но в Interface Repository типы кодируются CORBA TypeCode с нехитрым сишным API, а в Emitter Framework под каждый struct, enum и sequence — отдельный класс. Пока нет генератора, привязывать классы получается дольше.

@OCTAGRAM:
OCTAGRAM

«Поддержка» четырёхбайтовых строк в Delphi реализована посредством объявления type UCS4Char = type LongWord; и type UCS4String = array of UCS4Char;
…а также функций для конвертации между WideString и UCS4String, а в юникодных Delphi — также между UnicodeString и UCS4String. Поскольку UCS4Char — это не символ, а замаскированное число, в теле программы такие литералы так просто не попишешь. Хотя, конечно, можно приводить тип постоянно. UCS4String — это вообще не строка, а динамический массив, и плюс на нём не сработает. Также для массивов не работает COW. Для строк Delphi автоматически добавляет в конец нулевые байты в нужном количестве на случай, если эту строку захотят послать в ущербные сишные API, вот она как раз бы и подошла сразу, а для динамического массива беззнаковых чисел такого делаться не будет, поэтому это делают функции конвертации. Соответственно, Length вернёт либо 0 для пустой строки, либо длину, на 1 большую настоящей длины. Так что даже если вдруг для динамических массивов заработает плюс, он будет косячить. В array of const и Variant, я так понимаю, UCS4String тоже просто так не влезет.

Но больше всего у меня горит от того, что в неюникодных Delphi функции конвертации поддерживают только BMP. Семёрка, похоже, если и сдохнет, то только со всеми Delphi вообще. Embarcadero так и не приложили усилий, чтобы это могло быть иначе.

@OCTAGRAM:
OCTAGRAM

Забубенил себе на форуме новую шапку. Для БлэкБокса чёт не смог найти вменяемого качества картинку

@OCTAGRAM:
OCTAGRAM

im_kos форкнул репозиторий OCTAGRAM/delphi-yaml под именем im_kos/delphi-yaml
im_kos форкнул репозиторий OCTAGRAM/delphi-cvariants под именем im_kos/delphi-cvariants
Связался по QQ китаец, помог пофиксить старые баги. Теперь форкнул. Таки пригодилось кому–то.

@OCTAGRAM:
OCTAGRAM

Поделал веб–сервер на 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.

@unfalse:
unfalse

Сергей Терлецкий, менеджер по работе с образовательными учреждениями в компании Embarcadero.
Наша компания постоянно мониторит рынок и опрашивает профессиональных разработчиков, чтобы развивать наши продукты в востребованных направлениях. Будущий тренд – это связь облачных технологий, мобильных приложений и интернет вещей. Особенно будет востребована кроссплатформенная разработка и создание связанных приложений. Попробуйте RAD Studio XE7.

Конечно, что же ещё ему советовать? tproger.ru

@OCTAGRAM:
OCTAGRAM

Что значит выпуск Юбилейного обновления Windows 10 для разработчиков

@CaufMAN:
CaufMAN

А там вон Лазарь новую версию запел зил
habrahabr.ru

кстати, %username%, а ты пользовал когда-нибудь fpc/lazarus для чего-нибудь? для чего?

@OCTAGRAM:
OCTAGRAM

Тут в LinkedIn хвастаются, что Delphi Seattle продано 1,3 миллионов. Удивительно, как с их системой лицензирования так мало пиратят

@den-po:
den-po

delphimaster.ru

@OCTAGRAM:
OCTAGRAM

Using Object Pascal or RIDL Syntax
Наткнулся как–то на сравнение синтаксисов IDL в Delphi, но не смог докопаться, а как работать с паскалевским–то, ведь Delphi моего патриотизма не оценила и показывала только RIDL. Оказывается, даже в XE2 его нету, в документации к Seattle, наверное, забыли убрать, зато в древней Delphi 2007 можно зайти в Tools » Options » Environment Options » Delphi Options » Type Library, переключить Language в Pascal, после этого обычным File » Open… открыть .tlb и переключиться на вкладку Text.

Понадобилось поизучать одну библиотечку без документации, ибо эта библиотечка может потенциально помочь мне поддерживать бинарные форматы, в которых ВУЗы обязаны посылать сведения в РосОбрНадзор. А библиотечка муторная, и в синтаксисе IDL у меня глаза начинают вытекать, вот я и вернулся к этому вопросу и–таки получил её в паскале–подобном синтаксисе.

Можно посмотреть здесь: 1, 2

С документацией на формат XML дела тоже не заладились. Когда–то документацию можно было скачать с сайта госконторы, которая этот формат и делала, а сейчас на её сайте какая–то хрень, и ничего не найти. И на сайте, куда переехал программный пакет GosInsp, тоже не видать.

@OCTAGRAM:
OCTAGRAM

Выполнил не так давно проект на Ada, теперь на Delphi пишу. Вот что чувствуется, так это то, что в Delphi тоже есть раннее объявление типов, но полностью объявлен тип должен быть в том же блоке type. Нельзя разорвать этот блок константами или процедурами. Приходится всё перетасовывать.
В Ada каждое объявление типа, подтипа, переменной или константы — отдельный элемент, там просто разрывать нечего.

@OCTAGRAM:
OCTAGRAM

I’ve Got a Great Ide(r)a – Let’s Buy Embarcadero!

Очередная перекупка Delphi очередной доселе неизвестной, но внезапно, оказывается, достаточно состоятельной для этого фирмой.

@OCTAGRAM:
OCTAGRAM

Project Centennial: Converting your Normal Windows App (Ada, Delphi, SOM) to a Metro Windows App for Distribution in the Windows Store
В Microsoft наконец зачесались, а чёй–то так мало приложений под Metro, наверное, средства разработки были трешовые, значит, надо дать возможность нормальными средствами разработки делать приложения для Metro

@OCTAGRAM:
OCTAGRAM

Тестируем IAccessible2, задачка — узнать, какое слово сейчас под курсором, например, в Firefox. На Windows 2003 реализация пашет замечательно, на Windows 7, как передаёт заказчик, тоже, а вот на Windows 10 нифига. Service provider у client area окна Firefox (IceDragon в моём случае) не хочет отдавать IAccessible2 интерфейс. И объект, возвращаемый AccessibleObjectFromPoint, тоже не приводится к интерфейсу IAccessible2.
Я грешу на то, что, наверное, uiAccess нужно включить и подпись цифровую сделать. Пожалел, что своевременно не озаботился попросить ключик для цифровой подписи для open source разработчиков, так бы быстро проверил.

@OCTAGRAM:
OCTAGRAM

Немного про странноватых менеджеров, которые хотят переписать на C++
A new project manager at my company asserts that Delphi can not be used in an FDA approved medical device. Has anyone heard of such a thing; do you have an contra evidence ? He assert the same for Windows Embedded, Linux and C++ is what it must be.
I don't think he has a basis, other than C++ programmer's distain and disrespect for Delphi plus the desire to do things the way he has done in the past. The Devices are Class 1, with no chance of patient harm. Problem is we have a large code base, developed over 15 years, that according to the project manager must be ported to C++ (at the risk of breaking the bank).
Your comments that "never been raised as an issue" is what I have heard from others, regulators don't care what language the software is written in.
Thanks for your comments; I'm not sure if I will continue to fight the anti-Delphi biases.

Matt, thanks for your testimonial. I'll add it to my bucket of evidence.
The 2nd reason my PM says we MUST port to C++ is the difficulty of finding Delphi programmers. There is a grain of truth perhaps to that, but I don't think it should be elevated to a reason to risk the company by undertaking a costly port to C++.

The argument about C++ programmers being more prevalent may be valid (there are other threads that discuss this), but if for the sake of argument we assume that it's true, then his argument is about the tradeoff for the perceived safety of a larger body of programmers at a cost of longer development and debug times. It also harkens back to the old saying (pre-PC days) "No one ever got fired for buying IBM". Your manager may be a CYA type. So it goes.
The previous product suffered a rewrite into C++ and never came back to life, and still sits in a pile on the floor. One would think people would not repeat the same mistake, but that CEO and PM were fired because of the failure and the new ones have big egos and don't want to hear about history. Go Figure.

@OCTAGRAM:
OCTAGRAM

bitbucket.org

Году так в 2009м исходя из той картины мира, которой я тогда руководствовался, я считал, что на языке Ада будет здорово писать, если будет полное WinAPI, чтоб и ACL поманипулировать, и оконными сессиями, и в пространство объектов NT забраться можно было. Win32Ada оставляли желать лучшего по охвату современного API. Делать я это намеревался не через сишные заголовки, в которых часть метаинформации безнадёжно потеряна, а вкрутив мозги джедаям. То есть, есть группа JEDI, которая делает неплохие привязки, но вот одна проблема, они это делают для Delphi, а не для Ada. Так как языки похожи, неплохо бы одно в другое сконвертировать, причём, по возможности, автоматом, и не AST в AST, а текст в текст.

Поначалу я пытался наладить конвертацию на препроцессоре GEMA, даже получилось, но это было явно больше, чем на что был расчитан GEMA, да и писать тяжело. Чем более зрелую реализацию пытаешься сделать, тем в большее количество ограничений упираешься. Для тех, кто не знает, там какое–то продвинутое программирование начинает становиться похожим на продвинутое программирование в bash. То есть, мы не можем сделать переменную x ассоциативным массивом, зато можем понаплодить переменных x[*], и работать дальше как будто у нас есть ассоциативный массив.

Решил поискать альтернативу. Смотрел в сторону GPP. Смотрел в сторону Refal. Как остановился на Icon, уже точно и не помню. Примерные соображения таковы, что когда–то раньше мне было интересно, чтобы «for а := 1 to 3 do B;» было не единым узлом синтаксического дерева, а чтоб 1 to 3 сам по себе что–то значил, присваивание было бы таким же присваиванием, как и в других местах, и for мог перебирать не только это, но и другие выражения, и как–то так получилось, что такой язык действительно есть, и так как он по описанию хорошо подходит для обработки текста, и в нём есть backtracking, его и решил взять. Так я и начал писать на Icon. Начало не из лёгких. Одно дело переписать что–нибудь с одного императивного языка на другой (а на Icon можно писать в императивном стиле). Другое дело — нужно было переписать шаблоны. На GEMA уже кое–что было написано, упирающееся в ограничения GEMA, надо было разобраться в Icon и переписать на него. Долго мучился, пока не начал думать «в две стороны». В Icon каждое выражение — это генератор, и функции — это тоже генератор, и особенно важно научиться писать функции, которые не обычные функции, как в императивном языке программирования, а пробуют распознать текст по шаблону и переписать в другой текст, и сами при этом такие же, как они, преобразователи для своей работы используют. Чтобы их писать, надо думать в две стороны: что случится, если выполнение идёт вперёд, и что случится, если начнётся откат.

Переписал. И пошёл дальше этим путём, насколько смог. Времена у меня были не из лёгких, 2005-2010 года самые паршивые в жизни получились, да и сейчас до сих пор не сахар. Довёл до такого состояния:

bitbucket.org
bitbucket.org

У меня на сайте написано:
Хочу как вот этот парень (Л. Поттеринг), и есть идеи, чем бы я мог заняться, а получается так, что мой поезд жизни едет и едет по своим рельсам, а мне только и остаётся, что жадно смотреть в окно.
Это как раз тот случай. «Посмотрел в окно» — и дальше по своим рельсам. Специальность у меня приборостроитель, диплом придётся на левую тему делать, совместить образование с учёбой в очередной раз не получается. Сейчас бы я, впрочем, за кое–что другое взялся.

Когда я пишу про то, чтобы взять Cocoa и GNUStep и сделать мост в SOM, а потом, может быть, и сам GNUStep переделать, это для меня выглядит вполне посильно. Есть BridgeSupport XML, есть опыт преобразования текст=>текст (в том числе #1435793). Самые разые способы достигать этих целей.

@OCTAGRAM:
OCTAGRAM

Есть в Delphi и Ada приятная плюшка, собирать несколько пакетов в динамические библиотеки для совместного использования (.bpl в Delphi). Приятно это тем, что всё прозрачно. Вчера собирал всё статически, завтра решил, что вот этот, этот и вот этот пакеты должны быть отдельно в другой динамической библиотеке, и это вынесение происходит без лишних изменений кода. Не приходится вставлять макросы типа «если объект динамической компоновки в этом проходе такой–то, то экспортируем эту функцию, иначе импортируем её». Но вот есть ещё SOM, который решает проблему хрупкого базового класса и другие аналогичные проблемы, которые возникают хоть в C++ библиотеках, хоть в .bpl, они в этом плане не отличаются. Если делать SOM эмиттеры для Delphi и Ada, лучше с самого начала предусмотреть ситуацию, когда .bpl и SOM .dll применяются одновременно, так как хрупкость .bpl может нивелировать преимущества SOM. То есть, допустим, реализован у нас какой–то SOM класс в каком–то юните, который попал в какой–то .bpl и оттуда переэкспортируется в .dll, откуда может быть использован SOM потребителями. А юниты, соседствующие с юнитом SOM класса внутри .bpl, конечно, будут искать структуры ClassData не через .dll, а обращаться напрямую в юнит. Кроме того, так могут поступать и юниты из соседних .bpl. И тут может быть такая проблема, что интерфейс SOM класса мы поменяли, и SOM это изменение поддерживает, вот только интерфейс .bpl изменился, и это изменение может сломать весь код, который ходил в структуры ClassData через .bpl в обход SOM. С другой стороны, если попытаться это исправить наивным способом, то даже .bpl будет ходить в свой собственный класс через .dll, что не должно происходить. Пока я решение вижу в том, чтобы отрезать все меж–.bpl'ные связи между компонентами, которые собираются независимо. То есть, если у нас скрипт собирает 3 .bpl синхронно, между ними связь разрешена, иначе нужно ходить через .dll. Теперь надо подумать, как это лучше сделать. В реализации CORBA для Delphi, например, делается три разных юнита с разными суффиксами для каждого класса, один для импорта, второй для экспорта, и ещё третий для чего–то. Но CORBA клиент и сервер обычно живут в разных процессах, а SOM — это внутрипроцессная CORBA. В моём случае юнитов, импортирующих одно и то же, будет столько же, сколько и независимо собираемых компонентов. Вплоть до того, что у каждого, получается, должно быть своё видение SOM API. Либо будет NoBPL версия, которую нельзя заворачивать в .bpl, а для .bpl нужно автоматизировать клонирование импортирующих юнитов в другое пространство имён. То есть из SOM.pas делается Baz.SOM.pas, из SOM.ClassManager.pas делается Baz.SOM.ClassManager.pas, и uses у них внутри переписываются. Либо надо посмотреть, можно ли включить юнит внутрь .bpl, но чтоб он наружу не светился, тогда этого делать не придётся. У всех независимо собираемых компонент будет свой взгляд на мир за счёт статического включения импортирующих юнитов, но не придётся называть эти юниты по–разному.

@GovnoMor:
GovnoMor

если кому-то надо, могу поделиться ссылкой в личку на варезный форум, куда выкладываются наипиздатейшие дорогие VCL-компоненты для delphi, взломанные или в исходниках. А если не надо, то идите нахуй, традиционно.

@OCTAGRAM:
OCTAGRAM

bitbucket.org
Прокушев раззадорил, решил тоже хоть куда–нибудь продвинуться. Почитал SOM Technical Overview, страница 151, выполнил newemit, переделал полученный C код в Delphi, собрал emitdelphi.dll, и вроде бы оно даже не падает, как это обычно бывает, если перепутать уровень косвенности или ещё что–нибудь. Ничего особенного при этом пока не делается, сам код весь заглушечный, просто дампит в выходной файл всё, что через него проходит.

@OCTAGRAM:
OCTAGRAM

Типичный Borland. Пока не пнёшь, не полетит. Вот Microsoft выписал живительный пинок, ограничив COM строки юникодом, только так и появились WideString. Что бы Borland делал без такого пинка?

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

docwiki.embarcadero.com

You might consider using the {$IFDEF AUTOREFCOUNT} directive in order to have the best code for both scenarios: ARC and traditional. AUTOREFCOUNT defines code that uses automatic reference counting, such as code for the Delphi mobile compilers. This is an important directive, different from {$IFDEF NEXTGEN} (the directive that defines the new language features of the mobile compilers). AUTOREFCOUNT might be useful in the future, in case ARC is implemented on top of the Delphi desktop compilers as well.
Как тут не вспомнить пропагандистский миф
Земля наша велика и обильна, а порядка в ней нет: придите княжить и володеть нами.
IBM, ну зачем ты сдох? Кто же теперь отвесит пендель, чтоб ещё была хорошая объектная система? Они ж ведь, бедные, сами не догадаются, а от догадок юзеров будут как обычно отводить глаза.

@OCTAGRAM:
OCTAGRAM

bitbucket.org
Делал привязки к IBM SOMObjects DTK 3.0 for WinNT на делфях. Во–первых, с целью ознакомления с SOM, потому что OS/2 или Mac OS Classic я ставить не буду, и каких–то других простых способов пощупать SOM мне неизвестно, а, читая документацию, я не получаю ответа на все вопросы. Остаётся чувство магии, будто бы всё, что я не понимаю, как работает, работает, как по волшебству. Так не должно быть. Ну и, кроме того, я бы хотел начинать дружить нативные языки программирования с Delphi и Ada.

Дописался до того, что вручную сделал привязки для Emitter Framework. Этого достаточно, чтобы начать писать эмиттер, то есть, плагин для SOM Compiler. SOM Compiler читает .idl файлы, создаёт структуру в оперативной памяти и передаёт её выбранному плагину, который может делать что угодно, сгенерить файлы, обновить базу данных Interface Repository, сделать какие–то проверки. В моём случае, конечно, нужно сделать генератор сорцов для Delphi, который бы позволил изпользовать и реализовывать SOM классы в Delphi. Я в курсе про существование эмиттера для полуосного фрипаскаля, но, во–первых, в OS/2 SOM 2.1, а я ориентируюсь на SOM 3.0 (а в будущем — на somFree), во–вторых, сам Free Pascal не вызывает доверия своей историей развития, в–третьих, для моих целей мне нужно идеальное понимание, как устроен SOM, и для этого мне нужно полностью пройти эту дорогу.

Вот, например, до того, как я вообще начал писать привязки, я не знал, что в SOM можно сделать опережающее объявление, и до конца компиляции это объявление так и не наступит. То есть, вот есть у SOMClassMgr метод, возвращающий объект типа Repository, а что это за Repository, информации может так и не появиться. Наследник SOMObject — вот максимум информации, которая про него есть. Так как это в самом ядре SOM, emitter должен будет поддерживать такие приколы. Разобравшись с хитросплетением макросов, которыми вызываются методы в привязках для C и C++, я начал понимать, как они устроены. Объект в SOM устроен, в принципе, похожим на объекты в Ada, Delphi и C++, способом, с той разницей, что проблема хрупкого базового класса устранена тем, что пользователи объекта сами не знают, по какому смещению в VMT нужный метод. Зато они знают, где найти сгенеренный в runtime thunk, который знает. По какому смещению каждый класс может найти свои данные в экземпляре, тоже никто, кроме runtime, не знает, для этого тоже есть thunk. Кроме того, что в thunk есть прыжок, я так понял, там по определённым смещениям есть ещё служебная информация или прыжки, которые нужны, чтобы классам–наследникам вызывать метод n-го родителя. Так, по крайней мере, на платформах, поддерживающих динамическую генерацию кода. Там, где это не поддерживается, например, на iPhone, макросы будут разворачиваться так, что все вызовы методов пойдут через somResolve(), подобно тому, как это в Objective-C.

@egoistmax:
egoistmax

Жуйк, а как нынче дела у этого ЯП? Везде только и слышно java, c++, питон, С# и т.д., а про delphi ващпе тишина. На нем вообще еще пишут где-то кроме ВУЗов или как?

@Ta2i4:
Ta2i4

В Delphi (нынче от Embarcadero), ЕМНИП, начиная с XE3, реализована поддержка sqlite. Попробовал поработать с sqlite3 в Delphi XE4. Не ожидал, что придется делать костыли.

Подцепиться к sqlite можно через dbExpress. Но сама dbExpress реализована так ограниченно, что:
1. Для вывода данных в TDBGrid необходимо организовать следующую цепочку: TSQLConnection -> TSQLDataSet -> TSQLDataSetProvider -> TClientDataSet -> TDataSource -> TDBGrid.
2. Данные, выводимые в TDBGrid путем, описанным в п.1, можно отредактировать и пополнить, но лишь виртуально — на диск изменения не сохраняются.
3. Из-за п.2 необходимо самому писать sql-запрос с insert'ом и запускать его через TSQLConnection. А потом, чтобы вывести обновленную табличку в TDBGrid, необходимо что-то делать с TClientDataSet, так как он еще хранит старые неотредактированные данные (я как быдлокодер сделал на TClientDataSet просто Close и затем Open).

Возможно, я где-то ошибаюсь, но пока набыдлокодил только так.

@RA:
RA

На выходных столкнулся с софтиной на Delphi. Конечно с BDE. Плохо то, что стандартные компоненты отображения данных выглядят просто хуже некуда. Вместо того, чтобы как-то оформить учетную запись человека, просто выводят разлинееную табличку со столбцами с строками. Но самое плохое, что разработчик не понимает что можно сделать иначе. Эти таблички они везде.

@NokitaKaze:
NokitaKaze

СИНТАКС ЗАБЫЛ, ИДЕ СТРАШНАЯ, ФОЛДИНГА НЕТ, НОРМАЛЬНОЙ ПОДСВЕТКИ НЕТ, ОПТИМИЗАЦИИ КОДА НЕТ, ПРИЛОЖЕНИЕ ВЕСИТ ОВЕР 200 КБ.

Никита Ветров не писал на Делфи более двух лет

@Ta2i4:
Ta2i4

В Delphi XE5 появится возможность разработки софта под Android: webdelphi.ru
Записаться на бета-тест Delphi Android: forms.embarcadero.com

PS. Не факт, конечно, что попаду на бета-тест, но записался :)

@memiury:
memiury

webdelphi.ru
cyberforum.ru

@Ta2i4:
Ta2i4

От нечего делать решил посмотреть, как в Delphi работать с либой Bass (от un4seen.com), с которой работает, например, тот же AIMP.

@murrrf:
murrrf

Неужели и впрямь все так плохо?.. Вчера перед сном перевел в паблик свое резюме на джоб.ру и хэдхантере. Уже получил три письма и два звонка — всем нужен квалифицированный программист на Delphi. Куда все делись-то?..

@Radjah:
Radjah

Чем больше я пилю свой извлекатор данных, тем больше он похож на сраное говно. Походу грядет момент перепила всего интерфейса, а может даже придется на несколько окон разбить.

@Ta2i4:
Ta2i4

Обновился FPC до 2.6.2: goo.gl

@Ta2i4:
Ta2i4

В пятницу останусь на три дня дома один. Займусь портированием одного небольшого проектика с delphi на lazarus. Свободного времени будет много.

@Ta2i4:
Ta2i4

Думаете, что Delphi умерла? Фиг там! Ей 18 лет исполнилось: habrahabr.ru
А вот ключевые изменения за последние 8 релизов: blogs.embarcadero.com

@unfalse:
unfalse

Возрадуйтесь, декабр^Wдельфисты, конференция Delphi Developer Days скоро! softwarepeople.ru