Чем отличается HB2 от HB1.1?

Форум » [x]Harbour » Чем отличается HB2 от HB1.1? » Ответить

Чем отличается HB2 от HB1.1?

wad1: Здравствуйте всем! Скачал HARBOUR2.0. Настроил пути и собрал проект. Исполняемый модуль увеличился. А что еще хорошего следует ожидать от замены компилятора? Спасибо за ответы!

Ответов - 35, стр: 1 2 All

PSP: http://www.harbour-project.org/news.html

wad1: Это я конечно видел. Но понимается с трудом (и дело не только в незнании английского). Хотелось бы по-русски узнать - кто какие преимущества реально ощутил после перехода на 2.0

PSP: Интересный вопрос... :) Мне думается, что каждый сам может выяснить, глядя на список изменений и дополнений, есть какие-либо преимущества лично для него или нет. Проект развивается - это главное "преимущество", имхо. :)

sergey5703: Выскажу сугубо личное мнение. Вот у меня на домашнем компьютере нет принтера, в Windows установлен принтер "Generic / Text Only" для которого указан порт вывода - файл на диске. И СКОЛЬКО HARBOUR-ОВ Я НЕ ПЕРЕПРОБОВАЛ - НИ ОДИН НЕ ХОЧЕТ В НЕГО ПЕЧАТАТЬ! А с xHarbour - легко и приятно иметь дело. Меня не интересует кросс-платформенность и GNU C++, и Linux я осваивать не собираюсь (вместе с Unix-ом). ИМХО!

PSP: sergey5703 пишет: в Windows установлен принтер "Generic / Text Only" для которого указан порт вывода - файл на диске. И СКОЛЬКО HARBOUR-ОВ Я НЕ ПЕРЕПРОБОВАЛ - НИ ОДИН НЕ ХОЧЕТ В НЕГО ПЕЧАТАТЬ! Только что попробывал. Нормально работает. Единственный момент: если написать следующий код SET PRINTER TO ( Win_PrinterGetDefault() ), то имя принтера по-умолчанию должно быть пригодным для создания файла ИмяПринтера.prn В нашем случае имя принтера - "Generic / Text Only". Думаю, не стоит объяснять, почему система не сможет создать файл с именем "Generic / Text Only.prn"... :) Можно просто установить принтер "Generic / Text Only" по-умолчанию и написать: SET PRINTER TO ( "SpoolFile" ) и получим файл "SpoolFile.prn"

wad1: Хочется услышать сравнительные характеристики по скорости, надежности и прочее. Например Harbour намного превосходит Clipper при сложных заданиях на локальной машине при работе одним пользователем. В сети при нескольких работающих станциях преимущество практически незаметно. А как с H2? И еще. В примерах поставки H2 есть пример терминального протокола. Кто-нибудь пробовал? Как я понял, для применения терминального доступа нужно несколько модифицировать свое приложение и запускать его на сервере. Кроме того, запустить там же терминальный сервер, а на рабочей станции - клиент. После этого приложение будет выполняться на сервере, а на клиент будут посылаться экраны, обратно - нажатия клавиш (может и мышь?). С печатью вроде бы не все гладко. Очень заманчивая вещь для многопользовательских систем. Может организуем клуб "терминальщиков"? Сообща веселее.

Pasha: Имеется в виду examples\terminal ? Я запускал этот пример по локальной сети, нажатие клавиш отрабатываеися с задержкой. Почему - не разбирался. Что касается удаленной печати, то ее можно сделать таким образом. Разработать класс RemotePrint. Обьект этого класса создается на терминальном сервере приложением вместо объекта класса Win_Prn В обработчике ERROR HANDLER на клиент должны передаваться имя метода с параметрами. На клиенте при этом будет создаваться уже обьект класса Win_Prn, выполняться его методы, и обратно возвращаться результат. Обработчик ERROR HANDLER на сервере вернет результат приложению. Такой же механизм можно использовать для работы и с дугими классами. Собственно можно сделать один подобный класс вида: CREATE CLASS TrmRemote DATA ServerClass DATA socket DATA handle METHOD New( cClass ) CONSTRUCTOR ERROR HANDLER OnError() ENDCLASS

wad1: Да, речь именно об этом. Прежде чем вкладывать в эту штуку время и другие ресурсы, хотелось бы узнать мнение гуру: это реальная вещь или игрушка, от которой до настоящей терминал-серверной работы - вечность?

