Вообщем поскольку проект Кладова уже давно почти не развивается думаю стоит разработчикам ХайАсм искать ему достойную альтернативу посовременней ( бо давно забытое старье в основе все еще главного пакета Windows многих отпугивает)

Недавно обнаружил проект Light LCL (LLCL) - Small Windows executable files

https://github.com/FChrisF/LLCL

Да LLCL проект куда менее развитый чем Кол но его демки вполне успешно собираются свежими версиями FPC(v3+)/Lazarus(1.7-1.8) + есть надежда на сохранение кроссплатформенности .

Размеры исполняемого EXE-модуля программ вполне сопоставимы с теми что выходят при использовании Кол
(От 100 кб )
+ думаю как минимум для виды перенести ХайАсм-совместимые модули элементов с кол на LLCL будет не так уж сложно.

Как идея ?

Редактировалось 1 раз(а), последний 2018-01-05 21:45:51

AlexKir, Это как из анекдота: типа "Ну где нам столько японцев найти "
Тут грубо говоря от кола 50-60 процентов реализовали и то рекорд, обещанного наплыва программистов не преплыло за 10 лет как минимум (причём если и был раньше ажиотаж хоть по пять строк в схему вставить то их поганой метлой вон гнали, ладно хоть как ведьм и колдунов на костре не жгли, иначе бы я уже на форуме не кому и не чем не помог наверно)

На то есть одна причина. В Хайасме маловато официальных способов работы с кодом.
(+ многие достаточно неудобны что-бы их можно был использовать на одном уровне знаний с "классическим-хайасмом")

Сторонних элементов написанном много но их мало кто кроме их создателей использует( или слишком специальные или не выдерживают "конкуренции оп качеству" с основным набором).

Удивительно другое:"Хайасме для фанов" есть довольно многого ПАКЕТОВ под разные платформы языки и компиляторы.
(Не многие "доведены до ума",но сам факт впечатляет !)

А что-бы адаптировать то что уже есть, к чуть другому даже не языку, а стилю много кодеров ИМХО не нужно.

Тем более, что побудительный мотив совершенно в данном случае очевиден. Совершенно ясно, что не за горами тот день
когда набор из старого компилятора и не менее старого КОЛ-а просто перестанет работать с новыми ОС и железом.
(Это я про FPC, а про "секретный компилятор" я и вовсе молчу, бо "древность седая" и вообще непонятно как до сих пор работает )

К тому же новые версии FPC совершенно реально более стабильны и гененрят значительно более стабильный код .
+ 64бита которые давно не экзотика "а средство передвижения".
+ Реальный кросс с Линукс
+ Оптимизации для новых CPU

Почему ранее попытки (в том числе и мои ) предложить что-то похожее, но например с "классическим LCL" в качестве замены Кол были менее "релевантны" ... ну думаю что это потому, что чистый LCL в качестве альтернативы КОЛ "не катит", а чистый WinApi просто громоздок и устарел при программировании.

Во всяком случае думаю, что взвесить "за и против" определенно стоит !
(Пока берусь погонять LLCL под Лзарусом бо у меня есть много проектов, где от интерфейса "пара кнопок", а LCL раздувает код на мегабайты )
.
.

Редактировалось 9 раз(а), последний 2018-01-06 16:21:49

Нет, их мало кто использует по той причине, что их сложно устанавливать и использовать так, чтобы делать переносимые схемы. Установить элемент - это целая отдельная задача, которой не каждый пользователь будет заниматься, выложишь схему на публику - и мало кто ее даже скомпилировать сможет, а если схема большая - то найти и установить все нестандартные компоненты. Решение этой проблемы придумано давно - репозиторий компонентов (а там заодно и пакетов, и проектов...).

Pascal, как язык, сам по себе уже морально устарел, некоторые даже не включают его в топ самых используемых языков, а переписывать огромную кодовую базу пакета Windows с KOL на LLCL - это не такая уж простая и быстрая задача, как вам могло показаться. Поэтому и встает вопрос: а стоит ли вообще прикладывать столько сил ради морально устаревшей технологии или лучше вложиться в создание новых пакетов на базе C#, web/javascript? Параллельно уже идет разработка пакета .net/C#, а web-пакет так вообще официальный и основной в hion.

