Разбор SHA-файлов

Вверх ↑

Форумы "Игра в слова"Разбор SHA-файлов ← Ctrl1 2 3 4 5 678 9Ctrl →

Этот топик читают: Гость

Администрация

Ответов: 15295

Рейтинг: 1519

#91: 2007-05-28 18:55:32 ЛС | профиль | цитата

iarspider писал(а):

Тогда совсем кратко: взял кодогенератор от Delphi

это и имелось ввиду под:

Dilma писал(а):

Просто не думаю, что имеет смысл всерьез заморачиваться над этим с применением ф-ности используемой сейчас в стандартном пакете

по причине:

Dilma писал(а):

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

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

Предлагаемый же пакет на основе wxWidgets безусловно расширяет горизонты, но как и Delphi будет является практически нерасширяемым, неповоротливым и совершенно не оптимальным. Вот и возникает вопрос: стоит ли брать за его основу Delphi движок?

карма: 27

https://hiasm.com

Ответов: 5446

Рейтинг: 323

#92: 2007-05-30 18:08:28 ЛС | профиль | цитата

Dilma, не спорю. Но, как мне кажется, кодогенератор a-la Web будет очень сложно подогнать для генерации в случае не-скриптового языка, хотя я могу и ошибаться.

Пока что единственное, что можно бы было извлечь из кодогенератора Web - это микрооптимизацию выходного кода (if вместо вызова метода класса, свёртывание case в switch, ...).

карма: 1

Администрация

Ответов: 15295

Рейтинг: 1519

#93: 2007-05-30 18:39:03 ЛС | профиль | цитата

iarspider писал(а):

Но, как мне кажется, кодогенератор a-la Web будет очень сложно подогнать для генерации в случае не-скриптового языка, хотя я могу и ошибаться.

не могу это ни опровергнуть, ни подтвердить. Так в общих чертах вроде бы кодогенератор WEB переносим куда угодно с урезкой его возможностей до одного языка(вместо трех в стандаотной комплектации), расширением базового набора типов и видоизмененной обработкой оператора &. С другой стороны повсеместное обязательное соблюдение типов данных может действительно где-то всплыть явным образом и уперетьтся в необходимость качественной переделки движка.
В общем тут надо пробовать.

iarspider писал(а):

Пока что единственное, что можно бы было извлечь из кодогенератора Web - это микрооптимизацию выходного кода (if вместо вызова метода класса, свёртывание case в switch, ...).

такое врятли возможно без соответствующей структуры движка.

карма: 27

https://hiasm.com

Ответов: 5446

Рейтинг: 323

#94: 2007-05-30 21:00:49 ЛС | профиль | цитата

Dilma, я ещё раз посмотрел на структуру пакета Web, и теперь попробую выразить свои претензии.

По сути, кодогенерация a-la Web означает отход от рассмотрения каждого компонента как класса, а это существенно усложняет работу с событиями. По сути, вместо динамического назначения static-методов классов-обёрток обработчиками событий мы вынуждены будем всю обработку вести через MessageMap внутри кода самой формы (панели, ...), что мне лично представляется труднореализуемым при нынешней квазилинейной схеме кодогенерации.

То есть, нам надо отлавливать моменты начала/конца SDK:

* в начале SDK создаём в памяти заготовку кода компонента (назовём его "master"), который будет обрабатывать все события
* по мере формирования кодов содержимого - добавлять master-у обработчики и их псевдокоды (ссылки вперёд!!!)
* по завершении SDK мы должны разрешить все ссылки вперёд, довести псевдо-коды до окончательной формы и только тогда записать в выходной поток код master-а

Как мне кажется, при нынешнем механизме генерации это затруднительно.

Но огпять же, я могу и ошибаться.

карма: 1

Ответов: 9906

Рейтинг: 351

#95: 2007-05-30 21:12:01 ЛС | профиль | цитата

iarspider писал(а):

По сути, кодогенерация a-la Web означает отход от рассмотрения каждого компонента как класса, а это существенно усложняет работу с событиями

Полная неправда. Этим способом можно совершенно запросто воспроизвести сегодняшний пакет Дельфи.
Типа совершенно механически... Есть такая идея...

Вывод: мы НЕ ОДИНАКОВО ПОНИМАЕМ ОДНИ И ТЕ ЖЕ КОДЫ.
Вопрос: кто правильно
Следовательно: давай разъяснения к своему пониманию - с какой радости такие смелые выводы

iarspider писал(а):

