Re: [Harbour] SF.net SVN: harbour-project:[12706] trunk/harbour
On Fri, 16 Oct 2009, Lorenzo Fiorini wrote: Now Harbour supports -gd option which enable such functionality directly in compiler so .d files can be generated without any additional time cost caused by second .prg files preprocessing. Just a minor issue: hbmk hello.prg -gd -ohello.exe hello.d is: hello.c: hello.prg instead of hello.exe: hello.prg Yes it is. It's expected behavior. Please read my other messages. Harbour compiler does not know that you want to create .exe file so in such situations you have to set extgension explicitly yourself. hbmk hello.prg -gd.exe -ohello.exe best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12706] trunk/harbour
On Wed, 14 Oct 2009, Lorenzo Fiorini wrote:
* harbour/bin/hb-func.sh
! do not look for .c files as result of hbcmp script executed
with -s or -sm switch and without -g[oh] * switches.
I've locally added a -MD switch to hb-func.sh:
...
-MD=*) HB_MD=\${v#*=} ;;
...
hb_cmp()
{
${hb_cmpname} \$@ \${HB_OPT} \${HB_PATHS} \\
( [ \${HB_GEN//c/} != ] || [ \${HB_NOC} = yes ] || \\
( [ -f \${FOUTC} ] \\
hb_cc -c \${FOUTC} -o \${FOUTO} \\
( [ \${HB_GEN} = c ] || rm -f \${FOUTC} ) ) )
if [ -n \${HB_MD} ]; then
MDOUT=\`${hb_cmpname} \$@ -q0 -m -sm \${HB_OPT} \${HB_PATHS}\`
echo \${FILEOUT}: \${MDOUT} \${HB_MD}
fi
}
...
The rules.mk so looks like:
...
-include $(DFILES)
%.hrb: $(ROOT)%.prg
hbcmp $(PRGFLAGS) -MD=$(@:.hrb=.d) $ -o$@
...
The requirements are to define -o file and use -MD=file.d.
Do you see any better way to do it or any problem with it?
I intentionally haven't implemented such switch at hb* scripts
level because it has to execute Harbour compiler twice so it
causes additional speed overhead.
Now Harbour supports -gd option which enable such functionality
directly in compiler so .d files can be generated without any
additional time cost caused by second .prg files preprocessing.
It means that your final rules can look like:
%.hrb: $(ROOT)%.prg
hbcmp $(PRGFLAGS) -gh -gd $ -o$@
%.o: $(ROOT)%.prg
hbcmp $(PRGFLAGS) -gc0 -gd.o $ -o$@
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About the new -sm option
On Wed, 14 Oct 2009, Lorenzo Fiorini wrote:
#!/bin/sh
echo -n ${1%.prg}.o: ${1%.prg}.d
hbcmp -n2 -sm -q2 $1 ${1%.prg}.d
What about integrate it with hbcmp itself?
This is a typical rules file I use in a hrb+js+xml app where prg
includes many js and xml using streaminclude:
...
PRGFILES=$(wildcard $(ROOT)*.prg)
PPXFILES=$(patsubst %.prg,%.hrb,$(PRGFILES))
HRBFILES=$(subst $(ROOT),,$(PPXFILES))
-include $(HRBFILES:.hrb=.d)
%.hrb: $(ROOT)%.prg
hbcmp -km -w3 -es0 -q0 -gh -n -D__hrb__ -I../dbl/ $?
if hbcmp would accepts -sM or -sMM and would produce a target:
dependeces it would great.
This will also be in sync with standard make like in:
OBJS := foo.o bar.o
# link
proggie: $(OBJS)
gcc $(OBJS) -o proggie
# pull in dependency info for *existing* .o files
-include $(OBJS:.o=.d)
# compile and generate dependency info
%.o: %.c
gcc -c $(CFLAGS) $*.c -o $*.o
gcc -MM $(CFLAGS) $*.c $*.d
Just an idea.
You do not need any new hbcmp script switches to replicate such
behavior, i.e.:
PRGFLAGS=-km -w3 -es0 -q0 -gh -n -D__hrb__ -I../dbl/
%.hrb: $(ROOT)%.prg
hbcmp $(PRGFLAGS) $?
( echo $@ ; hbcmp $(PRGFLAGS) -q2 -sm $? ) $(?:.prg=.d)
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About the new -sm option
On Wed, 14 Oct 2009, Lorenzo Fiorini wrote: You do not need any new hbcmp script switches to replicate such behavior, i.e.: PRGFLAGS=-km -w3 -es0 -q0 -gh -n -D__hrb__ -I../dbl/ %.hrb: $(ROOT)%.prg hbcmp $(PRGFLAGS) $? ( echo $@ ; hbcmp $(PRGFLAGS) -q2 -sm $? ) $(?:.prg=.d) Many thanks. I've also tried sth like that but I get: ../hrb/anaedt.d:1: *** missing separator. Stop. when I add -include $(DFILES) .d files are not in the form that can be used directly in make. Please simply modify above example and instead of 'echo $@' use 'echo $@: ', i.e.: ( echo $@: ; hbcmp $(PRGFLAGS) -q2 -sm $? ) $(?:.prg=.d) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About the new -sm option
On Wed, 14 Oct 2009, Lorenzo Fiorini wrote: On Wed, Oct 14, 2009 at 2:54 PM, Przemyslaw Czerpak dru...@acn.waw.pl wrote: Please simply modify above example and instead of 'echo $@' use 'echo $@: ', i.e.: ( echo $@: ; hbcmp $(PRGFLAGS) -q2 -sm $? ) $(?:.prg=.d) It doesn't work when I use it in prg - o hbcmp. There is no difference on the harbour side (I intentionally did not add destination.exe: to dependencies list generated by harbour compiler to not move such problems to compiler code) so the problem is in your Makefile. make stop with Error 1 on the first prg but it works if I use make -i ( ignore error ) I can't really see the difference ( beside the fact that it creates .o instead of .hrb ). And for harbour compiler and hb* scripts such difference does not exists so it has to be sth in your Makefile settings. I cannot help you without seeing your exact Makefile code. (I guess you added -n to above echo command). best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About the new -sm option
On Wed, 14 Oct 2009, Lorenzo Fiorini wrote: I can't really see the difference ( beside the fact that it creates .o instead of .hrb ). If I add -gh to the ( echo $@: ; hbcmp $(PRGFLAGS) -gh -q2 -sm $? ) $(?:.prg=.d) it works. So it could be the hb_cc that gets execute while it should be skipped with -sm. You are right though it's not the problem of executing hb_cc but missing .c file as result of harbour compiler call. hb_cmp looks for such file when -gc[0-3] is used or non of -g* switch is passed by user. Using -gh or -go as workaround resolves the problem. I'll update hb* scripts in a while. Thank you for information. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12705] trunk/harbour
On Wed, 14 Oct 2009, vszak...@users.sourceforge.net wrote:
Hi,
2009-10-14 13:43 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* utils/hbmk2/hbmk2.prg
+ Added 'gcc -MM' based C header dependency detection in -head=native
mode.
Please note that it's slower than regular methods, so for projects
with many .c source files this setting may not be ideal.
Thank you very much.
-M* GCC switches were designed to use with static dependencies files
not to scan source code on each make call so the speed was less important
because dependencies list is created once at startup and then only rebuilt
if some files in the list is modified.
If you can add support for optional files with explicit dependencies then
it's possible to use this functionality in the same way with hbmk2 as with
GCC and GNU make, i.e. you can read .d files. They have format like:
dstfile: srcfiles,...
\ as last non blank character concatenates lines. To simplify the format
and resolve possible conflicts with '\' ad path separator in DOS/Windows
we can define that it has to follow blank (TAB or SPACE) character or is
the only one non blank character in the line.
Below I'm attaching code which creates hash array indexed by files with
array of dependent files so it's enough to check if given file is in
such array, i.e.:
if cFile $ hDeps
for each cDep in hDeps[ cFile ]
if hb_FGetDateTime( cDep, @tDepTime ) .and. tDepTime tFileTime
lRebuild := .t.
exit
endif
next
endif
Can you add it?
best regards,
Przemek
static function deplst_read( cFileBody )
local cList := , cLine
local nLine := 0
local hDeps := {=}
cFileBody := StrTran( cFileBody, Chr( 13 ) + Chr( 10 ), Chr( 10 ) )
cFileBody := StrTran( cFileBody, Chr( 9 ), Chr( 32 ) )
for each cLine in hb_aTokens( cFileBody, Chr( 10 ) )
++nLine
cLine := AllTrim( cLine )
if cLine == \ .or. right( cLine, 2 ) == \
cList += Left( cLine, Len( cLine ) - 1 )
else
cList += cLine
if !deplst_add( hDeps, cList )
? error at line: , nLine, cList
return nil
endif
cList :=
endif
next
if !deplst_add( hDeps, cList )
? error at line: , nLine, cList
return nil
endif
return hDeps
static function deplst_add( hDeps, cList )
local cFile
local aList
local n
if !empty( cList )
n := At( :, cList )
if n != 0 .and. !empty( cFile := AllTrim( Left( cList, n - 1 ) ) )
aList := hb_aTokens( SubStr( cList, n + 1 ) )
if cFile $ hDeps
AMerge( hDeps[ cFile ], aList )
else
hDeps[ cFile ] := aList
endif
else
return .f.
endif
endif
return .t.
static function AMerge( aDst, aSrc )
local item
for each item in aSrc
if hb_AScan( aDst, item,,, .T. ) == 0
AAdd( aDst, item )
endif
next
return aDst
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12705] trunk/harbour
On Wed, 14 Oct 2009, Szak�ts Viktor wrote:
Hi,
I'll commit something, but I'd like to ask you to test it.
Feel free to even make corrections.
Before I do, I have a few questions:
- Shouldn't Harbour compiler also use this same .d format, so
we can use the method for .prg files, too?
I'm not sure I understood you.
Are you asking about adding to current -sm output desfile:
at the beginning of each line?
If yes then I haven't implement it intentionally because final
destfile may be different then the one which harbour compiler
can set. Harbour does not generate .{o,obj} files naively and
user may need it as destination rule. Anyhow I also plan to add
option to create .d files by compiler in one pass with compilation
so they will be created without any noticeable speed overhead and
in this case I will have to arbitrary chose destfile extension
using information from -g? switch though maybe I'll try to add also
an option to set the extension by user because in many cases
user will need .{o,obj} but with -gc* used to generate .c files.
- Am I right that these .d files are supposed to be autodetected?
How thay will be used depends on user. The general idea is
If so, what is the name? filename.d or filename.c.d?
filename.d and it's -MD GCC option behavior.
Here I have a little worry that this extra file existence
check in mass will slow down normal make process, especially
on network shares. I have projects with up to 800 files.
You do not have to make it automatically. Just simply recognize .d
files given by user in command line with wildcard extension in non
POSIX shell environment and load all dependencies sets inside each
of them into one hash table. Then inside code which checks for
dependencies check if scanned file belongs to this hash table and
if yes then take defined dependencies list.
Other options are passing these .d files explicitly, or
add a new switch to enable parsing of .d files, like -head=d.
exactly though -head=d should only disable other methods used to
detect dependencies. HBMK2 should always recognize .d files given
at command line and load dependencies into hash table. This hash
table should always be used to check if file has to be rebuilt.
If it does not give positive answer then there is a question if
we should try to use other methods. And here we have 3 choices:
1. never use other methods
2. always use other methods
3. use other method only if '! destfile $ hDeps' so adding
destfile to one of .d files even with empty dependencies list
will disable other method used to detect if file should be
recompiled.
I can imagine situations where each method can be usable so maybe
we should have option to chose one of them.
I'm leaving the decision for you. You know HBMK2 code much better
then any of us.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Wed, 14 Oct 2009, Szak�ts Viktor wrote: Hi, Thank you. I'd like to ask Przemek to review these modifications, as they are also altering the CP engine. It breaks Turkish CPs so we cannot use it in such form. I'll add soon alternative method to register CPs. It will use 4 tables with 256 bytes each of them. One for upper translation, second for lower translation, third for sorting and forth with bits describing character attributes (alpha, digit, upper, lower) for IS*() functions. It will allow to automatically generate CP modules for Harbour from Clipper applications what should definitely resolve the problem for all programs which have to share data with Clipper. Anyone will be able to create CP module for Harbour himself. But for such definitions I have to change existing code used for translations and update some code which now directly access CharsUpper and CharsLower HB_CODEPAGE members (mostly GT code). best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour Forum and Wiki.
On Tue, 13 Oct 2009, Szak�ts Viktor wrote: Hi, I can't solve the PP parser part, but if such function gets added to core, I'm ready to add support for it in hbmk2. Przemek, do you think that such function would be possible to implement? __PP_INCLUDELIST( cPRGFileName, cOptions ) - aINCLUDEFileName (or something with similar effect) It has to be fully integrated with compiler because included files may depend on conditional compilation so you have to activate compiler with all compiler switches which are used for normal compilation (plus switch(es) which enable autodependent checking) to preproces .prg files otherwise it will not work for situations like: #xcommand INCLUDEFILE file = #include file #xcommand INCLUDEAGAIN = #ifndef _AGAIN; #define _AGAIN;; INCLUDEFILE __FILE__ ; #endif #define SHOW_DATA #pragma __streaminclude data.inc|? %s #ifdef _AGAIN ? SECOND PASS SHOW_DATA ? #else proc main() ? main() #if __HARBOUR__ + 0 = 0x2 .and. !defined( MYDEF ) INCLUDEAGAIN #endif return #endif when you compile this code with and without -DMYDEF parameter. I think that you can easy imagine much more complicated situations. In poractice you have to activate the compiler with all it's setting and macros to fully replicate conditional compilation. Please also remember that Harbour supports also #pragma __[c]streaminclude which should also be detected and in the future may support some other extensions like using compiler switches in #if expressions, i.e.: #if enabled( -kh ) #include hbext_rules.ch #endif in summary it means that the only one method to generate correct dependencies list which will always work is compiler (or code which fully replicates compiler and PP behavior). I'll add to compiler support for such functionality. It will work like -M in GCC. For hbmk2 which uses embedded Harbour compiler I also add support for function which will return list of dependencies instead of sending them to stdout. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour Forum and Wiki.
On Tue, 13 Oct 2009, Szak�ts Viktor wrote: Please also remember that Harbour supports also #pragma __[c]streaminclude which should also be detected and in the future may support some other extensions like using compiler switches in #if expressions, i.e.: #if enabled( -kh ) #include hbext_rules.ch #endif I didn't know we have such feature :) In this case full compilation is indeed unavoidable. support for enabled() does not exist yet and I'm not sure it will be added in the future anyhow do not forget about Clipper compatible features and files included by compiler not PP, i.e. try this code: proc main() do file1 _procReq_( file2 + .def ) return In Clipper and Harbour above code tries to open file1.prg and file2.def and in both cases it's done by compiler after analyzing existing code not by PP. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About the new -sm option
On Tue, 13 Oct 2009, Lorenzo Fiorini wrote:
I'm trying to figure out how to use it in my makefiles with hb* scripts.
To avoid the double call of hbcmp, I'm trying to create a make depend
target that creates a .d file.
Is this the supposed usage?
If you want to use it in such context then why not, i.e. use this
script to generate .d file for .prg file given as 1-st parameter:
#!/bin/sh
echo -n ${1%.prg}.o: ${1%.prg}.d
hbcmp -n2 -sm -q2 $1 ${1%.prg}.d
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12701] trunk/harbour
On Wed, 14 Oct 2009, Szak�ts Viktor wrote: Thank you. You read my mind :) :-) Please also look at next commit. If hbmk2 uses all harbour compiler parameters set by user also with -sm switch (does it?) then passing -m to hbmk2 should give some additional small improvement. In practice it finish optimizations for -sm which can be done at compiler level. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour Forum and Wiki.
On Mon, 12 Oct 2009, Roberto Lopez wrote: Hi, All Harbour and contrib libraries are 'intact' (exactly as are distributed). The same applies for 'harbour.exe' and basic docs. So, bugs in Harbour compiler found by HMG users should be not a problem for Harbour developers. My personal experience is that the most often the sources of user problems are wrongly synced with Harbour core code build scripts in different add on libraries. Recently hbmk2 strongly reduced such bug reports and I'm very happy from that. I think that also HMG users can benefit from it. Additionally you cannot say that sth is not necessary for HMG users as long as you do not give them a chance to try it. I.e. I do not believe that non of HMG users have ever tried to create multi language application looking for I18N support. If you do not include hb18n or hbmk2 (it can be used to replace hb18n) then you are not giving them very important functionality which allows to easy create metalanguage application. I also do not believe that non of HMG users have ever needed to execute some .prg code as scripts. Such functionality is given by hbrun which can execute .hrb files but also directly .prg files, i.e.: hbrun mycode.prg and unlike all other script like tools for .prg code hbrun is fully functional compiler with _ALL_ harbour compiler features which compiles .prg code on the fly giving the same PCODE as stand alone Harbour compiler and then executes it with full HVM speed. Additionally hbrun can be executed without parameters and in such case it works like .dot command prompt xbase interpreter. I think you should give HMG users a chance to try such tools so they can decide if they really need them or not and it should not be your arbitrary decision. Now Harbour included in HMG is seriously reduced in basic functionality, i.e. it does not even contain Harbour shared libraries. The problem is that we use commands to do that, that are translated by PP to #includes. So, HBMK do not recognize them as include files and changes do not force recompilation of prgs. Do you use tool which emulates Harbour PP use to analyze .prg files for automatic dependencies checking? Can you write sth more about it? What exact functionality do you need? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FreeDOS in VMWare VM
On Sun, 11 Oct 2009, Bruno Luciani wrote: Hi, I think that some configuration may be necesary I don' t use wine dos emulation , but what you see in the png file is a real clipper old aplication running in my home directory in kubuntu linux using wine 1.1.26 only one click and it run without use the wineconsole command Maybe you have binfmt configured to execute DOS applications with DOSEMU. It works in such way. I don' t know if it is diferent but how you can see it run Can you send here result of this command: file yourdosapp.exe May be not all dos applications works None of pure DOS application can work because WINE does not have code necessary to execute them. But as I said it's possible that you have DOS emulation layer with your MS-Windows libraries and it's used automatically. Do you have MS-Windows installed on your computer (on different partitions) or only Linux is installed without any MS code. I use wine running my OOHG- Harbour(windows) program in linux boxes conected to a lin ux server via smbclient. Windows applications can be executed without any problems using WINE but the performance of IO operations is fatal. Even simple tests show that database access is over 10 times slower then in native applications. DOS applications executed by DOSEMU are only about 2-3 times slower. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FreeDOS in VMWare VM
On Mon, 12 Oct 2009, Angel Pais wrote: You're failing the comparison point. Meassuring apples against bananas. We cannot compare gui applications against console apps. I do not compare user interface at all. I compare only simple IO operations in SEEK or SKIP which are the same in GUI and CUI application. The same reports created by application under WINE control are over 10 times slower. Console ones are faster even on windows. I haven't tried to measure it. It's unimportant in current days. We have such fast computers that if sth is done in 1/100 sec. or 1/10 sec then for users it does not creates any differences. But if report is created in 1 hour by native code and then in 10 hours by the same code executed by WINE then it sth what blocks using WINE in bigger installations. None of my clients can accept it. And of course I'm talking about local file access. In remote access using file server the difference is much bigger then 100 times. Unless you are developpping a web server, i/o access is a minimal part of all your app running time. The time is important only in long operations. In the rest is not important at all. At least is not visible for users. In current days it doesn't matter it's CUI or GUI application. In both cases the code is executed fast enough to work interactively without any problems. User can see the slowness only when he tries to collect some data from tables and such operations needs some deeper analyzes. And here the speed overhead in WINE is the biggest one. If you execute pure .prg code, i.e. simple FOR/NEXT loop then code in WINE works with the same speed as native applications. Just execute speedtst.prg compiled as native application and as windows application. It's even possible that the windows one will be a little bit faster. But if you try to read or write from/to files or sockets then you will find that code executed by WINE is very slow. Even considering that, most apps are running over a network and performance is even worst and people are used to it. Until Harbour has a working GUI development API, denigrating WINE is a no-no, as for now, is the only usable platform on the linux world for real apps. If you want to achieve optimus performance then you have to make real 2 or 3 tier apps. Tier 1:being a gui app client under wine or anything else. Tier 2: a console app server under pure linux and an opcional 3rd. Tiers with a rdbms if you don't like dbfs. I can understand that using RDBMS when tables are access remotely can increase the performance but it still will be many times slower then local access by remotely executed applications. User interface is less important here. You can divide your applications into two parts and execute native GUI code on client side which will communicate with application on server side which process data locally. Creating simple RPC protocol is not very complicated job. We have all things necessary to implement it inside HBRTL. It's enough to collect them together. RDBMS does not exclude using DBFs as storage format. ADS is RDBMS and can use DBFs. I've never understood why Clipper users used to think that SQL == RDBMS and DBFs != SQL or DBFs != RDBMS. These are three different things which can be used in one product or in separate products. It's quite easy to add SQL support to DBF tables but it will not convert the program to RDBMS. Just like RDBMS can use DBF format to store data because unlike common opinion said it's one of the most efficient data base formats in many situations. The serious candidate for this is uhttpd but the are missing a protocol for serialize-transmit-deserialize data in a 2 way relationship. I rather suggest to write simple RPC server from scratch. Using HTTP protocol and some universal HTTP server is not very good idea. At least it will be very inefficient in some cases and you will have to deal with many of problems caused by sateless protocol like HTTP. Just my humble oppinion about our technological status. Let's work all together to improve this marvelous plattform instead. My hat off for this great meeting of great programmers Harbour has earned. In some spare time I'll write simple RPC server for Harbour. Maybe you and other users find it interesting. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FreeDOS in VMWare VM
On Mon, 12 Oct 2009, Phil Krylov wrote: None of pure DOS application can work because WINE does not have code necessary to execute them. Sorry, you're wrong. It's been long since I tried to run any 16-bit DOS apps using Wine (BTW it's written like this, not WINE), but they (not all but some) did work. Now I'm on 64-bit which needs some additional hacks to run 16-bit DOS code, but the code in Wine is still there: http://source.winehq.org/source/dlls/winedos/ It's a kind of ntvdm emulation. Thank you very much for the information. So winevdm emulation exists in WINE and it's not dummy code as i thought but can be used to execute some of DOS applications and it's not necessary to use native MS-Windows ntvdm. It's interesting why it's not working for me even for very simple application which only calls int 21 to terminate process. I'll try to look at it closer when I'll find some spare time. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FreeDOS in VMWare VM
On Mon, 12 Oct 2009, Bruno Luciani wrote: You are right Przemyslaw my mistake The console aplication that I test was compiled using Harbour Talking with a friend of mine , make me notes that diference and trying a real 16 bit binary , not work Looks that I was wrong and WINE has some own VDM code though for some reasons it does not work for me. I'm interesting if it's working for anyone else. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12692] trunk/harbour
On Mon, 12 Oct 2009, fsgiud...@users.sourceforge.net wrote: Hi, 2009-10-12 22:28 UTC+0200 Francesco Saverio Giudice (info/at/fsgiudice.com) + Added new hb_IniString() funtion hb_IniString( cData, lKeyCaseSens, cSplitters, lAutoMain ) - hIni that reads directly from a string. So hb_IniRead() read from a file, hb_IniString() read from memory string. Maybe you should call it hb_iniReadStr() ? If you need such function then sooner or later someone else will need also function to convert hash table to string in .ini file format so natural will be adding: hb_iniWriteStr( hIni, cCommentBegin, cCommentEnd, lAutoMain ) - cData | NIL or maybe you can even add such function too. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - HBXBP : Garbage Collection
On Mon, 12 Oct 2009, Pritpal Bedi wrote:
Hi,
I did a few experiments which lead to some
satisfying results but also with some weired ones,
which at the moment I am unable to fix, your help is
requested in highest needs.
1. Download attached are files which outlines my concept.
http://www.nabble.com/file/p25865022/hbqt_misc.zip hbqt_misc.zip
2. Redistribute them in respective folders.
3. Make the following change in QWidget.cpp
/*
* QSize size () const
*/
HB_FUNC( QT_QWIDGET_SIZE )
{
#if 0
hb_retptr( new QSize( hbqt_par_QWidget( 1 )-size() ) );
#else
void ** ph = ( void ** ) hb_gcAlloc( sizeof( void * ), QObject_release );
* ph = new QSize( hbqt_par_QWidget( 1 )-size() ) ;
hb_retptrGC( ph );
#endif
}
4. Issue - \harbour\contrib\hbqt\generator:\hbmk2 hbqtgen -run
5. Recompile HBQT.lib.
6. Move to tests folder and compile demoqt.prg as
hbmk2 demoqt -lxhb -Lc:\qt\2009.01\qt\lib -run
7. Open up some debugger utility to view the debug messages.
You may uncomment block at line # 143 to generate GPF right
after demoqt.exe shows up.
THE REAL ISSUE: hbqt_slots.cpp
===
HB_GARBAGE_FUNC( QObject_release )
{
char str[50];
void ** ph = ( void ** ) Cargo;
hb_snprintf( str, sizeof( str ), QObject_release 0 ); OutputDebugString(
str );
if( ph * ph )
{
try
{
const QMetaObject * m = ( ( QObject * ) * ph )-metaObject();
hb_snprintf( str, sizeof( str ), QObject_release 000 );
OutputDebugString( str );
if( m != NULL )
{
const char * name = m-className();
hb_snprintf( str, sizeof( str ), QObject_release 1 %s, m-className() );
OutputDebugString( str );
delete ( ( QObject * ) * ph );
}
* ph = NULL;
}
catch ( int e )
{
}
}
hb_snprintf( str, sizeof( str ), QObject_release 2 ); OutputDebugString(
str );
}
The GPF is generated right at
const QMetaObject * m = ( ( QObject * ) * ph )-metaObject();
This can happen in two situations:
1. If the ph is not of type QObject : in case we
uncomment block shown above.
What seem to be expected.
2. If the object is released by Qt itself and detection line if( ph *
ph )
does not reconizes that the pointer has been releases.
This detection works only for object released by GC block destructors
or released/detached by your own helper functions which explicitly clear
the reference inside ph. It does not help in any way to detect that
object was released by QT code. To resolve this problem you should
detach all objects which are managed by QT and will be released by
QT code. If it's hard for you to implement such detaching then you
should use guarded pointers as Teo suggested and store them in GC
block instead of direct QObject pointers.
Please note that try{}catch{} mechanism is not helping any way.
It usually do not help to resolve programmers errors so it's not a solution.
Never create code which uses try/catch as some type of workaround for bugs
in code, i.e. to hide problems with doubly free pointers.
I need following favours:
1. If it can be detected the ph is a valid pointer.
See above.
2. If it could be determined which type of object ph is referring to.
[ All objects deriving from QObject are detected fine but any other
class does not respect this construct, i.e. QSize and allied
classes ]
You have to use different GC blocks with different destructors for each
class which do not have common destructor. You can also add 'type' filed
and try to implement it using single GC destructor function but IMO it's
not good idea.
3. If GPF could be trapped anyway if any of the above implementions are
not possible.
It can be trapped but it will not resolve any problems so fighting
with it it's a waste of time and in the worst case you will only
hide very serious application bugs which will still exists but
problems will be exploited in different places, i.e. GPFs in valid
code which fails due to memory corruption caused by hidden real
errors.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour Forum and Wiki.
On Mon, 12 Oct 2009, Roberto Lopez wrote: Hi, about hbmk2 can you post a little sample (also with minigui) so i will try Facts are that Viktor have modified each error post here regarding hbmk2 I've explained in a post on Sunday: http://www.hmgforum.com/viewtopic.php?p=5494#p5494 The text is clear for me but it's not clear for me what you used so far. In my opinion such functionality can be implemented only inside PP and all tools which tries to make it without replicating whole PP logic with all compiler predefined settings and macros are buggy by definitions and users can always create some code which will confuse them. HBMK2 is not an exception here (I haven't even know that it tries to make that) so I'm interesting what is your alternative and what you used so far. I can add such functionality for .prg code to Harbour compiler (GCC already have it for C code) and it's the only one place where it can be well implemented. So far only Lorenzo asked about it. If it's really important then I'll implement it but I do not understand why hbmk2 cannot be used without this feature and what is the core of problem. One of the most important hbmk2 job is hiding differences between C compilers and some Harbour internals like platform or installation dependent settings so it can be always used as simple wrapper to Harbour and C compilers and linker. The incremental mode is only additional functionality which you do not have to use. Anyhow if HBMK2 tries to detect automatically included files then it should be done correctly though I can still imagine situations when only manually created dependence list will work. BTW does HBMK2 supports dependencies list defined by user? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FreeDOS in VMWare VM
On Sat, 10 Oct 2009, Ciro Vargas C wrote: Sorry but Wine support DOS applications. please test it and you got surpraised I think you will be surprised if you create pure DOS application. Let's try: /*** t76.prg ***/ proc main() ? date(), time() ? os() ? version() ? procname() wait return druzus:/tmp/24# file t76.exe t76.exe: MS-DOS executable, MZ for MS-DOS druzus:/tmp/24# wineconsole t76.exe fixme:mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer winevdm: unable to exec 'Z:\tmp\24\t76.exe': DOS memory range unavailable druzus:/tmp/24# Let's hack the kernel and unblock access to low memory: root:~# sysctl -w vm.mmap_min_addr=0 vm.mmap_min_addr = 0 and then again: druzus:/tmp/24# wineconsole t76.exe fixme:mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer wine: Unhandled page fault on read access to 0x0d96f002 at address 0x7e8e15b1 (thread 001a), starting debugger... Let's try to execute pure clipper.exe binaries: druzus:/tmp/24# wineconsole /mnt/nwe/lng/clipper5/bin/clipper.exe fixme:mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer wine: Unhandled page fault on read access to 0x19bf8002 at address 0x7e8e85b1 (thread 001a), starting debugger... WINE does not support DOS application. For such support it's necessary to emulate whole DOS with all DOS interrupts and memory regions, emulate BIOS interrupts, etc. so to make it well it's necessary to replicate FreeDOS or other DOS inside Wine with some emulation layers given by DOSEMU which are not available in pure WINE. I have no idea what you have tested. Maybe it's possible to execute DOS application using WINE indirectly, i.e. using some emulation layer which comes with real MS-Windows installed on the same computer when WINE is configured to use original MS-Windows code and original Windows installation contains MS-DOS emulator for executing DOS application. I've never tested it so I cannot confirm if it works or not. Anyhow it does not change the fact that WINE cannot execute DOS programs and it only executes DOS emulator which executes DOS programs. In such case I suggest to use DOSEMU to reduce number of emulation layers. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Re: Problem with set filter
On Fri, 09 Oct 2009, Itamar Lins wrote:
After searching this problem for a few hours... normal to the learner, got
the following result.
proc main()
field f
local inicio, fim
set date to brit
set epoch to 1970
dbcreate(_tst,{{F,D,8,0}})
use _tst
dbappend(); f := ctod('22/09/09')
dbappend(); f := ctod('23/09/09')
dbappend(); f := ctod('28/09/09')
dbappend(); f := ctod('28/09/09')
close all
use _tst new alias 't1' shared
use _tst new alias 't2' shared
inicio := ctod('22/09/09')
fim:= ctod('22/09/09')
while !t1-(eof())
? t1-(recno()), t1-f
t1-(dbskip())
enddo
?
set filter to t1-f = inicio .and. t1-f = fim
t1-(dbgotop())
while !t1-(eof())
? t1-(recno()), t1-f
t1-(dbskip())
enddo
return
Please comment shared option while open dbf file.
use _tst new alias 't1'
use _tst new alias 't2'
try again.
If you need any help then please start testing your examples with
Clipper. It's the last time when I'm answering for message with
not verified problems.
The above code compiled by Harbour, xHarbour and Clipper gives
exactly the same results.
1 22/09/09
2 23/09/09
3 28/09/09
4 28/09/09
1 22/09/09
2 23/09/09
3 28/09/09
4 28/09/09
what is perfect behavior because you are setting filter on 'T2' area
but skip test is done on 'T1'.
I think that such messages should be sent to Harbour user group.
The developer list is not the place to learn Clipper programming.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Re: Re: Problem with set filter
On Sun, 11 Oct 2009, Itamar M. L. Jr. wrote: Hi, My problem was that unintentionally area was changed and set filter stopped working or is working with error. In my view an error set filter, despite the respect that harbour compatibility with clipper but for me it is a mistake to harbour, because I never used clipper. If I'm using alias to set area in which the filter should be applied. The problems you presented so far are your own bugs in .prg code and I'm really sorry but I do not have time to help each Harbour programmer in creating .prg code and fix their own bugs. Maybe you should look for some payments assistance in the future if you need help in such situations. So if the command set filter does not work with alias should show an error when compiled SET FILTER works perfectly. Aliases are fully separated so SET FILTER in one workarea does not change the behavior of other workareas what is expected behavior and very important functionality. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error 9011 on harbour
On Fri, 09 Oct 2009, José Luis Capel wrote: Hi, Making some tests of .clp files I found this error on harbour when I typed wrongly the name of a clp file: c:\ harbour @myapp.clp Harbour 2.0.0beta3 (Rev. 12672) Copyright (c) 1999-2009, http://www.harbour-project.org/ Cannot open input file: myapp.clp Unrecoverable error 9011: hb_xfree called with a NULL pointer MyApp.clp does not exist. Thank you very much forn information. Fixed, best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_xgrab requested to allocate zero bytes
On Thu, 08 Oct 2009, Mitja Podgornik wrote: Hi, please, can anybody help? This function occasional causes GPF and occurs sporadic only on some xp/vista machines Application Internal Error ... Terminated at: Info: Harbour MiniGUI 1.7 Extended Edition (Build 74) - 2009.09.30 Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes Called from SOCKETRECEIVE(0) recv() on error returns -1 not 0. nLen = recv( m_hSocket, pRead, nLen, 0 ); hb_storclen( pRead, nLen, 2 ); And in such case error appears here. As short hackt o resolve the problem you can add hust after recv() if( nLen 0 ) nLen = 0; This function can be also greatly optimized though it's maybe less important. Anyhow I suggest to convert this code to use internally hb_socket*() functions. This functions can create some other problems changing socket options, i.e. as parameter for SOL_SOCKET-SO_RCVTIMEO struct timeval (the same as in select()) should be used but this code uses integer. I've never used it on Windows so it's possible it's a bug in MS-Windows BSD socket implementation and it really needs int value but I suggest to verify it. Please also note that it changes socket parameters and then does not restore them so next calls will use timeouts setting set by previous calls. Of course if they work and someone can confirm that SOL_SOCKET-SO_RCVTIMEO uses 'int' as parameter in MS-Windows. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - HBXBP : Garbage Collection
On Thu, 08 Oct 2009, Pritpal Bedi wrote:
Hi,
In order to let GC collect these pointer automatically
you need to use hb_retptrGC(), along with a callback
to the freeing.
So, I tried like this:
static HB_GARBAGE_FUNC( QMessageBox_release )
{
void ** ph = ( void ** ) Cargo;
/* Check if pointer is not NULL to avoid multiple freeing */
if( ph * ph )
{
/* Destroy the object */
delete ( ( QMessageBox * ) ph );
/* set pointer to NULL to avoid multiple freeing */
* ph = NULL;
}
}
static QMessageBox* xhbqt_par_QMessageBox( int iParam )
{
void ** ph = ( void ** ) hb_parptrGC( QMessageBox_release, iParam );
return ph ? ( QMessageBox * ) ph : NULL;
}
Here is mistake. The last line should be changed to:
return ph ? ( QMessageBox * ) * ph : NULL;
HB_FUNC( QT_QMESSAGEBOX )
{
void ** ph = ( void ** ) hb_gcAlloc( sizeof( QMessageBox ),
QMessageBox_release );
* ph = new QMessageBox();
hb_retptrGC( ( QMessageBox * ) ph );
}
/*
* DESTRUCTOR
*/
HB_FUNC( QT_QMESSAGEBOX_DESTROY )
{
void ** ph = ( void ** ) hb_parptrGC( QMessageBox_release, 1 );
if( ph * ph )
{
delete ( ( QMessageBox * ) ph );
* ph = NULL;
}
}
Very good. Please only remember that QT_QMESSAGEBOX_DESTROY is optional.
You do not have to implement this function because destructor will be
automatically activated when the last .prg item holding the pointer
to QMessageBox will be released (cleared or overwritten).
In some cases you may also need function DETACH which will be used for
widgets attached to some other QT widgets so they will be released
automatically with parent objects and should not be release by our GC.
I.e.:
void xhbqt_detach_QMessageBox( PHB_ITEM pItem )
{
void ** ph = ( void ** ) hb_itemGetPtrGC( pItem, QMessageBox_release );
if( ph *ph )
*ph = NULL;
}
In most of cases such function should be called by C code which attach
widget to parent object but if you really need it then you can create
.prg wrapper two:
HB_FUNC( QT_QMESSAGEBOX_DETACH )
{
xhbqt_detach_QMessageBox( hb_param( 1, HB_IT_POINTER ) );
}
Please only remember that after detaching GC will not free the object
automatically and it has to be freed in other way, i.e. by parent object.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_xgrab requested to allocate zero bytes
On Fri, 09 Oct 2009, Grigory Filatov wrote: Hi, Thanks for your suggestion! someone can confirm that SOL_SOCKET-SO_RCVTIMEO uses 'int' as parameter in MS-Windows. There is the following definition in the header file winsock.h from BCC: int PASCAL FAR setsockopt ( IN SOCKET s, IN int level, IN int optname, IN const char FAR * optval, IN int optlen); I know but it's the standard definition in all BSD * socket implementations though POSIX standard suggest to use as last two parameters: const void *optval, socklen_t optlen anyhow it does not inform what is the internal structure of value pointed by optval. Different options use different parameters. You have to check in the documentation expected value for each socket option you are using and pass as parameter valid structure, i.e. here is Linux documentation for SO_RCVTIMEO and SO_SNDTIMEO which is semantically compatible with original BSD documentation: SO_RCVTIMEO and SO_SNDTIMEO Specify the receiving or sending timeouts until reporting an error. The parameter is a struct timeval. If an input or out‐ put function blocks for this period of time, and data has been sent or received, the return value of that function will be the amount of data transferred; if no data has been transferred and the timeout has been reached then -1 is returned with errno set to EAGAIN or EWOULDBLOCK just as if the socket was specified to be non-blocking. If the timeout is set to zero (the default) then the operation will never timeout. Timeouts only have effect for system calls that perform socket I/O (e.g., read(2), recvmsg(2), send(2), sendmsg(2)); timeouts have no effect for select(2), poll(2), epoll_wait(2), etc. As long as you do not know any MS-Windows socket documentations which explicitly says that WINSOCK uses different structure as SOL_SOCKET- SO_RCVTIMEO parameter then I strongly suggest to use original BSD socket documentation and in this case modify the code to use pointer to 'struct timeval' instead of pointer to 'int' as parameter for setsockopt( sd, SOL_SOCKET, SO_RCVTIMEO, ... ). best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Fri, 09 Oct 2009, Maurizio Faccio adinet wrote: What I do not understand is that: Compiler says that the patch was applied correctly Clipper (R) 5.2e Copyright (c) 1985-1995, Computer Associates International, Inc. But VERSION() in clipper tolds - 5.2d Intl. (x215) (1994.03.25) It means that you linked final application with 5.2d libraries. So you haven;t patched your libraries or it's a result of some mistakes in LIB envvar settings. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Problem with set filter
On Fri, 09 Oct 2009, Itamar Lins wrote:
Hi,
Thanks for response.
Please analize my file, because it was make with old xHarbour.
http://www.4shared.com/file/139644752/e204a705/encomenda.html
proc main()
local inicio, fim
set date to brit
use encomenda new alias 'pd'
dbgotop()
inicio := ctod('20/08/09')
fim:= ctod('28/08/09')
while !eof()
If pd-data_compr = inicio .and. pd-data_compr = fim
? recno(), pd-data_compr
endif
dbskip()
enddo
?
set filter to pd-data_compr = inicio .and. pd-data_compr = fim
dbgotop()
while !eof()
? recno(), pd-data_compr
dbskip()
enddo
return
Very strange for me results.
For me above code gives expected results.
Harbour, xHarbour and Clipper gives exactly the same results:
empty record set.
There is no bug in any of the above compilers and they behave as
it's documented. This is why I'm asking to create self contain examples.
HINT: add this line at the end of your code:
? hb_dtoc( inicio, DD/MM/ ), hb_dtoc( fim, DD/MM/ )
and read in Clipper documention what does SET EPOCH TO ...
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2: Error: Running Harbour compiler (internal). 1
On Thu, 08 Oct 2009, José Luis Capel wrote: Hi, Using hbmk2 (created from lastest svn) I try to compile an old clipper app. I use same .clp file as follow: hbmk2 @miappl.clp Finally (after showing a syntax error on my app) shows this message: 1 error no code generated. hbmk2: Error: Running Harbour compiler (internal). 1 (e:\programacion_ant\hb_mingw\bin\harbour.exe) -n2 @hbtrade.clp -ie:/programacion_ant/hb_mingw/include So it's syntax error in your application code. If you need help then we have to know what exactly your code contain in given line. It's also possible that automatic -n mode detection (-n2 switch) does not work with you code. In such case try to use -n- switch, i.e.: hbmk2 -n- @miappl.clp best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBINFO(DBI_MEMOHANDLE)
On Thu, 08 Oct 2009, Saulius Zrelskis wrote:
Hi,
Sample below GPFs:
-
#include dbinfo.ch
PROC main()
DBCREATE(test, {{F1, C, 20, 0}},, .T., test)
? DBINFO(DBI_MEMOHANDLE)
DBCLOSEALL()
RETURN
Thank you very much for information.
Fixed.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_setTermCP() + GTWVT UNICODE vs non-UNICODE
On Thu, 08 Oct 2009, Szak�ts Viktor wrote: Hi, hb_setTermCP() will mess up the keyboard input for national chars when used in UNICODE builds, while it won't for non-UNICODE builds. Tested with GTWVT. The point here is not the mess up part, but rather that app behavior is different in UNICODE and non-UNICODE builds. This is most probably not right this way. (the culprit is hb_setKeyCP() behavior) I do not understand what is the problem in your case but for sure above does not discribe GTWVT behvior. For both UNICODE and non UNICODE modes all you should use: hb_setTermCP( cTermCP, cHostCP ) where cTermCP is OS encoding and cHostCP is HVM encoding. When cHostCP is not given then _SET_CODEPAGE is used. The only one difference between UNICODE and non UNICODE mode is the fact that in UNICODE mode cTermCP is ignored and only cHostCP is significant but for user code it does not create any differences. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_setTermCP() + GTWVT UNICODE vs non-UNICODE
On Thu, 08 Oct 2009, Szak�ts Viktor wrote:
I do not understand what is the problem in your case but for sure
above does not discribe GTWVT behvior.
For both UNICODE and non UNICODE modes all you should use:
hb_setTermCP( cTermCP, cHostCP )
where cTermCP is OS encoding and cHostCP is HVM encoding.
When cHostCP is not given then _SET_CODEPAGE is used.
The only one difference between UNICODE and non UNICODE mode
is the fact that in UNICODE mode cTermCP is ignored and only
cHostCP is significant but for user code it does not create
any differences.
Yes, sorry, I mixed the cases, it's ignored in UNICODE and
not ignored in UNICODE as you say.
It means I have to manually adjust CP setup for each platform,
build type and active GT (even WINE, but that's probably not
Harbour's fault). GTWIN works differently than GTWVT,
??? I do not see any difference and I still do not understand what
is the problem. In UNICODE builds we do not have to know OS character
encoding. Just simply such knowledge is unnecessary for us because
we are exchange data between OS using UNICODE characters.
In non unicode builds we have to set valid OS CP used by font
and/or keyboard input. Here default setting depends on country
and user locale settings.
GTWVT works differently in UNICODE and non-UNICODE mode, and
things work a little bit differently with other GTs. Things
will be a bit more complicated on Windows, after my app switched
to ISO CP from DOS.
Can you explain precisely what's the difference for you?
I.e. some small self contain example.
Now I had to drop hb_setTermCP() as it seems dangerous in
portable code. Instead I'm adjusting DispCP and KeyCP separately
depending on above factors. KeyCP is only set on *nix systems.
Plus HB_GTI_CODEPAGE on win when ISO CP is used. I didn't
test UNICODE mode in this scenario yet.
WIN CP settings are ignored in UNICODE builds.
For me this is a little confusing. Prone to break easily.
For me hb_set{Term,Disp,Key}CP() works perfectly and I do not
see any thing wrong in portability. In general I still do not
understand what is your problem.
Self contain examples will make things more precise.
Probably I'm missing sth important for you.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Wed, 07 Oct 2009, WenSheng wrote: Hi, Do you have to think about 'TransForm()' ? No, we do not use it in any context which needs to force pure ASCII processing. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Wed, 07 Oct 2009, Szak�ts Viktor wrote: Hi, Indeed, especially for WinCE users, on desktop I expect it to be used rather rarely, although it may also be useful f.e. when connecting to a remote GT with higher resolutions. Yes but it's also usable if user creates many console windows using them just like CTWIN and wants to scroll some of them automatically. BTW, GTXWC also has the same artificial limit. Yes though it has a little bit different meaning in GTXWC because maximal and minimal console window size and resize factor is send to XServer so it's process out of Harbour application on the client side. Anyhow I can remove this limits too. You can disable the code for font resizing by: HB_GTINFO( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_ROWS ) and it should resolve the problem. I have no idea what is expected behavior for: SetMode( 250, 250 ) when HB_GTI_RESIZEMODE_FONT is set. We have few possible choices, i.e.: 1. chose default window dimensions: 25x80 2. resize rows and cols like in HB_GTI_RESIZEMODE_ROWS 3. refuse to create window (SETMODE()-FALSE). Users using HB_GTI_RESIZEMODE_FONT should chose sth what they prefer. I'd vote for 3. (and 1. as the second choice) In fact we already have 3 but the problem is when application starts and default or user settings creates too big for screen size. I'll commit small modification in a while which will check if startup (default or user) parameters are do not exceed screen dimension and if yes then they will be reduced to the screen size. BTW set mode does not automatically change the font size. Maybe it will be good to add such functionality but please remember that we have problem here with priority of object to update: window size or font size so I think it's important to first define expected behavior (algorithm) and document it and later update the code so anyone working on GTWVT will know expected behavior and can keep it adding own modifications. And of course it should be possible to disable it because not always our algorithm with its arbitrary decisions will follow user preferences. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Wed, 07 Oct 2009, Szak�ts Viktor wrote: BTW set mode does not automatically change the font size. Maybe it will be good to add such functionality but please remember that we have problem here with priority of object to update: window size or font size so I think it's important to first define expected behavior (algorithm) and document it and later update the code so anyone working on GTWVT will know expected behavior and can keep it adding own modifications. And of course it should be possible to disable it because not always our algorithm with its arbitrary decisions will follow user preferences. SetMode() works for me (with GTWVT) on app startup to resize font to make the requested (by cmdline) dimensions fit on the screen. Yes but only on startup and only when it's possible to find font small enough for whole console window. If it's not possible to find such font then current GTWVT uses default font (not the smallest available one and reduces number of rows and/or columns. If try to use SetMode() to resize existing console window then given dimensions are validated using current font size not the smallest available so SetMode() returns .F. is current font is too big without trying to find smaller one. See SETMODE() method in GTWVT. We can add such automatic default font size decreasing but without precise algorithm which can increase font size when SetMode() is used to reduce number of rows and columns it will be only one way feature. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Index compatible bug?
On Tue, 06 Oct 2009, Enrico Maria Giordano wrote:
The following sample prints 102 (in Clipper also):
FUNCTION MAIN()
SET DELETED ON
DBCREATE( BUGTEST, { { CODICE, N, 3, 0 } } )
USE BUGTEST
APPEND BLANK
REPLACE FIELD - codice WITH 101
DELETE
APPEND BLANK
REPLACE FIELD - codice WITH 101
APPEND BLANK
REPLACE FIELD - codice WITH 102
INDEX ON FIELD - codice TO BUGTEST UNIQUE
GO TOP
WHILE !EOF()
? FIELD - codice
SKIP
ENDDO
CLOSE
INKEY( 0 )
RETURN NIL
I wonder if it should print 101 and 102.
The behavior is correct. Index contain record 1 with value 101 but
is filter by your SET DELETE ON filter. If you want to filter such
records when index is created then use USEFILTER clause in INDEX ON
command, i.e.:
INDEX ON FIELD - codice TO BUGTEST UNIQUE USEFILTER
In such case record 1 (101) will not be added to filter but
record 2 which has the same key.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Tue, 06 Oct 2009, Chen Kedem wrote:
Hi,
After some checks:
1) The file is source/codepage/cpes850c.c (and not source/lang/...).
2) Current SVN version is besically the same version as originally
added to the repository.
3) I can't find in the dev list any remarks regarding its validity since
the day it was added.
NOTE: I'm not a user of this Spanish codepage and have no idea how it is
implemented in Clipper. I'm just the guy who forward bug reports from SF to
this list.
Try the code below.
It generates characters strings which can be used to create CP definition
in Harbour. It's enough to compile this code using Clipper and then link
with given Clipper sort module (usually ntx*.obj) file and then execute.
If there is a problem with cpes850c.c then the upper and lower strings
will be different. If Spanish user can confirm it then we will update
cpes850c.c. Please only remember to attach information about exact version
of used sort modules. In some countries there were different sort modules
with the same CP name, i.e. distributed with CA-Clipper and with SIx3
library.
best regards,
Przemek
/*
* cpinfo.prg
*/
proc main()
local cLo, cUp, c, cl, cu, i, a
set alternate to cpinfo.txt additive
set alternate on
a := array( 256 )
for i := 1 to len( a )
a[ i ] := i
next
asort( a,,, { |x,y| chr( x ) + chr( 0 ) chr( y ) + chr( 0 ) } )
? date(), time(), os(), version()
? Character encoding:
? ===
cLo := cUp :=
for i := 1 to len( a )
c := chr( a[i] )
if isalpha( c )
cl := lower( c )
cu := upper( c )
cLo += cl
cUp += cu
if cl == cu
? upper + charval( cu ) + and lower + charval( cl ) + ;
equal
elseif !isalpha( cl )
? wrongly defined character + ;
charval( c ) + : + charinfo( c ) + ;
, lower + charval( cl ) + : + charinfo( cl )
elseif !isalpha( cu )
? wrongly defined character + ;
charval( c ) + : + charinfo( c ) + ;
, upper + charval( cu ) + : + charinfo( cu )
endif
elseif islower( c ) .or. isupper( c )
? wrongly defined character + ;
charval( c ) + : + charinfo( c )
endif
next
? 'upper: ' + cUp + ''
? 'loerr: ' + cLo + ''
? ===
?
return
static function charval( c )
return ' + c + ' ( + ltrim( str( asc( c ) ) ) + )
static function charinfo( c )
local cInfo
cInfo := ISALPHA- + iif( isalpha( c ), Y, N )
cInfo += , ISUPPER- + iif( isupper( c ), Y, N )
cInfo += , ISLOWER- + iif( islower( c ), Y, N )
return cInfo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Just tested MSVC 2008 x86 now default UNICODE build and I'm having the same display problems in GTWIN as in x64. As it turns out, it's not related to UNICODE build though. The console app was starting up with default screen dimensions which is 80x300, and apparently this messes it up. I'll have to investigate further how can any screen dimension mess up such things as windows handling. [ and now Windows doesn't seem to allow me to reset the value to original defaults, well, time to go anyway. ] It's expected behavior. In Win2K and higher the size of console buffer is returned as window size. If you do not need such big area then simply change to size of console buffer in application preferences or use setMode() best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Tue, 06 Oct 2009, Przemyslaw Czerpak wrote: Hi, Try the code below. I've just committed a little bit extended version of this code to harbour/tests/cpinfo.prg. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Tue, 06 Oct 2009, Chen Kedem wrote: Hi, I've just committed a little bit extended version of this code to harbour/tests/cpinfo.prg. The attached results were made with the program you posted in the list (going to check your new one soon). Tested with Clipper 5.2e once with NTXSPA.OBJ and once with MDXSPA.OBJ (I included the internal version string from these files) And Harbour Rev.12653 build with BCC5.5.1 with ES850C (the compatible) and ES850 (modern Spanish) So for sure ES850C in Harbour is not compatible with ntxspa.obj. Interesting is that mdx and ntx use different sorting. I haven't expected it. Maybe it's result of some historical decisions or simply bug. For me the ordering in MDXSPA does not look correctly but maybe in some cases accented characters should be sorted before unaccented ones. It's the question to Spanish user not for me. Anyhow I'll update cpinfo.prg code to show more precise information which should help in replicating exact Clipper behavior. If I find a while then I also try to add alternative method to define CP in Harbour so it will be possible to adopt Clipper's definitions as is and generate them automatically from cpinfo.prg. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: I know this. I need to clarify, by messed up I don't mean the scrollbars and whatnot when using such big buffer. Instead I mean that the displayed (by Harbour app) _screen content_ is wrong. It looks like as if (ctwin) windowing gets confused about current window, so it's painting to the wrong one and returning size of the wrong one. But I'll make some real tests later, could be my app code. It's possible that there is sth wrong in CTWIN though it should work correctly - at least I do not see any problems looking at the code. If you have some additional extensions then please check if you do not have some places which may cause coordinates casting to BYTE or which may calculate screen offset or index in screen buffer using [U]SHORT value. Try to reduce number of rows to 255 and check if it helps. Few years ago I made some tests with very large screen buffers in MS-Windows console and I've found some bugs in MS-Windows console code so it's possible that the problem is caused by exploiting them. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Tue, 06 Oct 2009, Bisz István wrote: Hi, I found a quite strange behavior in some CP settings necessary in my project. See the following sample: CODE proc main() set alternate to uperr.txt additive set alternate on REQUEST HB_CODEPAGE_TR857 HB_SETCODEPAGE( TR857 ) ? diag=diag, UPPER(diag=diag) ? diag, UPPER(diag) return ENDCODE generating the wrong output: diag=diag DAG=DAG diag DIAG It's Clipper compatible behavior in UPPER() optimization. Clipper optimize UPPER( cConst ) at compile time if cConst contains only characters like [A-Za-z0-9 ] and as result if gives cUpperConst where characters like [a-z] are converted to [A-Z]. During compilation CP is unknown so only such strings are translated and only pure Latin letters. In Harbour Clipper behavior is fully replicated because some code which initialize static variables needs it, i.e.: static s := upper( diag ) Unfortunately it creates problems for Turkish CPs where upper(i) is not I but due to compile time optimization it's wrongly translated to I. In your example first string contains = character what disables compile time UPPER() optimization so it's correctly translated at runtime but the second string is fully optimized. The only one solution I can give you is not using UPPER() with string constant values containing Turkish strings. Maybe in the future I'll add new -k? switch to disable UPPER() optimization but I cannot make it in default builds due to compatibility with existing code. If it's critical for you now then you can disable UPPER() optimization in Harbour compiler code and recompile your custom Harbour version. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Tue, 06 Oct 2009, Bisz István wrote: Hi, Unfortunately this i to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE - 0x98 152 in CP857) upper conversion generates more problems, now in MEMOEDIT: Error BASE/1004 Message not found: HBMEMOED˜TOR:HBEDITOR Called from __ERRRT_SBASE(0) Called from HBMEMOED˜TOR:ERROR(0) Called from (b)HBOBJECT(0) Called from HBMEMOED˜TOR:MSGNOTFOUND(0) Called from HBMEMOED˜TOR:HBEDITOR(0) Called from HBMEMOED˜TOR:EDIT(0) Called from MEMOEDIT(0) The missed I in 'HBMEMOED˜TOR' is this İ ugly character. I don't know how to handle this. In practice setting such CP causes that all symbols containing 'i' may not be properly converted if .prg code use UPPER(). In above case it's working and only class name looks ugly bad it should not cause bigger bad side effects as long as you do not want to make sth with such class name, i.e. use it in macro compiler. The above can be quite easy resolved by small modification in include/hbclass.ch. It's enough to change: HBClass():new( (ClassName) to: HBClass():new( Upper( (ClassName) ) and compile time optimization for UPPER resolves the problem so it's enough to recompile the Harbour code. Anyhow seems that it will be good to add new function i.e. HB_ASCIIUPPER() and use it instead of UPPER() in core library code in all places where we are operating on compiler symbols or other ASCII identifiers. [ Viktor I think we should make it. ] Please only remember that you also have to be careful writing your own code. BTW How are you leaving with such CPs? ;-) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: I agree. I'd rather user hb_upperAscii() though, to keep names well aligned (i.e. it's a sub-type of upper()). Fine though if we plan to add also other ASCII oriented functions for LOWER, ISALPHA, ISUPPER, ISLOWER, ISDIGIT operations then IMO using hb_ascii*() prefix will be better to keep names aligned. Just like now we have set of hb_utf8*() functions: HB_UTF8CHR(), HB_UTF8LEN(), HB_UTF8LEFT(), HB_UTF8RIGHT(), HB_UTF8STUFF(), HB_UTF8SUBSTR(), HB_UTF8STRTRAN(), HB_UTF8PEEK(), HB_UTF8POKE(), HB_UTF8TOSTR() best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Wed, 07 Oct 2009, Szak�ts Viktor wrote: Some more results, this time using GTWVT, as it seems the problem isn't GTWIN specific, so: 1) SetMode( 80, 255 ) // works as expected 2) SetMode( 80, 256 ) // works with display artifact (will check it further to eliminate local cause) The artifact is slightly different in Win32 and Win64 mode. In Win32 only current window is messed up, while in Win64 mode some additional problems are visible, like mentioned wrapped menu on screen. 3) SetMode( 80, 257 ) // not accepted by GTWVT, resulting in default 80, 25 dimensions. Both in Win32 and Win64. (notice however that it would use such bigger resolutions if it is the system default, this may of course only happen with GTWIN) GTWVT is limited at compile time to: #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 It's historical limit in very old xHarbour code which can be removed from current code. 4) SetMode( 250, 80 ) // will result in a no window situation, where the app works, but there is no visible screen. Experienced with GTWVT. I guess it's side effect of code which tries to allocate font which fits given dimensions. The original code was working in different way. BTW There is no support for automatic scroll bars in GTWVT and I think it will be nice to add it. Case 3) may be wrong, at least I see no reason why Harbour should limit dimensions this way. It's of course possible that this is the threshold value where window couldn't fit on screen anymore and 256 vs. 257 is just a coincidence. This limit was taken arbitrary by Peter and it was the size of screen buffer in very old GTWVT implementation. When I was rewriting GT core code I removed this limit from GTWVT and I left only #define for backward compatibility. You can safely remove them but please only remember to add dynamically allocate in RESIZE() method TCHAR[cols] string and use in hb_gt_wvt_PaintText() function instes of text[]. BTW there is typo: 'text[ WVT_MAX_ROWS ]' instead of 'text[ WVT_MAX_COLS ]' though without bad side effects because both defines are equal. In case 2) the desktop (CTWIN) window creation will fail and return -1, and my app isn't ready to handle that, causing mentioned mess. Traces pointed to these lines in ctwin.c: #define HB_CTWIN_MAXROWS 255 #define HB_CTWIN_MAXCOLS 255 It's only for strict CT3 compatibility. Which artificially limits max window size. Removing the size validation in window creation code fixes all artifacts experienced in 2). Shall I commit it? The only bad side effect will be internal error (out of memory) if user tries to create very huge window. In case 3) it's again an artificial limit controlled by #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 Do we need this, or should we raise this limit? This can be eliminated. If we fix the code for automatic font resizing then limitation by screen dimensions should begin to work just like in old GTWVT code. We can introduce minimal font size (i.e. 4x2 or 6x3) to resolve the problem. This leaves 4) on the TOFIX list. You can disable the code for font resizing by: HB_GTINFO( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_ROWS ) and it should resolve the problem. I have no idea what is expected behavior for: SetMode( 250, 250 ) when HB_GTI_RESIZEMODE_FONT is set. We have few possible choices, i.e.: 1. chose default window dimensions: 25x80 2. resize rows and cols like in HB_GTI_RESIZEMODE_ROWS 3. refuse to create window (SETMODE()-FALSE). Users using HB_GTI_RESIZEMODE_FONT should chose sth what they prefer. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Mon, 05 Oct 2009, Alexandr Okhotnikov wrote:
Hi,
Rather for people who do not want to move his code to server side.
ADS is only partial solution and much better and more efficient is
moving whole application to the server and execute it remotely.
50-100 councurrent access
Over 100 in one of my installations.
1. very large load on the server
No at least in programs I wrote. The most expensive is database access
and rest is unimportant.
2. Given the current local machine (very productive) - why do we need
a decision like Terminal-server?
Sorry I do not use terminal server so I do not know what answer do you
expect from me.
3. not everything can be transferred to the server (browse...)
I still do not understand.
In my case whole applications are executed on server side.
SEEK: for numeric fields to translate a string based on the dimension
of the field (no loss of accuracy)
You do not understand the problem. It is problem and it's very serious bug.
For SEEK, I do not see the problem. What exactly I do not understand?
For me it's obvious that seek may not work properly and I do not
understand why I have to clarify such simple things.
Please try this code with pure DBFCDX and LetoDB.
REQUEST DBFCDX
REQUEST LETO
field F
proc main(rdd)
local cFile := _tst
if empty( rdd )
cFile := //127.0.0.1:2812/ + cFile
rddSetDefault( LETO )
else
rddSetDefault( DBFCDX )
endif
dbCreate( cFile, {{F,N,10,4}} )
use (cFile)
? rddSetDefault(), alias(), used()
index on F tag T to (cFile)
dbAppend(); F := 1 / 8
? FOUND:, dbSeek( 1 / 8 )
close
return
If you plan to answer in your next message that you do not use seek
in such context so it's not a problem then please do not waste my
time.
What exactly would the author - one must ask the author. In any case
the project is completed by the author (based on activity over the
past year)
Now we are not talking about the UDF. I would like to, but it means a
change that just lead to incompatibility with the current
implementation
And it's the reason I do not want to touch LetoDB code and I strongly
prefer to create sth new from scratch using my own ideas for final
code. Most of the problems which have to be resolved in such fully
functional remote server implementation I resolved adding MT mode to
Harbour so now it's enough to use this functionality but it also mean
that the new code will not work with older Harbour versions or with
xHarbour.
You can use RDD section in CA-Clipper 5.3 Technical Reference.
Harbour RDD model follow very closely Clipper one. There are only
few small differences and extensions and it was the place were
I started before I touched Harbour RDD code.
few small differences and extensions :)
Your comment clearly shows that you haven't invest even 5 minutes to
compare Clipper documentation with Harbour RDD implementations.
We may return to this discussion when you will have something serious
to say or some precise questions for which you cannot find answers in
Clipper documentation.
I also suggest to look into ChangeLog and if possible into xHarbour
ChangeLog too. A lot of RDD code I committed in the past working on
xHarbour as primary repository. Together with Clipper documentation
it address everything.
If you want to see what it means in practice then please try the
code below. It shows only thr cost of scope setting/restoring in
current LetoDB (3-rd value).
Here are results in my Linux box and localhost connection.
1. using local file access:
RDD: DBFCDX _tst2
creating table... 0.20 sec.
indexing... 0.03 sec.
testing... 0.07 sec.
2. using NETIO:
RDD: DBFCDX NET:127.0.0.1:/_tst2
creating table... 0.72 sec.
indexing... 0.14 sec.
testing... 0.20 sec.
3. using LetoDB:
RDD: LETO //127.0.0.1:2812/_tst2
creating table... 2.43 sec.
indexing... 0.05 sec.
testing... 86.17 sec.
So in this test LetoDB is 431 _times_ slower then NETIO and believe
me it's not the worst case. If you want you can try to increase number
of records and you will see what will happen.
If you repeat this tests in LAN then network overhead should reduce
the difference but I do not think that LetoDB will be faster.
If you have a while then I'm interesting in your results in LAN.
Key values (for a real application) are three:
1. use SHARED!
Yes,
2. LAN (not local)
Only local table access by remotely executed application.
LAN access even using real remote are only partial solutions for me
with some exception when real local access on client side is intentionally
introduced for some special type of applications, i.e. which have to work
without any network access for some time.
Of course you do not have to agree with me but it's not my
Re: [Harbour] What is Przemek's architecture ?
On Mon, 05 Oct 2009, Ernad Husremovic wrote: Hi, During this discussions, Przemek explained that he has no needs for client server RDD: .. In my case whole applications are executed on server side ? Please, can you explain us what is the architecture of your applications ? Especially how do you implement client side ? It's nothing amazing but standard *nix functionality. My applications are executed remotely on the server side usually using some terminal emulators. I wrote my own 'screen' like program which keeps alive applications executed on the server side even if client station disconnect or crashes. In such case program is still running and when user login again he continues his job using the same instance of programs. If he want then he can start working with the program in the office then he can close terminal program without logout from my application and login from home or on next day and continue his work. For users there is not difference it's WAN or LAN access. Because pure terminal programs does not give to the remote program access to all local resources on client side then we are using also small servers installed on client computers which are controlled remotely by application on the server so we can share serial or USB ports, display pictures, access to local printers or drives, activate some programs on client computer, etc., We usually use SHH connections with internal tunnels for our client side services. In the future GTNET should give the same functionality for all multiprocess platforms (single process platforms like DOS or WinCE can be only clients) and should contain buildin most important client side services with support for executing .hrb code sent dynamically from the server side so programmers can easy extend it in any way he want also dynamically not only by static relinking client side code. Now this functionality is available if user collects (in some cases creates) all peaces himself though it's not very hard work. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile Error Using BCC 6.20
On Thu, 01 Oct 2009, Szak�ts Viktor wrote: Hi Viktor, Binary file import32.lib matches Binary file intraweb_100_140.lib matches Binary file ws2_32.lib matches How can I include these libs to build Harbour? Thanks. ws2_32 is already on the liblist, so the problem may lie elsewhere As I can see ws2_32 is not given when harbour.dll is linked. We have: ilink32.exe -q -Gn -C -aa -Tpd -Gi -x c0d32.obj @__dyn__.tmp and inside __dyn__.tmp: ..\..\..\..\..\source\common\obj\win\bcc\expropt1_dyn.obj + [...] ..\..\..\..\..\source\vm\obj\win\bcc\vm_dyn.obj + , ..\..\..\..\..\bin\win\bcc\harbour-20-bcc.dll,, cw32mt.lib import32.lib so only w32mt.lib and import32.lib which are hrdcoded in win/bcc.mk are passed and it could be the source of problem. For me it looks like a typo and instead of DLIBS := $(foreach lib,$(LIBS),$(LIB_DIR)/$(lib)$(LIB_EXT)) we should have DLIBS := $(foreach lib,$(LIBS) $(SYSLIBS),$(lib)$(LIB_EXT)) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Mon, 05 Oct 2009, Alexandr Okhotnikov wrote: Hi, Yes, it is and here LetoDB is very inefficient because is disables existing RDD optimizations. My example (two connections to the table): RDD: DBFCDX \\192.168.170.11\income\_tst2 testing... 25.58 sec. RDD: LETO //192.168.170.11:2812/_tst2 testing... 56.09 sec. 1. what is 'your example' in this test? 2. how many records (N_RECCOUNT) you tested? 3. can you also show results for my example? This is your example, but the network Can you explain how it's possible that in your network it works faster then on my computer locally? Without modification in the code I sent it seems impossible for me. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Mon, 05 Oct 2009, Alexandr Okhotnikov wrote: Hi, I (honestly) do not understand the meaning of this example, since a long time (even with the clipper 5.2) away from such actions (unstable floating-point on different machines and operating systems) Use for just such a character string (always predictable results) index on STR(F,10,4) tag T to (cFile) dbSeek( STR( 1 / 8, 10, 4 ) ) In some index formats like NTX such rounding and conversion to string is done automatically at C level so it's not necessary to slow down the code by repeating the same job at .prg level. In CDX and NSX format numeric and date values are stored as modified IEEE758 double values without any rounding and people often use this fact to store number with some very wide range where precision cannot be strictly defined. They do not need exact comparison so FL arithmetic difference are not a problem at all. Any hidden rounding like in LetoDB makes such code unusable so in my opinion it should be fixed. What we do with the current functionality? Bright and well into the future and the present is bad? For me the main problem is with time necessary to update existing code. I can make some minor cleanups, casting, update code for current SVN, etc. quite easy but to make serious fixes and modifications I will have to double the work necessary for creating such code from scratch because I will have to carefully follow existing code and integrate my own strongly different ideas with it. Looking at current LetoDB code I've found the only one thing which I would like to copy and integrate with Harbour: blowfish encryption of course if we do not have it yet in contrib or RTL. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Mon, 05 Oct 2009, Horodyski Marek (PZUZ) wrote: Hi, Can I start a terminal window on a Windows applications working on Linux ? For example via putty or another terminal ? What GT in app shuld then linked ? yes, you can use PuTTY as terminal emulator login to some *nix machine and execute any harbour application linked with GTTRM. In my case whole applications are executed on server side. Not universally used is Linux :( Clients do not even know where to program is running and which OS is used on server machine. They can use any OS they like on his own computers if some terminal emulators are supported, i.e. recently very popular is using cellar phones as such remote terminals. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Hi, The only issues are UNICODE in gtwvt [so I'll probably disable it there while we fix it]. (Also gtwin, but gtwin isn't really critical for me, it will fade quite soon) Without real windows access it will be hard for me to help in this problem. Ops, the other issue is -shared mode GPF. Maybe I'll make some more tests. Anyhow I don't use it either. Have you used -fpic switch for dynlib code compilation? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile Error Using BCC 6.20
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Hi, Indeed you're right. With one small correction, I think $(LIB_DIR) must be needed for BCC when run in WINE env (according to your comments in .mk), so this line should be added instead, after 'DLIBS :=' line: DLIBS += $(foreach lib,$(SYSLIBS),$(lib)$(LIB_EXT)) Yes sure though as far as I know we do not use any LIBS yet to create harbour*.dll so it should also work. I cannot retest it now even with 5.5 (where it was working anyway), I hope Mario can report some results with 6.2 and someone else with 5.5. After that we should commit. I tested it with 5.5. and WINE and it works. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What is Przemek's architecture ?
On Mon, 05 Oct 2009, Ernad Husremovic wrote: Especially how do you implement client side ? Switch to Linux :) I am on linux :). But my custumers are not :( But only your application needs Linux or other *nix like OS and your customer can still use the same OS as so far. Believe me that I also do not plan to force any OS on client computers. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: The only issues are UNICODE in gtwvt [so I'll probably disable it there while we fix it]. (Also gtwin, but gtwin isn't really critical for me, it will fade quite soon) Without real windows access it will be hard for me to help in this problem. I still maintain my offer, if you want to have some fun with the issue ;) (and have time) I can pass you RDP access to a freshly installed VM with 64-bit Windows and dev tools. Since it's on my MBP, we only have to sync schedules. Thank you for your proposition and I'll ask you about it if we cannot resolve the problem in other way. If this isn't appropriate I can make some screenshots, maybe it gives you some clues about the situation. Well, here they are: http://www.syenar.hu/harbour/win64.png http://www.syenar.hu/harbour/win64u.png Looks that non ASCII glyphs are missed. Is it local to Win64 or the same happens also in Win32? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Mon, 05 Oct 2009, Maurilio Longo wrote: Hi, latest svn code calls both postinst.prg and postinst.cmd ! 'hbxbp' library skipped ./bin/os2/gcc/hbrun.exe --hb:gtcgi ./bin/postinst.prg ! Making e:\harbour\bin\hbmk.cfg... .\bin\postinst.cmd Is this something I'm seeing because of OS/2 use, or is it a general issue? There are also other problems with postinst.prg. It makes HB_BUILD_PARTS=compiler unusable because to compile hbrun it's necessary to recompile whole core code. Now it simply does not work. Additionally in some package compilation which can be done using non real directories but for final system wide installation (i.e. RPMs) hbrun is linked with shared harbour library but cannot be executed from the temporary build time directories. In summary I'm not sure it's good idea to use it. Instead of making things simpler it introduce additional dependencies. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What is Przemek's architecture ?
On Mon, 05 Oct 2009, Massimo Belgrano wrote: Hi Massimo, Today is my birthday and your vision is the best present happy birthday gtnet will be a important solution for many user here how gtnet in windows will recognise user at login to reestablish his session? It will depend on the authentication method and used encryption in final code. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: What is Przemek's architecture ?
On Mon, 05 Oct 2009, Angel Pais wrote: Hi, Nowadays I'm using a similar but GUI solution: I share xbase++ aplications runing under wine+samba tru FREENX SERVER. The drawback is you can´t use local resources as printers. For this I had to develop a client/server printing program. Have you ever measured the WINE overhead in IO operations? It's over 10 times slower then native code. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: What is Przemek's architecture ?
On Mon, 05 Oct 2009, Angel Pais wrote: Hi, I know that. But my clients wont accept a console application, so I'm in a trap I have to live with. Hence the need for a linux gui development platform and/or a client server RDD. So maybe you should try XHGTK or some other native Linux GUI library and execute them remotely using client side XServers? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Looks that non ASCII glyphs are missed. Is it local to Win64 or the same happens also in Win32? Will try to test it later. It's not just the glyphs, notice the font is not the right one. (and placement is also wrong, but that may be a consequence of former). Please try Win64 builds with current SVN code. I've just committed: 2009-10-05 17:28 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/rtl/gtwvt/gtwvt.c ! fixed font selection in UNICODE builds - it was not selected at all ! fixed possible double font freeing in non UNICODE builds but I cannot test it - WINE does not replicate precisely MS-Windows font selection and encoding. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Hi Viktor, There are also other problems with postinst.prg. It makes HB_BUILD_PARTS=compiler unusable because to compile hbrun it's necessary to recompile whole core code. Now it simply does not work. Additionally in some package compilation which can be done using non real directories but for final system wide installation (i.e. RPMs) hbrun is linked with shared harbour library but cannot be executed from the temporary build time directories. In summary I'm not sure it's good idea to use it. Instead of making things simpler it introduce additional dependencies. That's why I was asking about it before making any move. Well maybe the shared vs non-shared issues should be solved for all occasions in some ways. But what we should with HB_BUILD_PARTS=compiler? Now this option is unusable. To create native hbrun binaries it's necessary to recompile whole core code. The second very important problem is support for installation in some temporary directory tree for some packages like RPM or mpkg_tgz.sh. We have to introduce sth like: HB_INSTALL_PREFIXTMP (or any other name you may preffer) which will be used as prefix in all places where HB_*_INSTALL envvars are used. This is important to restore long time existing functionality which is broken now. I see some benefit in this setup because we do have to eat our own dog food. Plus of course it allows to create a shell independent postinst in a language which is well understood by everyone. So so far I like it despite the extra issues you mention. I believe these can be solved in some ways. I do not see any easy way to eliminate OS shell scripts. Please also note that we do not have in core code any platform dependent extensions and if you want to continue using .prg file to finish installation phase then we will have to introduce wrappers for POSIX functions like umask(), chmod(), chowm(), chgrp() getuid(), getgid(), getpwnam(), getpwuid(), getpwent(), ... to set user permission, owner, groups, makes conversions between numeric and literal user/group names, etc. Now all such things are available as simple shell instruction and we do not have to build them yourself using .prg wrappers to low level C functions. I really think it will be much more work then updating simple script. In real life it will not be using .prg code but it will be adding to core Harbour code .prg wrappers for platform specific functions when sth new will have to be set in installation phase. BTW do you know what we may need in VMS? For DOS/WIN/OS2 the installation code is nearly the same and can be quite easy moved to .mk files. We can use it for all platforms to copy or create config files and then we can execute native scripts to make operations which are strongly platform specific. In practice we talk here only about other systems. For DOS/WIN/OS2 such files can be empty. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Hi, Just tested it, and visual glitches are now all gone in GTWVT UNICODE mode. Thank you very much. Fine. I would like to ask about keeping some builds in UNICODE mode so thay can be tested in the future. AFAIR UNICODE mode was fully functional about two years ago and we lost it by some modifications which were not well tested. I hope that now all basic GTWVT functionality What remains is the char encoding problem. It seems as if in UNICODE mode the HB_GTI_CODEPAGE setting is ignored. Yes it is and it's intentional. HB_GTI_CODEPAGE is MS-Windows only extension used in non UNICODE mode. Use hb_setTermpCP()/hb_setKeyCP()/hb_setDispCP() just like in all other GTs. See tests/gtchars.prg I'm getting line-drawing chars in place of 852 accented chars. see above. [ Something similar happens in UNICODE GTWIN, but there I'm seeing '?' chars. ] GTWIN was never updated to work internally in UNICODE mode so I guess it has problem with non ASCII characters. It should be quite easy to add support for UNICODE mode for someone who can verify the results on the screen. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Ops, the other issue is -shared mode GPF. Maybe I'll make some more tests. Anyhow I don't use it either. Have you used -fpic switch for dynlib code compilation? I'm getting this: --- x86_64-w64-mingw32-gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -DUNICODE -oexpropt1_dyn.o -DHB_DYNLIB -fpic -c ../../../expropt1.c ../../../expropt1.c:1:0: warning: -fpic ignored for target (all code is position independent) --- So it has to be sth else. Maybe you can catch were it GPFs using GDB. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Hi, I'm using subdirs inside 'pkg' dir for similar purpose on non-*nix packaging. Could this work also in this scenario? I have no idea what it does. In general I ask about sth what allows to set HB_*_INSTALL envvars so they will be stored in any configuration files and but real file copy will be done in some different prefixed place. Just simply make mpkg_tgz.sh working from normal user account in any *nix system. I do not see any easy way to eliminate OS shell scripts. Please also note that we do not have in core code any platform dependent extensions and if you want to continue using .prg file to finish installation phase then we will have to introduce wrappers for POSIX functions like umask(), chmod(), chowm(), chgrp() getuid(), getgid(), getpwnam(), getpwuid(), getpwent(), ... to set user permission, owner, groups, makes conversions between numeric and literal user/group names, etc. This is not necessary, as these functions can be called from .prg code using hb_run() or similar method. Sorry but now I'm really confused. What is the reason thay you want to replace shell scrpits by .prg code which calls shell commands? What I don't know is how to eliminate most of the still significant amount of .sh code, plus special pkg creation logic currently used. Why you want to eliminate it? What is wrong with shell scripts? F.e. we've been talking about creating .spec file on the fly, but writing this in .sh doesn't seem to enhance much, since we'd just swap one proprietary solution to another, and the resulting .sh code would be quite cryptic for most ppl. If we could move it to .prg code though, it would certainly be more maintainable / digestable. We was talking about generating spec files as workaround for integration with current make system but for me it was never goal itself but rather temporary hack. Please make it in the way you prefer but I would like to ask you to restore functionality which is broken now: RPMs and TGZ packages. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Hi, Please make it in the way you prefer but I would like to ask you to restore functionality which is broken now: RPMs and TGZ packages. And here comes the problem: I have no idea how to do this. Given that I had never installed Harbour with sudo and I will never do, plus I don't have an .rpm based distro, this is a flight in the dark for me. Your help would be needed. Or, I'll try to reimplement it in .prg (at least the .tgz part, which I can test). Your recent modification forced using sudo for simple mpkg_tgz.sh. I want to restore previous functionality which didn't need any special user rights to create Harbour binaries using mpkg_tgz.sh. So I'm asking about restoring pure shell script functionality here. No sudo and no RPM at all. I want to be able to execute mpkg_tgz.sh without sudo as it was possible in the past. In the last months I was updating .spec files after your modifications but I do not think it was good idea because each time after few days you used to change sth and they stop to work again. Last time it was not even 24 hours. I updated them: 2009-09-23 22:05 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) and your modifications: 2009-09-24 17:42 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) made my fixes unusable. You have to begin to control it yourself or at least you should not commit modifications which break some builds. If you can restore mpkg_tgz.sh functionality then I can try to adopt your solution to RPMs and once again hack .spec files and build script to work with current make system. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote:
I've recently enabled UNICODE for all non-x86 win builds
exactly for above reason.
Thank you very much and also for your tests.
Oh I see. I was missing hb_setTermCP() in Windows builds.
Adding it fixed GTWVT UNICODE build. (I didn't retest non-UNICODE
yet, I hope it stays OK too)
In non unicode builds it can be used only for character translations
but it cannot change font encoding. It can be done only using MS CP
number with HB_GTI_CODEPAGE though if someone has a while then he
can create function which will translate our unicode CPs to MS CP
numbers and we can use it inside SETDISPCP() method to automatically
set font encoding in non unicode GTWIN and GTWVT builds.
With GTWIN the remaining problems are HB_GTI_WINTITLE
CP in UNICODE mode (I didn't report this before), plus the
I guess you are talking about national characters but it's
general problem which should be covered globally for all
windows Unicode translation inside common/hbwince.c which
should respect HVM CP.
As temporary workaround you can add additional translation
using _SET_OSCODEPAGE so it will work like for file names.
high level drawing (seemingly window related) problem. I'll
try to make tests with 32-bit UNICODE to check what exactly
enables this.
AFAIK Windows does not use 32-bit UNICODE values and support only U16.
What is the exact problem?
If you are talking about save/restore which drops box characters
then you should disable VGA compatible video buffer and enable
extended attributes in {Save,Rest}Screen() data by:
hb_gtInfo( HB_GTI_COMPATBUFFER, .F. )
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Fri, 02 Oct 2009, Alexandr Okhotnikov wrote: Hi, Take as an axiom: in the harbour need open replacement ADS (for multi-user environment) for those who still uses DBF and can not be (not wants) to switch to SQL Rather for people who do not want to move his code to server side. ADS is only partial solution and much better and more efficient is moving whole application to the server and execute it remotely. 2. it does not support timestamp values The main types are (my opinion that this long enough), add the rest later (for DBF, they are not critical) These are only your personal preferences. 3. numeric values in some operations like SEEK are converted to strings so they cannot be safely used with double values because such conversions round them to number of decimal places used to show numeric item on the screen SEEK: for numeric fields to translate a string based on the dimension of the field (no loss of accuracy) You do not understand the problem. It is problem and it's very serious bug. 4. it does not optimize multirecord skips on filtered or set_deleted workareas 5. it does not use aliases on server side so expressions sent to server cannot use aliases too (.f. index key/for, filters, ...) 6. relations are implemented only on client side and this code is not finished - it needs fixes in many places, missing server side relations seriously reduce functionality and performance in programs which use aliases though without server side support for aliases it still not be fully usable. Using ADS almost the same :) almost makes huge difference and unfortunately my code for client side relations in ADS RDD was not fully replicated in LetoDB. As long as it will not be fixed using relations in LetoDB is very danger and may cause data corruption because related area are wrongly positioned in some places. 7. it does not respect many of _SET_* settings and also does not inform server about settings like _SET_DATEFORMAT, _SET_EPOCH, _SET_TIMEFORMAT, _SET_DECIMALS, _SET_FIXED, _SET_EXACT, ... which are important for correct execution of user expressions on server side I think to finish (or customize a specific case) will not take much time It's not the question about the time necessary to implement it but rather how it should be done to keep original author vision which is unknown. I can imagine at least three different implementation which will give different final functionality. Some implementation strongly depends on used communication protocols some others may badly work with .hrb modules automatically registered on server side by clients (i.e. with UDFs used by client in filter or index expressions), etc. I do not know what is the final goal of LetoDB development and to implement it I will have to take some arbitrary decisions which may create problems in the future. 18. I do not see any documentation which divides actions on client and server side so it's hard to add the extensions keeping original author vision, in the moment when such projects stops to be single author code such at least very basic documentation is a must, otherwise we will end with set of functions and RDD methods often replicating existing functionality because each developer tried to resolved his local problems in his own way, it also causes that bug fixing is very hard because developers seeing that sth is potentially wrong have to analyze whole code for possible workarounds in different places, i.e. I'm not able to verify everything what I see after looking at this code without investing day or two in deep analyzing And that, in the harbour is not so? It isn't. I could not find documentation on the RDD (as in the rest of the implementation of what either), but this does not prevent me to use the harbour You can use RDD section in CA-Clipper 5.3 Technical Reference. Harbour RDD model follow very closely Clipper one. There are only few small differences and extensions and it was the place were I started before I touched Harbour RDD code. 20. server uses internally own threads but does not use hbthread.h API what creates problems with portability and adding some extensions in the future, i.e. simultaneous executing .prg code by such threads is impossible now, it also blocks using HVM threads which could resolve important problems in current server implementation Maybe, maybe not I do not understand what you try to say. There is not place for any maybe here. For sure such threads cannot execute simultaneously .prg code and for sure LetoDB performance in concurrent access is strongly reduced by serialized execution using ST HVM. 21. I do not understand some parts of server code, i.e. there is an option to reuse existing tables between connections but why it was added? It cannot work without disabling most of server side processing because there is only single area
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
Hi All, First I think that Alexander should comment this subject not me. So far I was not interested in LetoDB code anyhow seeing your messages I invested some time to look at this code closer and I've found that there are some problems which have tro be fixed: 1. it tries to use DBF record buffer but does not support all field types and features supported by core DBF* RDDs 2. it does not support timestamp values 3. numeric values in some operations like SEEK are converted to strings so they cannot be safely used with double values because such conversions round them to number of decimal places used to show numeric item on the screen 4. it does not optimize multirecord skips on filtered or set_deleted workareas 5. it does not use aliases on server side so expressions sent to server cannot use aliases too (.f. index key/for, filters, ...) 6. relations are implemented only on client side and this code is not finished - it needs fixes in many places, missing server side relations seriously reduce functionality and performance in programs which use aliases though without server side support for aliases it still not be fully usable. 7. it does not respect many of _SET_* settings and also does not inform server about settings like _SET_DATEFORMAT, _SET_EPOCH, _SET_TIMEFORMAT, _SET_DECIMALS, _SET_FIXED, _SET_EXACT, ... which are important for correct execution of user expressions on server side 8. some important RDDI_*, DBI_*, DBOI_*, DBRI_*, DBS_* actions are not implemented at all or are implemented wrongly what breaks some other code, i.e. there is no DBI_GETLOCKARRAY so dbRlockList() function does not work or it informs GT that it uses DBF compatible record buffer and can transfer whole records but such functionality is not implemented so optimized by RDD code COPY TO ... and APPEND FROM ... operations fail 9. it tries to optimize some operations like dbAppend() but it's done in unsafe way which is not compatible with Clipper RDDs, i.e. dbAppend() is buffered and always return success though other client may set FLOCK() on the table so it will fail later when such appended record is sent to the server. For some programs it introduce other bugs because some algorithms may use APPEND rlocks for synchronization and to protect other stations against setting FLOCK so such behavior will causes total desynchronization 10. in some methods it does not send all parameters and settings to server so some operations may not work as expected, i.e. important ordCondSet() settings are not transfer to server side 11. some methods are implemented as dummy ones what only disables error messages when user tries to use them so he does not even know that they failed silently, such things have to be eliminated and I hope it's only unfinished code 12. some operations are hacked to work only in some very limited situations, i.e. DBOI_KEYADD/DBOI_KEYDELETE works only with string key values which does not have any embedded 0 13. some things are implemented wrongly, i.e. if current record is locked (unlocked) then dbRlock( nRecXX ) (dbRUnLock( nRecXX )) calls are ignored 14. the transaction code also looks like unfinished, now it makes only one thing: it delays sending modifications to the server side with only very basic support for modifying the same record more then once, it may be usable in some applications but probably breaks most of programs which were not designed from beginning to work with RDDs where modifications are not visible during updates, missing documentation for exact isolation level causes that such transactions can be safely used only by LETO code authors who well know the internal behavior and created .prg code compatible with it 15. it's not MT safe and needs very serious internal modifications to work with user MT applications. As I can see so far it's not ever defined how it should be done so it's necessary to design such model from scratch. 16. it encodes/decodes messages using sprintf()/sscanf() functions what introduce some additional problems, i.e.: - this is very slow method of data encoding and decoding though in comparison to TCP/IP delay it's not critical - C compilers quite often provide *printf()/*scanf() functions in two version for ST and MT modes so for MT mode it's very important to use MT safe CRTL and leto code have to be always compiled with MT C compiler flags. We have our own hb_sprintf() function which is fully reentrant safe but we do not support hb_sscanf() so it's potential problem - it's very unsafe and hard to protect against buffer overflow and current leto code has a lot of potential buffer overflows which can cause server or client crash or hangup if user pass some data exploiting them - these functions operate on text data but LetoDB needs to transfer also binary data so
Re: [Harbour] SF tracker#2871130: 5 AdsOpenTable and Free Tables with DD (patch)
On Thu, 01 Oct 2009, Chen Kedem wrote: Hi, The following patch was submitted to our bug tracker: http://sourceforge.net/tracker/index.php?func=detailaid=2871130group_id=681atid=300681 Anonymous wrote: In ads1.c (adsOpen function call), when a DD is used, there are instances where free table access might still be desired. This fix solves the problem by introducing a second call to AdsOpenTable after the inital call fails to find the free table in the DD. This procedure was commented on by Alex Wong in the Advantage.xHarbour newsgroup with his approval. See comment with my name Andy Ross in the source to locate the change. Please review and apply if it is the correct solution. 1. it's for old code with bugs which were fixed 2. if 1-st call to AdsOpenTable() success then uninitialized fRetry is used as loop stop condition so the behavior is random and depends on C stack context - potentialy it's infinit loop. Classic example why clear indenting is necessary - due to dropped indenting very serious bug cannot be seen immediately. 3. for non ADS_DATABASE_CONNECTION it repeates exactly the same call which fail before so the next one will also fail 4. fixing above problems is trivial but still the final modification can be source of very serious problems when free tables with the same names as the ones in DD exists. If for some reasons DD tables cannot be accessed, i.e. they are open in exclusive mode by other clients then silently the free tables are open instead without any information for user what may cause that important data will be stored in temporary tables which will be removed later or some other similar bad things. In such context the argument that free tables are usable sometimes we have to revert to free tables are very danger and we will havew to fix above fix. 5. it still does not allow to control by programmer table location and DD has higher priority hiding free tables with the same name. if ADS users really need such functionality then current code allows to access free tables using different connections and connection can be passed as dbUseArea() parameter. Anyhow if it's still not enough for and users wants to use the same connection then we can add option to force free table access by some function or using new ADS* RDD which will inherit from ADS. The second version allows to use COPY TO / APPEND FROM between free tables and DD using the same table names. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] xHarbour compatible Hwgui analog clock.
On Wed, 30 Sep 2009, Itamar Lins wrote: Hi, This is program was created by Luis Basso, analog clock. Works fine with xHarbour, Have you tried with *EXACTLY* the same code? I know quite well both compilers internals and for me such things are impossible. with Harbour I get this is error: error base/1001 Undefined function: HTIMER Called from HTIME(0) The most important question: is missing 'R' your typo? If not then you are using seriously broken HVM and maybe we will have to invest more time in this problem. If yes then you have perfect error message so why you haven't tried to read it and fix your problem? Function HTIMER was not linked with your final application and it's accessed by macrocompiler only so the problem is not reported at link time. I think that you should read some Clipper documentation about linkers and instruction for REQUEST funcName statement. Please check what will happen if you add to your code: REQUEST HTIMER It has the same behavior in Harbour, xHarbour and Clipper. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Type assignment discards qualifiers from pointer target type
On Mon, 28 Sep 2009, Lorenzo Fiorini wrote: This is an old C function but it's used in a 3rd party lib so I can't use HB's standard one. When I build it with 2.0.0beta3 gcc warnings. How can I fix it? It has to be rewritten. This function is buggy. It's illegal in Clipper and in [x]Harbour to modify string buffer returned by [hb]_parc() function. Recent modifications helps to locate such buggy code generating warnings during compilation. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Type assignment discards qualifiers from pointer target type
On Mon, 28 Sep 2009, Lorenzo Fiorini wrote: Yes this is why I'd like to replace it. I've tried to replace it with a prg func but the original works on strings while hb_bit* work on numbers and I'm not sure about the correct conversion to use. Not tested, just written: func BIT( cValue, nOffset, lSet ) local lResult, nChar nChar := strpeek( cValue, nOffset / 8 ) lResult = hb_bitTest( nChar, nOffset % 8 ) if valtype( lSet ) == L .and. lSet != lResult strpoke( @cValue, nOffset / 8, ; iif( lSet, hb_bitSet( nChar, nOffset % 8 ), ; hb_bitReset( nChar, nOffset % 8 ) ) ) endif return lResult Please only remember that unlike the C code you send this function respects @ operator and will not change original string if cValue is not passed by reference. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Type assignment discards qualifiers from pointer target type
On Mon, 28 Sep 2009, Lorenzo Fiorini wrote: Many thanks. I'm not sure my test is correct but I'm still not getting the same results. Modify the offset range (-1) and revert bits (most significant has offset 0): function bitnew( cValue, nOffset, lSet ) local lResult, nChar, nOff, nBit nOff := ( nOffset - 1 ) / 8 + 1 nBit := 7 - ( nOffset - 1 ) % 8 nChar := strpeek( cValue, nOff ) lResult = hb_bitTest( nChar, nBit ) if valtype( lSet ) == L .and. lSet != lResult strpoke( @cValue, nOff, iif( lSet, hb_bitSet( nChar, nBit ), ; hb_bitReset( nChar, nBit ) ) ) endif return lResult best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 xhb support
On Thu, 24 Sep 2009, Phil Krylov wrote: Hik, Of course I can do it and will do it when I have time, I only would like to see that it has established in Harbour. Basically, I don't like the syntax, why was .ARCH. chosen, what do these dots mean, are they somehow related to xBase syntax for logical values and operators? ;) Are there any other samples of usage of such syntax? Does someone else feel it like me? I also do not find it as ideal solution but as alternative we have to add new switch. If we want to use -undef: then the right side value cannot be valid identifier and it's the reason why I added dots (I chose character which does not have special meaning in different shells to avoid unecessary quoting). If you prefer separate switch for such functionality then I'll add it. Please only chose the name for such switch. Let's hope so. The other annoying bit is __PLATFORM__Windows and __PLATFORM__Linux. Hopefully someone will fix them there. I think we ([x]Harbour) should define both versions in the current situation. It was of course a bad choice to make them mixed-case initially, but I think that it should be kept for compatibility. It's quite long time when in Harbour these macros were converted to upper case so users updated their code. Adding support for mixed case macros to Harbour will only confuse them. Now the problem is mostly related to xHarbour and this has to be xHarbour team decision. xHarbour developers should decide if they want to support both macros or rather force code updating. In longer terms the second solution seems to be the best choice. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_xgrablarge() ?
On Fri, 25 Sep 2009, Szak�ts Viktor wrote: Hi, Shouldn't we add memory allocation functions which are able to allocate memory of 64-bit size? We have it: hb_xgrab() ;-) In all platforms except Win64 'long' is large enough to hold pointer. Over ten years ago looking at Win API I said that MS will have horrible problems introducing 64bit support. 32bit 'long' in Win64 is side effect of bad very design decisions which should not happen in such big firm but it does not resolve the problem for us. I think that we can add such function when we will work on new types. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Wed, 23 Sep 2009, Mindaugas Kavaliauskas wrote: I want to share more test results after using memory FS in real project. Report generation time (min:sec): Local disk database 3:07 Network database25:52 Local disk database and MemFS2:22 + 0:03 (copying to memory FS) Network database and MemFS 2:24 + 0:13 (copying to memory FS) Very nice contribution and also final results. In last week I've found a while to make some test with NETIO and MS-Windows. The test were done on WinXP, SMB and NETIO servers were on Suse Linux, T100 LAN. Any opportunistic locks in SMB server were disabled. The test program is attached below. I was testing only shared mode. I tested SMB, NETIO and also xHarbour REDBFCDX and there is not noticeable results. All tests gave results similar: Harbour 2.0.0beta3 (Rev. 12431), Windows XP 5.1.2600 Dodatek Service Pack 3 RDD: DBFCDX type: CHARACTER (shared) records: 1, repeated: 1, modulo: 1 creating database and index...69.66 sec. skip test... 17.38 sec. count: 1 revers skip test... 17.28 sec. count: 1 testing seek... 17.28 sec. count: 1 goto test... 17.34 sec. count: 1 goto+skip test... 30.38 sec. count: 1 skip test... 17.41 sec. count: 1 revers skip test... 17.27 sec. count: 1 testing seek... 17.30 sec. count: 1 goto test... 17.27 sec. count: 1 goto+skip test... 30.31 sec. count: 1 Total execution time... 268.91 sec. and the difference were smaller then 0.5%. Just simply the net overhead is such huge that rest is unimportant. The difference can be seen only in local tests and here Harbour was faster then xHarbour but it's mostly result for faster Harbour VM. The local disk tests in WinXP and Harbour using DBFCDX with native IO took ~2.50 seconds. It means that in above test Harbour consumes less then 1% and rest is the cost of network overhead. BTW testing REDBFCDX do not forget to add RE_TURBO( .f. ) - REDBFCDX enables dirty reading by default or add Sx_SetTurbo( .t. ) to other RDDs to enable it too. Otherwise there is no sense to make any comparisons and probably it's also the reason why Miguel has better then native SMB protocol results testing REDBFCDX. Of course the difference strongly depends on hardware transport layer, the results in WAN or in T10/T1000/T1 LANs can be completely different but this test clearly shows that to reach real speed improvement it's necessary to create RDD oriented server which can group IO operations in some bigger logical units to reduce number of packages which have to be send and confirmed. Operating only on transport layer like NETIO we can reach some small improvement yet, i.e. we can disable confirmation in UNLOCK operation what in above tests can increase the SKIP tests ~20% (Maybe I'll add such extension soon) or we can try to group some operations, i.e. join index lock and concurrent access counter read into single operation what may give even 50% speed improvement in the SKIP but it needs modifications in core RDD code so I do not like it because it may start very danger in longer terms process of adding local hacks to core RDD code. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MT compile warning
On Mon, 21 Sep 2009, Mindaugas Kavaliauskas wrote:
Hi,
code:
PROC main()
#pragma begindump
#include hbthread.h
static HB_CRITICAL_NEW( s_mtx );
void somefunc( void )
{
HB_CRITICAL_INIT( s_mtx );
}
#pragma enddump
causes warning on BCC:
Warning W8075 test.prg 7: Suspicious pointer conversion in function somefunc
The same warning is generated for HB_CRITICAL_LOCK( s_mtx ) and
HB_CRITICAL_UNLOCK( s_mtx ).
HB_CRITICAL_NEW() creates structure which does not need any initialization
and can be used with hb_threadEnterCriticalSection()/
hb_threadLeaveCriticalSection() functions.
HB_CRITICAL_INIT()/HB_CRITICAL_LOCK() and HB_CRITICAL_UNLOCK() are not
public macros. Please do not use it.
To reduce confusions probably I'll hide them for non HVM core code in
the future.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 xhb support
On Thu, 24 Sep 2009, Szak�ts Viktor wrote: Hi, I've added xhb support to hbmk2 a while ago, but so far I didn't see quite a huge interest in this feature, so, since it's a maintenance nightmare, and it isn't very well tested either, I'd like to remove it. But before I do so, I'd like to ask opinions on this feature. Does anyone thinks it's good, or does anyone actually needs it? [ f.e. now with -undef:.ARCH. support in Harbour, I still had to keep complete old code because of xhb support. ] If it creates any bigger problems then simply drop it. Anyhow you can also try to keep Harbour support with minimal cost and simply add function to update final commands like Harbour parameters or linked library list. BTW you can pass -undef:.ARCH. to xHarbour compiler and it will be simply ignored. The most important reason to keep xHarbour support in hbmk2 is using it as base make system in some 3-rd party projects what allows to eliminate different make files/systems but without some help from xHarboru developers then it will be hard to keep it alive. In this particular case I suggest to pase -undef:.ARCH. to xHarbour compiler and maybe in the future one of xHarbour developers (maybe Phil) will add support for this switch so it will not be ignored. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour under OS/2 - eCS 12604
On Thu, 24 Sep 2009, David Arturo Macias Corona wrote: Hi, Przemek: hbrun.exe run fine. As you remember it was raising GPF Yes but Viktor changed -P64 to -P72 in WLIB parameters and I guess it also resolved the problem with symbol table inside HBEXTERN library which caused the GPF. ..\..\..\hpdffdft.c(2109): Warning! W136: Comparison equivalent to 'unsigned == 0' [...] in current SVN I disabled all OpenWatcom warnings for external/ code. If you repeat the test then they should disappear. tlabel.c(548): Warning! W013: col(18) unreachable code tlabel.c(548): Warning! W013: col(18) unreachable code It's a side effect of -gc3 code compiled by OpenWatcom. In fact it's an OpenWatcom problem (false warning). You can safely ignore them. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bin/postinst.cmd
On Thu, 24 Sep 2009, Szak�ts Viktor wrote: Hi, To be in sync with GNU Make to solve the same problem IMO easiest would be to use os2cp in postinst too. (if there isn't any native way to silence copy operation in OS/2 shell). In general using copy with the same source and destination file is bad idea and it may cause file corruption or data lost. If possible we should add protection against such situations. We should add such protection globally in instsh.mk. Now we have code like: ifeq ($(INSTALL_DIR),) # Empty install dir INSTALL_RULE := @$(ECHO) $(ECHOQUOTE)! Can't install, install dir isn't set$(ECHOQUOTE) else [...] # installation endif It should be enough top change it to sth like: ifeq ($(INSTALL_DIR),) # Empty install dir INSTALL_RULE := @$(ECHO) $(ECHOQUOTE)! Can't install, install dir isn't set$(ECHOQUOTE) else ifeq ($(realpath $(INSTALL_DIR)),$(realpath .)) INSTALL_RULE := @$(ECHO) $(ECHOQUOTE)! Skip installation to the same directory$(ECHOQUOTE) else [...] # installation endif endif best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bin/postinst.cmd
On Thu, 24 Sep 2009, Szak�ts Viktor wrote: Hi, I'd drop the error message (! Skip installation...) from your patch though, as it'd produce many lines in output with little use to builders. IMHO it's better then: make: Nothing to be done for `install'. which appears by default if I we do not set INSTALL_RULE. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bin/postinst.cmd
On Thu, 24 Sep 2009, Szak�ts Viktor wrote: Hi, IMHO it's better then: make: Nothing to be done for `install'. which appears by default if I we do not set INSTALL_RULE. That's true, but can we somehow make it fully silent with some tricky command? Maybe define an $(ECHONUL) command with content $(ECHO) /dev/null|nul Would that work? It's platform/shell dependent command so we should introduce new macro for it. The best name will be TRUE and for POSIX shells it should be defined as: TRUE=true and it should be used in all places where we need dummy command which does not set execution error. Anyhow in this particular case I do not think that 1 message for harbuor/install and on non *nix platforms two 2 harbour/doc and harbour/doc/en-EN is enough reason to introduce it. More messages can appear only if someone set BIN or LIB directory to default build time localization but it's still only few messages. I've just committed: INSTALL_RULE := @$(ECHO) $(ECHOQUOTE)! Skip install, destination dir '$(INSTALL_DIR)' is the same as source$(ECHOQUOTE) what allows to verify destination directory settings. If you think it's unnecessary then simply add support for TRUE command and replace it with: INSTALL_RULE := $(TRUE) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bin/postinst.cmd
On Thu, 24 Sep 2009, Szak�ts Viktor wrote: Anyhow in this particular case I do not think that 1 message for harbuor/install and on non *nix platforms two 2 harbour/doc and harbour/doc/en-EN is enough reason to introduce it. More messages can appear only if someone set BIN or LIB directory to default build time localization but it's still only few messages. This is the default case on non-*nix for lib, so it will be a lot of messages there. [ I can't test it right now though. ] Still only few - one per library and executable file and they will replace current: 1 file(s) copied so it does not increase the output too much. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0beta3 (Rev. 12618) dirmake and /usr/include tree permissions...
On Thu, 24 Sep 2009, elart wrote: Hi, [...] I think i might have something to dress into the /usr/bin/hbmk.cfg conf file. and there be something wrong during install process of harbour because it change the /usr/include tree files and dirs permissions. Viktor, Marco is right here. I haven't noticed it so far. I've only seen similar problem with strip but because you removed 'strip *' command from postinst.sh I haven't wrote about it. I see that you copied from mpkg_tgz.sh/harbour.spec to postinst.ch this line: chmod 644 $HB_INC_INSTALL/* It has to be removed. Both mpkg_tgz.sh and harbour.spec were working on local directories only so it was safe to make such trick but here you are operating on real system directories so it's very serious bug which have to be fixed. There is also problem with current mpkg_tgz.sh. It was always operating on local directories only so user could execute it from non root account. Now it operates on real system directories so it's not possible to create packages without write permissions to system directories and creating packages makes also hidden upgrade of Harbour system wide installation. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Thu, 24 Sep 2009, Przemyslaw Czerpak wrote:
The test program is attached below. I was testing only shared mode.
I forger about attachment.
Now test code included.
best regards,
Przemek
//#define TST_NUM
//#define TST_DAT
//#define TST_CHR
#ifndef TST_NUM
#ifndef TST_DAT
#ifndef TST_CHR
#define TST_CHR
#endif
#endif
#endif
#define TST_SILENT
//#define NO_ORDKEYVAL
static nLoops := 1
static nModulo := 1
static nRepeat := 1
#ifdef _SIX3_
#xtranslate ordkeyval([xx,...]) = sx_keyData([xx])
#endif
field FTST
#ifdef TST_ADS
#include ads.ch
REQUEST ADS
init proc tst_rddInit()
AdsSetServerType( ADS_LOCAL_SERVER )
return
#endif
proc main(rdd, xLoops, xModulo, xRepeat, xLateInd, xReUse, xExcl)
local aDb, n, cFi:=./_tstdb, cNet:=, tm, total:=seconds(), cType,;
lLateInd:=!empty( xLateInd ), lReUse:=!empty(xReUse),;
pConn
set alternate to nettio.log additive
set alternate on
?
#ifdef __HARBOUR__
// SET DBFLOCKSCHEME TO 5
#endif
#ifdef __CLIP__
SET TRANSLATE PATH OFF
#endif
#ifndef FlahShip
#ifdef _SIX_
REQUEST SIXCDX
REQUEST SIXNSX
REQUEST SIXNTX
#else
REQUEST DBFCDX
REQUEST DBFNTX
#ifdef __HARBOUR__
REQUEST DBFNSX
#endif
#endif
#endif
? VERSION()+, +OS()
if empty(xExcl)
SET EXCLUSIVE OFF
else
SET EXCLUSIVE ON
endif
#ifdef TST_NUM
cType := NUMERIC
aDb:={{FTST, N, 20, 9}}
#endif
#ifdef TST_DAT
cType := DATE
aDb:={{FTST, D, 8, 0}}
#endif
#ifdef TST_CHR
cType := CHARACTER
aDb:={{FTST, C, 20, 0}}
#endif
if !empty( xLoops )
nLoops := val( xLoops )
endif
if !empty( xModulo )
nModulo := val( xModulo )
if nModulo == 0
nModulo := nLoops
endif
endif
if !empty( xRepeat )
nRepeat := val( xRepeat )
if nRepeat == 0
nRepeat := 1
endif
endif
if !empty(rdd) .and. upper(rdd)=NET:
n:=rat(:,rdd)
cNet:=left(rdd,n)
rdd:=substr(rdd,n+1)
#ifdef __HARBOUR__
#ifndef __XHARBOUR__
NETIO_CONNECT()
#endif
#endif
endif
#ifdef __HARBOUR__
/* disable dirty reading in native RDDs */
Sx_SetTurbo( .f. )
#endif
#ifdef __XHARBOUR__
request BMDBFCDX
request REDBFCDX
/* disable dirty reading in REDBFCDX RDD - it's enabled by default */
RE_TURBO( .f. )
if !empty(rdd) .and. upper(rdd) = REDBFCDX
n:=rat(:,rdd)
if n != 0
cNet:=substr(rdd,n+1)
rdd:=left(rdd,n-1)
endif
if empty(cNet)
cNet:=127.0.0.1
endif
? connecting to: + cNet + :2813
pConn := NET_OPENCONNECTION( cNet, 2813 )
if empty( pConn )
? cannot connect to the server.
return
endif
cNet:=
endif
#endif
if empty(rdd)
#ifdef FlahShip
rdd:=DBFIDX
#else
rdd:=DBFCDX
#endif
endif
rddSetDefault(rdd)
? RDD: + cNet + rdd + type: + cType + iif(empty(xExcl), (shared) ,
(exclusive) )
? records: + ntrim( nLoops ) + ;
, repeated: + ntrim( nRepeat ) + ;
, modulo: + ntrim( nModulo )
if !lReUse
aeval(directory(cFi+.??x),{|x|ferase(x[1])})
ferase(cFi+.dbf)
? padr(creating database+iif(lLateInd, , and index)+..., 30)
tm := seconds()
dbcreate(cNet+cFi, aDb)
use (cNet+cFi)
if !lLateInd
if NTX $ upper(rdd)
index on FTST to (cNet+cFi)
else
index on FTST tag tg1 to (cNet+cFi)
endif
close
use (cNet+cFi) alias cFi
set Index To (cNet+cFi)
set Order To 1
endif
for n:=1 to nLoops
dbappend()
replace FTST with dbval(n)
#ifndef TST_SILENT
indexar2(nLoops)
#endif
next
dbcommit()
?? seconds() - tm, sec.
if lLateInd
? padr(creating index..., 30)
tm := seconds()
if NTX $ upper(rdd)
#ifndef TST_SILENT
index on FTST to (cNet+cFi) eval indexar()
#else
index on FTST to (cNet+cFi)
#endif
else
#ifndef TST_SILENT
index on FTST tag tg1 to (cNet+cFi) eval indexar()
#else
index on FTST tag tg1 to (cNet+cFi)
#endif
endif
dbcommit()
?? seconds() - tm, sec.
endif
close
endif
use (cNet+cFi)
set Index To (cNet+cFi)
set Order To 1
testskip()
testrskip()
#ifndef NO_SEEK_TEST
testseek()
#endif
testgoto()
testgotoskip()
testskip()
testrskip()
#ifndef NO_SEEK_TEST
testseek()
#endif
testgoto()
testgotoskip()
dbclosearea()
? padr(Total execution time...,30)
?? seconds() - total, sec.
?
#ifdef __XHARBOUR__
if pConn != NIL
NET_CLOSECONNECTION( pConn )
endif
#endif
return
function testskip()
local tm, vcur, vold, rcur, rold, l:=0
? padr(skip test..., 30)
tm := seconds()
dbgotop()
while !eof()
++l
vcur:=FTST
rcur:=recno()
#ifndef NO_ORDKEYVAL
if ordkeyval()!=dbval(recno())
? ordkeyval=+dspval(ordkeyval())+, dbval=+dspval(dbval(recno()))
endif
if rold!=nil .and. (vcur vold .or. (vcur == vold .and. rcur = rold ))
? skip faild: curr=[+dspval(vcur)+][+ntrim(rcur)+]
prev=[+dspval(vold)+][+ntrim(rold)+]
endif
#endif
vold:=vcur
rold:=rold
dbskip()
enddo
?? seconds() - tm, sec. count: +ntrim(l)
return nil
function testrskip()
local tm, vcur, vold, rcur, rold, l:=0
? padr(revers
Re: [Harbour] dbDrop() question
On Wed, 23 Sep 2009, Szak�ts Viktor wrote: Hi, Will dbDrop() also delete compound index and memo file if they are present? dbDrop() deletes table, memofile and production index if they exist. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: library format
On Wed, 23 Sep 2009, Maurilio Longo wrote: Hi Maurilio and David, I cannot say too much about OS2 real usage because I do not know this system. IMHO it will be good to create doc/os2howto.txt file to collect such information as David presented because it may be very useful in some farther developing saving the time. So, IMHO, we should use our very limited resources (and Viktor and Przemyslaw willingness to help us) to keep everything working. Even adding watcom compiler is, IMHO, a waste of time/resources. Here I do not agree. OS2 Watcom compiler support introduced one of the most important future to keep OS2 port alive. Now we can make OS2 build tests on Linux and Windows what greatly helps in code updating so we do not have to ask you or David about verification of even single commit to update the code after seeing your compile logs and repeat the request. For me it was a milestone in Harbour OS2 support. Please also note that OpenWatcom builds Harbour in C++ mode what also forces keeping the code clean with valid casting. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Tue, 22 Sep 2009, Saulius Zrelskis wrote: Hi, File hb_out.log is generated: Application Memory Allocation Report - D:\TESTS\test.exe Terminated at: 2009.09.22 13:19:25 Total memory allocated: 107343446 bytes (913 block(s)) Warning, memory allocated but not released: 99808005 bytes (7 block(s)) We need self contain .prg example to replicate this problem. Without it it's hard to guess what is wrong. In my tests all works correctly without memory leaks. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Tue, 22 Sep 2009, Przemyslaw Czerpak wrote: We need self contain .prg example to replicate this problem. Without it it's hard to guess what is wrong. In my tests all works correctly without memory leaks. Ups, I see you were replying to Mindaugas message with test code. I haven't tested it yet by I guess you did not remove tables and indexes created in memory. Use dbDrob() before application exit. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, 22 Sep 2009, Lorenzo Fiorini wrote: Hi, Sorry I'm not sure I've understood correctly. Warning CDX indexes created so far for such CDPs are not sorted using the same conditions as current SVN code so new applications should reindex. Does it mean that we need to recreate all the indexes after this change? I thought that ChangeLog entry is clear enough. Have you used Harbour CDP with accented or multibyte characters? If yes then you have to recreated all character indexes. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
On Sun, 20 Sep 2009, Szak�ts Viktor wrote:
[...]
Usually in system installation we have existing structure like:
instpref/bin - with executable files, one of PATH dirs
we should not use any subdirectories here
instpref/lib - with shared libraries, one of system library dirs
we can use subdirectory for static libraries and
it's even suggested to reduce name conflicts
but native shared library have to be in this
localization
instpref/include - with header files, we can and should use subdir
for our own header files
instpref/share/man - with man files - sub dirs with strict meaning and
naming convention. Sometimes it's without share
instpref/man (i.e. in /usr/local)
instpref/share/doc - with non man documentation, we should use subdir
instpref/etc - with configuration files, if necessary it's
possible to use subdirs with the exception to
/usr which stores configuration files in /etc
FHS suggests also to use /etc/opt and /etc/local
for configurations files from /opt /usr/local
For applications which can be globally accessed it's suggested to move
configuration files into '/etc' directory. It helps in creating backups
but also in locating configuration files by other programs bound with
given application, i.e. in our case we may talk about final user
applications compiled by Harbour which may look for some system global
Harbour configuration files, i.e. now /etc/harbour/hb-charmap.def which
is used optionally by some GTs like GTCRS or GTTRM (for details look at
source/rtl/gtcrs/hb-charmap.def, I plan to introduce also hb-keymap.def
and hb-termmap.def for GTTRM what should allow to configure some unknown
for GTTRM terminals by users or system admins) and I would like to keep
/etc/harbour as default global harbour configuration directory though
for packages installed in '/opt' FHS suggests to use '/etc/opt'.
It's not easy to create rules which can follow exactly different
distribution policy so we should give an interface to set each of the
above directory separately. It means that we have to introduce yet
two new envvars for man and configurations files, i.e. HB_MAN_INSTALL
and HB_ETC_INSTALL or HB_CNF_INSTALL.
Building RPM packages we have predefined macros like %{_bindir}, %{_libdir},
%{_includedir}, %{_mandir}, %{_sysconfdir}, %{_defaultdocdir}, ... which
can be used to set our own HB_*_INSTALL variables to suggested system
directories without touching HB_INSTALL_PREFIX so it's not a problem.
We do not use autoconf so we have to chose sth ourselves for 'manual'
installation using only HB_INSTALL_PREFIX. We have to remember also
that at runtime hbmk2 may need to replicate some parts of our detection
logic.
Here are 4 system wide installations which can be used in different
*nixes and try to confirm FHS as close as possible.
'-' means soft link,
1. FHS2.3 compliant localization for add-on applications:
=
/opt/
/harbour/
/bin/
harbour_executable_files
/lib/
native_harbour_libraries
[/addon_harbour_lib/
native_addon_libraries]
[/platform/cc/
platform_cc_libraries]
/include/
harbour_header_files
[/addon_harbour_lib/
addon_header_files]
/share/
/man/
/man1/
harbour_man_pages.1
/doc/
harbour_doc_files_and_dirs
[/addon_harbour_lib/
addon_docs]
/etc - /etc/harbour
/etc/
/harbour/
harbour_config_files
/etc/
/opt/ (if exists)
/harbour - /etc/harbour
if /opt/bin exists then we should create in this directory soft links
to executable files in /opt/harbour/bin
if /opt/lib exists then we should create in this directory soft links
to harbour shared libraries in /opt/harbour/lib
if /opt/man/man1 exists then we should create in this directory soft links
to harbour shared libraries in /opt/harbour/share/man/man1
2. FHS2.3 compliant localization for distribution applications:
===
/usr/
/bin/
harbour_executable_files
/lib/
soft_links_to_native_harbour_shared_libraries
/harbour/
native_harbour_libraries
[/addon_harbour_lib/
[/platform/cc/
platform_cc_libraries]
/include/
Re: [Harbour] build 12599 and os/2
On Tue, 22 Sep 2009, Szak�ts Viktor wrote:
writing it like this works ok
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
else
ARSTRIP = @$(ECHO) did not strip $(LIB_DIR)/$@
endif
hm ;) can't we use something which doesn't produce any output?
I guess plain empty $(ECHO) will not work unless we redefine
it to GNU version.
What about removing ARSTRIP from create_library and using sth like:
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
endif
AR_RULE = $(create_library) $(ARSTRIP) $(RM) __lib__.tmp
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2 .dll
On Tue, 22 Sep 2009, Maurilio Longo wrote: Hi, Ok, I'm able to build .dlls on OS/2 using gcc and they work since build 12599 (I've tested hbtest.exe only, but if it works everything should work as well). Thank you very much. I still have a question though: on OS/2 .dll names are restricted to 8.3 only. So, how can I name harbour .dlls? harbour.dll :-) BTW now we have GNU make for OS2 working with long internal definitions so I think we should remove FOR %I command loops from config/os2/gcc.cf and config/common/watcom.cf added as workaround for this problems and restore previous versions. Please remember that these rules causes that old files in given directory are added to library without any validation if they belongs to given library or not, i.e. they forced other workarounds to not add hbpp.obj to hbpp library. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, 22 Sep 2009, Lorenzo Fiorini wrote: I thought that ChangeLog entry is clear enough. Have you used Harbour CDP with accented or multibyte characters? If yes then you have to recreated all character indexes. Sorry but I have multi-millions records tables, I need to carefully plan the rebuild indexes. I use codepages with accented ( at least we call them in such way ) Sorry it's terminology/translation problem, probably Phil Krylov is the best person to define precis names but for sure not me not me. I thought about sorting method and our CPs definitions. Any of IT* CPs has marked accented characters. To reduce confusions I listed Harbour CPs which are defined with accented characters and multibyte characters. but you didn't list them in the msg. Here is my setup: REQUEST HB_CODEPAGE_ITISB REQUEST HB_CODEPAGE_ITISO REQUEST HB_CODEPAGE_IT850 None of above CPs uses accented characters which are not sorted using simple byte weight just like normal letters. They also do not use multibyte characters so nothing will change for them just like for most of other CPs. REQUEST HB_UTF8TOSTR HB_SETCODEPAGE( __CP_HOST__ ) HB_SETTERMCP( __CP_TERM__, __CP_HOST__, TRUE ) I also still have C53b/Fivewin apps that work on the same files. Not at the same site, Harbour apps are the next version of the same set of applications. Do I need to recreate the indexes when I switch between C53b/DBFCDX and Harbour? The modification was only for CPs which cannot be Clipper compatible because Clipper supports only simply byte weight sorting. Any Harbour CPs using multibyte characters or accented characters which are not sorted using the same rules as for any other character (simple character weight) were not Clipper compatible and will never be so this modification did not change anything in Clipper compatibility area. Things which were not compatible because Clipper does not support extended national sorting are still not compatible. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] set deleted onnot workin anyore from last CVS
On Mon, 21 Sep 2009, J. Lefebvre wrote:
Hi,
Using an older ADSRDD do not solve the problem . seem to be higher in RDD
structure.
Compiling the very last cvs version I discovered 'SET DELETED ON' do not
work anymore (using ADSRDD).
I see some modification around the 15-09-2009.
Any idea ?
I do not see any problems in ADS RDD behavior. SET DELETED ON/OFF works
as expected. I used code below to make tests.
If you think that sth does not work as it should then please create
self contain code example like the one below so we can see what's
the problem (if any).
best regards,
Przemek
/*** tst.prg ***/
request ADS
proc main()
AdsSetServerType( 1 )
rddSetDefault(ADSCDX)
dbCreate( _tst_, {{F1,C,10,0},{F2,D,8,0}} )
use _tst_
while lastrec() 10
dbAppend()
if recno() % 3 != 0
dbDelete()
endif
enddo
? set delete on
set delete on
dbEval({||qout(recno())})
? set delete off
set delete off
dbEval({||qout(recno())})
close
wait
? reuse
use _tst_
? set delete off
set delete off
dbEval({||qout(recno())})
? set delete on
set delete on
dbEval({||qout(recno())})
close
wait
return
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Possible OLE bug
On Wed, 23 Sep 2009, Szak�ts Viktor wrote: To all: My dev PC (WinXP) died tonight, so don't expect frequent SVN updates until the situation gets resolved. Ups, hope you will resolve it soon. BTW, the patch looks wrong to me as WideToAnsi() isn't passed any length data, so the conversion will cut the string at the first zero byte and garbage will be returned after that point by next hb_itemPutCLPtr() call. Somehow data length should be pulled from pVariant structure. Better check current Harbour SVN code. He simply asked about help in code he copied from old Harbour SVN repository and is distributing himself. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12586] trunk/harbour
On Mon, 21 Sep 2009, vszak...@users.sourceforge.net wrote: Hi, 2009-09-21 14:03 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * harbour-win-spec * harbour-wce-spec % Deleted some unnecessary lines (related to strip feature) Please revert it. __strip and __objdump macros were redefined intentionally. Without it in some systems RPM will try to use standard system commands for Win PE binaries. I left note about it in the .spec files. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12586] trunk/harbour
On Mon, 21 Sep 2009, Szak�ts Viktor wrote: Hi, I can revert it, but this way there is again duplicate [...] please do it. Why should rpm call strip (and objdump) in these cases at all? Because it on some distros ti tries to create separate package with debug information. Can't it be simply disabled? I do not know such method. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
