Отправлено: 07.11.09 14:03. Заголовок: Delphi Run-Time for [x]Harbour (размышления).

Здравствуйте.

Все-таки не покидает меня мысль о том, что было бы очень неплохо организовать Delphi Run-Time для [x]Harbour. В очередной раз мысль вернулась в связи с выходом Delphi2010. В этой версии сняты ограничения по rtti-доступу даже к private-секциям классов и т.д., что делало бы задачу еще проще.

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

Вообще, предоставление Дельфи ран-тайма не-дельфи инструменту, не является какой-то уникальной мыслью. Например, инструмент, написанный Алексеем Волковым - Script Builder. Он и будет иллюстрацией того, что я имею в виду под Delphi Run-Time.

Script Builder - это Delphi Run-Time для Microsoft Active Scripting (VBScript, JavaScript, ActivePerl, ActivePython). Скачать его можно с:

http://www.volkoff.ru/file_download/4/sbpro.exe

Script Builder написан на Delphi5 довольно давно (2000-й год) и имеет немного старомодный интерфейс. Но если вы его скачаете и немного "пощупаете", то увидите, что это продукт более качественный, чем те же Xailer или тем более Visual xHarbour. А по уровню предоставляемого ран-тайма и его расширяемости и сравнивать нечего, это, собственно, дельфи.

Так вот, под "Delphi Run-Time for [x]Harbour" я подразумеваю аналогичный (но более современный инструмент) для [x]Harbour, который полностью поддерживал бы Unicode (имею в виду визуальные компоненты).

-----

Реализация. Ясно, что начинать надо с 2-x сторон. 1) Delphi-часть, сначала собственно ран-тайм, здесь в общем-то все понятно и я могу это реализовать. 2) [x]Harbour-часть, здесь необходима некоторая библиотека, которая бы обеспечивала прозрачный доступ к классам, объектам Дельфи и делала бы их частью своего языка. Здесь моих знаний [x]Harbour явно не хватит. То есть, одному мне такой проект не поднять...

Поэтому и пишу Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии?

Жду ваши комменты

Спирин Сергей.

 Отправлено: 12.04.10 11:47. Заголовок: Наиль пишет: Delphi..

Наиль пишет:

цитата:

Delphi знаю хорошо, но вот с клипером-харбором (с кораблем и гаванью) только начинаю знакомиться.

Привет!
Вот здорово! Наконец-то я дождался дельфиста в этом "сумрачном" мире. То, что клиппер-харбор еще не знаете, это не страшно, тут ничего особо сложного нет, овладеете по ходу. Кстати, а какими судьбами в клиппер-харбор заносит? Обычно, здесь люди находятся по чисто историческим причинам только.

По версии дельфей. "Перегнать" декларации классов по RTTI в харбор декларации в общем-то можно в любой версии дельфей. Но в любой версии, кроме 2010, все ограничится только секцией piblished. Нам же, для полноценной работы, нужно вытаскивать и полноценно управлять еще хотя бы всем из public. То есть, пришлось бы что-то додумывать, варианты конечно есть, но в 2010 это уже дают "на блюдечке"... Отсюда и мой интерес именно к 2010. Использовать Турбо в виду бесплатности заманчиво, но доп. писанины будет много, как бы не оказалось это "бесплатным сыром"

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

Жду обсуждения

 Отправлено: 12.04.10 21:11. Заголовок: Начинаю

Существует два (пока два) варианта решения задачи: сильнодинамический и слабодинамический.
Предложенный выше вариант сильнодинамический. Суть решения в том, что нужно создать библиотеку-обёртку вокруг компонентов Delphi. Это позволит динамически создавать из харбора окна-формы любой сложности. Учитывая размер конфетки под обёрткой процесс может оказаться бесконечным и с неясной перспективой.
Поэтому я пошел по второму пути. Попробую создать некий конструктор, который позволит создавать форму и генерировать соответствующий ей объектный код на Харборе. Задача сгенерированного кода обеспечить интерфейс для событий клавиатуры и мыши (в начальном варианте) и изменения свойств объектов-компонентов.
Конструктор будет работать в отсутствии Delphi используя лишь bpl-файлы.
При слабодинамическом решении компоненты нельзя не удалить, не добавить, можно лишь изменить свойства, например скрыть.

 Отправлено: 13.04.10 07:04. Заголовок: Наиль пишет: будет ..

Наиль пишет:

цитата:

будет работать в отсутствии Delphi используя лишь bpl-файлы.

