О костылях и велосипедах, неотъемлемой части современной некромантии.

Эпиграф: «Пусть это вдохновит Вас на подвиг!» (Бел Кауфман, «Вверх по лестнице, ведущей вниз»).

Это история интеграции в процесс разработки одного единственного решения. Решение доведено до конечного результата, ссылка на репозиторий будет далее по тексту.

Казалось бы, что может быть более простым и естественным, чем прозрачная, без «нелепых телодвижений», работа с размещёнными в специально выделенной для этого папке ресурсами? А если среда разработки выпущена на границе тысячелетия?

Некоторое время назад понадобилось мне в одной Delphi-шной программе много посчитать, но расчеты шли как-то подозрительно долго. Переписывать около 100 kLOC не хотелось- особенно из-за наличия большого количества форм, но предыдущий мой опыт показывал, что если код расчетов перекомпилировать в Lazarus'е (с FPC3.0.4)- то скорость счета возрастает до 2-х раз, и поэтому было очевидно, что конкретно в данном случае компилятор Embarcadero (разных версий) сильно несилен, и надо его менять. С другой стороны, IDE от Embarcadero для рисования GUI- вне конкуренции, а их компилятор на редкость быстрый (оно и понятно- быстро+плохо, или медленно+хорошо). Но ведь вкус кактуса неимоверно притягателен. Профайлинг подручными средствами (tinyprofiler) во всех случаях показывал, что основное время (90%) занимают операции векторной алгебры над большими массивами чисел, а быстрый тест производительности этих процедур показал, что на операциях с этой алгеброй общая "пропускная способность" имевшегося математического ядра составляет для операций типа умножения векторов и скалярных произведений- ~4 ГБ/с, для умножения вектора на матрицу- 1,5-2 ГБ/с, а вот для операций обращения матрицы- проседает до 360 МБ/с (на Core I5 4460 и на Xeon 2660V2, DDR3-1866). Внутре рядом с неонкой используются только 3-х и 4-х мерные вектора и матрицы. В голову пришла мысль, что 4х4 матрица- должна целиком влезать в SSE-регистры процессора и для нее SIMD- очень желательны, а в компилятор Delphi SIMD не завезли, кажется не завезут, и вообще- дальше нижней половины XMM0 не используют. В итоге нарисовалась очень простая задача- реализовать быструю векторную алгебру в минимальном объеме для 3D/4D векторов своими руками- то есть, соорудить стероидный велосипед, о котором в заголовке написано.

И вот здесь мой навык гуглинга дал сбой- мне предлагали купить проприетарные библиотеки, в которых все уже есть, или примеры векторных операций с FP32 на SSE, но нужного FP64 - нету! Под катом- как на SSE руками сделать операцию с вектором для расчетов какой-нибудь физики и вывернуть матрицу наизнанку.

Осторожно-оптимистические размышления о месте современной производственной культуры в сопровождении унаследованного из древних времён программного обеспечения. И немного о взаимопроникновении принципов SOLID.

В этой статье я бы хотел рассказать о том, что Windows проекты на Delphi возможно перевести на Linux в разумные сроки и с разумными трудозатратами. Что такое SCADA-система, рассказывать не буду, а перейду сразу к делу.

Runtime ядро SCADA работает под Windows в качестве сервиса. Функции стандартные «как у всех»: сбор, обработка, архивирование данных, передача данных в другие SCADA-системы по стандартным протоколам обмена. Визуализация только через Web. Runtime ядро SCADA написано на Delphi. Решено было адаптировать исходный код под  FreePascal/Lazarus, так чтобы код под Windows компилировался и в FreePascal и в Delphi, вторым этапом было допиливание проекта непосредственно на Linux машине и переделка его в демон. В FreePascal привлекала возможность компиляции как для x64, так и для плат Raspberry pi (архитектуры ARMv7, ARM64 (aarch64)).

Конфигуратор работает под Windows в виде графического приложения. Пока решено не переводить его на Linux, в крайнем случае можно запустить под Wine.

Теперь перейдем к Runtime и будем говорить о нём. В нём применяются разнообразные компоненты:

Добрый, предновогодний день всем! В этой статье я бы хотел рассказать, как мне пришлось вернуться в legacy-проект на паскале, причем буквально перед тем, как навсегда распрощаться и с ним, и с лазарусом, и с отсутствием темной темы из коробки.

В прошлый раз я объяснял, что не являюсь программистом по роду профессиональной деятельности, но использую любимое хобби для автоматизации всего, что попадается под руку в работе юриста. Я уверен, что 90% всей юридической волокиты может быть успешно автоматизировано: ведение разнообразных баз и карточек, составление документов по шаблонам, контроль сроков выполнения задач, использование любых вспомогательных сервисов, уже имеющих свои api, для прикручивания автоматизации на конкретном рабочем месте и т.д. К этому нужно стремиться, чтобы по заветам Айзека Азимова высвободить время юриста для реализации основной задачи - размышлять над условиями договора и разводить демагогию в суде.