Петр: wad1 пишет: это реальная вещь или игрушка, от которой до настоящей терминал-серверной работы - вечность? Это реальный пример и не более того. Вы можете его улучшить (или ухудшить ). Написание этого примера стало возможным благодаря использованию новых возможностей hb 2.0 (МТ, socket etc.) В ближайшем будущем Пржемек пообещал вернуться к работе над GTNET - "..Anyhow I plan to work on GTNET in the nearest future..", так что пожелаем ему удачи, себе терпения . Хочется услышать сравнительные характеристики по скорости, надежности и прочее. Ну, наверное, для такого сравнения надо специальные тесты писать. Естественно я этого не делал. Более того, я использую не официальные выпуски, а делаю регулярно свои сборки, поэтому четко определить разницу между 1.0 и 2.0 не могу Теоретически (и практически) за последний год-полтора Harbour стал быстрее, и способствовало этому два фактора - использование собственного менеджера памяти на базе dlmalloc и компилирование HVM в виде единого файла (hvmall.c), что позволяет С компиляторам проводить более глубокую оптимизацию генерируемого кода. Само собой разумеется скорость зависит от выбраной модели ST или MT, cкорость также зависит от того какой С компилятор вы используете. У меня два фаворита MSVC и MinGW. С MSVC можно использовать еще один альтернативный менеджер памяти hoard. Теперь о надежности, в hb 2.0 были исправлены некоторые ошибки и другие потенциально опасные вещи, могущие привести к RTE или GPF. Прежде чем вкладывать в эту штуку время и другие ресурсы Рекомендую потратить время на изучение новых возможностей hb 2.0, hbnetio, hbmemio. А к идее терминала вернуться чуть позже, после реализации GTNET.

Andrey: Петр пишет: изучение новых возможностей hb 2.0, hbnetio, hbmemio А что это такое ? Хоть несколько строк, чтоб понять....

Петр: Andrey, вы же пользуетесь xHarbour, зачем вам это нужно? В терминологии xHb hbmemio - это filemem, hbnetio - что-то вроде hbfilere, но покруче, поскольку кроме операций RDD позволяет также исполнение RPC.

Andrey: Петр пишет: вы же пользуетесь xHarbour, зачем вам это нужно? Я же не век сидеть буду на хХарборе.... Тем более все пишут, что Харбор быстрей.... А быстродействие своих программ я тоже хочу поднять... Тем более нужно стремиться к новому ! Петр пишет: В терминологии xHb hbmemio - это filemem, hbnetio - что-то вроде hbfilere, но покруче, поскольку кроме операций RDD позволяет также исполнение RPC. А по русски можно ? Ну не все такие разбирающиеся в технологиях .....

wad1: Похоже, что с помощью hbmemio можно создавать таблицы (в виде DBF) в памяти, индексировать их, обрабатывать, и все это без записи на диск. Скорость обработки видимо должна существенно возрасти, если памяти достаточно. Однако сможет ли другое приложение увидеть такую таблицу? Частенько временные таблицы создаются для передачи их, например, внешнему генератору отчетов.