Позвольте вопрос ? А готовое приложение с чем будет ? В смысле: со своим EXE-ником и DLL-ки Delphi будут еще какие-то файлы ?
Это не есть хорошо.... Мне нравится Harbour за его компактность !!!

 Отправлено: 13.04.10 16:49. Заголовок: Наиль пишет: Сущест..

Наиль пишет:

цитата:

Существует два (пока два) варианта решения задачи: сильнодинамический и слабодинамический. Предложенный выше вариант сильнодинамический.......

Привет, Наиль.

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

Итак, конечной целью проекта является полное портирование VCL в Харбор приложение. Под этим под этим подразумевается полностью прозрачный доступ "в обе стороны". Как первый шаг, реализация без IDE (наподобие FiveWin), как идеал создание или портирование IDE.

Реализация в Delphi.

В сторону Харбор->VCL, все на чистом RTTI от Delphi2010. "Размер конфетки" "никакой рояли не играет", так как доступ полностью унифицирован. То есть, это десяток-полтора функций типа Get/SetProperty, CallMethod, Get/SetField и т.д.

В сторону VCL->Харбор, использование отработанной на Фасте технологии использования HB API. HarbourDataSet для прямого доступа к нативным Харбор-источникам данных, и т.д..

По модулям.

Это одна dll, содержащая вышеописанное взаимодействие в обе стороны, компилируется с пакетами, откуда, собственно, и будет брать VCL-функционал. Думаю, что где-то три пакета можно грузить сразу статично (rtl, vcl, vcldb), остальные динамически по вызову из Харбор-приложения.

Харбор-сторона.

Вот здесь как раз варианты есть. Можно в конце концов ограничится только импортом функций из dll и писать что-то типа:

SomeVar := CallConstructor("TForm", "Create")
SetProperty(SomeVar, "Width", 800)
CallMethod(SomeVar, "ShowModal")
......

Но это уж больно "как-то не то" . К тому же, исходя из переспективы IDE и дизайн-тайма такой "процедурный подход не катит". Отсюда идея сделать автоматическую декларацию классов, сделать точную копию дерева наследования и т.д. Это и есть "перегонка", при которой каждый метод "знает", что ему вызывать и т.д.. Тогда код на Харборе примет более нормальный вид:

MyForm := TForm:Create(nil)
MyForm:Width := 80
MyForm:ShowModal

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


Ну вот, собственно, пока все мысли по этому поводу

 Отправлено: 13.04.10 20:34. Заголовок: Еще раз о целях. 1)..

Еще раз о целях.
1) Вряд ли Делфи нуждается в Нарборе. Там уже столько наворочено
2) У Нарбора ( как программист, занимающий прикладным программированием ) вижу
ВСЕГО два недостатка:
- отсутствие удобной отлаженной IDE для работы в графическом режиме . Но просто повторение Делфи - это, вообщем, шаг назад. Использование DataSEt совсем не производительный метод. По различным оценкам, если сравнивать Делфи, VBasic, Access ( это все системы быстрой разработки приложений) скорость разработки на Access раз в 5 выше, чем у первых двух.Здесь речь идет о принципах.
- проддержка работы с SQL серверами , ставшими стандартом де-факто.

 Отправлено: 13.04.10 21:54. Заголовок: Vlad04 пишет: Еще р..

Vlad04 пишет:

цитата:

Еще раз о целях.

Влад, я очень ценю ваше желание пообщаться Но читать ваши суждения, честно говоря труд нелегкий Может, вам лучше не утверждать что-то, а просто спрашивать, если что-то непонятно?

Vlad04 пишет:

цитата:

1) Вряд ли Делфи нуждается в Нарборе

Гм..х....г... А кто-то говорил, что нуждается? Кто? Влад, речь об использовании Delphi-функционала в Харбор приложении.

Vlad04 пишет:

цитата:

Но просто повторение Делфи - это, вообщем, шаг назад.

Чего-чего? От чего это шаг назад? От MiniGUI? (Григорий извините..)

Vlad04 пишет:

цитата:

Использование DataSEt совсем не производительный метод.

Это вообще читается примерно как: "Фармацевтический смысл туманности Андромеды" Что называется, хоть стой, хоть падай.

Vlad04 пишет:

цитата:

скорость разработки на Access раз в 5 выше

От такого сравнения, у меня уже просто "мозг клинит" Даже, что сказать, непонятно... Немая сцена с открытым ртом

Влад! Пишите, повеселите еще!

 Отправлено: 14.04.10 06:57. Заголовок: Чего-чего? От чего ..

цитата:

Чего-чего? От чего это шаг назад? От MiniGUI?

Нет , конечно. Я и пишу об одном из недостатков Харбор - отсутствие удобной отлаженной IDE для работы в графическом режиме.

