█ 22.11.2021 17:38
Абыдно? – Да!!!
За потерянные 2 недели времени, изучения тенденции «развития» инструмента разработки, глубины владения инструментом у уважаемых мной профессионалов, попытки перевода своих систем на новый инструмент…
«Взглянув» на дату версии xHarbour, на которой создаются мои системы – v.1.2.1 от 2010 года вспомнил о ряде его ограничений, например невозможности отправки файлов с длинными именами на FTP и имея чуть свободного времени решил изучить, что нового в нём появилось, опробовать и перевести на новую, последняя 1.3.1 от 20.12.2020 версию инструмента свои системы, надеясь, что в ней решены проблемы старых релизов. Тем более, что постоянные потуги Олега: https://olegon.ru/showthread.php?t=36235 и захотелось проверить мой скептицизм по данным вопросам.
В начале решил «по легкому», задав конкретные вопросы профессионалам – печальный, забытый опыт общения со спецами в OpenSource описан: https://olegon.ru/showthread.php?t=11200&page=3, где получил, как основной совет - «Просто перекомпилируйте свой проект на Harbour - и все станет ясно. Если вы не используете какие-нибудь специфические штучки xHarbour, то высока вероятность того, что все будет компилироваться и работать»… Замечу, что он разумный для мелких (до 1000 строк кода) поделок. Как впоследствии убедился, что «совет» давался без анализа ими последствий «перехода».
Конечно с некоторым трудом, т.к. профи сами пользовались так или иначе устаревшими версиями, до-был самый свежий релиз инструмента и начал перекомпиляцию с мелких программ. Конечно «выплыли» ожидаемые несовместимости, в основном связанные с тем, что компилятор стал более строгим, но и выявилось, что сейчас компилятор даёт «слепую» диагностику, т.е. просто обозначая наличие ошибок, но не указывая их положение и смысл. Задал вопрос, как задать опции компилирования, что бы видел ошибки, как раньше – в ответ «тишина». Путем экспериментов подобрал способ помодульной проверки и поделился со спецами, а судя по «спасибам» - это было не очевидно.
В течении 4 дней «победил» почти все несовместимости и смог собирать все системы. Встретилась проблема и надеялся, что в этот конкретном техническом нюансе помогут. В шапке окна «УС Лэнд:ЕГАИС» вместо осмысленного текста появилась, меняющаяся при каждом запуске абрадабра.
Конечно на этот вопрос появились конкретные советы с приведением примеров кода. Сделал самостоя-тельный пример – всё отражается правильно, но тот же код в «УСЕга» давал косячное отражение. Всё описал, задал вопрос – где копать, получаю уже в ответ сарказм и пожелания искать, где неверно кодирую. Потеряв пару часов нашел ошибку последней версии разработки, которая порождала косяк в отражении шапки окна и способ её обойти… Профи согласились проверив на демо задачках и уже без сарказма.
Затем уже продолжил серьёзное тестирование нового инструмента, благо чудачества ФРАП: https://olegon.ru/showthread.php?t=36194 вынудили переделать 80% модулей систем и переделку, отладку делал на новом инструменте… Так, как мне приходится в плане сопровождения юзать реальные БД пользователей оставил и сборку программы и на старом инструменте, периодически сличая результаты работы, но код правил по новый релиз… Пока вдруг не закралось подозрение, что программы на новом инструменте работают медленнее? Остановился, начал сравнивать время построения отчетов и «долгих» режимов сборок на старом и новом инструменте… и «офигел» - программы на новом инструменте, в среднем на 33% работают медленнее (видимо убили скорость создавая более универсальные механизмы), как пример:
Основными преимуществами программ семейства «УС Лэнд» являются: быстродействие при вводе и анализе данных, глубина проработки бизнес процессов, а тут, сменив инструмент нивелирую преимущества и ради чего? Конечно дал профессионалам мои результаты тестов и хорошо, что уже не получил очередного совета так же протестить, например на Harbоur – ещё потерять месяц, а иначе моя реакция была бы неадекватной.
Что дальше? Оставил старый инструмент и вернул все программы «УС Лэнд» на него, а с «ограничениями», которые меня беспокоили… Вспомнил свойства инструмента – могу взять исходник нужного мне режима нового релиза, т.к. система разработки OpenSource, подключить в сбоку своей программы и тогда он заменит «старый» режим инструмента, а можно к «старому» инструменту подключать новые библиотеки, т.е. варианты остаться в современном тренде заложены при «рождении» xHarbour.
Изучал, чем же занимаются разработчики xHarbour? За последние 4 года в «основу» инструмента не добавлено ничего нового, а лишь исправлялись косяки, пока не нужных мне возможностей, а так же адаптировали его под серверные операционные системы и для работы программ на нем в среде серверных компьютеров, в частности майнфреймов от IBM.
За потерянные 2 недели времени, изучения тенденции «развития» инструмента разработки, глубины владения инструментом у уважаемых мной профессионалов, попытки перевода своих систем на новый инструмент…
«Взглянув» на дату версии xHarbour, на которой создаются мои системы – v.1.2.1 от 2010 года вспомнил о ряде его ограничений, например невозможности отправки файлов с длинными именами на FTP и имея чуть свободного времени решил изучить, что нового в нём появилось, опробовать и перевести на новую, последняя 1.3.1 от 20.12.2020 версию инструмента свои системы, надеясь, что в ней решены проблемы старых релизов. Тем более, что постоянные потуги Олега: https://olegon.ru/showthread.php?t=36235 и захотелось проверить мой скептицизм по данным вопросам.
В начале решил «по легкому», задав конкретные вопросы профессионалам – печальный, забытый опыт общения со спецами в OpenSource описан: https://olegon.ru/showthread.php?t=11200&page=3, где получил, как основной совет - «Просто перекомпилируйте свой проект на Harbour - и все станет ясно. Если вы не используете какие-нибудь специфические штучки xHarbour, то высока вероятность того, что все будет компилироваться и работать»… Замечу, что он разумный для мелких (до 1000 строк кода) поделок. Как впоследствии убедился, что «совет» давался без анализа ими последствий «перехода».
Конечно с некоторым трудом, т.к. профи сами пользовались так или иначе устаревшими версиями, до-был самый свежий релиз инструмента и начал перекомпиляцию с мелких программ. Конечно «выплыли» ожидаемые несовместимости, в основном связанные с тем, что компилятор стал более строгим, но и выявилось, что сейчас компилятор даёт «слепую» диагностику, т.е. просто обозначая наличие ошибок, но не указывая их положение и смысл. Задал вопрос, как задать опции компилирования, что бы видел ошибки, как раньше – в ответ «тишина». Путем экспериментов подобрал способ помодульной проверки и поделился со спецами, а судя по «спасибам» - это было не очевидно.
В течении 4 дней «победил» почти все несовместимости и смог собирать все системы. Встретилась проблема и надеялся, что в этот конкретном техническом нюансе помогут. В шапке окна «УС Лэнд:ЕГАИС» вместо осмысленного текста появилась, меняющаяся при каждом запуске абрадабра.
Конечно на этот вопрос появились конкретные советы с приведением примеров кода. Сделал самостоя-тельный пример – всё отражается правильно, но тот же код в «УСЕга» давал косячное отражение. Всё описал, задал вопрос – где копать, получаю уже в ответ сарказм и пожелания искать, где неверно кодирую. Потеряв пару часов нашел ошибку последней версии разработки, которая порождала косяк в отражении шапки окна и способ её обойти… Профи согласились проверив на демо задачках и уже без сарказма.
Затем уже продолжил серьёзное тестирование нового инструмента, благо чудачества ФРАП: https://olegon.ru/showthread.php?t=36194 вынудили переделать 80% модулей систем и переделку, отладку делал на новом инструменте… Так, как мне приходится в плане сопровождения юзать реальные БД пользователей оставил и сборку программы и на старом инструменте, периодически сличая результаты работы, но код правил по новый релиз… Пока вдруг не закралось подозрение, что программы на новом инструменте работают медленнее? Остановился, начал сравнивать время построения отчетов и «долгих» режимов сборок на старом и новом инструменте… и «офигел» - программы на новом инструменте, в среднем на 33% работают медленнее (видимо убили скорость создавая более универсальные механизмы), как пример:
Основными преимуществами программ семейства «УС Лэнд» являются: быстродействие при вводе и анализе данных, глубина проработки бизнес процессов, а тут, сменив инструмент нивелирую преимущества и ради чего? Конечно дал профессионалам мои результаты тестов и хорошо, что уже не получил очередного совета так же протестить, например на Harbоur – ещё потерять месяц, а иначе моя реакция была бы неадекватной.
Что дальше? Оставил старый инструмент и вернул все программы «УС Лэнд» на него, а с «ограничениями», которые меня беспокоили… Вспомнил свойства инструмента – могу взять исходник нужного мне режима нового релиза, т.к. система разработки OpenSource, подключить в сбоку своей программы и тогда он заменит «старый» режим инструмента, а можно к «старому» инструменту подключать новые библиотеки, т.е. варианты остаться в современном тренде заложены при «рождении» xHarbour.
Изучал, чем же занимаются разработчики xHarbour? За последние 4 года в «основу» инструмента не добавлено ничего нового, а лишь исправлялись косяки, пока не нужных мне возможностей, а так же адаптировали его под серверные операционные системы и для работы программ на нем в среде серверных компьютеров, в частности майнфреймов от IBM.
█ 01.07.2022 09:16
Цитата:
Что за прога? Хотя не важно! FinSoft ➤ Андрей, извиняюсь, запустил из любопытства твою прогу от 2018 году, которая без пароля. У меня стойкое впечатление, что там эмулятор. Обработка нажатия клавиш прямо с заметно задержкой проходит по сравнению с обычным виндовым приложением. Far, к примеру, работает быстро, он вроде как консольный. Это из-за старой версии может?
Помню писалось на форуме.... При смене инструмента разработки в 2010 году с Clipper - чистый Dos на многоплатформенный xHarbour... и смены наименования системы обратил внимание на некоторые (менее 0.1 секунды) замедление реакции на нажатие клавиш... Разбирался на форуме разработчиков на данном инструменте... по началу, по их мнению - всё нормально и ничего не меняется... Потом всё же их достал упрощенными примерами Clipper и Harbour приложения, проводили множество тестов и сборок... и пришли к коллективному мнению - проблема в драйверах терминала.
Терминал - библиотека взаимодействия с драйверами ОС отражения инфа на экране. Их на выбор более 3 видов, различающих наборов функция работы с экраном, полноты поддержки возможностей операционных систем Windows, Linux, OS/2, MacOS и т.д. Отчасти от драйвера терминала зависит интерфейс программы.
Задержки, которые не замечают пользователи GUI программ, но бросались в глаза пользователям Dos программы - плата за использования графических средств ОС и универсальности по операционным системам (многоплатформеность), частично лечиться ускорением ОС клавиш, например скорости нажатия, но главное пользователи за 12 лет привыкли и не замечают этих задержек.
█ 01.07.2022 09:55
Прога которая Егаис.
Меня удивило, что в far таких задержек я не вижу. Такие задержки один в один возникают, если запускать 16 разрядные досовские программы в 32 битной винде. Я так понимаю, что эмуляция имеет место быть. По большому счету, запуск 32 битных оконных приложений в 64 битной винде тоже использует эмуляцию, только там таких задержек нет, поскольку сама архитектура сохраняется.
Меня удивило, что в far таких задержек я не вижу. Такие задержки один в один возникают, если запускать 16 разрядные досовские программы в 32 битной винде. Я так понимаю, что эмуляция имеет место быть. По большому счету, запуск 32 битных оконных приложений в 64 битной винде тоже использует эмуляцию, только там таких задержек нет, поскольку сама архитектура сохраняется.
█ 01.07.2022 10:51
Цитата:
Всё не так и напутал теплое с мягким... а главное, если создатель GUI программ обращает внимание на задержке, то нужно разбираться с ОС... и их нельзя измерить, а лишь субъективные ощущения FinSoft ➤ Меня удивило, что в far таких задержек я не вижу. Такие задержки один в один возникают, если запускать 16 разрядные досовские программы в 32 битной винде. Я так понимаю, что эмуляция имеет место быть. По большому счету, запуск 32 битных оконных приложений в 64 битной винде тоже использует эмуляцию, только там таких задержек нет, поскольку сама архитектура сохраняется
1. КИС Lack была Dos приложением, допускающее максимум 32 разрядную ОС... И задержки почувствовал в сравнении с ней;
2. Far работает напрямую со средствами интерфейса, по сути через api win, а как описал. УС Land работает с ОС через дополнительные терминальные драйвера, а драйвера, которые есть в библах в исходных кодах не используют api win, а универсальны по отношению к операционной системе
... как отметил - признаю наличие "задержек" в ощущениях... ускорь клавиатуру средствами Win и "будет счастье"
█ 01.07.2022 16:23
xHarbour и Harbour очень близкие родственники, пересекаемые по функционалу на 98%. Сообщество xHarbour постепенно уменьшается, а Harbour наоборот достаточно динамично развивается, т.ч. возможна миграция "УС Лэнд" на него. Оставлю, как:
1. Напоминалку, обновляемый мануал по Harbour
2. Инструкцию, для желающих изучить данный инструмент... Ссылка:
1. Напоминалку, обновляемый мануал по Harbour
2. Инструкцию, для желающих изучить данный инструмент... Ссылка:
█ 20.01.2023 11:09
Неоднократно упоминал, что инструмент разработки - надстройка над классическим С++... Вот решил показать на простом примере - нашел мелкую программу для теста влияния функции "паузы" на остальные работающие приложения.
1. Исходный код с комментариями.
2. Всё, как бы написано на презренном ЯП xBase, однако команды xBase типа @ 0,0 SAY или WAIT - это просто инструкции предпроцессора и как показывал выше данными инструкциями легко описать все конструкции ЯП 1С:Предприятие или Pascal, т.е. программа может писаться на "любимом" ЯП... Только нужно создать схему языка.
При анализе синтаксиса компилятором Harbour исходная программа преобразуется в так называемый p-code: https://olegon.ru/showpost.php?p=389244&postcount=66 и уже его анализирует компилятор. Увидеть данный код можно установив ключ компиляции -p. Покажу его - команды xBase преобразовались в набор процедур, функций ЯП и удалены комментарии:
3. При отсутствии ошибок компиляции исходный код на ЯП Harbour преобразуется в исходный код на классическом C++, но указывается для компилятора С++ какого производителя он создан. Как правило дистрибутив системы разработки Harbour поставляется на одного из 5-10 компиляторов С++. Я использую Borland C++ 5.0 как наиболее совместимый с любой версией Windows, начиная от Windows 95. Что получается после работы компилятора Harbour:
... Понятно, что данный С++ код могу в дальнейшем как угодно использовать и дорабатывать, но не настолько хорошо, а точнее вообще не знаю C?
1. Исходный код с комментариями.
Код:
* -----------------------------------------------------------------------------------------------------------------
* Тестовая программа проверки влияния Inkey на быстродействие остальных программ, работающих на данном компьютере
PROC Main()
LOCA nCount:=0
Inkey(1)
@ 0,0 SAY "Нажмите клавищу Esc для заверщения программы"
WHIL Inkey(10) <> 27
++nCount
END
CLS
WAIT "Сделано "+Str(nCount,4)+" шагов"
RETU При анализе синтаксиса компилятором Harbour исходная программа преобразуется в так называемый p-code: https://olegon.ru/showpost.php?p=389244&postcount=66 и уже его анализирует компилятор. Увидеть данный код можно установив ключ компиляции -p. Покажу его - команды xBase преобразовались в набор процедур, функций ЯП и удалены комментарии:
Код:
PROC Main()
LOCA nCount:=0
Inkey(1)
DevPos( 0, 0 ) ; DevOut( "Нажмите клавищу Esc для заверщения программы" )
WHIL Inkey(10) <> 27
++nCount
END
Scroll() ; SetPos(0,0)
__Wait( "Сделано "+Str(nCount,4)+" шагов" )
RETU Код:
/*
* xHarbour build 1.2.1 Intl. (SimpLex) (Rev. 6633)
* Generated C source code from <pinkey.PRG>
* Command: pinkey.PRG -gc
* Created: 2023.01.20 11:35:19 (Borland C++ 5.5.1 (32 bit))
*/
#include "hbvmpub.h"
#include "hbpcode.h"
#include "hbinit.h"
#define __PRG_SOURCE__ "pinkey.PRG"
HB_FUNC( PINKEY );
HB_FUNC( MAIN );
HB_FUNC_EXTERN( INKEY );
HB_FUNC_EXTERN( DEVPOS );
HB_FUNC_EXTERN( DEVOUT );
HB_FUNC_EXTERN( SCROLL );
HB_FUNC_EXTERN( SETPOS );
HB_FUNC_EXTERN( __WAIT );
HB_FUNC_EXTERN( STR );
#undef HB_PRG_PCODE_VER
#define HB_PRG_PCODE_VER 10
#include "hbapi.h"
HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_PINKEY )
{ "PINKEY", {HB_FS_PUBLIC | HB_FS_LOCAL | HB_FS_FIRST}, {HB_FUNCNAME( PINKEY )}, &ModuleFakeDyn },
{ "MAIN", {HB_FS_PUBLIC | HB_FS_LOCAL}, {HB_FUNCNAME( MAIN )}, &ModuleFakeDyn },
{ "INKEY", {HB_FS_PUBLIC}, {HB_FUNCNAME( INKEY )}, NULL },
{ "DEVPOS", {HB_FS_PUBLIC}, {HB_FUNCNAME( DEVPOS )}, NULL },
{ "DEVOUT", {HB_FS_PUBLIC}, {HB_FUNCNAME( DEVOUT )}, NULL },
{ "SCROLL", {HB_FS_PUBLIC}, {HB_FUNCNAME( SCROLL )}, NULL },
{ "SETPOS", {HB_FS_PUBLIC}, {HB_FUNCNAME( SETPOS )}, NULL },
{ "__WAIT", {HB_FS_PUBLIC}, {HB_FUNCNAME( __WAIT )}, NULL },
{ "STR", {HB_FS_PUBLIC}, {HB_FUNCNAME( STR )}, NULL }
HB_INIT_SYMBOLS_END( hb_vm_SymbolInit_PINKEY )
#if defined(__ICL)
#pragma warning(disable:177)
#endif
#if defined( HB_PRAGMA_STARTUP )
#pragma startup hb_vm_SymbolInit_PINKEY
#elif defined( HB_DATASEG_STARTUP )
#define HB_DATASEG_BODY HB_DATASEG_FUNC( hb_vm_SymbolInit_PINKEY )
#include "hbiniseg.h"
#endif
HB_FUNC( PINKEY )
{
static const BYTE pcode[] =
{
/* 00000 */ HB_P_BASELINE, 1, 0, /* 1 */
HB_P_ENDPROC
/* 00004 */
};
hb_vmExecute( pcode, symbols );
}
HB_FUNC( MAIN )
{
static const BYTE pcode[] =
{
HB_P_FRAME, 1, 0, /* locals, params */
/* 00003 */ HB_P_BASELINE, 5, 0, /* 5 */
HB_P_LOCALNEARSETINT, 1, 0, 0, /* NCOUNT 0*/
/* 00010 */ HB_P_LINEOFFSET, 1, /* 6 */
HB_P_PUSHSYMNEAR, 2, /* INKEY */
HB_P_PUSHNIL,
HB_P_ONE,
HB_P_DOSHORT, 1,
/* 00018 */ HB_P_LINEOFFSET, 3, /* 8 */
HB_P_PUSHSYMNEAR, 3, /* DEVPOS */
HB_P_PUSHNIL,
HB_P_ZERO,
HB_P_ZERO,
HB_P_DOSHORT, 2,
HB_P_PUSHSYMNEAR, 4, /* DEVOUT */
HB_P_PUSHNIL,
HB_P_PUSHSTRSHORT, 45, /* 45 */
141, 160, 166, 172, 168, 226, 165, ' ', 170, 171, 160, 162, 168, 233, 227, ' ', 'E', 's', 'c', ' ', 164, 171, 239, ' ', 167, 160, 162, 165, 224, 233, 165, 173, 168, 239, ' ', 175, 224, 174, 163, 224, 160, 172, 172, 235, 0,
HB_P_DOSHORT, 1,
/* 00079 */ HB_P_LINEOFFSET, 4, /* 9 */
HB_P_PUSHSYMNEAR, 2, /* INKEY */
HB_P_PUSHNIL,
HB_P_PUSHBYTE, 10, /* 10 */
HB_P_FUNCTIONSHORT, 1,
HB_P_PUSHBYTE, 27, /* 27 */
HB_P_NOTEQUAL,
HB_P_JUMPFALSENEAR, 8, /* 8 (abs: 00099) */
/* 00093 */ HB_P_LINEOFFSET, 5, /* 10 */
HB_P_LOCALNEARINC, 1, /* NCOUNT */
HB_P_JUMPNEAR, 238, /* -18 (abs: 00079) */
/* 00099 */ HB_P_LINEOFFSET, 7, /* 12 */
HB_P_PUSHSYMNEAR, 5, /* SCROLL */
HB_P_PUSHNIL,
HB_P_DOSHORT, 0,
HB_P_PUSHSYMNEAR, 6, /* SETPOS */
HB_P_PUSHNIL,
HB_P_ZERO,
HB_P_ZERO,
HB_P_DOSHORT, 2,
/* 00113 */ HB_P_LINEOFFSET, 8, /* 13 */
HB_P_PUSHSYMNEAR, 7, /* __WAIT */
HB_P_PUSHNIL,
HB_P_PUSHSTRSHORT, 9, /* 9 */
145, 164, 165, 171, 160, 173, 174, ' ', 0,
HB_P_PUSHSYMNEAR, 8, /* STR */
HB_P_PUSHNIL,
HB_P_PUSHLOCALNEAR, 1, /* NCOUNT */
HB_P_PUSHBYTE, 4, /* 4 */
HB_P_FUNCTIONSHORT, 2,
HB_P_PLUS,
HB_P_PUSHSTRSHORT, 7, /* 7 */
' ', 232, 160, 163, 174, 162, 0,
HB_P_PLUS,
HB_P_DOSHORT, 1,
/* 00151 */ HB_P_LINEOFFSET, 9, /* 14 */
HB_P_ENDPROC
/* 00154 */
};
hb_vmExecute( pcode, symbols );
} ... Понятно, что данный С++ код могу в дальнейшем как угодно использовать и дорабатывать, но не настолько хорошо, а точнее вообще не знаю C?
█ 20.01.2023 15:31
Тут вопрос терминологии. Раньше под словом компилятор понимали преобразование исходного текста программы на каком-либо языке в машинный код. Преобразование во что-то другое, например, в пи код, называлось транслятор. Потом маркетологи начали все называть компилятром, окончательно всех запутав. Я предпочитаю для себя использовать начальную терминологию.
Компиляторы часто имеют фронт и бэк. Фронт преобразует синтаксис исходного языка в некий промежуточный байт код, а бэк из него в машинный код. Так, например, работают компиляторы jpi, которые использует кларион. Jpi это отдел разработки языков, выделившийся в отдельную фирму после раскола в Борланде, который в дальнейшем начал продавать чужой компилятор. Jpi делал компиляторы для модулы2, с, с++, паскаля. Все они использовали один бэк. И сейчас в кларионе можно прямо писать блоки кода на этих языках внутри кода на кларионе (смешанное программирование), система это обрабатывает, только сейчас этим крайне редко кто-то пользуется.
Трансляция из одного языка в другой достаточно популярная тема. Например, проект basic4x транслирует синтаксис бейсика в джаву и может работать на широком спектре операционных систем. Он, кстати, сейчас бесплатный, финансируется Nasa. Я его использую для написания небольших приложений для мобильных устройств на андроиде. Был ещё проект трансляции синтаксиса клариона в джаву, он есть в сети, но автор его уже в лучшем мире. Пытались делать clarion#, который транслировался в c#, проект так и не взлетел, хотя денег потратили немало.
Если харбор транслирует код в с++, то это неплохой вариант. Если нравится синтаксис клиппера. Как минимум, можно, наверно, относительно безболезненно перейти на 64 битный компилятор. У нас на кларионе с этим хуже. Разработчики из jpi и созданного на его базе topspeed или на других проектах, или в лучшем мире. Компилятор работает хорошо, но развивать его уже некому, насколько я знаю. Вопрос с переходом на другие компиляторы повлечёт серьёзные переделки во всей инфраструктуре среды разработки. Ресурсов для этого тоже нет. Поэтому кларион будет жить, пока ms поддерживает 32 разрядный приложения. После этого банкет закончится, но вряд ли это случится скоро.
Компиляторы часто имеют фронт и бэк. Фронт преобразует синтаксис исходного языка в некий промежуточный байт код, а бэк из него в машинный код. Так, например, работают компиляторы jpi, которые использует кларион. Jpi это отдел разработки языков, выделившийся в отдельную фирму после раскола в Борланде, который в дальнейшем начал продавать чужой компилятор. Jpi делал компиляторы для модулы2, с, с++, паскаля. Все они использовали один бэк. И сейчас в кларионе можно прямо писать блоки кода на этих языках внутри кода на кларионе (смешанное программирование), система это обрабатывает, только сейчас этим крайне редко кто-то пользуется.
Трансляция из одного языка в другой достаточно популярная тема. Например, проект basic4x транслирует синтаксис бейсика в джаву и может работать на широком спектре операционных систем. Он, кстати, сейчас бесплатный, финансируется Nasa. Я его использую для написания небольших приложений для мобильных устройств на андроиде. Был ещё проект трансляции синтаксиса клариона в джаву, он есть в сети, но автор его уже в лучшем мире. Пытались делать clarion#, который транслировался в c#, проект так и не взлетел, хотя денег потратили немало.
Если харбор транслирует код в с++, то это неплохой вариант. Если нравится синтаксис клиппера. Как минимум, можно, наверно, относительно безболезненно перейти на 64 битный компилятор. У нас на кларионе с этим хуже. Разработчики из jpi и созданного на его базе topspeed или на других проектах, или в лучшем мире. Компилятор работает хорошо, но развивать его уже некому, насколько я знаю. Вопрос с переходом на другие компиляторы повлечёт серьёзные переделки во всей инфраструктуре среды разработки. Ресурсов для этого тоже нет. Поэтому кларион будет жить, пока ms поддерживает 32 разрядный приложения. После этого банкет закончится, но вряд ли это случится скоро.
█ 20.01.2023 17:02
FinSoft, Отмечу для меня главное - больше всего "греет" в системе разработки, что исходник, в силу специфики "транслятора" можно легко пересобрать под любую ОС (выше был сообщение о сборке под mainframe) и при этом не нужно переучиваться. Можно делать GUI интерфейс, родной под любую ОС и связываться с любой SQL БД. За упокой - как и любая не модная система разработки, она непрерывно "угасает"... Даже на международных форумах 1-3 сообщений в сутки
Цитата:
Для меня, как "оконечного" разработчика, а не системного программиста, нюансы терминологии мало беспокоят, т.к. в итоге сборки получается "машинный код". Как варианты "чудачества" разработчиков - есть многим известная по посещениям поликлиник и, не дай бог больниц, медицинская система "Барс".... Ядро сервисов и интерфейс реализован на С++, но большинство бизнес-функция и работа с БД на Harbour, т.е. не С++ встраивается в программу на Harbour, а модули на Harbour в программы на С++ в OS Linux. FinSoft ➤ Тут вопрос терминологии. Раньше под словом компилятор понимали преобразование исходного текста программы на каком-либо языке в машинный код. Преобразование во что-то другое, например, в пи код, называлось транслятор. Потом маркетологи начали все называть компилятром, окончательно всех запутав. Я предпочитаю для себя использовать начальную терминологию.
Компиляторы часто имеют фронт и бэк. Фронт преобразует синтаксис исходного языка в некий промежуточный байт код, а бэк из него в машинный код. Так, например, работают компиляторы jpi, которые использует кларион. Jpi это отдел разработки языков, выделившийся в отдельную фирму после раскола в Борланде, который в дальнейшем начал продавать чужой компилятор. Jpi делал компиляторы для модулы2, с, с++, паскаля. Все они использовали один бэк. И сейчас в кларионе можно прямо писать блоки кода на этих языках внутри кода на кларионе (смешанное программирование), система это обрабатывает, только сейчас этим крайне редко кто-то пользуется.
Трансляция из одного языка в другой достаточно популярная тема. Например, проект basic4x транслирует синтаксис бейсика в джаву и может работать на широком спектре операционных систем. Он, кстати, сейчас бесплатный, финансируется Nasa. Я его использую для написания небольших приложений для мобильных устройств на андроиде. Был ещё проект трансляции синтаксиса клариона в джаву, он есть в сети, но автор его уже в лучшем мире. Пытались делать clarion#, который транслировался в c#, проект так и не взлетел, хотя денег потратили немало.
Если харбор транслирует код в с++, то это неплохой вариант. Если нравится синтаксис клиппера. Как минимум, можно, наверно, относительно безболезненно перейти на 64 битный компилятор. У нас на кларионе с этим хуже. Разработчики из jpi и созданного на его базе topspeed или на других проектах, или в лучшем мире. Компилятор работает хорошо, но развивать его уже некому, насколько я знаю. Вопрос с переходом на другие компиляторы повлечёт серьёзные переделки во всей инфраструктуре среды разработки. Ресурсов для этого тоже нет. Поэтому кларион будет жить, пока ms поддерживает 32 разрядный приложения. После этого банкет закончится, но вряд ли это случится скоро.
Компиляторы часто имеют фронт и бэк. Фронт преобразует синтаксис исходного языка в некий промежуточный байт код, а бэк из него в машинный код. Так, например, работают компиляторы jpi, которые использует кларион. Jpi это отдел разработки языков, выделившийся в отдельную фирму после раскола в Борланде, который в дальнейшем начал продавать чужой компилятор. Jpi делал компиляторы для модулы2, с, с++, паскаля. Все они использовали один бэк. И сейчас в кларионе можно прямо писать блоки кода на этих языках внутри кода на кларионе (смешанное программирование), система это обрабатывает, только сейчас этим крайне редко кто-то пользуется.
Трансляция из одного языка в другой достаточно популярная тема. Например, проект basic4x транслирует синтаксис бейсика в джаву и может работать на широком спектре операционных систем. Он, кстати, сейчас бесплатный, финансируется Nasa. Я его использую для написания небольших приложений для мобильных устройств на андроиде. Был ещё проект трансляции синтаксиса клариона в джаву, он есть в сети, но автор его уже в лучшем мире. Пытались делать clarion#, который транслировался в c#, проект так и не взлетел, хотя денег потратили немало.
Если харбор транслирует код в с++, то это неплохой вариант. Если нравится синтаксис клиппера. Как минимум, можно, наверно, относительно безболезненно перейти на 64 битный компилятор. У нас на кларионе с этим хуже. Разработчики из jpi и созданного на его базе topspeed или на других проектах, или в лучшем мире. Компилятор работает хорошо, но развивать его уже некому, насколько я знаю. Вопрос с переходом на другие компиляторы повлечёт серьёзные переделки во всей инфраструктуре среды разработки. Ресурсов для этого тоже нет. Поэтому кларион будет жить, пока ms поддерживает 32 разрядный приложения. После этого банкет закончится, но вряд ли это случится скоро.
Часовой пояс GMT +3, время: 23:48.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.