Разные "Си" и его производные по моему устарели еще больше ... но их развивают и поддерживают, а ветка Модула-Паскаль-Ада-Оберон "сохнет" .

Жив только Паскаль и отчасти Ада. Но все плохое, что приписывают паскалю, относится к периоду "массовой дельфинизации" (вроде и развитие, но именно в Дельфи появился соблазн "быдло-кодинга", когда почти любую задачу стало возможно решить при самом минимальном знании основ языка (и что важнее применении... ну допустим знаю я (хотя уже наверное точнее сказать "знал" ) ООП чуть глубже чем требуется для использования VCL/lcl/kol, но толку часто только в повышении ЧСВ -- заказчику все это "по барабну"! )

А Си держит планку, скорее как раз из за "корявости стиля", что-бы там писать стабильные программы часто просто приходится вникать значительно глубже . Но разумеется, дело не в "ужасной" простоте "дельфи-стиля", а в отсутствии баланса между "продвинутым" и "простым" уровнем его применения.Все просто "продвинутый" уровень должен быть снабжен "простыми" инструментам для его применения...

Так же как в хайасме, где сравнительно не удобный "доступ к коду", не поощряет его использования,даже там где это совершенно оправдано, там где вместо трех ОЧЕВИДНЫХ строчек "вставки из кода" приходится "путать целые клубки змей" в схеме, но тот-же инлайн-код требует на любые "три строки" описывать целый модуль и целый класс (да многое шаблонно но до сих пор не автоматизированно, ну что мешает сделать отдельный шаблон на каждую точку и не показывать "страшный" код всего модуля ? )...

И в случае с LLCL, кстати тоже (ИМХО) совсем необязательно "пугать хайасм" и "пугаться" самими ! Думаю достаточно "кода-адаптера" транслирующего методы кол в методы LLCL (более того можно часть "об пиленного Кол-а" оставить! Задача ведь добиться возможности сборки новым компилятором, а что "коды для кол" можно запросто переносить даже в "чистый" LCL я уже многократно убеждался на практике ! )

Зы

Но LLCL разумеется придется банально дописывать ... вчера например обнаружил, что там даже панелей(TPanel) нет.
Однако,"Главное чтобы костюмчик седел"...
.
.

Редактировалось 9 раз(а), последний 2018-01-12 01:50:55

как по мне тык лучше вырезать из дельфина этот кол. меньше косяков и костылей и все можно будет реализовать и переносить компоненты в пару часиков и одни плюсы кроме размера

Я не столь оптимистичен (что КОЛ что vcl/lcl это "целая экосистема кода") к тому-же "вырезать" можно по разному :

1 Заменить на свой код (что частично и так есть в Хайасме) + там где можно использовать стандартный WinApi-интерфейс .

2 Найти для КОЛ примерно равноценную замену и написать "модуль посредник" .
(LLCL как основа подходит и даже "принципами поступаться" нет нужды то бишь размеры EXE-файла при использовании LLCL как бы не меньше чем при использовании КОЛ )


Попытка перевести Хайасм на "обычный LCL" ( VCL отпадает из за необходимости полностью поставить ХайАсм в зависимость от Дельфи или полностью ставит в ряды пиратского кода ) уже предпринималась но по моему это тупик!


Плюс есть еще один путь "сделать все по новому чтобы было все по старому " ...

Можно просто адаптировать "старый и не очень добрый" КОЛ под новые компиляторы.
Но это означает снова и снова тащить "горб принцессы Чайки".


Зы
ИМХО давно пора саму среду разработки конвертировать в Лазарус
( Так можно будет полностью освободится от любого обвинения в пиратстве при использовании ХайАсм) .

Сейчас Лазарус моя основная среда разработки и могу точно сказать, что уровень стабильности получаемого кода и удобства программирования там совершенно точно достигла уровня Дельфи как минимум 7-й версии .

Зы Зы
Кстати, не мешает сделать "тотальную инвентаризацию" и для собственно элементов Хайасм в "десятке"(Win10) часть элементов оказывается работать "от слова совсем" !

Редактировалось 14 раз(а), последний 2018-01-12 01:47:31

Ну так-то среда давно и переписана с дельфи, правда на C++, HiAsm 5 же Да, HiAsm 5 признан тоже версией без поддержки, и развивать пока в планах hion (а он вообще на javascript).

Редактировалось 1 раз(а), последний 2018-01-12 08:51:44

Тоже хотел бы, чтобы среда была на Lazarus с открытым кодом.
Ну, от автора среды я таких попыток не помню. Но не имею ничего против "обычный LCL", в т.ч., его кроссплатформенности.

Nic, всё правильно: "хода нет - ходи с бубей!".
А вот забивать крышку ецё не стоит, если гвозди уже положили.
Обьяснюсь.


Солидарен с RAWY_EX и хотелки Netspirit поддержу.

Не думаю, что кому то из вас нужен Hiasm для написания чег-то. ( я так и сам, грешным делом, практикую...)
Длугое дело гимнастика мозгов - это ниприменно все системщики. Это не плохо.
Когда нет задачи, начинаем придумывать: движки, языки, Нiasm-ы и модификации... А кот Васька чего делает, и рассказывать не буду.
Короче говоря, свой аквариум обустраивать. А за стёклами аквариума бесконечеый мир.

Всё это му-ые рыдания по поводу лицензий!
Пришёл школьник домой из школы и начал в кубики играть, и ему кажется - круто!
Всё!
Не всё.
Постарше внуки и сами начинают копаться в коде, дочь и сыноввья "серьёзные" мены - не до того, а внуки задают вопрос:
Чё за ерунда, есть примеры из нета, а не пашeт? И попробуй обьяснить, зачем этот кол и на хрена так сделано.
Скачал CLASSES.PAS, CONSTS.PAS, ffmt.OBJ, SYSCONST.PAS, SYSUTILS.PAS, TYPINFO.PAS от d4, во всяком случае, для IC и своих компонентов пока хватает. + библиотеки.
, а размер собственно и не колышет.

По моему разумению, еси была бы возможность писать код не в IC, а как обычно(не Hiasm), то былобы - то, что доктор провисал.
Есть мысли, но... Но пока красивая картинка не получается, а не красивые самолёты, как известно, не летают.

Наверное не в тему, ...а может?
Делал летом ликовщик, который собирает куски скомпилированные на разных языках в один exe.
Даже проще - dll, exe, obj любого разлива, всё в одну кучу с нормальным вызовом функцмй друг из друга.
Конечно есть нюансы если это dll, или не свой exe.
Можно и наоборот, левые exe и dll в obj delphi разлива.
Зачем это? - не знаю!

Nic подошёл к этому вопросу радикально и это правильно.
Увижу-ль я Бразилию до старасти своей?
Только Дон и Магдалена...

Хотя и на пенсии, но есть определённые обязанности, в силу которых крайне сложно выкроить пару часов, чтобы в кнопки потыкать.
По этому хочется сразу вcё и сейчас!
А так бы к Nic-у подключился.
Но если назовусь груздем, то придётся ...
По этому - будем посмотреть.

Редактировалось 13 раз(а), последний 2018-01-13 03:40:42

AlexKir, одно дело более менее осовременить готовые решения (перейти с delphi на fpc) и другое начать делать (или переделывать) пакет под совсем новую библиотеку. Я еще в прошлой теме по FPC говорил, что заниматься пакетом на Pascal под Windows не имеет никакого смысла, т.к. это изначально тупиковая ветвь развития. Мы живем уже в 2018 году, когда большая часть населения планеты ежедневно использует смартфоны гораздо чаще, чем ПК, а вы тут размышляете над тем, как сэкономить пару мегабайт кода для приложений под десктопы для ОС, перспективы которой тоже весьма туманны и зыбки. Пакет, который разрабатывается в 2018 году с нуля просто де факто обязан уметь одно из:
1) работать под все ОС - Windows, MacOS, Linux
2) работать в WEB
3) работать на одной из мобильных платформ - Android, iOS