* в начале SDK создаём в памяти заготовку кода компонента (назовём его "master"), который будет обрабатывать все события
* по мере формирования кодов содержимого - добавлять master-у обработчики и их псевдокоды (ссылки вперёд!)
* по завершении SDK мы должны разрешить все ссылки вперёд, довести псевдо-коды до окончательной формы и только тогда

Не понятно НЕ ФИГА вообще.
Подробней, пожалуйста.

карма: 9

Ответов: 5446

Рейтинг: 323

#96: 2007-05-30 23:36:58 ЛС | профиль | цитата

Galkov, хорошо, давай разбираться.

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

В пакете же Web компоненты являются продолжением кодогенератора: скриптами на внутреннем языке. При этом, наверное, можно создать механический аналог пакета Delphi с кодогенератором a-la Web, но такое решение будет лишено какой-либо изящности. При таком подходе мы получим по два файла кодов на каждый компонент (за исключением flow control компонентов, для которых достаточно одного): скрипт, формирующий экземпляр класса и его связи; и собственно код класса. Причём скрипты-формирователи буду похожи друг на друга как близнецы-братья.

iarspider писал(а):

Сразу замечу, что вариант с нагромождением двух файлов на компонент мне не нравится, поэтому я его не рассматриваю.

В Delphi (KOL) обработка событий компонентами основана на перехвате собственной WinMain и вызове функций по "зарегистрированным" указателям (которая в нашем случае происходит в член-процедуре Init).

Теперь пакет Web. При однофайловой схеме генерации кода, мы оказываемся вынуждены, в части обработки событий, следовать логике wxWidgets. Есть два пути: через EventTable, или через Connect() (динамическое назначение обработчиков).

1. Через EventTable мы назначаем событию член-функцию класса, в котором этот Table определён. А сделать это мы должны в неком "master"-элементе контейнера (что-то типа EditMulti), который будет выполнять роль "диспетчера" - вызывать по событию XXX свой методж OnXXX, который уже сделает нужные действия. Было бы неестественным (и блокировало бы начисто возможность создания динамических компонентов) иметь одного master-а на всю схему - у каждого контейнера должен быть свой master. Этот "элемент" должен быть и первым, и одновременно последним элементом контейнера. Первым - чтобы сказать кодогенератору, что до конца контейнера все события будет обрабатывать именно он, последним - чтобы "вернуть" старый обработчик.

2. Через Connect(). Этот метод, на первый взгляд, кажется перспективным, но при этом мы либо начисто лишаемся возможности что-либо выдавать из компонента в потоке, либо опять вынуждены прибегать к услугам "посредника" (master). Более того, в этом случае нам придётся для каждой кнопки создавать свой класс-наследник wxButton, и создавать экземпляр уже этого класса.

Надеюсь, теперь понятнее.

карма: 1

Администрация

Ответов: 15295

Рейтинг: 1519

#97: 2007-05-31 12:01:40 ЛС | профиль | цитата

iarspider писал(а):

В пакете же Web компоненты являются продолжением кодогенератора: скриптами на внутреннем языке

Это не совсем так... Каждый такой скрипт выполняется в контексте элемента среды и поэтому с точки зрения ООП в широков смысле слова представляет из себя не статический кусок, а полноценный экземпляр класса. У этого скрипта всегда есть свой уникальный ID(в некотором роде это self или this в языках высокого уровня), у него есть свой конструктор(метод Init).

iarspider писал(а):

При таком подходе мы получим по два файла кодов на каждый компонент

Прощу прощения, а KOL аналог завернутый в обертку hiasm компонента стандартного пакета это не по два файла

От реализации ядра компонента в отдельном модуле и его применения в виде интерфейса взаимодействия с другими элементами мы никуда не денемся.

Ну и наконец замена прямой вставки кода посредством перевязки событий и методов делается так. Во-первых, приложения построенные на основе обработки системных сообщений(событий) требуют от кодогенератора некоторого знания того, какие компоненты могут генерировать левые события сами по себе. Либо всегда для всех компонент вызывать некий метод, в котором такая проверка будет осуществляться самим компонентом. Имея такую возможность для схемы:

Add(MainForm,16083304,21,105)
{
 Left=20
 Top=105
 Width=453
 Height=293
 Point(onMouseDown)
 link(onMouseDown,5255915:doMessage,[(68,153)(68,97)])
}
Add(Message,5255915,84,91)
{
}

с условием, что оба элемента у нас классы, мы получит код вроде такого:

 // mainform