цитата:

Использование DataSEt совсем не производительный метод Это вообще читается примерно как: "Фармацевтический смысл туманности Андромеды"

Да, при разработке метод Select, используемый в Харбор, намного производительней DAtaset. Вы попробуйте создать вычисляемое поле или подставляемое поле в Делфи и Харборе и сравните потраченное время.

цитата:

скорость разработки на Access раз в 5 выше

Увы, так оно и есть. Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе.

Вообщем, чего чего, а сарказма у Вас на всех хватит.

 Отправлено: 14.04.10 08:32. Заголовок: Привет, Влад! :sm12..

Привет, Влад!
Vlad04 пишет:

цитата:

Чего-чего? От чего это шаг назад? От MiniGUI? Нет , конечно. Я и пишу об одном из.....

Ну так, от чего это шаг назад то?
Vlad04 пишет:

цитата:

Да, при разработке метод Select, используемый в Харбор, намного производительней DAtaset.

Я уж было напрягся даже Потом вспомнил, что в HarbourDataSet, вызов "метода Select, используемого в Харбор" по коду встречается десятки раз, и успокоился, значит у меня производительный DataSet Влад, что такое для вас DataSet?

Vlad04 пишет:

цитата:

Увы, так оно и есть. Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе.

Влад, как бы вам объяснить, что вы сравниваете несравнимое - узкоспециализированное средство, включенное в MSOffice и универсальный, достаточно низкоуровневый язык программирования .... Вы случайно почту не "The Bat"-ом читаете? А в аське не "QIP"-ом сидите? Или может файлы копируете "Windows Commander"-ом? А может с разными базами работали когда-нибудь через IBExpert, PL/SQL-Developer, SQL-Navigator....? Это все программы, написанные на Delphi... Есть у меня какое-то смутное впечатление, что на Accsess QIP или PL/SQL-Developer быстро не напишешь

Vlad04 пишет:

цитата:

Вообщем, чего чего, а сарказма у Вас на всех хватит.

Надеюсь, сарказма здорового и необидного

 Отправлено: 14.04.10 11:43. Заголовок: Vlad04 пишет: Некот..

Vlad04 пишет:

цитата:

Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе.

Подробней пожалуйста ! С фактами !
Мне тоже интересно узнать, кто так делает !
2 раза писать систему ? Круто деньгами сорят ...

 Отправлено: 14.04.10 13:33. Заголовок: Не в обиду пишется. ..

Не в обиду пишется.
Я в своем опусе хотел выделить ЛУЧШИЕ стороны, имеющиеся в некоторых системах , а не системы в целом.
Вы невнимательны.
И про Select написано - при разработке. Т.е программист в Харбор оперируя RDD и Select пишет и вносит в программы изменения быстрее , чем это делается с DAtaSourse и DataSet в Делфи. Да и удобнее так (мне точно).
Речь не идет о производительности готовых систем.
Впрочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Делфи на Apollo приближается к Харбор и клипперу , но отстает все равно.
И хотя Access в целом мне не нравится, но там есть очень удобные моменты. Возможно что-то подобное есть в Делфи2010, я пока использую Делфи 7.

 Отправлено: 14.04.10 14:35. Заголовок: Vlad04 пишет: Впроч..

Vlad04 пишет:

цитата:

Впрочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах.

Давай пример одинаковый сделаем ! Очень хочется сравнить скорости !!!

 Отправлено: 14.04.10 14:47. Заголовок: Andrey пишет: Очень..

Andrey пишет:

цитата:

Очень хочется сравнить скорости !!!

Еще бы хотелось сравнить 1с

 Отправлено: 14.04.10 18:58. Заголовок: Что мы отвлекаемся. ..

Что мы отвлекаемся. Главное, сформулировать задачу для Сергея.
А сила 1с в другом - в организации данных.
В простом пересчете она , конечно, проиграет.

 Отправлено: 15.04.10 09:10. Заголовок: Привет. Vlad04 пише..

Привет.

Vlad04 пишет:

цитата:

Я в своем опусе хотел выделить ЛУЧШИЕ стороны, имеющиеся в некоторых системах , а не системы в целом. Вы невнимательны.

Как невнимателен? Да я до сих пор жду ответа про "шагом назад от чего?" было бы повторение Дельфи для Харбура. Ну и про ЛУЧШИЕ стороны тоже кое что теперь знаю, а именно:

- В Accsess есть тоже что-то хорошее.
- Писать вот так:

SELECT MYTABLE
GoTop()

Это намного удобнее, чем писать вот так:

MyTable.First;

Понял. Принял к сведению.

Vlad04 пишет:

цитата:

И про Select написано - при разработке. Т.е программист в Харбор оперируя RDD и Select пишет и вносит в программы изменения быстрее , чем это делается с DAtaSourse и DataSet в Делфи. Да и удобнее так (мне точно).

Последняя ремарка, я думаю, наиболее точно отражает положение вещей У меня коллега-клипперист, что называется "стоявший у истоков", до последнего "упирался", лишь бы кодировать в своем любимом Лексиконе. Сейчас правда перешел на.... редактор Far-а

Vlad04 пишет:

цитата:

прочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Делфи на Apollo приближается к Харбор и клипперу , но отстает все равно.

Слово Apollo я "слышал", но никогда не видел. Но, просто формализуем положение вещей объективной реальности:

- Native-код всегда будет работать быстрее, чем P-код.
- Нет ничего такого в реализации Клиппер-Харбура, чего нельзя было бы сделать на Дельфи.

Исходя из этих аксиом, и если Apollo действительно работает медленнее, нужно просто посмотреть в глаза разработчикам этого Apollo и спросить: "Что ж вы голубы делаете? Из какого места у вас руки растут"?

Кстати, вас наверное интересует работа только с dbf-файлами? В дельфи я с dbf уже и не помню, когда последний раз работал... давно. Но когда еще работал, то использовал Halcyon. Симпатичная такая библиотечка, за 100 баксов шла с полными исходниками. И с производительностью, насколько я помню, у нее проблем не было, то есть она была явно выше, чем у Клиппер-Харбура.

P.S. C dbf я, действительно, уже "100 лет" не работаю. Но тут мне Oracle не так давно, выдал такую ошибку:

ORA-XXX Не могу открыть dbf-файл.

У меня чуть челюсть об стол не стукнула

 Отправлено: 15.04.10 19:35. Заголовок: Не будем препираться..

Не будем препираться, кто что сказал. Вперед, Сергей, твори. Будем смотреть , критиковать.

 Отправлено: 17.04.10 16:57. Заголовок: Vlad04 пишет: Не бу..

Vlad04 пишет:

цитата:

Не будем препираться, кто что сказал.

Сильно не люблю людей, не отвечающих за свои слова... Поэтому, просьба вам, не "проявляться" в моих темах.

Vlad04 пишет:

цитата:

Вперед, Сергей, твори. Будем смотреть , критиковать.

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

 Отправлено: 18.04.10 19:43. Заголовок: Наиль пишет (11.04.1..

Наиль пишет (11.04.10 23:52.):

цитата:

К следующему воскресению тоже постараюсь состряпать прототип.

Воскресенье заканчивается, а мы всё ждём! И ... ?

 Отправлено: 18.04.10 21:01. Заголовок: Proxy пишет: Воскре..

Proxy пишет:

цитата:

Воскресенье заканчивается, а мы всё ждём! И ... ?

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

 Отправлено: 18.04.10 21:42. Заголовок: Наиль пишет: Извинит..

Наиль пишет:

цитата:

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

Наверное после "Курса молодого бойца"
Но, как бы то ни было, всё равно ждём

 Отправлено: 21.04.10 21:12. Заголовок: Proxy пишет: Наверн..

Proxy пишет:

цитата:

Наверное после "Курса молодого бойца" Но, как бы то ни было, всё равно ждём

Так как времени писать программу нет, то я пишу письма.
Одно из них я направил Алексею Волкову с предложением открыть исходные коды программы Script Builder, которую он забросил много лет назад.
Вот что он пишет в ответ:
Здравствуйте, Наиль.
Извиняюсь за задержку с ответом, я тут застрял в аэропорту, в интернете
появляюсь не регулярно.

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

Открыть исходники или передать разработку был бы выход,
но от этого шага меня удерживает одна "небольшая" проблема - движок-то
проприетарный, и исключительные права на него принадлежат некой
австралийской фирме Dream Company (они ещё живы?). И даже автор движка
не думаю что в силах что-то изменить. Я как основной разработчик среды и
контрибьютор движка имею исходники (свой форк) и лицензию на исходники,
но я не правообладатель. Я не имею право раскрывать исходники движка. А
это главный тормоз.

Попробуйте поговорить с Сергеем Костинским, может он лучше знает, кому
сейчас принадлежат права на движок. Если они согласны раскрыть свои
исходники под GPL или LGPL, то и я не буду возражать против раскрытия
своих.
Насколько я понял по сайту http://www.dreamcompany.com/ фирма Dream Company стала частью фирмы Altium. Т.е. продолжает использовать и продавать тот код, как часть других продуктов.
Так что здесь облом.