Это конечно при условии, что вы не делаете специализированный пакет, аудитория которого заранее определена (например, GUI для программирования микроконтроллеров конкретной фирмы). Но такие варианты нет смысла тут рассматривать.

В этом ключе хорошей перспективой обладает .NET Mono - работает в Windows, MacOS, Linux, сейчас поддерживается самим Microsoft и за ним стоит .NET, который точно в ближайшие десятки лет никуда не денется.

Интересным в этом плане является QT, но только лишь с реализаций сборки в облаке, т.к. настройка окружения на своей машине и скорость сборки приложений это тот еще геморрой. Поддержка всех ОС там хоть и есть, но все таки имеются свои нюансы при запуске в окружениях, отличных от Linux, плюс размер готового приложения достаточно большой (десятки мегабайт).

Хороший вариант так же это пакет под Electron/NWJS - компоненты писать очень легко и быстро, собирается все мгновенно, работает на всех ОС без вопросов, возможно легко портировать в WEB, но размер конечного приложения очень большой (за сотню МБ), оперативной памяти жрет примерно столько же, запускается не всегда быстро, плюс сильно ограничены в возможностях и интеграции с ОС.

Пакет под Lazarus + LCL (родная библиотека элементов Lazarus) тоже интересный вариант, т.к. поддерживает кучу платформ, быстро собирается, легок в изучении, размер конечного приложения (в сравнении с вариантами выше) не большой. Но использование Pascal в качестве основного языка все таки вызывает вопросы.

