А вот что писал Dilma Еще раз -- где здесь упомянуто Delphi? Этот проект нельзя называть Delphi2, так как совершенно нет никакого синтаксиса Delphi, даже отдаленно. Вот довести до ума обычный пакет Delphi и его компоненты, это можно, а вот изучать новый скриптовый язык меня не тянет вообще.

[size=-2]------ Добавлено в 00:12
И я в Web не нашел Debug'a, только компиляция. Это совсем не интересно.

А больше Dilma ни чего не писал, что ли



Сказано же: Карфаген должен быть разрушен
Никто никого не заставляет.
Просто ненавязчиво намекают: можно остаться у разбитого корыта.


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


Перевожу: Вам дан пример, показывающий, что 90% кодогенератора WEB - языково-независимо: его ядро использовано для кодогенерации для Дельфи. Кто понял это, и ему интересен именно Дельфи (а аналогичным образом можно делать и другие языки) - может развивать пакет. Наращивать мясо на имеющиеся кости

Galkov, ага, ты на чем изучал язык -- на исходном коде CodeGen.dpr, а Dilma не вложил его в презентацию пакета, и что теперь? Костей-то не видно... Сложно все это как-то. Надо себе еще представлять что делает кажда команда и как она дальше интерпретируется. Мне не ясно, пока, как присобачить обработчик, как послать сообщение окну, да много чего не ясно. Нет, все же надо смотреть исходники, а иначе это -- пустой разговор. ИМХО.

Да ну

Не смог компилить пример:

Galkov, когда я его тянул первый раз там его не было.

[size=-2]------ Добавлено в 10:23
Nic, у меня то же самое выдало.

Коротко еще раз:
1) Смысл всей затеи очень точно был сформулирован в одной короткой фразе:

Дальнейшее развитие стандартного пакета именно к этому и приведет. Причины назывались уже не раз: достаточно часто не возможно из кода компонента убрать то, что не нужно пользователю в данный момент. Т.е. развитие пакета медленно, но верно ведет к его распуханию и снижению производительности на многие порядки. До тех пор, пока вы это не осознаете читать дальше не имеет смысла. Как и знакомится с содержимым этой темы тоже.

2) Имеется некоторая путанница из-за непонимания или незнания шагов потоковой кодогенерации. Точнее все привыкли к "кодогенерации" стандартного пакета, где её так назвать можно было очень условно. Скорее это не кодогенерация, а создание карты линков между элементами. Честная кодогенерация это создание кода приложения по шаблону. Язык, на котором пишется шаблон универсален и ни в коем разе не зависит от целевого языка. А вот целевым языком уже может быть PHP, JavaScript, HTML, Delphi или любой другой не важно какой. Пока разработчиком компонент такого пакета не будет до конца усвоено, что такое шаблон, то дальше в изучение можно даже не пытаться углубляться и не задавать вопросов типа "А как послать сообщение окну"...

3) Приведенные сслылки на справочные материалы содержат полное независимое описание скриптового языка. Приводить тут цитаты о PHP или JavaScript - это лишний раз демонстрировать непонимание работы потоковой кодогенерации. Galkov, упоменул о том, что 90% ядра языконезависимы. На самом деле это все 99%. 1% составляет разницу в операторе конкатенации строк целевого языка и символе обрамления этих строк.


должна стоять 163 версия с последним патчем. Так ли это?

[size=-2]------ Добавлено в 11:37
На счет поддержки: как правильно было замечено "кости даны, осталось облепить мясом". Следующий поддерживаемый пакет будет базироваться на основе языка С++. Причины так же не раз уже были сказаны.

Вообще-то, мне показалось, что это "неполностью скопированный" пример frm.sha
Поскольку, моей целью не стояло тестирование CodeGen на "дуракоустойчивость", то я его просто не запускал.
А запускал frm.sha

Ну типа: я сначало смотрю (и по сторонам - в том числе), а потом кнопку нажимаю....

Galkov, между прочим в процессе наброска этого пакета возникло понимание того, сколь большое количество концепций можно реализовать. И какая из них наиболее правильная и понятная совершенно не известно. Скажем сейчас сделано так, что процесс создания формы и помещения на нее интерфейсных элементов выглядит как последовательный вызов doCreate в нужном порядке...
Плюсы очевидны:
- мы теперь в любое время в любом месте можем динамически сделать элемент(а раньше такое возможно было только в контейнере)
- элемент можно создать даже если в проекте нет родителя(т.е. реализована давняя мечта вставлять элементы в неинтерфейсное приложение)
Минусы столь же наглядны:
- теряется прежняя логика пакета, когда вставка в проект компонента приводила к его появлению на форме
- из-за возможности создать в рамках одного элемента hiasm много элементов kol(путем многократного вызова doCreate) придется усложнить логику и ввести нижнюю точку Control(это помимо handle причем), а так же инструменты управления для нее.

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

