Отправлено: 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). Скачать его можно с:
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 явно не хватит. То есть, одному мне такой проект не поднять...
Поэтому и пишу Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии?
А каковы преимущества компилятора? Парадоксально, но интепретатор интегрировать проще, и дёргаться-то будут всё те же методы через RTTI. Преимущества ActiveScript - возможность настраивания бизнес-логики на ходу. Плюс такие вкусности, как о отладка. Производительность хуже? Не будем же мы сравнивать производительность пустого обработчика Button1Click в скрипте с пустым нативным обработчиком? Даже на Pentium1 разницы не будет заметно. Встраивать VCL через RTTI, но в компилированный код обвязки - всё равно что тратить на водку, но экономить на спичках )) Ну это ИМХО.
Здесь, боюсь, Алексей, Вы "со своим уставом в чужой монастырь" Кроме того, что подобное явно противоречит представлениям сообщества, но это еще и вряд ли возможно технически. Похоже Вы не знаете, например, какой компилятор использует Харбор для получения исполняемого модуля, это Borland C, Pellle С, C от Microsoft и т.д. Компилятор Харбор называется таковым скорее по привычке, это "лексический анализатор" переводящий Клиппер синтаксис в PCode-"болванку" для С компилятора. Просто по коду можно использовать С, что часто и делается.. и.т.д. Вы думаете, все это можно повторить скриптом?
Alexey Volkov пишет:
цитата:
И моя сегодняшняя работа никаким местом с Дельфи не связана. Просто неожиданно вдруг совершенно разные люди, с разными задачами проявили интерес к проекту. Вплоть до предложений выкупить права. Ну а в свете последних изменений в Дельфи, мне кажется, хоронить проект или отказываться от него пока рано. Если перевести на компонентную базу 10ки, то он ещё столько же проживёт, пусть в закрытом виде, но кому оно интересно, что там внутри, если оно не будет глючить и будет дружить со сторонними компонентами?
Хоронить, конечно, не надо. Скриптинг вещь востребованная. Если переведете на 2010, будет очень солидно. Но нельзя ли сделать ветку и не для скриптовых языков тогда? В принципе, это даже несколько проще должно быть? Нужно же только IDE, "дизайнер форм", и поддержка отладчика... Никакого ран-тайм в "скриптовом смысле". Вот это бы было бы очень взаимно интересно..
Отправлено: 12.05.10 23:59. Заголовок: Петр пишет: цитата..
Петр пишет:
цитата:
цитата: К сожалению, я не знаком с Клипером-Харбором и не могу оценить красоту цитата: Я заинтересовался Delphi Run-Time для [x]Harbour (DRT4HB) потому, что из всего Харбора знаю лишь Delphi.
Очень точно характеризует обсуждение темы в последние дни
Да и еще перл:
Наиль пишет:
цитата:
Для Delphi сообщества это может быть интересно потому, что взамен смеси двух языков Pascal+SQL для проектирования баз данных можно получить один язык - Харбор
Но, Алексея, давайте "простим" (пока ) за нежелание хоть что-то узнать о предметной области
Здесь, боюсь, Алексей, Вы "со своим уставом в чужой монастырь" Кроме того, что подобное явно противоречит представлениям сообщества, но это еще и вряд ли возможно технически. Похоже Вы не знаете, например, какой компилятор использует Харбор для получения исполняемого модуля, это Borland C, Pellle С, C от Microsoft и т.д. Компилятор Харбор называется таковым скорее по привычке, это "лексический анализатор" переводящий Клиппер синтаксис в PCode-"болванку" для С компилятора. Просто по коду можно использовать С, что часто и делается.. и.т.д. Вы думаете, все это можно повторить скриптом?
С подобным "компилятором" я в данный момент работаю, только на PowerPC. точно так же трансляция в си, возможность правки болванки, компиляция в нативный код. Но там ресурсы сильно ограничены. Не думал, что на PC тоже актуальна борьба за такты.
Представлениям противоречит, но технически возможно, если IDispatch поддерживается. Повторить в скрипте можно всё, вопрос в задержках. Имхо, требования к задержкам на десктопе вообще и в ГУИ в частности несколько мягче, чем в системах реального времени. Впрочем, вам виднее. К тому же я вовсе не говорю о полной замене нативного кода скриптом, а лишь об обвязке (обработка событий, настраиваемая бизнес-логика), некритичной к задержкам.
Sergey Spirin пишет:
цитата:
Хоронить, конечно, не надо. Скриптинг вещь востребованная. Если переведете на 2010, будет очень солидно. Но нельзя ли сделать ветку и не для скриптовых языков тогда? В принципе, это даже несколько проще должно быть? Нужно же только IDE, "дизайнер форм", и поддержка отладчика... Никакого ран-тайм в "скриптовом смысле". Вот это бы было бы очень взаимно интересно..
Не сказал бы что проще. скорее сложнее. Ведь на выходе дизайнера вам нужно будет сгенерить не dfm, а что-то своё? в синтаксисе клиппера, конструирующее форму, с возможностью выборочной ручной правки, по типу SWING в JAVA, транслирующееся далее в pcode, потом в си, и тут мы теряем все преимущества разделения мух и котлет, ибо всё равно "позднее связывание". Я готов поспорить, что скорость создания формы из dfm всяко больше, чем создание её динамически из транслированного кода. Преимущества такого рантайма не очевидны, кроме возможности править исходник по F4, и собирать один екзешник. Возьмите для начала Generic IDispatch Proxy Classes, поиграйтесь с VCL объектами вручную Харборовском коде. Я очень сомневаюсь, что работать они будут быстрее, чем в скриптовом приложении.
Альтернативы конечно есть, но вы же не будете всерьёз рассматривать "раннее связывание"?
Представлениям противоречит, но технически возможно, если IDispatch поддерживается. Повторить в скрипте можно всё
Повторить... Теоретически, наверно, только Тут, фактически сразу 2 языка, один из которых С. То есть, указатели, структуры, препроцессор, ассемблерные и машинокодные вставки наконец Да и Клиппер-Харбор язык немолодой и накопил оччень значительное количество своих нетривиальных синтаксических конструкций
Alexey Volkov пишет:
цитата:
Имхо, требования к задержкам на десктопе вообще и ГУИ в частности несколько мягче, чем в системах реального времени.
Гм... Грид с юзерской отрисовкой в событии OnPaint? Скриптом...
Alexey Volkov пишет:
цитата:
а лишь об обвязке (обработка событий, настраиваемая бизнес-логика),
Насчет обработки событий не очень понимаю, что вы имеете в виду. А вот "настраиваемая бизнес-логика" - это безусловно востребованная скриптовая ниша. Кстати говоря, у вас SB сделан так, что генерит целиком скриптовое приложение. У меня какое-то ощущение, что более востребован скрипт как встраиваемае подсистема, а не "целиковое решение".
Alexey Volkov пишет:
цитата:
Не сказал бы что проще. скорее сложнее. Ведь на выходе дизайнера вам нужно будет сгенерить не dfm, а что-то своё?
Зачем? dfm конечно будет, зачем здесь что-то придумывать? "в синтаксисе клиппера" будет клипперный класс с конструктором в 2 строки вызова "дельфийской стороны". Первая создаст объект формы и загрузит dfm, вторая расставит обработчики событий. В чем проблема?
Повторить... Теоретически, наверно, только Тут, фактически сразу 2 языка, один из которых С. То есть, указатели, структуры, препроцессор, ассемблерные и машинокодные вставки наконец
Добавится третий, "managed", или "код обвязки", как мост между визуальной частью и первыми двумя.
Sergey Spirin пишет:
цитата:
Гм... Грид с юзерской отрисовкой в событии OnPaint? Скриптом...
Но Грид-то и вся иерархия под ним от этого не перестанет быть нативным win32 кодом на Паскале? Скриптовый только обработчик, который сегодня может вызывать одну нативную процедуру, а завтра другую, а послезавтра обе, и ещё "немножечко шить", и это без необходимости перекомпиляции и наличия полновесного средства разработки на объекте. В этом смысл managed-кода.
Конкретно по OnPaint в чистом скрипте - даже интересно попробовать. Вопрос, как будем замерять разницу? На глаз?
Sergey Spirin пишет:
цитата:
Насчет обработки событий не очень понимаю, что вы имеете в виду. А вот "настраиваемая бизнес-логика" - это безусловно востребованная скриптовая ниша. Кстати говоря, у вас SB сделан так, что генерит целиком скриптовое приложение. У меня какое-то ощущение, что более востребован скрипт как встраиваемае подсистема, а не "целиковое решение".
Я видимо непонятно объясняю. Надеюсь, сейчас насчёт событий объяснил понятно?
Насчёт встраиваемой подсистемы я уже по второму кругу захожу - да, именно это уже реализовано, и уже успешно внедрялось годы назад. Вы, видимо, невнимательно продукт изучили, есть там Script Builder for Applications, и я не вижу технических причин, почему нельзя его использовать в любом компилируемом приложении, умеющем работать с OleVariant. Естественно, с пониманием того, что делаешь, с пониманием разделения кода на native (time-critical) и managed. Ещё раз вам советую скачать пример, посмотреть, как оно работает, и представить, что екзешник у вас написан на Харборе, а скрипт - на чём угодно, возможно для вашего удобства - на XBScript. Если такая модель взаимодействия вас идеологически устраивает, то дальнейший разговор имеет смысл. Sergey Spirin пишет:
цитата:
Зачем? dfm конечно будет, зачем здесь что-то придумывать? "в синтаксисе клиппера" будет клипперный класс с конструктором в 2 строки вызова "дельфийской стороны". Первая создаст объект формы и загрузит dfm, вторая расставит обработчики событий. В чем проблема?
Если предложенная модель вас устраивает, то именно так и будет.
Если предложенная модель вас устраивает, то именно так и будет.
Так Вы готовы в этом участвовать? Супер! Тогда "пасьянс" складывается полностью. Если так, то я готов перейти от "размышлений" к делу.
Фронт работы выглядит тогда очень гармонично:
Петр и, возможно Паша (Паш, вы как?) - это Харбор сторона. Я - DelphiEngine, сопряжение с одной стороны с Харбор API, с другой с дезайн-тайм ("обвяжем" конечно ) Алексей - IDE, дезайн-тайм.
По Delphi2010 решим "как всегда"? То есть, работаем на хакнутом, платим, если продукт состоится?
Отправлено: 14.05.10 11:17. Заголовок: Моё участвие в общем..
Моё участвие в общем-то сведётся к апгрейду моего же продукта. Интерфейсы "наружу" революционным образом не поменяются. Конкретные шаги - портирование на 10ку, встраивание THarbourDataSet в палитру, регистрация XBScript. Консультирование, дебагирование.
Но есть определённые риски. Я не знаю, насколько гладко портируется старый инструментарий на новую компонентную базу, сколько времени это займёт и какой будет результат. Поэтому да, подход "как всегда" разумен, а финальную версию можно будет собрать на арендованном "облаке". Надо выяснить, сколько это стоит.
Отправлено: 14.05.10 11:43. Заголовок: Не смог, извините, с..
Не смог, извините, смолчать. Так все время гостем заходил. Sergey Spirin пишет:
цитата:
То есть, работаем на хакнутом, платим, если продукт состоится?
Ну вот и Spirin без глянца. А то "не люблю я этого". Работать, голубчик, тоже надо на легальном раз уж декларации такие. Это во-первых. Во-вторых, пасьянс был бы полон, если бы ИМХО для русскоязычного сообщества, на котором по мнению того же Spirin много не заработаешь, Run-time был бы бесплатен. А то как с FR, перефразируя известную песню "Горькую ягоду ели вместе, а сладкую ты одна!" Но это, наверное, решать нашим гуру, Кресину, "апостолам-хранителям" Петру и Павлу, Филатову и др. Или я не прав, мужики?
Отправлено: 14.05.10 11:50. Заголовок: Perec, имхо, не стои..
Perec, имхо, не стоит заострять на легальности. "Пусть первым кинет камень тот, кто сам безгрешен" Мало кто из нас использует все легальное (бесплатное). Пусть делают, на чем хотят. И вопрос платности (цены) - это вопрос авторов. Их дело - предложить, наше - ... ну а дальше каждый сам решит. Это мое мнение.
Уважаемый, PSP. Вопрос мой был только относительно "во-вторых". Причем я высказал пожелание, исходя из того, что участники форума могли бы, да и будут участвовать в тестировании и т.д. И еще. Без "наших гуру" никакой Run-Time не состоится. Если предположить, что продукт получится, (а я уверен, что при благоприятных условиях получится) то со временем он может стать (особенно, если еще и с отладчиком) конкурентом для Хaler, FiveWin и т.д. И поэтому спецам стоит задуматься о финансовых условиях участия в разработке. И не в последнюю, а в первую. А в остальном вы безусловно правы.
Perec, имхо, не стоит заострять на легальности. "Пусть первым кинет камень тот, кто сам безгрешен" Мало кто из нас использует все легальное (бесплатное). Пусть делают, на чем хотят. И вопрос платности (цены) - это вопрос авторов. Их дело - предложить, наше - ... ну а дальше каждый сам решит. Это мое мнение.
Полностью согласен с PSP !!! Если цена не будет выше чем у всяких Visual Harbour'ов и Xaler'ов, тогда нормально все ! Еще бы совместимость с Lunix обеспечить - было бы классно ! А в качестве тестера тоже согласен быть. Надоело писать программы без IDE... И гибриды надоели.....
Моё участвие в общем-то сведётся к апгрейду моего же продукта. Интерфейсы "наружу" революционным образом не поменяются. Конкретные шаги - портирование на 10ку, встраивание THarbourDataSet в палитру, регистрация XBScript. Консультирование, дебагирование.
Но есть определённые риски. Я не знаю, насколько гладко портируется старый инструментарий на новую компонентную базу, сколько времени это займёт и какой будет результат. Поэтому да, подход "как всегда" разумен, а финальную версию можно будет собрать на арендованном "облаке". Надо выяснить, сколько это стоит.
Возможно не все "гладко" переведется, в основном из-за Unicod-а. Если использовали много стороннего, нужны будут Уникодные версии и т.п.
>> регистрация XBScript.
Вот этот пункт мне все-таки не ясен, зачем нужен XBScript? Можно ли без него?
Ну вот и Spirin без глянца. А то "не люблю я этого". Работать, голубчик, тоже надо на легальном раз уж декларации такие.
Застыдил Ладно, я действительно "этого не люблю" и уже задумался о покупке Delphi2010 без привязки к этому проекту.
Perec пишет:
цитата:
Во-вторых, пасьянс был бы полон, если бы ИМХО для русскоязычного сообщества, на котором по мнению того же Spirin много не заработаешь, Run-time был бы бесплатен.
Гм... А что по этому поводу думают "мои коллеги"?
Perec пишет:
цитата:
А то как с FR, перефразируя известную песню "Горькую ягоду ели вместе, а сладкую ты одна!"
Чего-чего? Не понял. Все кто мне помогал лицензию получили бесплатно. Или о чем речь?
Чего-чего? Не понял. Все кто мне помогал лицензию получили бесплатно. Или о чем речь?
Исходя из Perec пишет:
цитата:
Во-вторых, пасьянс был бы полон, если бы ИМХО для русскоязычного сообщества, на котором по мнению того же Spirin много не заработаешь, Run-time был бы бесплатен.
я понял так, что Perec хотел бы поиметь ФастРепорт для Харбор бесплатно. Но нехороший Spirin не даёт, хотя сам пользуется халявной средой разработки .
Perec А если серьёзно, то я не могу купить Delphi 2010, т.к. программирование для меня всего лишь хобби и дохода не приносит. Мои потребности полностью закрываются TurboDelphi (я тоже не люблю пиратов). Даже те у кого Delphi куплен, как правило НЕ нуждаются в ещё одной (учитывая цену каждой версии). А на данный момент важно привлечь как можно больше соУчастников проекта. Поэтому и говорится о возможности участниками использовать такую Delphi2010, какую смогут себе позволить.
santy пишет:
цитата:
Ну с Линукс думаю будет тяжеловато, Делфи пока работает только под винду.
В конце октября должен выйти Delphi 2011 c поддержкой Linux, но это не поможет, т.к. SB под Windows.
Sergey Spirin пишет:
цитата:
Вот этот пункт мне все-таки не ясен, зачем нужен XBScript? Можно ли без него?
Хотя на этот вопрос отвечать Алексею, но мне кажется, что если начать с XBScript, то уже в этом году мы увидим полноценно работающий вариант, хотя и интерпетируемый, а не компилируемый. Без него конечно можно обойтись, но учитывая специфику SB, создание связки SB-Harbor равносильно приделыванию паровозу крыльев. Может и полетит, а может и нет.
Все даты в формате GMT
3 час. Хитов сегодня: 627
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии? 
Да и еще перл: 
Ладно, я действительно "этого не люблю" и уже задумался о покупке Delphi2010 без привязки к этому проекту. 
- участник сейчас на форуме
- участник вне форума