Здравствуйте, sfsoft, Вы писали:
PO>>Не могу больше помочь, извините. Видимо Вам придется решить — оставаться на Delphi (может это и неплохой вариант), или неспеша пробовать адаптировать код под FPC/Lazarus.
S>Спасибо за помощь. Комьюнити, видимо, таки работает. Две недели назад trunc FPC и trunc Lazarus совместно не работали. LCL не подходила к FCL. Что-то сломали. Я в тот момент плюнул на это, а пару дней назад увидел тему об этом на форуме. Вчера вечером скачал оба trunk'а — и всё завелось. Пропали и те ошибки несовместимости. И мои, кстати, тоже пропали. Постараюсь не дышать на FPC, чтобы ничего не сломать
Рад, что у Вас наметился прогресс! Сделайте бэкап установленных Lazarus/FPC.
PO>>А что Delphi сейчас не умеет компилировать VCL приложение для Linux?
S>Нет. Есть проект VCL для Linux от Крюкова, но он заброшен, насколько можно судить по его баг-трекеру. Ещё есть FMXLinux. Но это FMX. Я его как-то не очень, хотя надо отдать должное, за 10 лет он сильно изменился. Плюс на FMX нужно весь GUI переписывать с нуля, конвертер умер (был такой, Mida). Ну и самое главное, из-за курса доллара и отмены Путиным постановления о двойном налогообложении все поставщики западного ПО подняли цены на 20-25% единомоментно. И сейчас Delphi для Linux стоит 488000 т.р. Что как-то овердофига.
Ого, вот это цены.
В плане Linux поддержки, Lazarus должен быть хорош (но я пока не пробовал).
Lazarus/FPC еще скоро научится компилировать под Web Assembly (альфа уже есть). Под JS уже умеет.
Еще пользуюсь скриптовым FPC — InstantFPC под macOS — пишу на нем простенькие скрипты сборки дистрибутива запускаются как батники на Windows без предварительной компиляции. Под Win/Linux тоже можно запускать.
Вообщем проект развивается. И мы можем пользоваться, никакие санкции у нас не отнимут Лазарус — в этом его большой плюс.
Здравствуйте, Черный 😈 Властелин, Вы писали:
ЧВ>6) Доустанавливаем пакеты с закладки Modules, в частости я ставлю virtualtreeview и bgrabitmap, это добавит кросс-платформенное дерево-список и работу с графикой с альфой и всякими крутыми штуками для рисования.
на этом этапе у меня компиляция модуля GLScene не проходит, удаление тоже не работает
пробуем исправить ошибку — все зависает
да, возвращаемся в пункт 2
пробуем другой пакет Graphics32, ошибка...
ЧВ>Ну и собсно все.
хотел поиграться в связке с Qt, но видимо не судьба
Здравствуйте, icezone, Вы писали:
I>Ничего не работает.
В телеграмм-канале Delphi/Lazarus автор https://delphihtmlcomponents.com тоже плачется по этому поводу. Ему пытаются объяснить, что в Linux'е всё не так, как в Windows и OS X. И если у тебя ничего не работает, то ты просто недостаточно читал мануалы/недостаточно не спал ночами/недостаточно умный/недостаточно ловкий/недостаточно умелый и так далее.
В целом соглашусь, Lazarus производит удручающее впечатление, если брать его по привычке, как Delphi, Visual Studio или Jet Brains IDE. Но если представить, что это всё писали инопланетяне для себя, то некоторые вещи начинают казаться нормальными и даже качественными В общем дорогу осилит идущий, я потихоньку перепиливаю проект на Lazarus. Глюков куча, дженерики работают как хотят. Например, если в Delphi (да и в .NET) вот такое будет работать:
procedure SendData(List: TList<TObject>);
то в Lazarus'е — фиг вам. Нужно вот так всё переписать:
type
TObjectList = TList<TObject>;
procedure SendData(List: TObjectList);
Вроде мелочь — а напрягает. И таких подводных камней там разложено, что пи...ц
В общем продолжаю грызть кактус.
А, да, ещё необычное поведение нашлось: вложенные в методы класса процедуры не имеют доступа к членам класса. Точнее компилятор это считает нормальным (и это вроде и правда нормально), а вот в runtime весело падаем со всем этим добром с AV
Здравствуйте, sfsoft, Вы писали:
S>В целом соглашусь, Lazarus производит удручающее впечатление, если брать его по привычке, как Delphi, Visual Studio или Jet Brains IDE. Но если представить, что это всё писали инопланетяне для себя, то некоторые вещи начинают казаться нормальными и даже качественными В общем дорогу осилит идущий, я потихоньку перепиливаю проект на Lazarus.
Я пробовал Lazarus как-то. И решил, что если и буду переписывать, то уже на другом языке. Может, на плюсах, плавно — подключая еще непереписанный код в виде dll. Lazarus не дал впечатления достаточной надежности для коммерческой разработки.
Здравствуйте, JustPassingBy, Вы писали:
JPB>Я пробовал Lazarus как-то. И решил, что если и буду переписывать, то уже на другом языке. Может, на плюсах, плавно — подключая еще непереписанный код в виде dll. Lazarus не дал впечатления достаточной надежности для коммерческой разработки.
Вполне норм, как ни странно. Боль — да. Страдания (даже после не сильно современной Дельфи) — в избытке. Но, сцука, работает! А IDE, кстати, кое в чем даже удобнее Дельфи. Ну и кроссплатформенность в качестве бонуса.
Есть одна тяжелая расчетная операция, связанная с большим объемом чтения из БД, обработкой этой радости, и записи обратно в БД. В Delphi это занимает, в среднем, 0.9 секунды из 100 итераций в тесте. В Lazarus со всеми оптимизациями и использованием менеджера памяти от mormot — 2 секунды. Для бесплатного инструмента, ИМХО, очень даже.
Здравствуйте, JustPassingBy, Вы писали:
JPB>И решил, что если и буду переписывать, то уже на другом языке.
Я тоже так думал до недавнего времени. Что, типа, фигня какая, переписать на Java или .net проект при необходимости. Но как только столкнулся с реальными сроками и бюджетом по переходу, протестировал разные варианты, то пришел к выводу, что или Lazarus или Firemonkey. Другие варианты не жизнеспособны в реальности при проекте, которому больше 20 лет и больше 25 мегабайт исходников (без сторонних либ).
program Project1;
{$mode delphi}uses
Generics.Collections;
procedure Proc(List : TList<TObject>);
var
o : TObject;
begin
for o in List do
WriteLn(o.ToString);
end;
begin
Proc(TList<TObject>.Create);
end.
Здравствуйте, JustPassingBy, Вы писали:
JPB>Я пробовал Lazarus как-то. И решил, что если и буду переписывать, то уже на другом языке. Может, на плюсах, плавно — подключая еще непереписанный код в виде dll. Lazarus не дал впечатления достаточной надежности для коммерческой разработки.
У меня большой старый продукт портированный с Delphi на Lazarus еще 4 года назад. В процессе перехода также сделал 64-bit и Mac версию. Все работает и быстро, багов не стало больше. Коммерческий продукт. Счастлив, что перешел на Lazarus.
Верю, что у FPC могут быть проблемы с новомодными расширениями языка Delphi, типа дженериков. Но я ими не пользуюсь. Я считаю ошибкой, что Delphi и следом FPC пытаются утяжелить избыточными языковыми возможностями.
Здравствуйте, sfsoft, Вы писали:
JPB>>И решил, что если и буду переписывать, то уже на другом языке.
S>Я тоже так думал до недавнего времени. Что, типа, фигня какая, переписать на Java или .net проект при необходимости. Но как только столкнулся с реальными сроками и бюджетом по переходу, протестировал разные варианты, то пришел к выводу, что или Lazarus или Firemonkey. Другие варианты не жизнеспособны в реальности при проекте, которому больше 20 лет и больше 25 мегабайт исходников (без сторонних либ).
В принципе, за пару-тройку месяцев можно написать конвертер сорцов из паскаля в плюсики. Задача не выглядит слишком сложной
Здравствуйте, PeterOne, Вы писали:
PO> Верю, что у FPC могут быть проблемы с новомодными расширениями языка Delphi, типа дженериков. Но я ими не пользуюсь. Я считаю ошибкой, что Delphi и следом FPC пытаются утяжелить избыточными языковыми возможностями.
Дженерики в FPC и Delphi разные. Дженерики в FPC скорее шаблоны, и значительно мощнее дельфийских. С недавних пор дженерики в FPC могут специализироваться константами (!). Вообще, в плане возможностей языка FPC уделывает Delphi.
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, sfsoft, Вы писали:
JPB>>>И решил, что если и буду переписывать, то уже на другом языке.
S>>Я тоже так думал до недавнего времени. Что, типа, фигня какая, переписать на Java или .net проект при необходимости. Но как только столкнулся с реальными сроками и бюджетом по переходу, протестировал разные варианты, то пришел к выводу, что или Lazarus или Firemonkey. Другие варианты не жизнеспособны в реальности при проекте, которому больше 20 лет и больше 25 мегабайт исходников (без сторонних либ).
П>В принципе, за пару-тройку месяцев можно написать конвертер сорцов из паскаля в плюсики. Задача не выглядит слишком сложной
Грустно будет после FPC/Delphi смотреть насколько замедлилась компиляция большого продукта после любого изменения в коде. После модулей возвращаться к убогому C++ так себе идея.
Здравствуйте, PeterOne, Вы писали:
П>>В принципе, за пару-тройку месяцев можно написать конвертер сорцов из паскаля в плюсики. Задача не выглядит слишком сложной
PO>Грустно будет после FPC/Delphi смотреть насколько замедлилась компиляция большого продукта после любого изменения в коде. После модулей возвращаться к убогому C++ так себе идея.
Ну, в принципе да, компиляция в дельфях очень шустро происходит, этого не отнять. Но после любого изменения — это не совсем так, локальные изменения в .cpp тоже быстро собираются, хотя и помедленнее. Плюс — можно PCH настроить. Плюс — в новые плюсики модули уже завозят, тут я конечно хз, насколько это ускоряет. И убогость в плюсиках рази шо в скорости компиляции, как язык он божественен. Плюс приобретается возможность интеграции с любыми либами (они всегда или сишные, или плюсовые, или плюсовые с сишным интерфейсом) без всяких ненужных приседаний. Ну, и всегда можно продолжать писать на паскале, запускать для отладки нативный паскаль, чтобы шустро, а сборку релиза (для собственно релиза и предрелизной проверки/тестирования) производить через плюсики. Плюс приобретается возможность собирать разными компиляторами под разные платформы, кучи тулзеней для проверки кода и тп.
В общем, я бы такой подход не сбрасывал со счетов, тем более, что с паскалем проблемы
Здравствуйте, sfsoft, Вы писали:
S>Я тоже так думал до недавнего времени. Что, типа, фигня какая, переписать на Java или .net проект при необходимости.
Как раз я понимаю, что даже переход на Lazarus это вообще не фигня, слишком много в проекте используется последних возможностей Delphi. Поэтому если и "валить" с паскаля, то уж насовсем. Lazarus выглядит как Delphi 7, все эти отдельные окна, что тоже как-то наводит тоску. Объективно я понимаю, что переписывать ничего не буду, лучше это время потратить на развитие.
R>program Project1;
R>{$mode delphi}
R>uses
R> Generics.Collections;
R>procedure Proc(List : TList<TObject>);
R>var
R> o : TObject;
R>begin
R> for o in List do
R> WriteLn(o.ToString);
R>end;
R>begin
R> Proc(TList<TObject>.Create);
R>end.
На простом проекте работает. А на большом в proc приезжает null
Здравствуйте, sfsoft, Вы писали:
S>На простом проекте работает. А на большом в proc приезжает null
Тут два варианта, или это баг в большом проекте (портится память например) или баг в компиляторе. Опыт подсказывает, что первое намного вероятнее второго.
Здравствуйте, JustPassingBy, Вы писали:
JPB>Тут два варианта, или это баг в большом проекте (портится память например) или баг в компиляторе. Опыт подсказывает, что первое намного вероятнее второго.
Насчёт опыта согласился бы, но я принципиально не использую арифметику указателей и прочие хаки для увеличения скорости работы. Надежность важнее. Плюс ни FastMM (в Delphi), ни heaptrc (в Lazarus) утечек памяти не находят.
Всегда, конечно, есть вероятность подобного в сторонних либах, тут всё может быть