А значит нужно думать, как организовать пакет, чтобы сохранилась прежняя прозрачность приложения и в то же время была возможность проектировать схемы так, как в frm.sha.

Ну а что с Delphi2? Он не будет поддерживаться вообще и не стоит даже заморачиваться, так что ли? Ну прям как мелкософт -- ну не хотите работать на WEB и на C++, то валите нафиг, остальное поддерживаться не будет. И что теперь, плюнуть на Delphi и сидеть изучать C++ (я про скриптовый язык WEB вообще молчу, но его изучать всеравно надо).

Не то слово

Но как-то давно уже думалось, что если в том, что у нас называется Фоновым приложением, запустить модальную форму, то получится наше же Приложение Windows

Если еще с Applet-ом (куды его засунуть) разберемся

nesco, честно - смысл претензий до меня не доходит совершенно. FASM когда-то был выпущен с составом из двух компонент и словами "А вот так можно делать на HiAsm программы на ассемблере". Пришел человек по имени tsdima и решил развить идею дальше.

Delphi2 - уже 10 раз сказали, что это демонстрация ТЕХНОЛОГИИ не имеющей никакого отношения к целевому языку пакета.

На всякий случай поясню - никто стандартный пакет не отменял. Если нет желания или способностей двигаться выше можно и дальше заниматься разработкой в этом направление - откажется от него Galkov будешь лично ты ведущим. Не будет ведущих, значит останется как PocketPC висеть в качестве примера одного из вариантов реализации.

На счет языков могу ответить в таком же духе, раз личные предпочтения в решение задач имеют больший вес нежели здравые рассуждения: купи нам борландовый компилятор с правом неограниченного тиражирования и будет тебе Delphi 2. До тех же пор высказывания по этому вопросу можно считать не более чем, прошу прощения, нытьем.

PS: мы делаем HiAsm для людей, которым знать языки не обязательно. Мне кажется, что разработкой такого рода технологий могут заниматься только те люди, у которых такой проблемы уже нет и которые знают, как избавить от нее остальных. А проблема эта может исчезнуть только в том случае, если не делать для себя особой разницы между Delphi, C++, Basic, Java, PHP, Perl и т.д. и т.п. и выбирать только то, что наилучшим образом подходит для решения данной конкретной задачи.

[size=-2]------ Добавлено в 13:18
Galkov, в приведенном пакете так и получается: если вставил форму, то будет интерфейсное приложение, а если убрал, то сервисное. Не сложно дописать и элмент Console посче чего делать программы с консолью или с консолью и формой сразу. Или создавать либо консоль, либо форму в зависимости от командной строки. В общем возможности широкие - точнее не уступающие любому иному способу программирования

Скорее всего, я чего-то еще не догнал. Но вот с эти согласен В принцие, разница действительно не большая, все языки очень похожи.

Да...
разные концепции и в скриптовых языках есть.

В CPP - появление переменной в области видимости, это безусловный запуск конструктора класса. И добавление деструктора в finally блок, который опять же безусловно запускается (не считая исключений) по закрытии данного блока видимости.

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

Был бы CPP базовым - проблем не было бы.

Наш аналог "появления переменной в области видимости" - это установка элемента на схему...
Первый вариант (CPP-шный) - чего-то больше мне нравится. Как-то там все надежней продумано, и менее противоречиво...

Конечно, не принципиальная проблема это проблема для кодогенерации.
Но и минусы мы помним конечно:
1) не визуализирован порядок создания объектов.
2) хоть и каждый запросто может быть динамическим - но как-то странно у нас это сегодня выглядит...

еще одним бонусом нового подхода явилось то, что часть компонент теперь стало так же языконезависимым. Если раньше такими были элементы вкладки Помощники, поскольку они не имели кода вообще, то теперь к ним добавились Hub,GetData,MultiElement(в режиме Inline), VisualText и прочие. Вероятно в будущем можно будет составить общий алгоритм описания синтаксиса целевого языка, на основе которого такие компоненты как Math,MathParse,StrCat,StringBuilder и другие так же станут полностью переносимыми без изменения кода вообще.