PSP: Про hbnetio (чтобы исключить неточности, цитирую из ChangeLog) 2009-09-01 00:56 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) ............................................................................................................ + added new library: HBNETIO. It implements alternative RDD IO API which uses own TCP/IP sockets to exchange data between client and server. This library contains client and server code and is fully MT safe. On client side it's enough to execute: NETIO_CONNECT( [<cServer>], [<cPort>], [<nTimeOut>] ) -> <lOK> function to register alternative NETIO RDD API and set default server address and port. <cServer> - server addres (default 127.0.0.1) <cPort> - server port (default 2941) <nTimeOut> - connection timeout (default -1 - not timeout) Above settings are thread local and parameters of the 1-st successful connection are used as default values for each new thread. After registering NETIO client by above function each file starting "net:" prefix is automatically redirected to given NETIO server, i.e. use "net:mytable" It's also possible to pass NETIO server and port as part of file name, i.e.: use "net:192.168.0.1:10005:mytable" On the server side the following functions are available: create NETIO listen socket: NETIO_LISTEN( [<nPort>], [<cAddress>], [<cRootDir>] ) -> <pListenSocket> | NIL accept new connection on NETIO listen socket: NETIO_ACCEPT( <pListenSocket> [, <nTimeOut>] ) -> <pConnectionSocket> | NIL start connection server: NETIO_SERVER( <pConnectionSocket> ) -> NIL stop connection accepting or connection server: NETIO_SERVERSTOP( <pListenSocket> | <pConnectionSocket>, <lStop> ) -> NIL activate MT NETIO server (it needs MT HVM): NETIO_MTSERVER( [<nPort>], [<cAddress>] ) -> <pListenSocket> | NIL To create NETIO server is enough to compile and link with MT HVM this code: proc main() local pListenSocket pListenSocket := netio_mtserver() if empty( pListenSocket ) ? "Cannot start server." else wait "Press any key to stop NETIO server." netio_serverstop( pListenSocket ) pListenSocket := NIL endif return NETIO works with all core RDDs (DBF, DBFFPT, DBFBLOB, DBFNTX, DBFCDX, DBFNSX, SDF, DELIM) and any other RDD which inherits from above or use standard RDD IO API (hb_file*() functions). Without touching even single line in RDD code it gives the same functionality as REDBFCDX in xHarbour but for all RDDs. It's possible that such direct TCP/IP connection is faster then file server protocols especially if they need more then one IP frame to exchange data so it's one of the reason to use it in such cases. Please make real speed tests. The second reason to use NETIO server is resolving problem with concurrent access to the same files using Harbour applications compiled for different platforms, i.e. DOS, LINUX, Windows and OS2. It's very hard to configure all client stations to use correct locking system. NETIO fully resolves this problem so it can be interesting alternative also for MS-Windows users only if they do not want to play with oplocks setting on each station. I'm interesting in user opinions about real life NETIO usage.

Andrey: PSP пишет: Про hbnetio Это чтож получается, как у "alkresin" - драйвер LetoDB ? А кто реально пробовал эти штуки ? Ваши впечатления, господа ?

Pasha: Нет, это не клиент-сервер. При использовании netio доступ к файлам выполняется не через файловые операции: open, read и пр, а с помощью передачи данных по ip протоколу.

Петр: Да это не клиент-сервер, как пишет автор, это альтернативное RDD IO API, использующее свой очень простой TCP/IP файл сервер. Но, в версии 2.0.1 в HBNETIO протокол была добавлена поддержка RPC (удаленного вызова процедур). К примеру ? netio_funcexec( "upper", "hello world !!!" ) // Естественно такая функция должна существовать на стороне сервера. Что можно делать с таким комбинированным сервером, это уже сам программист должен решать. Но то, что это очень и очень расширяет возможности - это факт.

sergey5703: Не знаю, может я что то путаю, но мне кажется, что NETIO очень сильно смахивает на заготовку ядра будущего Харборовского SQL-сервера (пока без языка запросов и всего прочего). В тексте, процитированным PSP разработчик Przemyslaw Czerpak просит "Пожалуйста сделайте реальные тесты скорости", а также пишет: "Я интересуюсь пользовательскими мнениями о реальном использовании NETIO".

wad1: Вопрос: в случае применения NETIO нужно давать пользователю полные права на каталог с данными? Хочется надеяться, что нет. Однако как быть с источниками данных, не являющимися DBF-таблицами: INI-файлы, бланки отчетов и т.д.? Еще вопрос: если клиентов много, то сервер должен запускаться только один? А скольких клиентов он потянет? И последний (в этот раз): Смогут ли параллельно с сервером работать с этими же файлами сторонние подсистемы с корректным применением блокировок и корректировкой индексов?

Петр: в случае применения NETIO нужно давать пользователю полные права на каталог с данными нет Однако как быть с источниками данных, не являющимися DBF-таблицами: INI-файлы, бланки отчетов и т.д.? RPC, пока если клиентов много, то сервер должен запускаться только один? С технической стороны таких ограничений нет, вы можете запустить несколько сервером на одном компе используя разные порты, или несколько серверов в сети, создать вычислительный кластер А скольких клиентов он потянет? Попробуете, поделитесь информацией Смогут ли параллельно с сервером работать с этими же файлами сторонние подсистемы с корректным применением блокировок и корректировкой индексов? Что вы имеете ввиду под "сторонние подсистемы", если это приложения написанные на harbour - да.

полная версия страницы