func _GlobalInit_()
  // ....
  if(linked(onMouseDown))
    event(onMouseDown)
  end
  if(linked(onMouseUp))
    println('procedure onMouseUp', _id_, '(MouseX, MouseY);')
    println('begin')
      event(onMouseUp, 'MouseX' & 'MouseY')
    println('end;')
  end
  if(linked(onMouseMove))
    event(onMouseMove)
  end
  // ....
end

// message
func Init()
  // тут объявляем и создаем переменную класса TMessage с именем mes + code(_id_)
end

func doMessage()
  prrintln('mes', _id_, '.doMessage(', _data, ');')
  event(onMessage)
end

вот вроде бы и вся кухня. Очевидно, что я убрал код по разбивке файла на блоки, создание общего глобального класса контейнера, создание мостов от событий внешних компонент к событиям hiasm и прочие мелочи.
Собственно это пример того, как:

Galkov писал(а):

Этим способом можно совершенно запросто воспроизвести сегодняшний пакет Дельфи

просто ф-ции кодогенератора по линковке точек перенесены в сам компонент и все.

карма: 27

https://hiasm.com

Ответов: 5446

Рейтинг: 323

#98: 2007-05-31 23:03:35 ЛС | профиль | цитата

Dilma, я об этом и говорил: чисто механически мы можем сделать CG для Delphi в стиле Web. Но CG у классического пакета Delphi не в пример прозрачнее и понятнее, чем оный для Web. Когда я только начал разбираться с кодогенерацией, то сразу же "потонул" в CG пакета Web, и поэтому решил взять за основу Delphi.

Я не спорю, что путь Delphi в определённом смысле тупиковый, но я пока не вижу слиьной выгоды от кодогенерации a-la web, за исключением возможности немного оптимизировать код за счёт инлайнинга flow control операций (if, ...). Или я что-то упускаю?

Прощу прощения, а KOL аналог завернутый в обертку hiasm компонента стандартного пакета это не по два файла

Ну хорошо, с учётом КОЛ - в пакете Delphi_classical два, в пакете Delphi_web - три.

[size=-2]------ Добавлено в 23:03
Короче говоря, я пока не вижу, как можно по-человечески (а не механически) сделать пакет GCC с кодогенерацией типа Web

карма: 1

Ответов: 9906

Рейтинг: 351

#99: 2007-06-01 07:06:46 ЛС | профиль | цитата

iarspider писал(а):

то сразу же "потонул" в CG пакета Web

Ну я тоже не один день разбирался. Мягко говоря
И ни в коей степени не утверждаю, что там все чисто и гладко.
Есть вопросы, и не решенные в том числе.

Но не потонул. Спрашивай конкретно - и выплывешь.

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#100: 2007-06-01 10:33:44 ЛС | профиль | цитата

iarspider писал(а):

Я не спорю, что путь Delphi в определённом смысле тупиковый, но я пока не вижу слиьной выгоды от кодогенерации a-la web

Представь себе результат работы пакета WEB как нечто, что практически не отличается от кода, который мог бы написать среднестатистический программист и сравни с тем, что получается в стандартном пакете. Это не просто оптимизация If и case(как раз на эти мелочи стоило обращать внимания в последнюю очередь), а увеличение производительности в разы(не в два или три, а десять - двадцать)...

iarspider писал(а):

Ну хорошо, с учётом КОЛ - в пакете Delphi_classical два, в пакете Delphi_web - три.

всетаки не понимаю почему так. Давай по порядку. В Delphi_classical в лучшем случае мы имеем:
- *.pas файл с описанием класса элемента
- некоторый код, который мы прописываем при кодогенерации для связи этого компонента с другими
т.е. 1 файл

в худшем случае имеем:
- *.pas файл с описанием класса базового элемента типа KOL(какой-нибудь WebBrowser к примеру)
- *.pas файл с описанием класса элемента, построенного на базе предыдущего
- некоторый код, который мы прописываем при кодогенерации для связи этого компонента с другими
2 файла

для Delphi_web в лучшем случае будем иметь:
- некоторый код, который мы прописываем при кодогенерации для связи этого компонента с другими
1 файл

в худшем:
- *.pas файл с описанием класса базового элемента типа KOL(какой-нибудь WebBrowser к примеру) или свой собственный класс для больших элементов
- некоторый код, который мы прописываем при кодогенерации для связи этого компонента с другими
2 файла

iarspider писал(а):

Короче говоря, я пока не вижу, как можно по-человечески (а не механически) сделать пакет GCC с кодогенерацией типа Web

нужно пояснить, что значит "механически" и как будет "не механически"

iarspider писал(а):

Когда я только начал разбираться с кодогенерацией, то сразу же "потонул" в CG пакета Web