И последнее, что можно рассматривать, это Java. С кросплатформенностью тоже все хорошо, размеры конечного приложения (без учета самого Java) достаточно малы, библиотек под все возможные задачи куча, если интеграции с ос вдруг не хватет, легко пишутся native модули на любом языке. Из минусов можно назвать лишь то, что изначально язык не рассчитан на gui приложения и все они не отличаются особым быстродействием, а часто и вовсе выбиваются из стиля остальных приложений системы. Чаще всего почему-то если GUI программа написана на java, то это означает, что интерфейс у нее будет вырви глазным. Бывают правда исключения в виде Eclipse, Netbeans и прочих монстров java мира, но там сотни человек работает и приводить их в пример не очень корректно. С учетом того, что .NET и C# делались с сильной оглядкой на Java в том числе, то причин отдать предпочтение Java (если уж мы выбираем языки с vm), а не Mono я лично не особо вижу.

PS: лично о своих предпочтениях я уже говорил в темах по Hion - мне в данный момент больше интересно WEB направление, которое развивается семимильными шагами и будет развиваться дальше. Интересно оно в первую очередь тем, что в своей работе я практически полностью использую WEB приложения и не вижу вообще никакого смысла ставить небольшие утилиты в систему для выполнения простых задач, когда любую из них можно открыть в браузере, который всё равно все 100% времени открыт и никогда не закрывается. Под те задачи, которые нельзя выполнить готовыми приложениями, я использую Hion, при этом из коробки получаю возможность "шарить" приложения другим людям и обновлять их сразу у всех, кто ими пользуется.

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


Все верно, об этом тоже писал ранее, что пока каждый пытается пилить свой вариант IDE, свой вариант кодогенератора и свой вариант пакета, ничего закончено в ближайшее время не будет. Это можно сделать, но нужно много времени. В моем представлении IDE должна быть написана на WEB технологиях (Hion + NWJS\Electron), кодогенератор RTCG и пакет на базе одного из стеков, которые описаны выше. Поскольку коллега Nic уже многое сделал в пакете .NET, то разумнее всего остановиться на этом варианте.

Почему так? Да очень просто: Hion открыт полностью, работает везде, очень легок в изучении (код), отладки (его переписывать можно прям в браузере), расширении и сборки. RTCG - так же открыт, быстр, прост, адаптирован к Hiasm, может генерировать код для любых языков, кроссплатформенный. Ну а у .NET плюс в том, что он уже написан и содержит целую кучу готовых элементов. Зачем постоянно придумывать и предлагать что-то еще - я ума не приложу. Пора бы уже и реальности в глаза посмотреть.