Данное повествование не предназначено для разработчиков, которые не знают что такое Delphi и не умеют на нём программировать. Просьба людей, не имеющих дела с данными средствами разработки, не комментировать статью и не травмировать и без того расшатанные нервы дедушек, упорно продолжающих поддерживать многолетние разработки, написанные с применением данных средств разработки. Предложения переписать всё с нуля на что-то более модное не приветствуются.

Меня зовут Тимофеев Константин, мне 40 лет и я являюсь ведущим программистом компании 3В Сервис в подразделении, занимающемся системами автоматизации динамических расчётов (САДР).

Данная статья посвящена разбору подводных камней при портировании разрабатываемого нами программного комплекса на операционные системы семейства Linux.

В продолжении одной из тем, поднятых в публикации Александра Ершова (Ustas) «Нейросетевой визуальный поиск», предлагаю читателям Хабра погрузиться в мир концепции Н.М. Амосова, ее $$-моделей, М-сетей и автоматов. Как я надеюсь, именно они — наиболее вероятные кандидаты на роль «серебряной пули», которая позволит энтузиастам «сильного интеллекта» или, в другой терминологии, «искусственного разума» приблизиться к пониманию путей его реализации.

В данной статье автор попытался предельно сжато (конспективно) изложить основные положения концепции Николая Михайловича Амосова. Этот подход достаточно детально изложен в коллективной монографии «Автоматы и разумное поведение. Опыт моделирования», авторами которой был Н.М. Амосов и его соратники: A.M. Касаткин, Л.М. Касаткина и С.А. Талаев. Могу сказать, что это единственная монография, из всех работ по теме «искусственного разума», с которыми я смог познакомиться до сегодняшнего дня, содержащая ясное, обстоятельное, всестороннее, систематическое и в тоже время убедительное, а, в отдельных местах — даже высокохудожественное (говорю это без малейшей доли иронии) — изложение теоретических основ авторской концепции «искусственного разума», а также полученных на ее основе экспериментальных результатов.

Обращаюсь ко всем, у кого есть задор, жгучий интерес к теме «искусственного разума», а также желание поближе познакомиться с подходом Н.М. Амосова — читайте дальше...

При программировании на телефоне программ под DOS или под Windows в эмуляторах существует проблема ввода русского текста - клавиатура, которой вы только что набирали русский текст в обычных андроид программах, не будет вводить никакой текст в эмуляторы. Эмуляторы, как правило, принимают на вход только обычные англоязычные коды и код других клавиш английской раскладки. А уже поставленный в DOS русификатор или настроенная языковая панель Windows на лету превратят эти англоязычные коды в русские символы при вводе (если вы предварительно переключитесь на RU язык).

Для эмулятора нужна клавиатура, которая работала бы как англоязычная, но на кнопках у нее отображалась бы и русская раскладка тоже.

BroKB Emulz - именно такая клавиатура!

Добрый день, дорогие мастера своего дела!

private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) {                                         
        File MyFile = new File("D:\\Sample\\text.txt");
        MyFile.delete();
    }                        

Предисловие

1. Shared memory.
2. Pipes.

Приветствую всех, кто начал читать эту заметку! Хочу предложить вам (а в большей степени фанатам Object Pascal, любителям программистских трюков, технических приемов и синтаксических изысков) ознакомиться с переводом довольно старого (2007 года) поста "Hack#17: Virtual class variables, Part I" и "Hack#17: Virtual class variables, Part II" известного разработчика и автора многочисленных технических приемов, ориентированных на применение в Delphi, Халлварда Вассботна (Hallvard Vassbotn).

Сообщение Халлварда посвящено одной из интереснейших тем – возможности размещения и использования данных, связанных с конкретным классом прикладных объектов. Если вы подумали о константах или переменных класса, то вы окажетесь правы, но только частично.
Речь в этой заметке пойдет о class virtual var, по-русски это словосочетание звучит как виртуальная переменная класса (именно оно и вынесено в название данного перевода). Вы скажете, что такой синтаксической конструкции в Object Pascal’е нет, и окажетесь абсолютно правыми. Более того, я уверен, что знатоки и разработчики на других ОО-языках программирования заявят: в своей практике я не слышал, не сталкивался и не использовал ничего подобного. Как и все я «суслика не вижу…», но буду утверждать, что он может существовать. И об этом пойдет в речь в тексте предлагаемого вам перевода.

writeln('Content-type: text/html');