Форум » [x]Harbour » Delphi Run-Time for [x]Harbour (размышления). » Ответить
Delphi Run-Time for [x]Harbour (размышления).
Sergey Spirin: Здравствуйте. Все-таки не покидает меня мысль о том, что было бы очень неплохо организовать 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 явно не хватит. То есть, одному мне такой проект не поднять... Поэтому и пишу Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии? Жду ваши комменты Спирин Сергей.
Sergey Spirin: Наиль пишет: Delphi знаю хорошо, но вот с клипером-харбором (с кораблем и гаванью) только начинаю знакомиться. Привет! Вот здорово! Наконец-то я дождался дельфиста в этом "сумрачном" мире. То, что клиппер-харбор еще не знаете, это не страшно, тут ничего особо сложного нет, овладеете по ходу. Кстати, а какими судьбами в клиппер-харбор заносит? Обычно, здесь люди находятся по чисто историческим причинам только. По версии дельфей. "Перегнать" декларации классов по RTTI в харбор декларации в общем-то можно в любой версии дельфей. Но в любой версии, кроме 2010, все ограничится только секцией piblished. Нам же, для полноценной работы, нужно вытаскивать и полноценно управлять еще хотя бы всем из public. То есть, пришлось бы что-то додумывать, варианты конечно есть, но в 2010 это уже дают "на блюдечке"... Отсюда и мой интерес именно к 2010. Использовать Турбо в виду бесплатности заманчиво, но доп. писанины будет много, как бы не оказалось это "бесплатным сыром" Поэтому, если делать будем, то надо все-таки сразу определиться с версией дельфей, ну и подумать о переспективе покупки (у меня лицензионные только тройка и семерка). Ну а дальше можно будет распределить направления. Очень надеюсь, что совсем скоро у меня появится достаточно времени для этого проекта. Думаю, что моя первая задача - это адаптация и расширение, написанного для фаста движка на 2010. Вы, действительно, могли бы заняться "перегонкой классов", ну а по харбор конкретике, то есть, во что перегонять, как движок "цеплять" и т.д. заведовал бы Петр. Вроде все "логично" получается Основная проблема в таких проектах, конечно, время. Жду обсуждения
Наиль: Существует два (пока два) варианта решения задачи: сильнодинамический и слабодинамический. Предложенный выше вариант сильнодинамический. Суть решения в том, что нужно создать библиотеку-обёртку вокруг компонентов Delphi. Это позволит динамически создавать из харбора окна-формы любой сложности. Учитывая размер конфетки под обёрткой процесс может оказаться бесконечным и с неясной перспективой. Поэтому я пошел по второму пути. Попробую создать некий конструктор, который позволит создавать форму и генерировать соответствующий ей объектный код на Харборе. Задача сгенерированного кода обеспечить интерфейс для событий клавиатуры и мыши (в начальном варианте) и изменения свойств объектов-компонентов. Конструктор будет работать в отсутствии Delphi используя лишь bpl-файлы. При слабодинамическом решении компоненты нельзя не удалить, не добавить, можно лишь изменить свойства, например скрыть.
Andrey: Наиль пишет: будет работать в отсутствии Delphi используя лишь bpl-файлы. Позвольте вопрос ? А готовое приложение с чем будет ? В смысле: со своим EXE-ником и DLL-ки Delphi будут еще какие-то файлы ? Это не есть хорошо.... Мне нравится Harbour за его компактность !!!
Sergey Spirin: Наиль пишет: Существует два (пока два) варианта решения задачи: сильнодинамический и слабодинамический. Предложенный выше вариант сильнодинамический....... Привет, Наиль. Вообще говоря, понять однозначно то, что вы сказали (или хотели сказать), трудновато Думаю, что нужно определиться с терминологией, конечными целями и вытекающими из них задачами более конкретно. Итак, конечной целью проекта является полное портирование 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 Так как классов у нас очень немало, то такая перегонка должна быть полностью автоматизирована и продумана по объему. Ну вот, собственно, пока все мысли по этому поводу
Vlad04: Еще раз о целях. 1) Вряд ли Делфи нуждается в Нарборе. Там уже столько наворочено 2) У Нарбора ( как программист, занимающий прикладным программированием ) вижу ВСЕГО два недостатка: - отсутствие удобной отлаженной IDE для работы в графическом режиме . Но просто повторение Делфи - это, вообщем, шаг назад. Использование DataSEt совсем не производительный метод. По различным оценкам, если сравнивать Делфи, VBasic, Access ( это все системы быстрой разработки приложений) скорость разработки на Access раз в 5 выше, чем у первых двух.Здесь речь идет о принципах. - проддержка работы с SQL серверами , ставшими стандартом де-факто.
Sergey Spirin: Vlad04 пишет: Еще раз о целях. Влад, я очень ценю ваше желание пообщаться Но читать ваши суждения, честно говоря труд нелегкий Может, вам лучше не утверждать что-то, а просто спрашивать, если что-то непонятно? Vlad04 пишет: 1) Вряд ли Делфи нуждается в Нарборе Гм..х....г... А кто-то говорил, что нуждается? Кто? Влад, речь об использовании Delphi-функционала в Харбор приложении. Vlad04 пишет: Но просто повторение Делфи - это, вообщем, шаг назад. Чего-чего? От чего это шаг назад? От MiniGUI? (Григорий извините..) Vlad04 пишет: Использование DataSEt совсем не производительный метод. Это вообще читается примерно как: "Фармацевтический смысл туманности Андромеды" Что называется, хоть стой, хоть падай. Vlad04 пишет: скорость разработки на Access раз в 5 выше От такого сравнения, у меня уже просто "мозг клинит" Даже, что сказать, непонятно... Немая сцена с открытым ртом Влад! Пишите, повеселите еще!
Vlad04: Чего-чего? От чего это шаг назад? От MiniGUI? Нет , конечно. Я и пишу об одном из недостатков Харбор - отсутствие удобной отлаженной IDE для работы в графическом режиме. Использование DataSEt совсем не производительный метод Это вообще читается примерно как: "Фармацевтический смысл туманности Андромеды" Да, при разработке метод Select, используемый в Харбор, намного производительней DAtaset. Вы попробуйте создать вычисляемое поле или подставляемое поле в Делфи и Харборе и сравните потраченное время. скорость разработки на Access раз в 5 выше Увы, так оно и есть. Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе. Вообщем, чего чего, а сарказма у Вас на всех хватит.
Sergey Spirin: Привет, Влад! 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 пишет: Вообщем, чего чего, а сарказма у Вас на всех хватит. Надеюсь, сарказма здорового и необидного
Andrey: Vlad04 пишет: Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе. Подробней пожалуйста ! С фактами ! Мне тоже интересно узнать, кто так делает ! 2 раза писать систему ? Круто деньгами сорят ...
Vlad04: Не в обиду пишется. Я в своем опусе хотел выделить ЛУЧШИЕ стороны, имеющиеся в некоторых системах , а не системы в целом. Вы невнимательны. И про Select написано - при разработке. Т.е программист в Харбор оперируя RDD и Select пишет и вносит в программы изменения быстрее , чем это делается с DAtaSourse и DataSet в Делфи. Да и удобнее так (мне точно). Речь не идет о производительности готовых систем. Впрочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Делфи на Apollo приближается к Харбор и клипперу , но отстает все равно. И хотя Access в целом мне не нравится, но там есть очень удобные моменты. Возможно что-то подобное есть в Делфи2010, я пока использую Делфи 7.
Andrey: Vlad04 пишет: Впрочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Давай пример одинаковый сделаем ! Очень хочется сравнить скорости !!!
Dima: Andrey пишет: Очень хочется сравнить скорости !!! Еще бы хотелось сравнить 1с
Vlad04: Что мы отвлекаемся. Главное, сформулировать задачу для Сергея. А сила 1с в другом - в организации данных. В простом пересчете она , конечно, проиграет.
Sergey Spirin: Привет. 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-файл. У меня чуть челюсть об стол не стукнула
Vlad04: Не будем препираться, кто что сказал. Вперед, Сергей, твори. Будем смотреть , критиковать.
Sergey Spirin: Vlad04 пишет: Не будем препираться, кто что сказал. Сильно не люблю людей, не отвечающих за свои слова... Поэтому, просьба вам, не "проявляться" в моих темах. Vlad04 пишет: Вперед, Сергей, твори. Будем смотреть , критиковать. В дилетанских "речах" я не нуждаюсь, к тому же, если продукт состоится, то он будет явно не дешев, явно не для вас...
Proxy: Наиль пишет (11.04.10 23:52.): К следующему воскресению тоже постараюсь состряпать прототип. Воскресенье заканчивается, а мы всё ждём! И ... ?
Наиль: Proxy пишет: Воскресенье заканчивается, а мы всё ждём! И ... ? Извините, что не оправдал ваших ожиданий. Авральная неделя, пришлось работать без выходных. На прототип времени не осталось. Следующая неделя обещает быть такой же, так что даже не знаю, когда смогу что-то показать.
Proxy: Наиль пишет: Извините, что не оправдал ваших ожиданий. Авральная неделя, пришлось работать без выходных. На прототип времени не осталось. Следующая неделя обещает быть такой же, так что даже не знаю, когда смогу что-то показать. Наверное после "Курса молодого бойца" Но, как бы то ни было, всё равно ждём
Наиль: Proxy пишет: Наверное после "Курса молодого бойца" Но, как бы то ни было, всё равно ждём Так как времени писать программу нет, то я пишу письма. Одно из них я направил Алексею Волкову с предложением открыть исходные коды программы Script Builder, которую он забросил много лет назад. Вот что он пишет в ответ: Здравствуйте, Наиль. Извиняюсь за задержку с ответом, я тут застрял в аэропорту, в интернете появляюсь не регулярно. Странное что-то происходит, вы уже третий человек, кто интересуется Билдером за последний месяц, и это после нескольких лет затишья. Интересы у всех интересующихся диаметрально разные - один предлагает сделать "облачную" версию на дотнете, второй предлагает допиливать паскаль скрипт как есть, вы как я понял, просто хотите прикрутить клиппер. Открыть исходники или передать разработку был бы выход, но от этого шага меня удерживает одна "небольшая" проблема - движок-то проприетарный, и исключительные права на него принадлежат некой австралийской фирме Dream Company (они ещё живы?). И даже автор движка не думаю что в силах что-то изменить. Я как основной разработчик среды и контрибьютор движка имею исходники (свой форк) и лицензию на исходники, но я не правообладатель. Я не имею право раскрывать исходники движка. А это главный тормоз. Попробуйте поговорить с Сергеем Костинским, может он лучше знает, кому сейчас принадлежат права на движок. Если они согласны раскрыть свои исходники под GPL или LGPL, то и я не буду возражать против раскрытия своих. Насколько я понял по сайту http://www.dreamcompany.com/ фирма Dream Company стала частью фирмы Altium. Т.е. продолжает использовать и продавать тот код, как часть других продуктов. Так что здесь облом.
полная версия страницы