Зарплата устраивает. Переписывать на другом стеке это минимум 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 так удобнее сейчас. Лазарус тоже пробовал. Заказчиков на линукс версию не особо много, но точто им надо (видеокадры системы регулирования для аэс) сейчас завелось.
Ну как бы так и делали. Ездил технолог от завода на наладку и в автоматизированной режиме шил стойки. Программист занимался только драйвером для плат ввода вывода. Но это все не означает что предварительно алгоритмы не обкатали на полигоне поставщика и не сравнили очень внимательно изменения в сгенерированном коде при обновлении версии программы. Ну и вообще шьют оборудование представители поставщика а не специалисты цеха ТАИ.
Numerical Recipes
in Fortran 77
The Art of Scientific Computing
William H. Press
Harvard-Smithsonian Center for Astrophysics
Saul A. Teukolsky
Department of Physics, Cornell University
William T. Vetterling
Polaroid Corporation
Brian P. Flannery
EXXON Research and Engineering Company
Я когда-то писал для нашего программного комплекса (ПК МВТУ-3 и МВТУ-4 (SimInTech)) свой встроенный язык — что-то среднее между Pascal и Matlab, думал тогда сделать его с JIT-компиляцией, но обошёлся тогда псевдокодом, сейчас вот думаю может допилить генерацию машинного кода для скорости ибо программа активно используется во многих местах и скриптов там написано очень много. Конкретно мне было бы интересно обеспечить оптимизированную генерацию кода для исполнения в оперативной памяти для скалярных математических выражений без лишних вызовов подпрограмм как минимум на x86 архитектуре. Сам программный комплекс у нас на Delphi написан исторически. Вы не пробовали сделать на базе вашего компилятора встраиваемую скриптовую машину с компиляцией в оперативную память? Это могло бы быть интересным.
Можно. В дистрибутиве идёт шаблон кода с исполнительной средой реального времени под Linux для платформы ARM (используется сборка кросс компилятора gcc для Rapsberry Pi, проверяли на соотвествующем дистрибутиве Debian на очень похожей аппаратной платформе). Сам шаблон кода находится в папке c:\SimInTech\bin\CodeTemplates\NordWind_Linux_ARM\
Для «голого» контроллера без ОС тоже можно собрать код, используя как основу шаблон сборки изолированного приложения для ARM\Linux
В принципе можно сделать шаблон и под какие-нибудь ещё варианты встраиваемых систем, но надо учитывать их ограничения, например отсутствие\наличие FPU (для систем без оного можно за основу брать шаблон кода FixPoint_16_16_MinGW_EXE)
Штатно в составе программы идут шаблоны сборки кода для:
— сборки DLL специального формата, которые можно загрузить в саму систему для локальной верификации сгенерированного кода
— сборки отдельного приложения для Windows или Linux
— сборки ELF SO для загрузки в исполнительную систему реального времени на QNX 6.5 или Linux.
Вообще опыт разработки и внедрения системы на протяжении 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 рендером работала
Ну как бы так и делали. Ездил технолог от завода на наладку и в автоматизированной режиме шил стойки. Программист занимался только драйвером для плат ввода вывода. Но это все не означает что предварительно алгоритмы не обкатали на полигоне поставщика и не сравнили очень внимательно изменения в сгенерированном коде при обновлении версии программы. Ну и вообще шьют оборудование представители поставщика а не специалисты цеха ТАИ.
По своему опыту скажу что для Windows лучший вариент — TortoiseGIT
Для Linux — SmartGIT (он вообще на java, по идее кроссплатформенный).
Запущена только работает хуже чем исходная. Как правило просто переписывание без анализа платформы и реинжиниринга ничем хорошим не кончается.
Numerical Recipes
in Fortran 77
The Art of Scientific Computing
William H. Press
Harvard-Smithsonian Center for Astrophysics
Saul A. Teukolsky
Department of Physics, Cornell University
William T. Vetterling
Polaroid Corporation
Brian P. Flannery
EXXON Research and Engineering Company
DNS проверим на доступ из-за границы.
Для «голого» контроллера без ОС тоже можно собрать код, используя как основу шаблон сборки изолированного приложения для ARM\Linux
c:\SimInTech\bin\CodeTemplates\RaspberryPi_ARM_EXE\
В принципе можно сделать шаблон и под какие-нибудь ещё варианты встраиваемых систем, но надо учитывать их ограничения, например отсутствие\наличие FPU (для систем без оного можно за основу брать шаблон кода FixPoint_16_16_MinGW_EXE)
Штатно в составе программы идут шаблоны сборки кода для:
— сборки DLL специального формата, которые можно загрузить в саму систему для локальной верификации сгенерированного кода
— сборки отдельного приложения для Windows или Linux
— сборки ELF SO для загрузки в исполнительную систему реального времени на QNX 6.5 или Linux.