[Harbour] somebody can give a reply on harbour user mailing list?
somebody can give a reply on harbour user mailing list? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 05, 2008 1:16 AM To: [EMAIL PROTECTED] Subject: [Harbour-users] Docs on installation? I am trying to use the mpkg_rpm_from_svn.sh script but it fails at this point after quite some time :- (just the last few lines shown) Aharbour/config/w32/mingw.cf Aharbour/config/w32/pocc.cf Aharbour/obj U harbour Checked out revision 9837. "rpm -b" is deprecated, use "rpmbuild -b" /usr/lib/rpm/rpmb_deprecated: line 3: exec: rpmbuild: not found [EMAIL PROTECTED] ~]$ Any help would be appreciated. System is Mandriva Linux 2008.1 running in VBox (under Mandriva Linux 2009.0) Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, I forgot about one thing, in order to implement __i18n_gettext() with hashes, two hash lookups are needed, but my tests were doing only one. Is there a way to eliminate two hash lookups in this expression: // IN: text, hash IF text $ hash text := hash[ text ] ENDIF // OUT: text I'm thinking of something like hb_HGet(), but to return the original key (or a passed default) if it's not found in the hash table (instead of generating an RTE). Brgds, Viktor On 2008.11.05., at 8:09, Szakáts Viktor wrote: Hi Przemek, Loading became more than twice as fast now, a now just a bit (18%) slower than current __i18n_loadfrommemory(). Perfect results for such generic function. r9830 r9838 __i18n_loadfrommemory(): 3.72 3.72 __i18n_gettext(): 3.39 3.33 hb_deserialize(): 10.26 4.41 hash lookup: 2.58 4.16 For some reason simple hash lookup became a bit slower, and now 30% slower than __i18n_gettext() (previously it was 30% faster). Still pretty good though. I wonder what may cause this. Brgds, Viktor On 2008.11.05., at 0:03, Przemyslaw Czerpak wrote: On Tue, 04 Nov 2008, Szak�ts Viktor wrote: Hi Viktor, If you can implement the raw hash deserialization - besides being great stuff by itself -, I think we will be able to simply drop the current special i18n functions, since we have everything we need using existing Harbour elements, with similar or possibly better overall performance. The only remaining part will be the "high-level" API, possibly in .c, as we've discussed. Please try current code. Hash deserialization should be noticeable faster. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
I can improve the speed by reading hash items in raw form but it may cause some bad side effects because hashes uses national collating by default. IMHO it's wrong and I would like to change it. The default should be binary collating we optimized for speed. If user wants then he can enable national sorting order by hb_hSetBinary( hValue, .F. ) or hb_hSetCaseMatch( hValue, .F. ). Simple binary sorting should give noticeable speed improvement. But in such case I can try to trust that the order read from serialized data is correct and eliminate hash array resorting. Hi, I see Przemek has already implemented national/binary hash ordering, so my remarks are too late, but I really do not understand a problem here. From my point of view hash is a way to obtain data value by key value (not by number like in array). The internal implementation of the hash it is hash's business. Have we documented, that hash uses sorted array and binary search to find a key value? Have we documented that HB_HGETKEYS() should return string keys in ascending order? If we did it, then it's a documentation bug!!! I think hash is hash, and user code should not depend on hash internal implementation. We can use any algorithm for sorting keys. We can also use the real hashing algorithm, i.e. generate some checksum of key, and try to find value using this checksum. In this case national/binary sorting is not used at all. So, I do not understand at all, why do we need hb_hSetBinary() and hb_hBinary()?!It should be hash's internals and users should not care about it! Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Szakáts Viktor wrote: Hi Przemek, I forgot about one thing, in order to implement __i18n_gettext() with hashes, two hash lookups are needed, but my tests were doing only one. Is there a way to eliminate two hash lookups in this expression: // IN: text, hash IF text $ hash text := hash[ text ] ENDIF // OUT: text I'm thinking of something like hb_HGet(), but to return the original key (or a passed default) if it's not found in the hash table (instead of generating an RTE). Hi, I see no problem here. It's simple to eliminate two lookups by using HB_HSCAN() and HB_HVALUEAT(), but this could not increase speed because of additional PCODE for function calls. Implementation in C language by using hb_hashScan() and hb_hashGetValueAt() for sure will be best and will use a single hash lookup. Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hb* scripts and dylibs path under Mac OS X
I use standard gnu makefiles with hb* scripts but under Mac OS X I can't find the right way to shared executables. Everything gets built correctly using the same makefiles I use under Win and Lin but at runtime the executable looks for libmylib.0.dylib while my lib is libmylib.dylib. If I change it using install_name_tool I can get it working but it's not the best way. Could it be that we need sth different in the hb-mkslib for darwin? Any idea? best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
I think that it will be also good to introduce internal hash flag which will force resorting on 1-st access and implement internal b-tree structure for hashes. It's waiting for really long time. I'll try to make these modifications in some spare time. Hi, does b-tree have a big advantage over simple binary search in case all data is IN MEMORY. I see no advantage in data lookup. There is advantage in data insertion in case of large number of keys. Best regards, Mindaugas P.S. b-tree is implemented in sqlmix. If there are more needs for this algorithm, we can create some "universal" module in hbvm library and use it in all cases (hashes, sqlmix, adsx, etc.), to avoid code duplication. Meanwhile I can hard code support for binary sorted hashes to serialize procedure. It should give noticable performance improvement so the results will be comparable to current __I18N_LOADFROMMEMORY() function. BTW I do not see in current __I18N_*() functions sth for binary array sorting so they will not work correctly with national characters if you will try to sort the array at Harbour level. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-02 13:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw Czerpak wrote: 2008-11-02 13:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprb.c ! fixed possible GPF/internal memory corruption in code like: ? HB_I18N_GETTEXT_NOOP( "Ala ma kota" + " !!!" ) Mindaugas, the fix is also the answer for the question you left in TODO. Hi, thanks. Great! It clear now. It seems I've copied some compiler code from another place, but could not understand all its logic. So, I left this comment. I hope it helped to find the bug. Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-05 13:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-11-05 13:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vc.mak * -GA option only used for HB_VISUALC_VER >= 70. Please update this if older versions also support it. * include/hbver.ch * source/common/hbver.c * Some more fiddling with version number terminology and hb_version() values: HB_VERSION_MICRO -> HB_VERSION_RELEASE HB_VERSION_BLD_DATE_STR -> HB_VERSION_BUILD_DATE_STR HB_VERSION_BLD_DATE -> HB_VERSION_BUILD_DATE HB_VERSION_BLD_TIME -> HB_VERSION_BUILD_TIME HB_VERSION_CHANGELOG_REV -> HB_VERSION_CHANGELOG_ID Third part of version number could also be: PATCH, MICRO, BUILD SVN revision could also be: BUILD BUILD is inherently connected with a physical binary, so I dropped it, PATCH is limiting and negativ, MICRO is not very common (otherwise good), so a finally opted for RELEASE. REVISION kept as is. ; If there are no objections I'll HB_VER_REVISION macro to HB_VER_RELEASE. This will be an INCOMPATIBLE change, but I expect not too many ppl being affected. * TODO - Removed MT as a TODO. Thanks Przemek for the nice job. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas, > I see Przemek has already implemented national/binary hash ordering, so my > remarks are too late, but I really do not understand a problem here. > From my point of view hash is a way to obtain data value by key value (not > by number like in array). To be precise: hashes allows to operate non continuous on indexes. These indexes does not have to be strings. F.e. AFAIR you are using pointers. > The internal implementation of the hash it is hash's business. > Have we documented, that hash uses sorted array and binary search to find a > key value? Have we documented that HB_HGETKEYS() should return string keys > in ascending order? If we did it, then it's a documentation bug!!! I think > hash is hash, and user code should not depend on hash internal > implementation. > We can use any algorithm for sorting keys. We can also use the real hashing > algorithm, i.e. generate some checksum of key, and try to find value using > this checksum. In this case national/binary sorting is not used at all. > So, I do not understand at all, why do we need hb_hSetBinary() and > hb_hBinary()?!It should be hash's internals and users should not care about > it! I fully agree. But I didn't want to discuss about it. I still remember from my xHarbour days discussion about keeping build order in hashes for replicating associated arrays class behavior. If we can agree that we do not need backward internal order compatibility then I'll be very happy in removing hb_hBinary(). But please do not forget about one thing. National sorting can cause that two different keys will be equal in some languages. It's the same problem like with CASEMATCH flag. So hb_hBinary() does not only change the internal item order but also keys hashing method. BTW in PHP hash value items are kept in build order and can be resorted by user manually and PHP authors documented it. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, We can use any algorithm for sorting keys. We can also use the real hashing algorithm, i.e. generate some checksum of key, and try to find value using this checksum. In this case national/binary sorting is not used at all. So, I do not understand at all, why do we need hb_hSetBinary() and hb_hBinary()?!It should be hash's internals and users should not care about it! I fully agree. But I didn't want to discuss about it. I still remember from my xHarbour days discussion about keeping build order in hashes for replicating associated arrays class behavior. If we can agree that we do not need backward internal order compatibility then I'll be very happy in removing hb_hBinary(). You have my vote for it. But please do not forget about one thing. National sorting can cause that two different keys will be equal in some languages. It's the same problem like with CASEMATCH flag. So hb_hBinary() does not only change the internal item order but also keys hashing method. I think this just leads to possible misunderstandings. IMO two different strings should be different regardless of national settings. If we want 'sorted array' feature with quick find support, that's a different thing and should be discussed/implemented outside hashes. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom
On Wed, 05 Nov 2008, David Arturo Macias Corona wrote: Hi David, > >Should be fixed. Please tray after: > > 2008-11-04 17:28 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > >> ../../../thread.c(402): Warning! W869: col(25) use of '_beginthread' > >> requires build target to be multi-threaded > >add -bm to OpenWatcom switches (CPPFLAGS) in owatcom.cf > OW docs said on "bm": > - > (Netware, OS/2, Win32 only) This option causes the compiler to emit into > the object file references to the appropriate multi-threaded library > name(s). The macros _MT and __SW_BM will be predefined if "bm" is > selected. > - > If "-bm" is added to owatcom.cf how it affect Harbour ST / MT ? > "appropriate multi-threaded library name(s)" refer to OW libraries ? It will make what we want. The code will use MT safe functions from OpenWatcom CRTL. > Thanks Przemek, AND CONGRATULATIONS :-) > For first time in Human history we have a build complete for current > Harbour - OS/2 - OpenWatcom 1.7 :-) Fine and many thanks for your help. > In make_ow.log I found: > for hbvmmt: > ../../../thread.c(402): Warning! W869: col(25) use of '_beginthread' > requires build target to be multi-threaded > ( not -bm added until confirmation ) -bm should pacify this warning and make other code which may call CRTL functions ready to use in MT programs. If possible please also make some tests with tests/mt/mttest*.prg hbmk_os2.cmd should be updated to support also OpenWatcom builds. You can take the code for OpenWatcom from hbmk.bat. If OS2 does not have such small command line size limits like DOS and Windows COMMAND.COM then instead of creating _hb_mk.tmp file for linker you can pass all parameters to wlink directly. > hbtest.exe output included below > Can you add harbour\config\os2\owatcom.cf to SVN ? yes sure but if possible please send me your current os2\owatcom.cf to avoid stupid typos caused by modifications I cannot verify. > - > and for config\os2\owatcom.cf: > >[19]: CPPFLAGS = -w2 -d1 -zq -bt=NT > -bt=OS2 > >[56]: echo @%watcom%/binnt/wlink.lnk >> __link__.tmp > For now is excluded > If included, should be used SYSTEM directive and which value ? Probably in 32bit OS2 by default is set to: os2v2 or os2v2_pm. This is necessary when you want to change the default to create different binaries, f.e. for console or GUI mode, DLLs or you want to make cross builds. > Harbour Regression Test Suite > Copyright (c) 1999-2008, http://www.harbour-project.org/ > --- > Version: Harbour 1.1.0dev (Rev. 9832) > Compiler: Open Watcom C++ 12.70.8 (32-bit) >OS: OS/2 4.50 >Date, Time: 2008.11.05 01:50:46 >Output: (stdout) > Shortcut opt.: ON > Switches: > === [...] > Test calls passed: 4687 ( 99.49 % ) > Test calls failed: 24 ( 0.51 % ) Fine, exactly the same results as on other platforms. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas, > does b-tree have a big advantage over simple binary search in case all data > is IN MEMORY. I see no advantage in data lookup. There is advantage in data > insertion in case of large number of keys. Exactly and this is the only one reason. The question is if it's important enough to invest time for it ;-) Best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] one cent for todolist
I dream reading some argument in todolist so compliment to Harbour that have done a big amount of changes Can I suggest another point that will be useful for make an uniform documentation of harbour Define a standard make system so each platform/c compiler will use similar instruction for compile a little sample, or a big project. so is difficult document how harbour works I suggest something like build project.exe from test1.prg,test2.prg,test.prg,hbvm.lib,hbmacro.lib,hbpp.lib,gtwvw.lib This disuniformity add difficult at first steep with harbour Imo can be choice from 3 ways Hbmk.prg defined by Przemyslaw for make uniform > If I'll find spare time to make some cleanups in hbmk.prg then I'll > commit it to SVN. It should give similar to hb* script functionality Pbmake by Phil Barnet is a make engine for Clipper, Xbase++, C and ASM written in clipper have Support conditional directives will performing actions just before/after the compile process Jump to Editor on Compile Failure We modification for be custom for harbour and multiplatform BrMake is a sub-project of https://sourceforge.net/projects/hrbtoolslibs/ This project ts written in [x]harbour and will be driven by command line or project file Command line syntax Need modification for multiplatform harbour have made a choice of high quality but make system is not at the same level of quality now In my opinion pbmake and brmake are similar so I suggest Viktor and or Przemyslaw verify if hbmk can be a good way or if the replacement for hbmake can be phmake/brmake Either are written in PRG Either will a good make system for compile either require modification for having same project file on multiple architecture Thanks in advance >Assign to: >Detail...: UNICODE support. >Status...: Open. >Assign to: Przemek >Detail...: Define multi platform platform API for GTs which can mix > graphics objects with standard text output. Now it's > possible in GTXWC, GTWVG and GTALLEG. This I will discuss > yet also with xHarbour developers. >Status...: Open. >Assign to: >Detail...: Add GTNET driver which will allow to run Harbour application > remotely. GTNET will be used on server side and on client > side any native GT driver. >Status...: Open. >Assign to: >Detail...: Add support for remotely controlled GUI objects so we will > be able to create GUI programs with GTNET. >Status...: Open. >Assign to: >Detail...: Add NETRDD - meta RDD which will allow transport layer > between client application and server application with any > other chosen RDD driver. Idea similar to GTNET but for RDD > drivers - it's sth like ADS does. >Status...: Open. Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi, From my point of view hash is a way to obtain data value by key value (not by number like in array). To be precise: hashes allows to operate non continuous on indexes. These indexes does not have to be strings. F.e. AFAIR you are using pointers. Yes, I know keys can be also numeric. Perhaps it's a lack of english knowledge to express the difference between a hash and array in a clear way. I'm using all type of hash keys, not only pointers. So, I do not understand at all, why do we need hb_hSetBinary() and hb_hBinary()?!It should be hash's internals and users should not care about it! I fully agree. But I didn't want to discuss about it. I still remember from my xHarbour days discussion about keeping build order in hashes for replicating associated arrays class behavior. If we can agree that we do not need backward internal order compatibility then I'll be very happy in removing hb_hBinary(). AFAIR, the problem with xHarbour was, that in the beginning it does not had a hash and TAssociativeArray() was used. Later hash implementation has changed it, and for backward compatibility some side effects was replicated in hashes. I believe we do not need to follow backward compatibility of xHarbour's TAssociativeArray(), I like solutions without side effects. But please do not forget about one thing. National sorting can cause that two different keys will be equal in some languages. It's the same problem like with CASEMATCH flag. Well, I did not know such things. After such know knowledge I'll be afraid to use ==. Perhaps, I'll write my own string_[binary_]equal() :) I really do not know what is the best solution in this case, but I see binary comparison most natural. Best regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> Well, I did not know such things. After such know knowledge I'll be afraid
> to use ==. Perhaps, I'll write my own string_[binary_]equal() :)
If you do not use CP which can introduce equal chars then you do not
have to think about such problem.
BTW I also do not like it and I changed original CDP code to never
return that strings are equal when == is used and strings are binary
different. So now we do not have such problem as long as my hack exists.
> I really do not know what is the best solution in this case, but I see
> binary comparison most natural.
But it cannot be used for hashes when CASEMATCH is disabled.
In such situation we have to use use functions which operate on
national characters to check which values in binary data are
letters for given language what makes hash array internals
CDP dependent. We can reduce the problem by storing modified
(hashed) keys when CASEMATCH is enabled so at least internal
representation will be always the same. The side effect is
that we will not be able to return original key value, f.e.:
h := hb_hSetCastMatch( {=>}, .F. )
h[ "Mindaugas" ] := "Kavaliauskas"
for each v in h
? v:__enumKey(), v
next
will show:
MINDAUGAS Kavaliauskas
but I think it's worth to pay. If other developers will agree
with me then I'll change internal hash representation so keys
will be hashed when added and then always sorted in binary form.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
I think that using standard serialization method will increase
functionality, f.e. users can easy change the place where they store
i18n translation tables, f.e. they can use DBF with MEMO fields.
I can update this code but if Mindaugas already has some working code
then maybe we should not repeat the work.
Mindaugas?
Hi,
my local i18n implementation is minimal. It has these functions:
// Set/Get language
PROC HB_i18nSetBaseLanguage( cLang, cTitle )
FUNC HB_i18nSetLanguage( cLang )
FUNC HB_i18nGetLanguage()
// Get translated string
FUNC HB_i18n_gettext( cId, cContext )
// Manage translation table
FUNC HB_i18ntable_create()
FUNC HB_i18ntable_add( aStrings, cId, cText, cContext )
// Save/Load table to/from binary (serialized hash) file
FUNC HB_i18ntable_save( aStrings, cFile )
FUNC HB_i18ntable_load( cFile )
// Save/Load table to/from text (.pot) file
FUNC HB_i18ntable_savetext( aStrings, cFile )
FUNC HB_i18ntable_loadtext( cFile )
// Load table. Windows only function! I always save translation tables
in resource
FUNC HB_i18n_load( cLang )
It is a little different implementation, than Viktor's. For example I do
not have hb_i18n_gettextlang( [, ] ), because all
strings are extracted from loaded hash values (other languages are in
file/resource). But I do support domain/context (in a minimalistic
implementation: hash table key is "msgid$$$msgctxt"). I attach my i18n
implementation at the end of the letter.
I general, I see translation tables implemented by hashes more flexible.
Usage of serialization function allows to store language files in any
media; file, memo field, etc. Harbour "native" hash functions allows a
simple management of translation table, it's very easy to write utility
for deleting, merging, editing translation tables (I'm using such
utility with a simple browse editor instead of standard GNU gettext
utilities). No special functions are needed, native hash functionality
is enough.
Both hashes and Viktor's implementation of translation table uses a
binary search, so I speed of table lookup should be almost the same.
There is no need to duplicate hash lookup code. That's everything I can
add to current discussion about i18n table implementation.
I think that some upper level functions like translation tools or .pot
files manipulations can be written as .prg code so user can easy extend
it. The low level functions and hb_i18n_gettext*() for RT performance
should be written in C.
Yes, my C "fluency" is incomparable to yours, so maybe
I'm not the best candidate for this job :)
After we find the best solution I can help to do C implementation.
FUNC __I18N_GETTEXT( cText, hTrans, cDomain )
local hDomain
if cDomain == NIL
cDomain := "[MAIN]"
endif
if cDomain $ hTrans
hDomain := hTrans[ cDomain ]
if cText $ hDomain
cText := hDomain[ cText ]
endif
endif
return cText
This code forced me to test if NIL can by a hash key. It's a pity, but
it's not :) We would be able to drop 3 lines of code, by removing
default cDomain initialization to "[MAIN]".
What are opinions about NIL beeing a hash key (not from the point of
view of this sample, but for hashes in general)?
Best regards,
Mindaugas
#define CONTEXT_SEPARATOR "$$$"
STATIC s_aStrings := {=>}, s_cLang := "", s_cTitle := ""
PROC HB_i18nSetBaseLanguage( cLang, cTitle )
s_cLang := cLang
s_cTitle := cTitle
RETURN
FUNC HB_i18nSetLanguage( cLang )
LOCAL cDump, aStrings
cDump := HB_i18n_Load( cLang )
IF cDump != NIL
aStrings := HB_DESERIALIZE( cDump )
IF VALTYPE( aStrings ) == "H"
s_aStrings := HB_DESERIALIZE( cDump )
s_cLang := cLang
RETURN .T.
ENDIF
ENDIF
RETURN .F.
FUNC HB_i18nGetLanguage()
RETURN s_cLang
FUNC HB_i18n_gettext( cId, cContext )
LOCAL cRet
IF cContext != NIL
cContext := cId + CONTEXT_SEPARATOR + cContext
ELSE
cContext := cId
ENDIF
IF HB_HHasKey( s_aStrings, cContext )
cRet := s_aStrings[ cContext ]
IF cRet != ""; RETURN cRet
ENDIF
ENDIF
RETURN cId
FUNC HB_i18ntable_create()
RETURN {=>}
FUNC HB_i18ntable_add( aStrings, cId, cText, cContext )
IF cContext != NIL
cContext := cId + CONTEXT_SEPARATOR + cContext
ELSE
cContext := cId
ENDIF
aStrings[ cContext ] := cText
RETURN aStrings
FUNC HB_i18ntable_save( aStrings, cFile )
LOCAL hFile, cDump
IF ( hFile := FCREATE( cFile ) ) == -1; RETURN .F.
ENDIF
cDump := HB_SERIALIZE( aStrings )
FWRITE( hFile, cDump, LEN( cDump ) )
FCLOSE( hFile )
RETURN .T.
FUNC HB_i18ntable_load( cFile )
LOCAL hFile, nLen, cDump, aStrings
IF ( hFile := FOPEN( cFile ) ) == -1; RETURN NIL
ENDIF
nLen := FSEEK( hFile, 0, 2 )
FSEEK( hFile, 0, 0 )
cDump := SPACE( nLen )
FREAD( hFile, cDump, nLen )
aStrings := HB_DESERIALIZE( cDump )
FCLOSE( hFile )
RETURN aStrings
FUNC HB_i18ntable_savetext( aStrings, cFile )
LOCAL hFile, cValue, cKey, nI
IF ( hFile := FCREATE( c
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> r9830 r9838
> __i18n_loadfrommemory(): 3.72 3.72
> __i18n_gettext(): 3.39 3.33
> hb_deserialize(): 10.26 4.41
> hash lookup: 2.58 4.16
> For some reason simple hash lookup became
> a bit slower, and now 30% slower than
> __i18n_gettext() (previously it was 30%
> faster). Still pretty good though. I wonder
> what may cause this.
Probably there are some different conditions in tests.
Binary search is noticeable faster then the previous one.
Below I'm attaching test code.
You asked about eliminating two scans in code like:
if cText $ h
cText := h[ cText ]
endif
return cText
And I see that Mindaugas gave perfect answer. If you rewrite
this code in C then it will use only one pass.
Anyhow here we can think about adding yet another feature to
hash arrays. We can introduce new hash flag that will indicate
that on access when variable with given key does not exists in
hash array then this key is return. In such case the above code
will look like:
return h[ cText ]
We can also make the same functionality in different way and instead
of intorducing new flag we can add special syntax for such situation,
f.e.:
return h[ @cText ]
this is only for perofrmance reasons. Using C we can easy write function
like:
HB_FUNC( HB_HKEY )
{
PHB_ITEM pHash = hb_param( 1, HB_IT_HASH );
PHB_ITEM pKey = hb_param( 2, HB_IT_HASHKEY );
if( pHash && pKey )
{
ULONG ulPos;
hb_hashScan( pHash, pKey, &ulPos );
if( ulPos )
pKey = hb_hashGetValueAt( pHash, ulPos );
hb_itemReturn( pKey );
}
else
hb_errRT_BASE( EG_BOUND, 1133, NULL, hb_langDGetErrorDesc(
EG_ARRASSIGN ), 2, pHash, pKey );
}
and in such case the above .prg code will look like:
return hb_hKey( h, cText )
but I haven't check how big overhead will be caused by function
call in this case. You can try to compare:
func f1(cText,h)
if cText $ h
cText := h[ cText ]
endif
return cText
with:
func f2(cText,h)
return hb_hKey( h, cText )
best regards,
Przemek
best regards,
Przemek
#define N_LOOP 1
#define N_SIZE 1000
proc main()
local h1, h2, aKeys, i, n, t, tn, x
h1 := {=>}
h2 := {=>}
hb_hSetBinary(h2,.f.)
aKeys := array(N_SIZE)
for i:=1 to N_SIZE
aKeys[i] := "[" + str( i, i%20+10 ) +"]"
h1[ aKeys[i] ] := aKeys[i]
h2[ aKeys[i] ] := aKeys[i]
next
t := secondsCPU()
for n:=1 to N_LOOP
for i:=1 to N_SIZE
x := aKeys[i]
next
next
tn := secondsCPU() - t
? "Other code overhead", tn, "sec."
t := secondsCPU()
for n:=1 to N_LOOP
for i:=1 to N_SIZE
x := h1[ aKeys[i] ]
next
next
? "Binary hash:", secondsCPU() - t - tn, "sec."
t := secondsCPU()
for n:=1 to N_LOOP
for i:=1 to N_SIZE
x := h2[ aKeys[i] ]
next
next
? "Binary hash:", secondsCPU() - t - tn, "sec."
return
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
ormation: "Code page name" are to "Char Set" as you see some times are confused by the alias name, any people can think incorrectly that iso-8859-1 is the same than windows-1252 but are real different Char Set Yes, exactly. Very important that ISO-8859-1 is an official standard, while Windows-1252 is not. They are similar, but not the same. I'd think we should encourage everyone to use the ISO standards for best portability. read MSDN please Windows-1252 is the standard used at windows application. ISO-8859-1 is the standard used at Linux and html application, but have a lot of synonyms on different Linux platform. I use it on my php applications. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] RE: Harbour Digest, Vol 25, Issue 24
>Date: Wed, 5 Nov 2008 14:56:27 +0100 >From: "Massimo Belgrano" <[EMAIL PROTECTED]> >Subject: [Harbour] one cent for todolist >To: >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset="us-ascii" > >I dream reading some argument in todolist so compliment to Harbour that >have done a big amount of changes > >Can I suggest another point that will be useful for make an uniform >documentation of harbour >Define a standard make system so each platform/c compiler will use >similar instruction for compile a little sample, or a big >project. so is Have you test xMate :) ? [ ... ] >>Assign to: >>Detail...: Add NETRDD - meta RDD which will allow transport layer >> between client application and server application with any >> other chosen RDD driver. Idea similar to GTNET but for RDD >> drivers - it's sth like ADS does. >>Status...: Open. > > Massimo, NETRDD -> LetoDB. Who know about possibility LetoDB on madiacy TCP/IP ? We need GTNET and wiedr access to sqldatabase (oracle, db2, mssql) and class/tools to www/html hosting (in this order). Regards, Marek Horodyski ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Wed, 05 Nov 2008, Miguel Angel Marchuet wrote: Hi Miguel, > Windows-1252 is the standard used at windows application. CP-1252 is local MS name. Nothing more. > ISO-8859-1 is the standard used at Linux and html application, ISO-8859-1 is standardized name and official standard encoding in many countries. In my country official encoding is ISO-8859-2. > but have a lot of synonyms on different Linux platform. I use it on > my php applications. I do not know about any other local synonyms of ISO-8859-1 (maybe only MS CP-1252). It's official name which has nothing to Linux. Linux only uses official standards. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Please, STOP this is part of MSDN documentation: as can be possible read are different code page of the same family. I'm not talking about of its aliases. Spanish (Modern Sort) | Western European (Windows) Code page: 1252 <-- family code page:1252 Code page name: Windows-1252 Aliases: ANSI_X3.4-1968, ANSI_X3.4-1986, ascii, cp367, cp819, csASCII, IBM367, ibm819, ISO_646.irv:1991, iso_8859-1, iso_8859-1:1987, ISO646-US, iso8859-1, iso-8859-1, iso-ir-100, iso-ir-6, latin1, us, us-ascii, x-ansi is different than Western European (ISO) Code page: 28591 <-- family code page:1252 Code page name: iso-8859-1 Aliases: cp819, csISO, Latin1, ibm819, iso_8859-1, iso_8859-1:1987, iso8859-1, iso-ir-100, l1, latin1 Western European (DOS) Code page: 850 family code page:1252 Code page name: ibm850 Aliases: Western European (Mac) Code page: 1 family code page:1252 Code page name: mathintosh Aliases: Western European (IA5) Code page: 20105 family code page:1252 Code page name: x-IA5 Aliases: Unicode (UTF-8) Code page: 65001 family code page:1252 Code page name: utf-8 Aliases: unicode-1-1-utf-8, unicode-2-0-utf-8, x-unicode-2-0-utf-8 Przemyslaw Czerpak escribió: On Wed, 05 Nov 2008, Miguel Angel Marchuet wrote: Hi Miguel, Windows-1252 is the standard used at windows application. CP-1252 is local MS name. Nothing more. ISO-8859-1 is the standard used at Linux and html application, ISO-8859-1 is standardized name and official standard encoding in many countries. In my country official encoding is ISO-8859-2. but have a lot of synonyms on different Linux platform. I use it on my php applications. I do not know about any other local synonyms of ISO-8859-1 (maybe only MS CP-1252). It's official name which has nothing to Linux. Linux only uses official standards. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour __ Informaci�n de ESET NOD32 Antivirus, versi�n de la base de firmas de virus 3586 (20081105) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] RE: Harbour Digest, Vol 25, Issue 24
-Original Message- >Have you test xMate :) ? I use xmate Xmate give me high productivity as possible The better choice in my opinion is made a make system compatible with xmate project xhp >>>Assign to: >>>Detail...: Add NETRDD - meta RDD which will allow transport layer >>> between client application and server application with any >>> other chosen RDD driver. Idea similar to GTNET but for RDD >>> drivers - it's sth like ADS does. >>>Status...: Open. >> >> >Massimo, >NETRDD -> LetoDB. >Who know about possibility LetoDB on madiacy TCP/IP ? >We need GTNET and wiedr access to sqldatabase (oracle, db2, mssql) and >class/tools to www/html hosting (in this order). AFAIK NETRDD will be little different as implementation NETRDD IS Przemyslaw idea reserved as name for future implementation GTNET can be intresting now for everyone In last year letodb project seem with low activity What is madiacy TCPIP? ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Wed, 05 Nov 2008, Miguel Angel Marchuet wrote: Hi Miguel, > Please, STOP > this is part of MSDN documentation: MS documentsion does not creates any standards in my country and I hope will never do but you can contact with my government and try to change it ;-) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
ormation: "Code page name" are to "Char Set" as you see some times are confused by the alias name, any people can think incorrectly that iso-8859-1 is the same than windows-1252 but are real different Char Set Yes, exactly. Very important that ISO-8859-1 is an official standard, while Windows-1252 is not. They are similar, but not the same. I'd think we should encourage everyone to use the ISO standards for best portability. read MSDN please I better like to get generic information from higher level sources. I read MSDN when I'd like to know something about the Windows API, MSVC, C#, you name it. Windows-1252 is the standard used at windows application. Exactly, so it's not a standard by my definition. In my terms "standard" means something standardized by an official standardization organization, and the standard being applied/applicable in a wide-range of products from different vendors. Lacking this, "Windows-1252" like above is nothing more than a convention used by a specific product / company, Windows/Microsoft in this case. Harbour is multiplatform, so I suggest others to endorse this kind of approach in context of this project. [ For Windows-only projects (which this isn't), this can be regarded as _the_ "standard" or "quasi-standard", and above lamentation is academic. ] [ BTW, this is one of the areas where Windows/MS did a terrible disservice to the world by introducing / forcing such hacked, proprietary "standards" on them. ] ISO-8859-1 is the standard used at Linux and html application, but have a lot of synonyms on different Linux platform. I use it on my php applications. Being used by Linux and 'html applications' is a consequence of being an official standard, as open source vendors (but not just them) generally prefer these over proprietary ones. It's by no means a "Linux/html standard". It has been standardized by ISO (as Organization), hence the name. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Miguel, if you're using MSDN as the sole source of your
information, you shouldn't wonder it's centering the world
around Microsoft, since they are the authors.
Please read other facts. "Windows-1252" was derived from
ISO-8859-1 standard (by Microsoft) with added (non-standard)
features ("embrace and extend").
It has never been accepted by any official standardization
bodies.
Moreover Microsoft is wrong, as ISO-8859-1 could never be
an alias of Windows-1252 as they are not exactly identical.
Microsoft is also wrong in calling their Windows CPs "ANSI"
giving the impression these are official ANSI standards.
They are not unfortunately.
Also notice that "Windows-1252" _as a name_ is an officially
registered one by IANA.
Brgds,
Viktor
On 2008.11.05., at 17:39, Miguel Angel Marchuet wrote:
Please, STOP
this is part of MSDN documentation:
as can be possible read are different code page of the same family.
I'm not talking about of its aliases.
Spanish (Modern Sort) | Western European (Windows)
Code page: 1252 <--
family code page:1252
Code page name: Windows-1252
Aliases: ANSI_X3.4-1968, ANSI_X3.4-1986, ascii, cp367,
cp819, csASCII, IBM367, ibm819, ISO_646.irv:1991, iso_8859-1,
iso_8859-1:1987, ISO646-US, iso8859-1, iso-8859-1,
iso-ir-100, iso-ir-6, latin1, us, us-ascii, x-ansi
is different than
Western European (ISO)
Code page: 28591 <--
family code page:1252
Code page name: iso-8859-1
Aliases: cp819, csISO, Latin1, ibm819, iso_8859-1,
iso_8859-1:1987, iso8859-1, iso-ir-100, l1, latin1
Western European (DOS)
Code page: 850
family code page:1252
Code page name: ibm850
Aliases:
Western European (Mac)
Code page: 1
family code page:1252
Code page name: mathintosh
Aliases:
Western European (IA5)
Code page: 20105
family code page:1252
Code page name: x-IA5
Aliases:
Unicode (UTF-8)
Code page: 65001
family code page:1252
Code page name: utf-8
Aliases: unicode-1-1-utf-8, unicode-2-0-utf-8, x-unicode-2-0-
utf-8
Przemyslaw Czerpak escribió:
On Wed, 05 Nov 2008, Miguel Angel Marchuet wrote:
Hi Miguel,
Windows-1252 is the standard used at windows application.
CP-1252 is local MS name. Nothing more.
ISO-8859-1 is the standard used at Linux and html application,
ISO-8859-1 is standardized name and official standard encoding in
many countries.
In my country official encoding is ISO-8859-2.
but have a lot of synonyms on different Linux platform. I use it on
my php applications.
I do not know about any other local synonyms of ISO-8859-1
(maybe only MS CP-1252).
It's official name which has nothing to Linux. Linux only uses
official standards.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
__ Informaci�n de ESET NOD32 Antivirus, versi�n de la
base de firmas de virus 3586 (20081105) __
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Actually they managed to do this locally with their office document standards a while ago :( I'm not sure what was the deal with Poland, but MS did use dirty tricks in several countries. Brgds, Viktor On 2008.11.05., at 18:00, Przemyslaw Czerpak wrote: On Wed, 05 Nov 2008, Miguel Angel Marchuet wrote: Hi Miguel, Please, STOP this is part of MSDN documentation: MS documentsion does not creates any standards in my country and I hope will never do but you can contact with my government and try to change it ;-) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-03 11:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Przemyslaw Czerpak escribió: On Wed, 05 Nov 2008, Miguel Angel Marchuet wrote: Hi Miguel, Please, STOP this is part of MSDN documentation: MS documentsion does not creates any standards in my country and I hope will never do but you can contact with my government and try to change it ;-) I don't love windows, but by the moment my customers buy windows applications. I don't want to change any standard. But ISO-? is not an standard, I as php developer found differences of names on all linux servers, I don't found the same ISO-??? name. is something horrible but true, and the only documentation more or less homogeneous in this regard is the one that presents microsoft :(. Sometimes Microsoft do good things ! But don't worry i understand you. Microsoft is as Virus !!! ;) ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek,
For some reason simple hash lookup became
a bit slower, and now 30% slower than
__i18n_gettext() (previously it was 30%
faster). Still pretty good though. I wonder
what may cause this.
Probably there are some different conditions in tests.
Binary search is noticeable faster then the previous one.
Dunno, my test is far from extensive, and several
optimally and less optimally placed strings should
have to be searched (or all), but that was the consistent
result for my example. (I tried to use a less-optimal
one, at the beginning of the sorted list, to better
highlight the differences). Anyhow, let's not be
blocked by this result, I believe you it's optimal.
Maybe dropping such features as discussed in other
thread (tweaking internal sort and other xhb
historic features), could further enhance speed.
that on access when variable with given key does not exists in
hash array then this key is return. In such case the above code
will look like:
return h[ cText ]
We can also make the same functionality in different way and instead
of intorducing new flag we can add special syntax for such situation,
f.e.:
return h[ @cText ]
Both excellent. I cannot see the consequences if implementation
and as a brand new hash user it's hard to tell which feels more
natural. Maybe the second one is more elegant. And/or we could
have an alternative hb_HGet???() function with same functionality.
this is only for perofrmance reasons. Using C we can easy write
function
like:
HB_FUNC( HB_HKEY )
{
}
and in such case the above .prg code will look like:
return hb_hKey( h, cText )
See above :) I think we could have this also. But
for below reasons, the simple assignment above
is superior for this case.
func f2( cText, h )
return h[ @cText ]
I'll do some tests a bit later.
Brgds,
Viktor
but I haven't check how big overhead will be caused by function
call in this case. You can try to compare:
func f1(cText,h)
if cText $ h
cText := h[ cText ]
endif
return cText
with:
func f2(cText,h)
return hb_hKey( h, cText )
#define N_LOOP 1
#define N_SIZE 1000
proc main()
local h1, h2, aKeys, i, n, t, tn, x
h1 := {=>}
h2 := {=>}
hb_hSetBinary(h2,.f.)
...
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Mindaugas,
The downside I see with 'context' implementation (while
it's pretty natural and straightforward), is that it
can make the language file quite fat for long context
strings. Easy to overcome by choosing a short one, in
my case context is a mere 2 chars, so it's not too bad.
As for NIL as a possible key value, I don't know how
it feels for hash users, but it could surely be useful
(maybe as part of some special syntax, or supported
in a function call as parameter).
Brgds,
Viktor
On 2008.11.05., at 16:28, Mindaugas Kavaliauskas wrote:
I think that using standard serialization method will increase
functionality, f.e. users can easy change the place where they store
i18n translation tables, f.e. they can use DBF with MEMO fields.
I can update this code but if Mindaugas already has some working code
then maybe we should not repeat the work.
Mindaugas?
Hi,
my local i18n implementation is minimal. It has these functions:
// Set/Get language
PROC HB_i18nSetBaseLanguage( cLang, cTitle )
FUNC HB_i18nSetLanguage( cLang )
FUNC HB_i18nGetLanguage()
// Get translated string
FUNC HB_i18n_gettext( cId, cContext )
// Manage translation table
FUNC HB_i18ntable_create()
FUNC HB_i18ntable_add( aStrings, cId, cText, cContext )
// Save/Load table to/from binary (serialized hash) file
FUNC HB_i18ntable_save( aStrings, cFile )
FUNC HB_i18ntable_load( cFile )
// Save/Load table to/from text (.pot) file
FUNC HB_i18ntable_savetext( aStrings, cFile )
FUNC HB_i18ntable_loadtext( cFile )
// Load table. Windows only function! I always save translation
tables in resource
FUNC HB_i18n_load( cLang )
It is a little different implementation, than Viktor's. For example
I do not have hb_i18n_gettextlang( [, ] ), because
all strings are extracted from loaded hash values (other languages
are in file/resource). But I do support domain/context (in a
minimalistic implementation: hash table key is "msgid$$$msgctxt"). I
attach my i18n implementation at the end of the letter.
I general, I see translation tables implemented by hashes more
flexible. Usage of serialization function allows to store language
files in any media; file, memo field, etc. Harbour "native" hash
functions allows a simple management of translation table, it's very
easy to write utility for deleting, merging, editing translation
tables (I'm using such utility with a simple browse editor instead
of standard GNU gettext utilities). No special functions are needed,
native hash functionality is enough.
Both hashes and Viktor's implementation of translation table uses a
binary search, so I speed of table lookup should be almost the same.
There is no need to duplicate hash lookup code. That's everything I
can add to current discussion about i18n table implementation.
I think that some upper level functions like translation tools
or .pot
files manipulations can be written as .prg code so user can easy
extend
it. The low level functions and hb_i18n_gettext*() for RT
performance
should be written in C.
Yes, my C "fluency" is incomparable to yours, so maybe
I'm not the best candidate for this job :)
After we find the best solution I can help to do C implementation.
FUNC __I18N_GETTEXT( cText, hTrans, cDomain )
local hDomain
if cDomain == NIL
cDomain := "[MAIN]"
endif
if cDomain $ hTrans
hDomain := hTrans[ cDomain ]
if cText $ hDomain
cText := hDomain[ cText ]
endif
endif
return cText
This code forced me to test if NIL can by a hash key. It's a pity,
but it's not :) We would be able to drop 3 lines of code, by
removing default cDomain initialization to "[MAIN]".
What are opinions about NIL beeing a hash key (not from the point of
view of this sample, but for hashes in general)?
Best regards,
Mindaugas
#define CONTEXT_SEPARATOR "$$$"
STATIC s_aStrings := {=>}, s_cLang := "", s_cTitle := ""
PROC HB_i18nSetBaseLanguage( cLang, cTitle )
s_cLang := cLang
s_cTitle := cTitle
RETURN
FUNC HB_i18nSetLanguage( cLang )
LOCAL cDump, aStrings
cDump := HB_i18n_Load( cLang )
IF cDump != NIL
aStrings := HB_DESERIALIZE( cDump )
IF VALTYPE( aStrings ) == "H"
s_aStrings := HB_DESERIALIZE( cDump )
s_cLang := cLang
RETURN .T.
ENDIF
ENDIF
RETURN .F.
FUNC HB_i18nGetLanguage()
RETURN s_cLang
FUNC HB_i18n_gettext( cId, cContext )
LOCAL cRet
IF cContext != NIL
cContext := cId + CONTEXT_SEPARATOR + cContext
ELSE
cContext := cId
ENDIF
IF HB_HHasKey( s_aStrings, cContext )
cRet := s_aStrings[ cContext ]
IF cRet != ""; RETURN cRet
ENDIF
ENDIF
RETURN cId
FUNC HB_i18ntable_create()
RETURN {=>}
FUNC HB_i18ntable_add( aStrings, cId, cText, cContext )
IF cContext != NIL
cContext := cId + CONTEXT_SEPARATOR + cContext
ELSE
cContext := cId
ENDIF
aStrings[ cContext ] := cText
RETURN aStrings
FUNC HB_i18ntable_save( aStrings, cFile )
LOCAL hFile, cDump
IF ( hFile := FCREATE( cFile ) ) == -
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
[...]
> I'll do some tests a bit later.
Below is small test code I've just created.
Here I my results:
__I18N_LOADFROMMEMORY: 5.93 sec.
hb_deserialize:6.63 sec.
other code overhead: 2.28 sec.
__I18N_GETTEXT: 16.11 sec.
HB_HKEY: 12.08 sec.
Native hash .prg access: 20.03 sec.
Looks that function call overhead is not too big in this test.
best regards,
Przemek
#define N_LOOP 1000
#define N_SIZE 1
proc main()
local a, h, aMem, hMem, i, n, t, tn, cKey, aKeys
? "Building arrays..."
h := {=>}
hb_hAllocate( h, N_SIZE )
a := array( N_SIZE )
aKeys := array( N_SIZE )
for i:=1 to N_SIZE
cKey := repl("text.", 9) + "[" + str(i,10) + " ]" + ;
repl( "*", i % 20 )
aKeys[ i ] := cKey
a[ i ] := { cKey, upper( cKey ) }
h[ cKey ] := upper( cKey )
next
aSort( a,,, { |x,y| x[1] < y[1] } )
? "Saving arrays to files"
__I18N_SAVE( "data.arr", a )
hb_memowrit( "data.hsh", hb_serialize( h ) )
aMem := memoread( "data.arr" )
hMem := memoread( "data.hsh" )
t := secondsCPU()
for i := 1 TO N_LOOP
a := __I18N_LOADFROMMEMORY( aMem )
next
? "__I18N_LOADFROMMEMORY:", secondsCPU() - t, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
h := hb_deserialize( hMem )
next
? "hb_deserialize:", secondsCPU() - t, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
next
next
? "other code overhead:", tn := secondsCPU() - t, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
cKey := __I18N_GETTEXT( cKey, a )
next
next
? "__I18N_GETTEXT:", secondsCPU() - t - tn, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
cKey := HB_HKEY( h, cKey )
next
next
? "HB_HKEY:", secondsCPU() - t - tn, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
if cKey $ h
cKey := h[ cKey ]
endif
next
next
? "Native hash .prg access:", secondsCPU() - t - tn, "sec."
return
#pragma begindump
#include "hbapi.h"
#include "hbapierr.h"
HB_FUNC( HB_HKEY )
{
PHB_ITEM pHash = hb_param( 1, HB_IT_HASH );
PHB_ITEM pKey = hb_param( 2, HB_IT_HASHKEY );
if( pHash && pKey )
{
ULONG ulPos;
hb_hashScan( pHash, pKey, &ulPos );
if( ulPos )
pKey = hb_hashGetValueAt( pHash, ulPos );
hb_itemReturn( pKey );
}
else
hb_errRT_BASE( EG_ARG, 1123, NULL, HB_ERR_FUNCNAME,
HB_ERR_ARGS_BASEPARAMS );
}
#pragma enddump
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
will show: MINDAUGAS Kavaliauskas but I think it's worth to pay. If other developers will agree with me then I'll change internal hash representation so keys will be hashed when added and then always sorted in binary form. Fully agree. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-05 19:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-11-05 19:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * bin/hb-func.sh * include/hbstdgen.ch * include/hbver.h * contrib/examples/pp/pp.c * source/pp/ppcore.c * source/pp/hbpp.c * source/common/hbver.c * HB_VER_REVISION -> HB_VER_RELEASE. INCOMPATIBLE. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-05 19:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-11-05 19:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbcurl/hbcurl.c % Removed two Harbour level functions not really adding to functionality but forcing linkage of these (otherwise unused) curl interfaces. CURL_SHARE_STRERROR() CURL_MULTI_STRERROR() INCOMPATIBLE (but I doubt even a single user would be affected) * source/rtl/version.c ! Fix to prev. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Thanks for these tests.
Local results:
__I18N_LOADFROMMEMORY: 9.86 sec.
hb_deserialize:9.02 sec.
other code overhead: 4.95 sec.
__I18N_GETTEXT: 18.84 sec.
HB_HKEY: 16.05 sec.
Native hash .prg access: 24.36 sec.
Very good results here also.
And there is a cKey assignment which could
still be optimized out in the function call
loops.
Brgds,
Viktor
On 2008.11.05., at 19:01, Przemyslaw Czerpak wrote:
On Wed, 05 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
[...]
I'll do some tests a bit later.
Below is small test code I've just created.
Here I my results:
__I18N_LOADFROMMEMORY: 5.93 sec.
hb_deserialize:6.63 sec.
other code overhead: 2.28 sec.
__I18N_GETTEXT: 16.11 sec.
HB_HKEY: 12.08 sec.
Native hash .prg access: 20.03 sec.
Looks that function call overhead is not too big in this test.
best regards,
Przemek
#define N_LOOP 1000
#define N_SIZE 1
proc main()
local a, h, aMem, hMem, i, n, t, tn, cKey, aKeys
? "Building arrays..."
h := {=>}
hb_hAllocate( h, N_SIZE )
a := array( N_SIZE )
aKeys := array( N_SIZE )
for i:=1 to N_SIZE
cKey := repl("text.", 9) + "[" + str(i,10) + " ]" + ;
repl( "*", i % 20 )
aKeys[ i ] := cKey
a[ i ] := { cKey, upper( cKey ) }
h[ cKey ] := upper( cKey )
next
aSort( a,,, { |x,y| x[1] < y[1] } )
? "Saving arrays to files"
__I18N_SAVE( "data.arr", a )
hb_memowrit( "data.hsh", hb_serialize( h ) )
aMem := memoread( "data.arr" )
hMem := memoread( "data.hsh" )
t := secondsCPU()
for i := 1 TO N_LOOP
a := __I18N_LOADFROMMEMORY( aMem )
next
? "__I18N_LOADFROMMEMORY:", secondsCPU() - t, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
h := hb_deserialize( hMem )
next
? "hb_deserialize:", secondsCPU() - t, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
next
next
? "other code overhead:", tn := secondsCPU() - t, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
cKey := __I18N_GETTEXT( cKey, a )
next
next
? "__I18N_GETTEXT:", secondsCPU() - t - tn, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
cKey := HB_HKEY( h, cKey )
next
next
? "HB_HKEY:", secondsCPU() - t - tn, "sec."
t := secondsCPU()
for i := 1 TO N_LOOP
for n := 1 to N_SIZE
cKey := aKeys[ n ]
if cKey $ h
cKey := h[ cKey ]
endif
next
next
? "Native hash .prg access:", secondsCPU() - t - tn, "sec."
return
#pragma begindump
#include "hbapi.h"
#include "hbapierr.h"
HB_FUNC( HB_HKEY )
{
PHB_ITEM pHash = hb_param( 1, HB_IT_HASH );
PHB_ITEM pKey = hb_param( 2, HB_IT_HASHKEY );
if( pHash && pKey )
{
ULONG ulPos;
hb_hashScan( pHash, pKey, &ulPos );
if( ulPos )
pKey = hb_hashGetValueAt( pHash, ulPos );
hb_itemReturn( pKey );
}
else
hb_errRT_BASE( EG_ARG, 1123, NULL, HB_ERR_FUNCNAME,
HB_ERR_ARGS_BASEPARAMS );
}
#pragma enddump
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-05 19:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-11-05 19:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/examples/dbu/bld_b32.bat * contrib/examples/dbu/bld_vc.bat * utils/hbdoc/bld_b32.bat * utils/hbdoc/bld_vc.bat * utils/hbmake/bld_b32.bat * utils/hbmake/bld_vc.bat * Minor cleanups. ; NOTE: Win9x support for BCC files is now dropped. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas, > This code forced me to test if NIL can by a hash key. It's a pity, but it's > not :) We would be able to drop 3 lines of code, by removing default > cDomain initialization to "[MAIN]". But it will not increase the final code speed because I plan to keep pointer to "[MAIN]" hash in separate item so we will have sth like: return iif( cDomain == NIL, hDefault[ cText ], hTrans[ cDomain, cText ] To eliminate one hash lookup and easy default domain switching. > What are opinions about NIL beeing a hash key (not from the point of view > of this sample, but for hashes in general)? It can be very easy implement but because we do not have separate bits for NIL value then HB_IT_HASHKEY will not be longer functional what will force some additional code overhead in places which uses HB_I[ST]_HASHKEY macro. There is one related subject I wanted to talk about long ago. Adding pointer items to hash keys introduced one side effect: when pointer item is collectible item then it will never be freed untill it exists as hash key. For some code it maybe interesting feature because the address in memory will never be freed so new pointer item with the same address should not appear but for some other code it can cause problems when pointer item is still "alive" as hash key and its detractor is not executed when all other instances are out of scope. We can easy change it by translating collectible pointer items to normal pointer items when they are stored as hash keys. But I still do not know what is better so I would like to hear other developers opinion. Best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Szak�ts Viktor wrote: [...] Hi Viktor, Mindaugas and others, I've just implemented support for h[ cKey ] => cKey when cKey does not exists in hash array and of course it gives optimal speed. It can be enabled by setting hash array flags by hb_hSet*() function. Now I only need good names for this function and hb_hKey() I sent earlier and I can commit. Probably they should use some similar core name because both are bound with similar functionality. hb_hKey() was a shortcut from hb_hashKey() because this functions translates (hashes) given key value using hash array but it's probably to cryptic for users. Please propose some alternative names. Maybe sth like: hb_hSetKeyHashing( , ) hb_hKeyHash( , ) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Viktor, Mindaugas and others, I've just implemented support for h[ cKey ] => cKey when cKey does not exists in hash array and of course it gives optimal speed. It can be enabled by setting hash array flags by hb_hSet*() function. Great! Now I only need good names for this function and hb_hKey() I sent earlier and I can commit. Probably they should use some similar core name because both are bound with similar functionality. hb_hKey() was a shortcut from hb_hashKey() because this functions translates (hashes) given key value using hash array but it's probably to cryptic for users. Please propose some alternative names. Maybe sth like: hb_hSetKeyHashing( , ) hb_hKeyHash( , ) Maybe: hb_HSetKeyAsDefault() hb_HGetIfExists() or hb_HKeyIfExists() Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 05 Nov 2008, Szak�ts Viktor wrote: >> will show: >> MINDAUGAS Kavaliauskas >> but I think it's worth to pay. If other developers will agree >> with me then I'll change internal hash representation so keys >> will be hashed when added and then always sorted in binary form. > Fully agree. Thanks. Other opinions? I possible I would like to join this hash modification with other I've just created. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] static BOOL hb_dbfIsLocked( DBFAREAP pArea, ULONG ulRecNo )
Hello Przemek dbf1.c static BOOL hb_dbfIsLocked( DBFAREAP pArea, ULONG ulRecNo ) Can you guide me with which call this method is implemented? IsLocked( nRecNo ) or something else. Also please tell me how it is routed via USRRDD. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/static-BOOL-hb_dbfIsLocked%28-DBFAREAP-pArea%2C-ULONG-ulRecNo-%29-tp2034p2034.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] somebody can give a reply on harbour user mailing list?
Dnia środa 05 listopad 2008, Massimo Belgrano napisał: > somebody can give a reply on harbour user mailing list? I am subscribed to this list and already answered to it. best regards, Adam -- ABIX - Linuksowe Systemy Wspomagania Biznesu www.abix.info.pl Gadu-Gadu: 302315 Skype: abix_adamj Wsparcie aplikacji: http://groups-beta.google.com/group/abix-rcsoft?hl=pl ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] static BOOL hb_dbfIsLocked( DBFAREAP pArea, ULONG ulRecNo )
On Wed, 05 Nov 2008, Pritpal Bedi wrote: > Hello Przemek > dbf1.c > static BOOL hb_dbfIsLocked( DBFAREAP pArea, ULONG ulRecNo ) > Can you guide me with which call this method is implemented? It's internal DBF RDD function used for few different things. > IsLocked( nRecNo ) or something else. Probably you are asking about: dbRecordInfo( DBRI_LOCKED, nRecNo ) > Also please tell me how it is routed via USRRDD. As I said hb_dbfIsLocked() is internal DBF RDD function. But if you want to add support for: dbRecordInfo( DBRI_LOCKED, nRecNo ) to your RDD based on USRRDD library then you have to overload RECINFO() method and add action for DBRI_LOCKED index. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] one cent for todolist
I've taken a quick look at brmake source, and it looks it would need some serious work to make it into Harbour as multiplatform 'hbmk' implementation. Some parts of it need to be translated to English, and apparently the code is targeting the Windows world exclusively (all filenames are in uppercase for a start). The code also implements some features which need intimate knowledge of 3rd party projects' properties, and while this could be a good service for some users, I'd think a generic make system should be as simple (and generic obviously) as possible, and without such dependencies. The beauty of OSS is that this project can live on its own merits, and I'm sure their developers would welcome everyone wanting to enhance it in above or other ways. It can also easily be used by any Harbour users even know, and I'd encourage everyone to try it, if they seek an hbmake alternative. It seems far better supported and probably superior to hbmake in other ways, too. I'd personally not invest more time (after hbmake) in refactoring other heavy build tools. It'd be nice to see Przemek's hbmk code to replace our current light batch/script solutions, though. Brgds, Viktor Can I suggest another point that will be useful for make an uniform documentation of harbour Define a standard make system so each platform/c compiler will use similar instruction for compile a little sample, or a big project. so is difficult document how harbour works I suggest something like build project.exe from test1.prg,test2.prg,test.prg,hbvm.lib,hbmacro.lib,hbpp.lib,gtwvw.lib This disuniformity add difficult at first steep with harbour Imo can be choice from 3 ways Hbmk.prg defined by Przemyslaw for make uniform If I'll find spare time to make some cleanups in hbmk.prg then I'll commit it to SVN. It should give similar to hb* script functionality Pbmake by Phil Barnet is a make engine for Clipper, Xbase++, C and ASM written in clipper have Support conditional directives will performing actions just before/after the compile process Jump to Editor on Compile Failure We modification for be custom for harbour and multiplatform BrMake is a sub-project of https://sourceforge.net/projects/hrbtoolslibs/ This project ts written in [x]harbour and will be driven by command line or project file Command line syntax Need modification for multiplatform harbour have made a choice of high quality but make system is not at the same level of quality now In my opinion pbmake and brmake are similar so I suggest Viktor and or Przemyslaw verify if hbmk can be a good way or if the replacement for hbmake can be phmake/brmake Either are written in PRG Either will a good make system for compile either require modification for having same project file on multiple architecture Thanks in advance ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-05 23:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-11-05 23:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vc.bat * contrib/hbgt/doc/gendoc.bat * contrib/hbapollo/make_vc.bat * contrib/hbcurl/make_vc.bat * contrib/hbmisc/doc/gendoc.bat % Non-empty 'echo.' commands in batch files cleaned. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: Re: [Harbour] one cent for todolist
Thanks for your effort Si we wait hbmk.prg - Messaggio originale - Da: Szakáts Viktor <[EMAIL PROTECTED]> Inviato: mercoledì 5 novembre 2008 22.44 A: Harbour Project Main Developer List. Oggetto: Re: [Harbour] one cent for todolist I've taken a quick look at brmake source, and it looks it would need some serious work to make it into Harbour as multiplatform 'hbmk' implementation. Some parts of it need to be translated to English, and apparently the code is targeting the Windows world exclusively (all filenames are in uppercase for a start). The code also implements some features which need intimate knowledge of 3rd party projects' properties, and while this could be a good service for some users, I'd think a generic make system should be as simple (and generic obviously) as possible, and without such dependencies. The beauty of OSS is that this project can live on its own merits, and I'm sure their developers would welcome everyone wanting to enhance it in above or other ways. It can also easily be used by any Harbour users even know, and I'd encourage everyone to try it, if they seek an hbmake alternative. It seems far better supported and probably superior to hbmake in other ways, too. I'd personally not invest more time (after hbmake) in refactoring other heavy build tools. It'd be nice to see Przemek's hbmk code to replace our current light batch/script solutions, though. Brgds, Viktor > Can I suggest another point that will be useful for make an uniform > documentation of harbour > Define a standard make system so each platform/c compiler will use > similar instruction for compile a little sample, or a big project. > so is > difficult document how harbour works > I suggest something like build project.exe from > test1.prg,test2.prg,test.prg,hbvm.lib,hbmacro.lib,hbpp.lib,gtwvw.lib > This disuniformity add difficult at first steep with harbour > Imo can be choice from 3 ways > Hbmk.prg defined by Przemyslaw for make uniform >> If I'll find spare time to make some cleanups in hbmk.prg then I'll >> commit it to SVN. It should give similar to hb* script functionality > > Pbmake by Phil Barnet is a make engine for Clipper, Xbase++, C and > ASM > written in clipper > have Support conditional directives > will performing actions just before/after the compile process > Jump to Editor on Compile Failure > We modification for be custom for harbour and multiplatform > BrMake is a sub-project of > https://sourceforge.net/projects/hrbtoolslibs/ > This project ts written in [x]harbour and will be driven by > command > line or project file > Command line syntax > Need modification for multiplatform > > harbour have made a choice of high quality but make system is not at > the same level of quality now > > In my opinion pbmake and brmake are similar so I suggest Viktor and or > Przemyslaw verify if hbmk can be a good way or if the replacement for > hbmake can be phmake/brmake Either are written in PRG Either will a > good > make system for compile either require modification for having same > project file on multiple architecture > > Thanks in advance ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: Re: [Harbour] somebody can give a reply on harbour user mailing list?
thanks - Messaggio originale - Da: ABIX - Adam Jurkiewicz <[EMAIL PROTECTED]> Inviato: mercoledi 5 novembre 2008 22.13 A: Harbour Project Main Developer List. Oggetto: Re: [Harbour] somebody can give a reply on harbour user mailing list? Dnia środa 05 listopad 2008, Massimo Belgrano napisał: > somebody can give a reply on harbour user mailing list? I am subscribed to this list and already answered to it. best regards, Adam -- ABIX - Linuksowe Systemy Wspomagania Biznesu www.abix.info.pl Gadu-Gadu: 302315 Skype: abix_adamj Wsparcie aplikacji: http://groups-beta.google.com/group/abix-rcsoft?hl=pl ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] static BOOL hb_dbfIsLocked( DBFAREAP pArea, ULONG ulRecNo )
Thanks Przemek >dbRecordInfo( DBRI_LOCKED, nRecNo ) is what I was looking for. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/static-BOOL-hb_dbfIsLocked%28-DBFAREAP-pArea%2C-ULONG-ulRecNo-%29-tp2034p20353189.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Classes: Methods and Instance Variables with SAME Name
Hello All
THE TOPIC IS BEING REVISITED
--
CLASS WvgWindow
DATA lbClick
METHOD Init()
METHOD lbClick
ENDCLASS
METHOD init() CLASS WvgWindow
RETURN SELF
METHOD lbClick( bBlock ) CLASS WvgWindow
hb_toOutDebug( 'WvgWindow:lbClick: ['+valtype( bBlock )+']' )
RETURN SELF
FUNCTION Main()
LOCAL oWnd
oWnd := WvgWindow():New()
/* This outputs WvgWindow:lbClick: [] */
oWnd:lbClick := {|| hb_toOutDebug( 'Hi, I am the instance variable!' ) }
/* This outputs WvgWindow:lbClick: [] */
oWnd:lbClick()
/* This generates the runtime error : variable not found */
Eval( oWnd:lbClick )
Return nil
THE QUESTION
===
Xbase++ provides this functionality. Do Harbour stands a chance to
have it? OR any workarounds you can suggest to simulate this behavior.
I am struck with Wvg* classes based on Xbase++ to draw a basic class
skelteton for CUI/GUI manipulation via objects.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Classes%3A-Methods-and-Instance-Variables-with-SAME-Name-tp20354744p20354744.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
