Форум » LetoDB, HbNetio. » Leto DB Server » Ответить
Leto DB Server
Pasha: Добавил функцию: LETO_GROUPBY(cGroup, cFields, [cFilter], [xScopeTop], [xScopeBottom]) cGroup - имя поля, по которому группируются данные; cFields - список числовых полей через запятую, которые суммируются. Символ # обозначает к-во записей в группе Функция возвращает двумерный массив строк. 1-й элемент каждой строки - значение поля cGroup, следующие элементы суммы полей, заданных в cFields, или к-во записей в группе
Pasha: alx_on пишет: у меня и раньше работало (правда MAC OS X 64-бита и gcc) есть какая то разница между mingw64 и gcc? Да, собиралось и раньше, но в редких случаях могла быть некорректная работа Я убрал варнинги, кое-где поставил вместо ULONG 8-байтный HB_SIZE Думаю, для letodb64 надо давать возможность работать и 32, и 64 разрядным клиентам А в mingw64 используется тот же gcc
Pasha: Sergey Spirin пишет: Паш, и чего, ни разу приведения pointer к int по всему коду не было? Абалдеть! P.S. Не советую тешиться Заслуга в том, что легким движением руки брюки превратились в элегантные шорты, не в letodb, а в истинной многоплатформенности харбора. В харборе напрямую тип __int 64 (longlong) не используется, а используются свои типы, которые в зависимости от архитектуры могут быть 4-х байтными или 8-ми байтными Никто же не специально не делал letodb под MacOS. Оказалось достаточно его собрать, и работает
alx_on: Pasha пишет: Я убрал варнинги Появились новые server/letofunc.c: In function ...leto_Mgmt...: server/letofunc.c:5344: warning: format ...%I64u... expects type ...unsigned int..., but argument 19 has type ...HB_SIZE... server/letofunc.c:5344: warning: format ...%I64u... expects type ...unsigned int..., but argument 20 has type ...HB_SIZE... server/letofunc.c: In function ...leto_udf...: server/letofunc.c:7071: warning: format ...%I64u... expects type ...unsigned int *..., but argument 3 has type ...HB_SIZE *... server/letofunc.c:7071: warning: format ...%I64u... expects type ...unsigned int *..., but argument 3 has type ...HB_SIZE *...
Pasha: Это для 64-битной сборки ? Для mingw64 этих варнингов нет В некоторых компиляторах для 8-байтных целых используется формат не %I64u, а %llu Если использовать для LETO_SIZE_FORMAT %llu, варнинги будут ?
alx_on: Pasha пишет: Если использовать для LETO_SIZE_FORMAT %llu, варнинги будут ? warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 19 has type ‘HB_SIZE’ PS letodb: Mach-O 64-bit executable x86_64
alx_on: Заметил плохую вещь, пока не разбирался на клиенте cp1251 таблицы cp866 установка фильтра с русскими буквами (например: "FIELD->PARAM=='привет'") лажается такие записи точно есть (без лето работает) дополнение: в функции leto_SetFilter() принудительно вызывается leto_SetUserEnv() если вызов leto_SetUserEnv() убрать, то все нормально странно...
Pasha: alx_on пишет: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 19 has type ‘HB_SIZE’ PS letodb: Mach-O 64-bit executable x86_64 Странно. А что в этой сборке показывает sizeof(HB_SIZE) ? Должно быть 8
Pasha: Pasha пишет: Заметил плохую вещь, пока не разбирался на клиенте cp1251 таблицы cp866 установка фильтра с русскими буквами (например: "FIELD->PARAM=='привет'") лажается такие записи точно есть (без лето работает) дополнение: в функции leto_SetFilter() принудительно вызывается leto_SetUserEnv() если вызов leto_SetUserEnv() убрать, то все нормально странно... То есть, имеем установку: hb_SetCodepage( "RU1251" ) use ... codepage RU866 Фильтр устанавливаем в cp1251 На клиенте он перекодируется в 866, и сервер его получает в 866 На сервере leto_SetFilter() вызывает leto_SetUserEnv(), который на сервере устанавливает текущую cp1251 Поле при чтении на сервере перекодируется 866->1251, и сравнивается со строкой фильтра в 866. Фильтр не срабатывает. Вызов leto_SetUserEnv() на сервере нужен для установки формата даты, да и для кодовой страницы тоже, чтобы правильно работал upprt/lower Наверное, надо убрать перекодировку строки фильтра на клиенте, и передавать фильтр на сервер без перекодировки, чтобы сервер перекодировал значение поля, и сравнивал его с фильтром. Завтра внимательно протестирую.
alx_on: Pasha пишет: Должно быть 8 Так и есть sizeof(HB_SIZE)=8 компилятор i686-apple-darwin11-llvm-gcc-4.2
Pasha: Да, перекодировку строки фильтра на клиенте надо убрать. Еще, на сервере в leto_RequestArea можно не устанавливать hb_cdpSelect, ведь это делается в leto_SetUserEnv Можно правда включить в leto_RequestArea leto_SetUserEnv, надо подумать
alx_on: Pasha пишет: в leto_RequestArea можно не устанавливать hb_cdpSelect, ведь это делается в leto_SetUserEnv На каждое соединение свой поток В начале инициализации потока один раз вызвать leto_SetUserEnv() Плохо только, если клиент позже сменил, например, кодовую страницу через hb_cdpSelect() Но это и сейчас не отрабатывается в leto_RequestArea() надо устанавливать hb_cdpSelect т.к. я могу подряд вызвать, например, два USE с разными codepage даже не так - hb_cdpSelect надо устанавливать в leto_SelectArea (в одной команде используется много таблиц с разными codepage, например, в UDF) Przemysław Czerpak: On Tue, 24 May 2011, marek.horody...@interia.pl wrote: > Can I in this version, when yes - how, reduce the effects of hb_cdpSelect () only to the current thread? This is default behavior - hb_cdpSelect() changes codepage only for current threads. It does not effect any other threads. Look at doc/xhb-diff.txt, section "MULTI THREAD SUPPORT" Кстати, если использовать для LETO_SIZE_FORMAT %lu, то варнингов нет
Pasha: alx_on пишет: Кстати, если использовать для LETO_SIZE_FORMAT %lu, то варнингов нет Но они есть в mingw64. Надо определить формат, устраивающий все компиляторы, или считывать int не через sscanf Один и тот же формат %lu не может использоваться и для 4, и для 8-ми байтовых int Какая размерность int у i686-apple-darwin11-llvm-gcc-4.2 ? Прогоните тест func main ? 'Hello', U_Long(1), U_Long(2), U_Long(3), U_Long(4), U_Long(5) return nil #pragma BEGINDUMP #define LETO_SIZE_FORMAT "%I64u" #include "hbapi.h" HB_FUNC( U_LONG ) { int iSize = 0; switch( hb_parni(1) ) { case 1: iSize = sizeof( ULONG ); //4 break; case 2: iSize = sizeof( HB_SIZE ); //8 break; case 3: iSize = sizeof( int ); //4 break; case 4: iSize = sizeof( long ); //4 break; case 5: //8 iSize = sizeof( long long ); break; } hb_retnl( iSize ); } HB_FUNC( U_FORMAT ) { HB_SIZE nSize; long lNum; long long llNum; sscanf(hb_parc(1), "Read" LETO_SIZE_FORMAT ";", &nSize); sscanf(hb_parc(1), "%lu", &lNum); sscanf(hb_parc(1), "%lu", &llNum); sscanf(hb_parc(1), "%I64u", &llNum); hb_retnll(nSize); } #pragma ENDDUMP Какие варнинги у последней функции ?
alx_on: ../../../test_c.c:1: warning: ignoring #pragma BEGINDUMP ../../../test_c.c: In function ‘HB_FUN_U_FORMAT’: ../../../test_c.c:43: warning: format ‘%I64u’ expects type ‘unsigned int *’, but argument 3 has type ‘HB_SIZE *’ ../../../test_c.c:43: warning: format ‘%I64u’ expects type ‘unsigned int *’, but argument 3 has type ‘HB_SIZE *’ ../../../test_c.c:45: warning: format ‘%lu’ expects type ‘long unsigned int *’, but argument 3 has type ‘long long int *’ ../../../test_c.c:45: warning: format ‘%lu’ expects type ‘long unsigned int *’, but argument 3 has type ‘long long int *’ ../../../test_c.c:46: warning: format ‘%I64u’ expects type ‘unsigned int *’, but argument 3 has type ‘long long int *’ ../../../test_c.c:46: warning: format ‘%I64u’ expects type ‘unsigned int *’, but argument 3 has type ‘long long int *’ ../../../test_c.c: At top level: ../../../test_c.c:50: warning: ignoring #pragma ENDDUMP Вывод: Hello 8 8 4 8 8
Pasha: т.е, для gcc darwin ULONG - это 8 байт, и формат %lu предназначен для int 64 bit, он подходит и для ULONG, и для HB_SIZE а для gcc mingw64 ULONG - это 4 байт, и формат %lu предназначен для int 32 bit, и формат должен быть разным
Pasha: Все уже украдено придумано до нас Надо вместо LETO_SIZE_FORMAT использовать "%" HB_PFS
alx_on: Отлично (в xHarbour также есть HB_PFS ?) Что решаем с фильтром?
Pasha: В хХарбор - нет, но там и HB_SIZE тоже нет, так что это не вопрос А с фильтром - убрать перекодировку на клиенте. Я проверил различные случаи - работает как надо Через часик выложу
Pasha: Кстати, смотрю: # if defined( HB_OS_DARWIN ) || defined( HB_OS_SUNOS ) || defined( HB_OS_HPUX ) # define HB_BIG_ENDIAN darwin это не big endian часом ?
alx_on: Pasha пишет: darwin это не big endian часом ? Какая то проблема с этим? PS на самом деле это там от безысходности :) /* We cannot detect byte order, we will have to guess */
Pasha: sf упал... некстати :( Вот коммит http://files.mail.ru/H12VQJ Как поднимут - сброшу
полная версия страницы