У LabView своя ниша, у нас своя которая с ними пересекается лишь частично. Основное назначение нашего пакета — создание комплексных моделей динамики энергетических установок, включая также и разработку моделей теплогидравлических сетей.
Объективно да — в Delphi работать мне лично удобнее. Поэтому и делал общую кодовую базу — чтобы при изменении в под Delphi автоматом они были в Linux-версии. То есть сейчас если я исправляю что-то в коде — сначала делаю в Delphi, потом после изменений проверяю собираемость и работу под Linux — жму кнопку пересобрать проект там и проверяю так ли оно работает как и в Windows.
При портировании дефайны в основном идут в заголовках и системно-зависимом кода (например при работе с COM-объектами, для некоторых вещей аналогов в линуксе просто нет, например OPC DA). В невизуальном коде расчётных библиотек их мало. Заказчиков на линукс-версию действительно не особо много, но они есть и хотят попробовать. При таком варианте портирования как я делал фактически VCL код старый неизменен и программа дописывается в текущем режиме без разрывов. TMX компоненты мы не использовали, использовали некоторые из JVCL, так что в чём-то было проще. Я за лазарь не агитирую, но по крайней мере что-то сделать работающее получилось. Я не считал подробно сколько у меня строк именно моего кода, но модулей более 900. Трудоёмкость например нашего проекта при частичном переписывании на Java составила 3 года * 3 человека и результат по качеству так себе на выходе был — работало хуже, это без меня делали другие люди. Вообще тут в принципе основное это то, что при портировании оказалось, что можно архитектуру сохранить и использованные технические приёмы разделения программы на части.
Пожалуйста! Пользуйтесь. Возможно я ещё выложу некоторые материалы и исходники наработанные по этому вопросу позже. Из этой статьи приложение было убрано, т.к. кода много.
Для домашнего использования мы бесплатно ключ выписывает. Для мелких задач тоже — делаете заявку и мне в почту кидаете или на официальную. Если бы с нуля делал именно сейчас для gui наверное был бы qt. Но не факт, потому что них коммерческая политика лицензирования не особо дешёвая, да и говорят переход с версии на версию небезударный. Я знаю точно что я бы НЕ использовал — java. На прошлой работе часть моей системы на неё переписали и вышло сильно хуже исходной версии на delphi, да ещё и jni вызовы не быстрые…
Нет. Исходники у меня сейчас одни на всё. 2 файла форм пришлось откорректировать руками после конвертации (замена компонентов), но они редко меняются и это не трудоемко.
Зарплата устраивает. Переписывать на другом стеке это минимум 5 лет работы и долботни будет больше намного, да и текущие средства разработки под наши задачи устраивают. Необходимо обеспечивать совместимость проектов между версиями по и непрерывную поддержку. Программа достаточно сложная и писалась не один год, а главное она вполне боевая и продаваемая.
А их мало которые различаются. Честно говоря тупо лень было и так быстрее получилось. Проблемы основные были с выбором библиотеки 2д графики под линукс и забавными приколами с памятью и многопоточностью.
Вопрос мегаспорный. Это скорее выбор инструмента под задачу и под человека. По сути если писать подобный нашему софт с требованиями скорости работы, кроссплатформенности и нативной интеграции с некоторыми внешними библиотека и на фортрана то выбор невелик — c++ и qt и как не странно Free Pascal с реализацией некоторых критических мест на си. На одной из прошлых моих работ мою систему 3 года переписывали на java и на редкость криво это сделали, хотя я им qt тогда советовал, на что мне ответили что сложно типа на qt. С другой стороны я знаю программы на qt которые разработчики не могут на линукс перетащить почему-то таким же образом. По поводу выбора инструментов под задачи разработки сапр вообще можно подискутировать.
Ну статью могу послать. Если подскажете куда именно. Изменений то в компонентах только в tee chart pro за который фирма 500 баксов заплатила. А разработчикам лазарус эти особенности недурно было бы в справку внести.
Долго они её модерировали только. Сейчас сидим на 10.3.3. Возможно обновимся. Программа не очень простая. Fmx не охота было пользовать, написано было много. А так вроде заработало все с не особо большими корректировками.
Линуксовая версия живёт в виртуалка, большие проекты тяжело сравнить. Небольшие примерно процентов на 20 медленнее но не все. В виндовой версии используется обсчет графики в отдельных потоках, поэтому если ядер много то лучше работает. Gtk так не умеет. Под винду используем delphi 10.3.3 так удобнее сейчас. Лазарус тоже пробовал. Заказчиков на линукс версию не особо много, но точто им надо (видеокадры системы регулирования для аэс) сейчас завелось.
Ну как бы так и делали. Ездил технолог от завода на наладку и в автоматизированной режиме шил стойки. Программист занимался только драйвером для плат ввода вывода. Но это все не означает что предварительно алгоритмы не обкатали на полигоне поставщика и не сравнили очень внимательно изменения в сгенерированном коде при обновлении версии программы. Ну и вообще шьют оборудование представители поставщика а не специалисты цеха ТАИ.
Если вы хотите её помучать пишите в личку или почту.
Для домашнего использования мы бесплатно ключ выписывает. Для мелких задач тоже — делаете заявку и мне в почту кидаете или на официальную. Если бы с нуля делал именно сейчас для gui наверное был бы qt. Но не факт, потому что них коммерческая политика лицензирования не особо дешёвая, да и говорят переход с версии на версию небезударный. Я знаю точно что я бы НЕ использовал — java. На прошлой работе часть моей системы на неё переписали и вышло сильно хуже исходной версии на delphi, да ещё и jni вызовы не быстрые…
Нет. Исходники у меня сейчас одни на всё. 2 файла форм пришлось откорректировать руками после конвертации (замена компонентов), но они редко меняются и это не трудоемко.
Вообще опыт разработки и внедрения системы на протяжении 17 лет сам по себе интересен.
У меня все несколько сложнее — требуется полная совместимость, ну и объем исходников большой.
Зарплата устраивает. Переписывать на другом стеке это минимум 5 лет работы и долботни будет больше намного, да и текущие средства разработки под наши задачи устраивают. Необходимо обеспечивать совместимость проектов между версиями по и непрерывную поддержку. Программа достаточно сложная и писалась не один год, а главное она вполне боевая и продаваемая.
А их мало которые различаются. Честно говоря тупо лень было и так быстрее получилось. Проблемы основные были с выбором библиотеки 2д графики под линукс и забавными приколами с памятью и многопоточностью.
У меня delphi 10.3.3 не вылетает вроде. Code typhon может но редко крайне и это чаще происходило из за заваливания вообще всей операционки сначала.
Вопрос мегаспорный. Это скорее выбор инструмента под задачу и под человека. По сути если писать подобный нашему софт с требованиями скорости работы, кроссплатформенности и нативной интеграции с некоторыми внешними библиотека и на фортрана то выбор невелик — c++ и qt и как не странно Free Pascal с реализацией некоторых критических мест на си. На одной из прошлых моих работ мою систему 3 года переписывали на java и на редкость криво это сделали, хотя я им qt тогда советовал, на что мне ответили что сложно типа на qt. С другой стороны я знаю программы на qt которые разработчики не могут на линукс перетащить почему-то таким же образом. По поводу выбора инструментов под задачи разработки сапр вообще можно подискутировать.
Ну статью могу послать. Если подскажете куда именно. Изменений то в компонентах только в tee chart pro за который фирма 500 баксов заплатила. А разработчикам лазарус эти особенности недурно было бы в справку внести.
В линуксе что надо сделать описано.
Легко. Делаете модуль с формой и в винде он работает. Чтобы окна были в той же группе что и главное application.handle := тоже самое в головном модуле
Долго они её модерировали только. Сейчас сидим на 10.3.3. Возможно обновимся. Программа не очень простая. Fmx не охота было пользовать, написано было много. А так вроде заработало все с не особо большими корректировками.
Линуксовая версия живёт в виртуалка, большие проекты тяжело сравнить. Небольшие примерно процентов на 20 медленнее но не все. В виндовой версии используется обсчет графики в отдельных потоках, поэтому если ядер много то лучше работает. Gtk так не умеет. Под винду используем delphi 10.3.3 так удобнее сейчас. Лазарус тоже пробовал. Заказчиков на линукс версию не особо много, но точто им надо (видеокадры системы регулирования для аэс) сейчас завелось.
Тестировали. Медленнее и не держало direct2d версию. Старая с gdi рендером работала
Ну как бы так и делали. Ездил технолог от завода на наладку и в автоматизированной режиме шил стойки. Программист занимался только драйвером для плат ввода вывода. Но это все не означает что предварительно алгоритмы не обкатали на полигоне поставщика и не сравнили очень внимательно изменения в сгенерированном коде при обновлении версии программы. Ну и вообще шьют оборудование представители поставщика а не специалисты цеха ТАИ.