тут тоже хотелось бы узнать, что вызвало трудности. По большому счету я не вижу необходимости как пользователь данного CG копаться в его внутренностях. Поскольку планируется сделать одно ядро для всех пакетов, использующих данную технологию, то сие копание имеет смысл только в том случае, если есть желание дописывать его в будущем. Сам же язык и его концепции достаточно просты. Тем более при генерации нескриптового кода половина ф-ности движка, связанного с миксингом нескильких языков в рамках одной схемы отпадает.

[size=-2]------ Добавлено в 10:33
iarspider, вообще видимо имеет смысл определиться для себя самого с главным вопросом:
"А правда ли, что кодогенерация в стиле WEB выгоднее и перспективнее и я хотел бы её использовать?"

а уже потом выяснять сложности, недоработки и прочее в пакете WEB.

карма: 27

https://hiasm.com

Ответов: 5446

Рейтинг: 323

#101: 2007-06-01 18:12:55 ЛС | профиль | цитата

Dilma писал(а):

"А правда ли, что кодогенерация в стиле WEB выгоднее и перспективнее и я хотел бы её использовать?"

Я этот вопрос (только немонго по-другому) и задал в конце последнего сообщения. Ответ есть только на вторую часть: да, хотел бы (особенно после того, как пристально посмотрел скрипты).

По поводу счёта файлов: я считал немного по-другому:
delphi_classical: два (hiXXX.pas + kol.pas) или 3 (hiXXX.pas + YYY.pas + kol.pas) файла

delphi_web: +1 файл-скрипт, создающий экземпляр и прописывающий свойства

"Механический" перенос пакета - это берём коды компонентов, добавляем скрипты для создания экземпляра и прописывания св-в (то, что раньше сам CG делал).

Dilma писал(а):

По большому счету я не вижу необходимости <...> копаться в его внутренностях.

Однако, или как говорят американцы - yummy!

тут тоже хотелось бы узнать, что вызвало трудности.

Я пока глубоко не копал (некогда было, поступал в аспу), но надо сказать, что сама структура CG web существенно сложнее, чем у Delphi.

В Delphi всё линейно: прочитал компонент, записал код. Если контейнер - влез, по нему прошёлся. Всё.

А в Web для каждого компонента создаётся обвеска, потом вызывается парсер, и только потом всё пишется.

Вобщем, спасибо за информацию. Только хотелось бы получить пример компонента-контейнера, хотя бы и на Delphi, но в стиле Web.

карма: 1

Администрация

Ответов: 15295

Рейтинг: 1519

#102: 2007-06-01 18:55:28 ЛС | профиль | цитата

iarspider писал(а):

По поводу счёта файлов: я считал немного по-другому:
delphi_classical: два (hiXXX.pas + kol.pas) или 3 (hiXXX.pas + YYY.pas + kol.pas) файла

это не корректное представление. Оно зависит исключительно от того, как, кем и для чего был сдела компонент. Этак можно насчитать и Windows.pas + Kol.pas + debug.pas + ....

iarspider писал(а):

"Механический" перенос пакета - это берём коды компонентов, добавляем скрипты для создания экземпляра и прописывания св-в (то, что раньше сам CG делал).

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

iarspider писал(а):

Только хотелось бы получить пример компонента-контейнера, хотя бы и на Delphi, но в стиле Web.

он больше ничем не отличается от обычного элемента.

карма: 27

https://hiasm.com

Ответов: 2059

Рейтинг: 28

#103: 2007-06-01 19:04:49 ЛС | профиль | цитата

Луди если вы говорите о новом HiAsm 4, то просьба большая к вам. А нельзя ли сделать в новом HiAsm возможность делать простые компоненты, так сказать статичные как в нынешнем HiAsm 3. И что бы новый CodeGen мог это определять и ни делал бы ни какую оптимизацию. А то молодым программистам придёться много потеть чтобы компоненты новые, для HiAsm 4, писать.

карма: 1

Ответов: 9906

Рейтинг: 351

#104: 2007-06-01 19:23:02 ЛС | профиль | цитата

Мультики делать будешь

карма: 9

Ответов: 3655

Рейтинг: 69

#105: 2007-06-01 19:52:36 ЛС | профиль | цитата

Эдик писал(а):

делать простые компоненты, так сказать статичные как в нынешнем HiAsm 3.

Galkov, прав статичными компонентами как раз и будут мультики.

карма: 0

Форумы "Игра в слова"Разбор SHA-файлов ← Ctrl1 2 3 4 5 678 9Ctrl →


Сообщение ...
Прикрепленные файлы (файлы не залиты)