Имеются в виду packages, ну как в Delphi.
думаю, многим это интересно узнать.
Когда появятся пакеты?
Модератор: Модераторы
GrayEddy, по большому счёту, большой ли в них смысл? Один из проектов, которыми я занимался, был полностью построен на bpl-пакетах. Т.е. в проекте было системное ядро, которое использовалось везде и набор функционала, который опционально добавлялся, если в этом была необходимость. Ядро и весь остальной функционал были оформлены в виде bpl. Когда у меня зародилась идея перенести проект на Windows CE, я стал анализировать, какую среду разработки для этого выбрать. Одним из критериев выбора, была поддержка пакетов в каком бы то ни было виде. Наиболее подходящим вариантом, сначала был Borland Developer Studio с какими то плагинами, позволяющими компилить под compact framework. Однако, позднее у меня сложилось ощущение, что кода, сложнее "Hello world" я там всё таки не получу. Поразмыслив, я решил, что для меня не будет критичным, если я буду компилить модули из пакетов в единый EXE-шник. Поэтому я остановил свой выбор на FPC, даже не смотря на то, что поддержки пакетов в нём нет.
Bupyc писал(а):GrayEddy, по большому счёту, большой ли в них смысл?
Большой. Пока их поддержки нет, Lazarus так и будет оставаться одним большим костылём. Собственно говоря, пакеты - одна из ключевых фич компилятора Delphi, которая как раз и позволила создать такую качественную VCL и, соответственно, RAD IDE.
P.S. Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?
"Нет сынок, это фантастика"(с):)
vital, я не спорю. Было бы лучше, если бы поддержка bpl или каких то аналогов была реализована в fpc. Но на мой неправильный субъективный взгляд, это не самая критичная проблема. При большом желании модульную разработку, основанную на bpl всегда можно перекомпоновать в единый ехе-шник, который будет работать точно так же, как и программа, состоящая из кучи пакетов.
Без пакетов, как то еще могу представить, а вот без библиотеки отлаженных визуальных компонентов представляю очень слабо. А LCL для win ce на сегодняшний день весьма и весьма нестабильна. Это, как мне кажется, намного большая проблема, чем поддержка динамических пакетов.
vital писал(а):P.S. Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?
Без пакетов, как то еще могу представить, а вот без библиотеки отлаженных визуальных компонентов представляю очень слабо. А LCL для win ce на сегодняшний день весьма и весьма нестабильна. Это, как мне кажется, намного большая проблема, чем поддержка динамических пакетов.
-
Slavikk
- постоялец
- Сообщения: 208
- Зарегистрирован: 15.01.2007 21:34:52
- Откуда: Из лесов...
- Контактная информация:
я тут недавно думал над этим вопросом, необходимо было в *.dll использовать LCL, т.е. попросту форма из *.dll. Нашёл только одно и достаточно кодоёмкое решение. В dll хранятся данные по которым прямо во время работы программы динамически создаются самой программой компоненты (формы и кнопки), а обработку событий созданных кнопок обрабатывает *.dll. Но по существу это псевдо LCL в *.dll - попросту файл по которому подымается дизайн + обычная dll. Но этого хватает заглаза.
Slavikk писал(а):я тут недавно думал над этим вопросом, необходимо было в *.dll использовать LCL, т.е. попросту форма из *.dll. Нашёл только одно и достаточно кодоёмкое решение. В dll хранятся данные по которым прямо во время работы программы динамически создаются самой программой компоненты (формы и кнопки), а обработку событий созданных кнопок обрабатывает *.dll. Но по существу это псевдо LCL в *.dll - попросту файл по которому подымается дизайн + обычная dll. Но этого хватает заглаза.
Может вот это пригодится?:
http://www.delphisources.ru/pages/faq/b ... n_dll.html
vital писал(а):Патчи чего?
Патчи, реализующие поддержку пакетов.
vital писал(а):P.S. Вы лично контактируете с разработчиками FPC?
Я контактирую с ними через списки рассылки и чат, так же, как и все другие желающие
Эта тема неоднократно обсуждалась в списке рассылки fpc-devel.
vital писал(а):Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?
А как пакеты помогут решить эту проблему
Максим писал(а):vital писал(а):Патчи чего?
1. Патчи, реализующие поддержку пакетов.vital писал(а):Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?
2. А как пакеты помогут решить эту проблему
1. "Патчи" - это ещё мягко говоря. Потребуется много дорабатывать компилятор напильником(возможно, и линкер тоже). Думаю, кроме авторов сделать это квалифицированно больше некому(нет, можно, конечно, убив кучу времени сесть за исходники компилятора и выдать что-то в итоге, но весь вопрос в целесообразности). Просто у авторов, судя по всему, не очень чёткое понимание перспектив развития своего детища. А перспектива, имхо, одна - достижение максимальной совместимости со стандартом де-факто промышленного Pascal-программирования(Delphi, вестимо). Без этого, Free Pascal , будет если и не мёртв, то гм... в медицине это называется "стабильно тяжёлым состоянием". И все эти увлечения такими "фичами", как перегрузка операторов и макросы в С-стиле на фоне отсутствия такого базового функционала Delphi, как поддержки пакетов, порой неудовлетворительной совместимости даже по библиотекам RTL(не далее как вчера столкнулся: реализация передачи в функцию открытого массива констант работает несколько по-другому) только ведут в тупик(Лазарь там находится уже давно, и судя по всему, так и останется вечной бетой
)
2. Помогут избежать ненужного дублирования кода. Сейчас Лазарь линкует "пакеты" статически и приходится тащить всё добро с собой, теперь представьте, что на мобильном устройстве стоит несколько Lazarus-программ и каждая содержит в себе жирный кусок одного и того же кода. Возможности сделать в этом случае своего рода фреймворк, используемый всеми этими программами и экономящий ресурсы нет в принципе
А говорите при чём тут пакеты...-
Deepthroat
- постоялец
- Сообщения: 144
- Зарегистрирован: 06.09.2007 00:21:34
- Откуда: Outer Heaven
- Контактная информация:
Slavikk писал(а):Неа, это не делфя, здесь такое не прокатит. Здесь программа и *.dll абсолюто автономны и по памяти и по rtl, поэтому я и делаю меж ними общение на основе интерфейсов и функций.
Ну в приведенной ссылке так и есть. Весь функционал формы в dll, а из программы только вызываются функции CreateTheForm, LoadTheForm, ReadTheForm, ShowTheForm, DestroyTheForm для создания, удаления и пр. Все автономно, а как иначе?
vital писал(а):Просто у авторов, судя по всему, не очень чёткое понимание перспектив развития своего детища. А перспектива, имхо, одна - достижение максимальной совместимости со стандартом де-факто промышленного Pascal-программирования(Delphi, вестимо).
На мой вкус понимание у них вполне чёткое. И проблеме совместимости с Delphi уделяется много внимания. При этом надо понимать, что 100% совместимости достичь очень сложно, в частности, в связи с кросс-платформенностью FPC/Lazarus. Плюс надо учитывать, что ряд возможностей, например, перегрузка функций и операторов, в FPC появился раньше, чем в Delphi.
vital писал(а):Без этого, Free Pascal , будет если и не мёртв, то гм... в медицине это называется "стабильно тяжёлым состоянием". И все эти увлечения такими "фичами", как перегрузка операторов и макросы в С-стиле на фоне отсутствия такого базового функционала Delphi, как поддержки пакетов, порой неудовлетворительной совместимости даже по библиотекам RTL(не далее как вчера столкнулся: реализация передачи в функцию открытого массива констант работает несколько по-другому) только ведут в тупик(Лазарь там находится уже давно, и судя по всему, так и останется вечной бетой
Как я уже писал выше, совместимость очень неплоха, и постоянно улучшается. Если вы обнаружили несовместимости с Delphi, сообщите о них в багтрекер.
Lazarus, кстати, развивается хорошими темпами, и уже сейчас IMHO вполне пригоден для работы.
vital писал(а):Помогут избежать ненужного дублирования кода. Сейчас Лазарь линкует "пакеты" статически и приходится тащить всё добро с собой, теперь представьте, что на мобильном устройстве стоит несколько Lazarus-программ и каждая содержит в себе жирный кусок одного и того же кода. Возможности сделать в этом случае своего рода фреймворк, используемый всеми этими программами и экономящий ресурсы нет в принципе
А вы учитываете, что при использовании пакетов у вас:
- а) Смартлинк идёт лесом => увеличивается совокупный размер программы и требуемых ей библиотек (например, становятся нужны RTL, FCL, LCL в полном объёме);
б) Имеет место некоторое падение производительности;
в) Появляется проблема DLL Hell, так как для каждой версии FPC и Lazarus библиотеки будут разными => проблема с обновлениями вашей программы.
Мне лично не очень понятно, зачем это всё нужно, если только код программы не закрыт.
Вот последний тред с обсуждением этого вопроса в списке рассылки.
-
alexs
- долгожитель
- Сообщения: 4069
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
Максим писал(а):в) Появляется проблема DLL Hell
На мой взгляд, это это одна из самых главных проблем и дельфи и вобще винды - очень большая бочка дёгтя в сторону пакетов. Особенно это будет заметно в FPC, где сам компилятор не стоит на месте и каждый день дорабатывается, соответсвенно будут меняться и пакеты.
alexs писал(а):Максим писал(а):в) Появляется проблема DLL Hell
На мой взгляд, это это одна из самых главных проблем и дельфи и вобще винды - очень большая бочка дёгтя в сторону пакетов. Особенно это будет заметно в FPC, где сам компилятор не стоит на месте и каждый день дорабатывается, соответсвенно будут меняться и пакеты.
dll-hell - это боян времён Win9x. Начиная с Win2k эта проблема решена. Эпизодические упоминания её исходят от самой Microsoft как рекламный слоган при продвижении .NET. И не более того.
P.S. Проблема rpm-hell встречается гораздо чаще, я бы сказал, несравнимо чаще.