[Harbour] Automatic ChangeLog notification activated
Hi all, As may have noticed the first automatic commit notification e-mail has arrived to the list (many thanks to Phil). This means that committers no longer have to manually send an email to this list, containing the changelog entry. In fact, the best would be to never send these anymore to avoid duplicate notification. On the other hand, from now on it's required from all committers to fill the "log message" on commit with the ChangeLog entry belonging to the commit. This is good practice anyway, and most of us did this so far. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
>This functionality is missing from Harbour, yet it would be best integrated >to the codepage subsystem. But before I do anything, I'd like to discuss it >here. Viktor, This is a nice feature for languages like portuguese for example. I have my own func that do this, but integrate it in HB_CODEPAGE structure sounds perfect. Regards, Toninho. __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
Viktor Szakáts wrote: Any comments? Are you thinking of catering for things like ß -> ss? Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
2009/1/30 Alex Strickland > Viktor Szakáts wrote: > > Any comments? >> > > Are you thinking of catering for things like ß -> ss? Yes, this one could be solved also. This actually makes it much more complicated that I've planned, but fits into the picture and needs to be solved. Another interesting area is cyrillic/greek characters (if we leave out far-east languages for now). Something like this, but in C: --- FUNCTION hb_StrToASCII( cSource ) LOCAL cTarget := "", nChar, tmp FOR tmp := 1 TO Len( cSource ) nChar := Asc( SubStr( cSource, tmp, 1 ) ) IF nChar >= 32 .AND. mChar <= 127 cTarget += SubStr( cSource, tmp, 1 ) ELSEIF HAS_ASCII_EQUIVALENT( nChar ) cTarget += GET_ASCII_EQUIVALENT( nChar ) /* May add multiple chars */ /*ELSE // Strip whole char */ ENDIF NEXT RETURN cTarget --- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
On Fri, 30 Jan 2009, Szak�ts Viktor wrote: Hi, > Stripping accents from a string is often needed when dealing with external > systems > accepting only ASCII alphabet, and is useful to prepare strings for > comparison (in > case of names f.e.). > original: "aááäbcdeéfghiííjklmnoóóöőőpqrstuúúüűűvwxyz" > stripped: "bcdeefghiiijklmnoopqrstuuvwxyz" > This functionality is missing from Harbour, yet it would be best integrated > to the > codepage subsystem. But before I do anything, I'd like to discuss it here. > I was thinking adding two new strings to the HB_CODEPAGE structure, > which would hold the necessary ASCII character equivalent of the current > accented lowercase and uppercase char strings. > Any comments? This should be done in different way. Current codepage implementation has few very serious limitations, f.e. it cannot translate characters between languages, it's very impossible to define CP which does not have corresponding upper case letters, it cannot translate multibyte characters, etc. If you add above strings to CP then you will have yet another thing which works locally only for given codepage without any relations to other CPs. This should be implemented in different way. We will need global unicode fallback table which will work for any CP looking for corresponding character replacement in the destination CP so it will be enough to make translation between any used CP and ASCII CP (we will have to introduce such unicode table where all characters which are not in range 32 <= x < 127 will be mapped to 0). Such fall back table will work also with multibyte translations or if necessary will replace single byte by multibyte phonetic sequence. f.e. personally I'm using such feature translation texts in Cyrillic to Latin characters. Meanwhile if you need such functionality then you can simply introduce new CPs which will have only ASCII characters for given langauge with some sufic like NONE or ASCII, f.e.: "PLNONE" [...] "AABCCDEEFGHIJKLLMNNOOPQRSSTUVWXYZZZ", "aabccdeefghijkllmnnoopqrsstuvwxyzzz", [...] and then to strip accented characters you can make translations between "PL*" -> "PLNONE" The same you can make for any other languages. Sooner or later I will have to start serious modifications in our CP code and I cannot promise that I'll be able to keep such CP extensions like you proposed working. The other solution is creating map from unicode table to Latin letters and then using this map for translations. This can be done as separate function and will also work for all langaues. It could be table indexed by unicode U16 value with ASCII characters or (if you want to introduce multibyte translations for languages which do not have corresponding unaccented single characters in Latin alphabet) with strings. It will be limited to ASCII conversions fallback table I want to introduce. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] A doubt with shared DBF
In the following sample I don't see the changed value if SKIP 0 is commented out: FUNCTION MAIN() USE TEST SHARED ? FIELD -> test ? "Waiting for a key..." INKEY( 0 ) // here the field is changed by another user //SKIP 0 ? FIELD -> test CLOSE RETURN NIL Is it expected? EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Clipper incompatibilities
Hi, Please note that this can be used only for temporary indexes. When index is reopened then it needs valid key and for expressions. It means that we create corrupted indexes in such way. I'm sure I do not reopen tags with empty key expression. We can add key expression check for expression loaded from index file. I've not tested, but I guess this check already exists. See dbfcdx1.c line 3581: pTag->RootBlock = 0; /* To force RT error - index corrupted */ I'll unblock such possibilities in next commit but maybe we should allow to create such indexes only if temporary flag is set. Temporary indexes are automatically removed on close so we will not leave corrupted files. They are also open in EXCLUSIVE mode so other application will not be able to access them. Currently we do not use temporary flag, but we use our own functions to generate temporary file name and we delete all temporary files on application exit. The implementation of temp file name is very similar to Harbour's (GetTempPathA(), GetTempFileNameA(), with a different prefix "~db", instead of "hb"). I do not remember the reason way we use our functions. Perhaps this is legacy from Clipper times. I'll try to add TEMPORARY flag and will look what will happen :) Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] A doubt with shared DBF
In the following sample I don't see the changed value if SKIP 0 is commented out: FUNCTION MAIN() USE TEST SHARED ? FIELD -> test ? "Waiting for a key..." INKEY( 0 ) // here the field is changed by another user //SKIP 0 ? FIELD -> test CLOSE RETURN NIL Is it expected? Hi, yes, of cause. The whole record buffer is written to file after record cursor is "touched". This helps to avoid multiple disk access on: FIELD1 := value1 FIELD2 := value2 ... FIELDn := valuen Use DBCOMMIT() (or move record pointer DBSKIP(), DBGOTO(), etc.) to force write of record buffer. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] A doubt with shared DBF
-Messaggio Originale- Da: "Mindaugas Kavaliauskas" A: "Harbour Project Main Developer List." Data invio: venerdì 30 gennaio 2009 15.31 Oggetto: Re: [Harbour] A doubt with shared DBF > Is it expected? yes, of cause. Ok, thank you. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
> > This should be implemented in different way. > We will need global unicode fallback table which will work for any CP > looking for corresponding character replacement in the destination CP > so it will be enough to make translation between any used CP and ASCII > CP (we will have to introduce such unicode table where all characters > which are not in range 32 <= x < 127 will be mapped to 0). Such fall > back table will work also with multibyte translations or if necessary > will replace single byte by multibyte phonetic sequence. f.e. personally > I'm using such feature translation texts in Cyrillic to Latin characters. > > Meanwhile if you need such functionality then you can simply introduce > new CPs which will have only ASCII characters for given langauge with > some sufic like NONE or ASCII, f.e.: > "PLNONE" > [...] > "AABCCDEEFGHIJKLLMNNOOPQRSSTUVWXYZZZ", > "aabccdeefghijkllmnnoopqrsstuvwxyzzz", > [...] > > and then to strip accented characters you can make translations between > "PL*" -> "PLNONE" The same you can make for any other languages. I'm doing this locally in a slightly different way. It needs two simple functions and some minimal high level management. Good but not generic and torn off from core CP handling. The question is really how to implement this properly as part of Harbour. Adding cp??asc?.c (or cp??non?.c) file for all languages seems like not the most optimal solution, albeit indeed this would solve it in the less intrusive way as part of core. > The other solution is creating map from unicode table to Latin letters > and then using this map for translations. This can be done as separate > function and will also work for all langaues. > It could be table indexed by unicode U16 value with ASCII characters > or (if you want to introduce multibyte translations for languages which > do not have corresponding unaccented single characters in Latin alphabet) > with strings. Probably that U16 table will have to point to a structure which would hold all these information amongst the others. > It will be limited to ASCII conversions fallback table I want to introduce. Okay, I won't change anything then, what you say is obviously better, but needs revamping the whole CP code, which goes beyond my scope. Anyhow let's keep this feature in evidence when touching the CP subsystem, because this feature seems to fit here the best and its not very easy to replicate locally in a proper way, yet many developers could benefit from it. Thanks a lot for your feedback. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Clipper incompatibilities
On Fri, 30 Jan 2009, Mindaugas Kavaliauskas wrote: Hi, > I'm sure I do not reopen tags with empty key expression. We can add key > expression check for expression loaded from index file. I've not tested, > but I guess this check already exists. See dbfcdx1.c line 3581: > pTag->RootBlock = 0; /* To force RT error - index corrupted */ Yes, it forces RT error. > Currently we do not use temporary flag, but we use our own functions to > generate temporary file name and we delete all temporary files on > application exit. > The implementation of temp file name is very similar to Harbour's > (GetTempPathA(), GetTempFileNameA(), with a different prefix "~db", instead > of "hb"). I do not remember the reason way we use our functions. Perhaps > this is legacy from Clipper times. I'll try to add TEMPORARY flag and will > look what will happen :) It will increase the performance for shared tables because TEMPORARY indexes are always used in exclusive mode without checking for concurrent modifications. Even if you do not want to use it then you should at least use EXCLUSIVE flag for your own temporary indexes to reach the same performance. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-30 20:19 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2009-01-30 20:19 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/make_gcc.mak
! added additional rules to fix time conditions in parallel compilation
* harbour/config/dos/dir.cf
* harbour/config/w32/dir.cf
* changed simple assignments to recursive ones
* harbour/config/dir.cf
+ added support for dependencies between build directories for
parallel execution. If compilation of dirX needs results of
dirY and dirZ compilation then it hsould be declared as:
dirX{dirY,dirZ}
% process directories defined in DIRS simultaneously when -j
GNU make switch is used - it gives additional speed improvement
on multi CPU machines
* harbour/Makefile
* harbour/source/Makefile
* set directory dependencies for parallel compilation
The parallel compilation can be enabled by using -j GNU make
switch on multiprocess platforms, f.e.:
./gnu_make.sh -j3
It should give some speed improvement even on single CPU machines.
These are results of clean Harbour compilation on my 3 phantom CPU
computer:
1. leaner compilation without -j6m29.895s
2. parallel compilation with -j5 but without
parallel directory processing 3m20.163s
3. parallel compilation with -j5 and with new
parallel directory processing 2m6.168s
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10139] trunk/harbour
Revision: 10139
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10139&view=rev
Author: druzus
Date: 2009-01-30 19:15:26 + (Fri, 30 Jan 2009)
Log Message:
---
2009-01-30 20:19 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/make_gcc.mak
! added additional rules to fix time conditions in parallel compilation
* harbour/config/dos/dir.cf
* harbour/config/w32/dir.cf
* changed simple assignments to recursive ones
* harbour/config/dir.cf
+ added support for dependencies between build directories for
parallel execution. If compilation of dirX needs results of
dirY and dirZ compilation then it hsould be declared as:
dirX{dirY,dirZ}
% process directories defined in DIRS simultaneously when -j
GNU make switch is used - it gives additional speed improvement
on multi CPU machines
* harbour/Makefile
* harbour/source/Makefile
* set directory dependencies for parallel compilation
The parallel compilation can be enabled by using -j GNU make
switch on multiprocess platforms, f.e.:
./gnu_make.sh -j3
It should give some speed improvement even on single CPU machines.
These are results of clean Harbour compilation on my 3 phantom CPU
computer:
1. leaner compilation without -j6m29.895s
2. parallel compilation with -j5 but without
parallel directory processing 3m20.163s
3. parallel compilation with -j5 and with new
parallel directory processing 2m6.168s
Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/Makefile
trunk/harbour/config/dir.cf
trunk/harbour/config/dos/dir.cf
trunk/harbour/config/w32/dir.cf
trunk/harbour/make_gcc.mak
trunk/harbour/source/Makefile
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] A Bunch of Thanks
To All Developers ( Past and Present ) Who Contributed to the Project called - HARBOUR In Any Way I pay a deep hearted tribute and extend a bunch of THANKS. For Today, I have deployed in production all of my applications, under the brand name "Vouch", compiled with Harbour, and have discontinued support for Clipper compilations for ever. Everything, everywhere, with every application, is running fine. "Vouch" is now a multi-threaded, multi-window, hibrid GUI, pure GUI ( whereever needed ), exploiting many famous Active-X controls, capable of running on LAN or as REMOTE Terminal (Proprietory), and with many more features beyond the scope of this token of thanks. Believe me, if we continue with same zest and enthusiam to contribute to this project, Harbour will become a mainstream language in the future. I invite all developers who contributed to this project just to say a "Hello" on this thread so that we all could feel your affection to the language called CLIPPER in good old days. Thanks again for this huge effort. Regards Pritpal Bedi a student of software analysis and design -- View this message in context: http://www.nabble.com/A-Bunch-of-Thanks-tp21758316p21758316.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] A Bunch of Thanks
+++! - Original Message - From: Pritpal Bedi To: harbour@harbour-project.org Sent: Friday, January 30, 2009 4:30 PM Subject: [Harbour] A Bunch of Thanks To All Developers ( Past and Present ) Who Contributed to the Project called - HARBOUR In Any Way I pay a deep hearted tribute and extend a bunch of THANKS. For Today, I have deployed in production all of my applications, under the brand name "Vouch", compiled with Harbour, and have discontinued support for Clipper compilations for ever. Everything, everywhere, with every application, is running fine. "Vouch" is now a multi-threaded, multi-window, hibrid GUI, pure GUI ( whereever needed ), exploiting many famous Active-X controls, capable of running on LAN or as REMOTE Terminal (Proprietory), and with many more features beyond the scope of this token of thanks. Believe me, if we continue with same zest and enthusiam to contribute to this project, Harbour will become a mainstream language in the future. I invite all developers who contributed to this project just to say a "Hello" on this thread so that we all could feel your affection to the language called CLIPPER in good old days. Thanks again for this huge effort. Regards Pritpal Bedi a student of software analysis and design -- View this message in context: http://www.nabble.com/A-Bunch-of-Thanks-tp21758316p21758316.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 mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] A Bunch of Thanks
Hello Pritpal, Congratulations! regards, budyanto On 30 Jan 2009 at 16:30, Pritpal Bedi wrote: > > To > All Developers ( Past and Present ) > Who Contributed to the Project called - HARBOUR > In Any Way > > I pay a deep hearted tribute and extend a bunch of THANKS. > > For > > Today, I have deployed in production all of my applications, > under the brand name "Vouch", compiled with Harbour, > and have discontinued support for Clipper compilations for ever. > > Everything, everywhere, with every application, is running fine. > > "Vouch" is now a multi-threaded, multi-window, hibrid GUI, > pure GUI ( whereever needed ), exploiting many famous Active-X > controls, capable of running on LAN or as REMOTE Terminal > (Proprietory), and with many more features beyond the scope > of this token of thanks. > > Believe me, if we continue with same zest and enthusiam to contribute > to this project, Harbour will become a mainstream language in the > future. > > I invite all developers who contributed to this project just to > say a "Hello" on this thread so that we all could feel your > affection to the language called CLIPPER in good old days. > > Thanks again for this huge effort. > > Regards > Pritpal Bedi > a student of software analysis and design > > -- > View this message in context: > http://www.nabble.com/A-Bunch-of-Thanks-tp21758316p21758316.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 mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
