если речь идет действительно об этом, то
1) интересно каким образом это относится к версии среды?
2) почему вопрос поднимается как "Я так понимаю лошадей на переправе не меняют, ну так и надо карты вскрыть", когда год назад об этом было подробно и объективно написано как минимум тут: http://blog.hiasm.com/article/10/?

Казалось простая мысль о переносе кода на новую платформу конструктора напрочь зафлудила чужую тему, просьба к модераторам перенести в отдельную тему.
------------ Дoбавленo в 21.59:
Dilma, мне просто казалось раз есть конверторы различных яву так и Вы возможно смогли-бы что нибудь предложить, там достаточно 70% перевода, остальное только подстёгивает для того чтобы веслом махать. (к сожелению у меня ссылка на блог не работает )

andrestudio, дабы внести ясность в суть вопроса: если вы не согласны с принимаемыми в рамках проекта решениями - приводите аргументы. Рассмотрим, подумаем, возможно что-то изменим.

Ну и для досуга вопрос с намеком: вы вообще как себе видите дальнейшее развитие пакета Windows?

Редактировалось 7 раз(а), последний 2025-02-28 12:10:09

это уже вопрос по существу...

Автоматический перевод элементом пакета Windows под что-то еще (что угодно, основанное на XTCG) не возможен сразу по нескольким причинам:
1) принцип кодогенерации пакетов настолько сильно различается, что эта задача становится эквивалентной пересборки танка в станок для напыления слоев процессора на кремниевую подложку
2) используемые фреймворки так же далеки друг от друга, как аналогия из п.1.

Однако кое-что перенести можно - если элемент реализует некий алгоритм по обработке чего-то, то он может быть перенесен с минимальными правками (элементы работы с графикой, со строками, с OpenGL и т.д.), при условии (очевидно), что целевые языки пакетов совпадают или обратно совместимы.

блин ещё и выкинуло до кучи. да как ещё его видеть то, только им и пользуюсь, можно конечно и в люниксойды податся, только некогда мне, работать надо а тестировать всё подряд.

Довольно забавно видеть обсуждение "нужна ли кроссплатформенность" или "куда девать наработки с Windows" в свете того, что Автор пользуется кардинально другой системой. То есть, по умолчанию, приоритеты его будут очевидны. Соответственно, надо понимать, что если равновесие и будет достигнуто, оно будет между ОС, и то только если со стороны пользователей ОС от Micro$oft будет не менее сильный источник "гравитации" в лице сильного разработчикаколлектива, достойный Автора.

не заметил прямого ответа на поставленный вопрос... Однако податься в линуксойды это значит отказаться от пакета, что надо понимать как ответ "путей дальнейшего развития пакета Windows не вижу". Так?

Впечатление, что больше всего тут будут рады (временному?) сохранению старого принципа кодогенерации (при том, что среда будет уже новая) в связке "самый новый FPC + самый новый KOL". Хотя, с неохотой согласятся на LCL ))

И так, потихоньку, перетаскивать их на более современные технологии. Приучать к мысли, что за кроссплатформенность надо платить.

andrestudio, а смысл? Тут ведь два варианта. Пользуемся 4-й версией и не жужжим, или 5-й, но жужжим по другому.
HiAsm 4-й уже совсем stable-stable. А пакеты к нему накручены и накручены. Так что проблем пока не вижу.

все верно


сильный источник "гравитации" в данный момент это пользователи, которые работают под ос линейки Windows.


вставлять в новую среду пакет Windows - не имеет никакого смысла. HiAsm5 абсолютно ничего нового не дает в сравнении с HiAsm4 (с точки зрения пользователя Windows, конечно же, ну и рюшки не в счет)

Ну как же, новые версии компиляторов и официальная поддержка Автора, возможность влиять на развитие конструктора и интерфейса, нет, тут огромное число преимуществ. Осталось помочь nesco с освоением LCL)

Для меня не с LCL проблема (Pascal -- он и в Африке Pascal), а с объектно ориентированным скриптом, гдя я не в зуб ногой
------------ Дoбавленo в 22.28:

Ну да, когда был последний инсталлятор 4-й версии, а когда последние ночные сборки Пакет уже черте куда ушел в исправлениях, и народ уже чаще и чаще приходится отправлять на SVN

nesco, угадал

Этот LCL сожрет все достоинство старого пакета -- размер прикладных программ. Да и нафиг не нужно супер быстродействие для простеньких программ обработки данных, это же не графика и не Open-GL