Re: [Harbour] Release 1.0.0 FREEZED
Szakáts Viktor wrote: - We're done. Well done! It's a superlative effort that you and Przemek have put in recently. Thanks also, to the contributions of the scores of other developers over the years, not least those at the "other" Harbour. Thank you Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SVN: Created tag harbour-1.0.0
Szakáts Viktor wrote: [ Next move is to upload source downloads, than binaries, and update our homepage, and announce the release in relevant places. ] Is there any batch equivalent to the install shell commands? I have contributed binary builds before for MSVC 6 but frankly, I have never been too sure what should be in them. If not, I will write a batch file, assuming that I can understand the install command to see what should be included (not something guaranteed at all). Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Release 1.0.0 FREEZED
On Wednesday 13 August 2008 10:45:24 am Szakáts Viktor wrote: >> - We're done. >Wow! What a project! I'm so happy to see this day come. Congratulations to everyone, to those who started this project, to those who supported it and now specially to Przemek and Viktor :-) David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour home page
When someone edit a page, please also update the "Last updated on" date at the bottom of each page. (Currently it says 2007/06/15) Chen. Oh, and greeting all for this release!!! ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Will be MT the next step?
On Wed, 13 Aug 2008, Lorenzo Fiorini wrote: Hi Lorenzo, I will work on it. For next 10 days I will not be available but when I'll return then I'll restore my worker MT repository. The very base version I can probably create quite fast but then we will have to decide which resources should be global and which thread local, which should be synchronized by HVM and which ones by user, which MT features should we supported and how (portability and cost) and finally update the code to respect our choices. This will have to take some time. It's possible that quite long anyhow the base version should be functional for people who will want to use it accepting that for final version they will have to update their code. > I cannot see anything more needed for 1.1 ( or 2.0 ). Multiwindow GTs, GT runtime switching, GTNET with remote resource sharing and procedures calls, new internal DBF* RDD API to not replicate the same code between different indexing RDDs, SQL queries for DBFs and other native RDDs, SQLRDD, virtual handle support with user defined streams and central event message queue, cleaned INET support with C API, rewriting some part of compiler covered by pure GPL license with new license, strong typing, finishing i18n support, file cache support, full object support for pointer HB_ITEMs for easy creating objects at C level and adding new types to HVM, ... Probably each user has his own priority list. > At the second place i would put the "hrb libraries" that is > the way to dinamically load more functions at once. This of course too. > These features are platform neutral and will complete the core > of the harbour. Not exactly. Some platforms like DOS or WinCE does not support threads but of course it does not mean that we should not implement them for others. Here I will need some help from other developers. I can create PTHREAD based version for POSIX systems and maybe some skeleton for MS-Win and OS2 but this code will have to be tested and updated by other developers who use these platforms. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour 1.0.0 binaries for OS/2-eCS
Harbour 1.0.0 binaries file for OS/2-eComStation are available in Harbour download page as harbour-1.0.0.bin-os2.gcc.zip Include Harbour libraries for: - MySQL 5.1.23 ( hbmysql.a ) - Postgres 8.1.4 ( hbpgsql.a ) - cUrl 7.18.1 ( hbcurl.a ) All packages from Paul Smedley site: http://www.smedley.info/os2ports/index.php David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] C compiler warnings using Visual Studio 2005
Hi all, I get the following warnings (in my DOS/command shell) when building release 1.0 using MS Visual Studio 2005: cl : Command line warning D9035 : option 'Og' has been deprecated and will be removed in a future release cl : Command line warning D9035 : option 'GX-' has been deprecated and will beremoved in a future release cl : Command line warning D9036 : use 'EHs-c-' instead of 'GX-' cl : Command line warning D9002 : ignoring unknown option '-Op' cl : Command line warning D9002 : ignoring unknown option '-G6' Should I just ignore these? Regards, Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] C compiler warnings using Visual Studio 2005
Randy, Try this before bui9ld. set_HB_VISUALC_VER=80 Paul Hi all, I get the following warnings (in my DOS/command shell) when building release 1.0 using MS Visual Studio 2005: cl : Command line warning D9035 : option 'Og' has been deprecated and will be removed in a future release cl : Command line warning D9035 : option 'GX-' has been deprecated and will beremoved in a future release cl : Command line warning D9036 : use 'EHs-c-' instead of 'GX-' cl : Command line warning D9002 : ignoring unknown option '-Op' cl : Command line warning D9002 : ignoring unknown option '-G6' ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] C compiler warnings using Visual Studio 2005
Someone off the list helped me with this - I needed to: set HB_VISUALC_VER=80 At 10:50 AM 8/14/2008, you wrote: Hi all, I get the following warnings (in my DOS/command shell) when building release 1.0 using MS Visual Studio 2005: cl : Command line warning D9035 : option 'Og' has been deprecated and will be removed in a future release cl : Command line warning D9035 : option 'GX-' has been deprecated and will beremoved in a future release cl : Command line warning D9036 : use 'EHs-c-' instead of 'GX-' cl : Command line warning D9002 : ignoring unknown option '-Op' cl : Command line warning D9002 : ignoring unknown option '-G6' Should I just ignore these? Regards, Randy. ___ 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] Issue with hb_numRound in MSVS 2005
Hi all,
I have changed the numeric comparison functions in my Harbour version
to compensate for floating point issues when comparing numeric values
(it was must simpler doing it in Harbour than in the PRG code) - I
round all values to 8 decimal places before making the comparison - I
have used this for years with many Harbour builds with MSVC v6.
I am trying MS Visual Studio 2005 (MSVC v8?) but there seems to be an
issue with my changes as they relate to hb_numRound. For example, my
hb_vmExactlyEqual() code was changed from:
else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
hb_vmPushLogical( hb_vmPopNumber() == hb_vmPopNumber() );
...to this...
else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
{
double dNumber2 = hb_vmPopNumber();
double dNumber1 = hb_vmPopNumber();
dNumber1 = hb_numRound( dNumber1, (int) MY_PRECISION ); //
MY_PRECISION is defined as 8
dNumber2 = hb_numRound( dNumber2, (int) MY_PRECISION ); //
MY_PRECISION is defined as 8
hb_vmPushLogical( dNumber1 == dNumber2 );
}
Again, this works fine in MSVC v6 but the following PRG code fails if
I build this using VS 2005:
? 3.2 == 3.2 // returns .T. in MSVC v6 and .F. in VS 2005.
If I remove the calls to hn_numRound() as...
else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
{
double dNumber2 = hb_vmPopNumber();
double dNumber1 = hb_vmPopNumber();
// dNumber1 = hb_numRound( dNumber1, (int) MY_PRECISION );
// dNumber2 = hb_numRound( dNumber2, (int) MY_PRECISION );
hb_vmPushLogical( dNumber1 == dNumber2 );
}
...it works ok.
Can anyone tell my why there is a difference between these 2 C versions?
TIA.
Regards,
Randy.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-14 18:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-14 18:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * ChangeLog + Added entry for yesterday's syncing/tagging. * make_deb.sh ! Removed hbsqlit2 from contrib list. + Added libharu detection. + Added FreeImage detection (commented). * Contrib list more or less ordered by alphabet. ; [ QUESTION: Do we need to keep this logic duplicated here, if we now have the detection logic and contrib list embedded into the make system anyway? ] * doc/linux1st.txt * Synced with make_deb.sh. 2008-08-13 17:41 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * SVN ; = ; = ; Fully synced /branches/harbour-1.0 with /trunk/harbour ; Created /tags/harbour-1.0.0 based on /branches/harbour-1.0 ; (revision 9175) ; = ; = -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 1.0.0 file releases uploaded
Hi all, I've uploaded following files to sf.net: Sources: harbour-1.0.0-src.zip harbour-1.0.0.tar.bz2 harbour-1.0.0.tar.gz OSX: harbour-1.0.0-darwin_9.4.0.bin.tar.gz Linux (Ubuntu/Debian): harbour_1.0.0-1_i386.deb harbour-1.0.0-linux_2.6.24-19-generic.bin.tar.gz Windows: harbour-1.0.0-win32-bcc551.zip harbour-1.0.0-win32-bcc582.zip harbour-1.0.0-win32-mingw345.zip harbour-1.0.0-win32-mingw412.zip harbour-1.0.0-win32-mingw431.zip harbour-1.0.0-win32-msvs2005.zip harbour-1.0.0-win32-msvs2005cpp.zip harbour-1.0.0-win32-msvs2008.zip harbour-1.0.0-win32-msvs2008cpp.zip harbour-1.0.0-win32-owatcom17.zip harbour-1.0.0-win32-pellesc45.zip harbour-1.0.0-win32-pellesc50.zip harbour-1.0.0-win64-msvs2008cpp.zip harbour-1.0.0-win64-pellesc50.zip DOS: HB100.zip Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-14 18:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-14 18:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * ChangeLog + Added entry for yesterday's syncing/tagging. * make_deb.sh ! Removed hbsqlit2 from contrib list. + Added libharu detection. + Added FreeImage detection (commented). * Contrib list more or less ordered by alphabet. ; [ QUESTION: Do we need to keep this logic duplicated here, if we now have the detection logic and contrib list embedded into the make system anyway? ] * doc/linux1st.txt * Synced with make_deb.sh. 2008-08-13 17:41 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * SVN ; = ; = ; Fully synced /branches/harbour-1.0 with /trunk/harbour ; Created /tags/harbour-1.0.0 based on /branches/harbour-1.0 ; (revision 9175) ; = ; = -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SVN: Created tag harbour-1.0.0
Congratulations on this milestone! Przemek and Viktor have really pulled more than their weight in this project. Szakáts Viktor wrote: Hi all, I've created Harbour 1.0.0 tag just now. URL: https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/tags/harbour-1.0.0 -- Luis Krause Mantilla lkrausem at shaw dot ca luis_krause at hotmail dot com "May the Source be with GNU" ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 1.0.0 file releases uploaded
Dnia czwartek, 14 sierpnia 2008, Szakáts Viktor napisał: > Hi all, > > I've uploaded following files to sf.net: On my homepage there are rpm's build on openSUSE 10.3 http://www.abix.info.pl/kompilator-harbour,56.html If you could upload them to sf... best regards, Adam p.s. Very good work ... congratulations. -- 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] Issue with hb_numRound in MSVS 2005
On Thu, 14 Aug 2008, Randy Portnoff wrote:
Hi Randy,
> I have changed the numeric comparison functions in my Harbour version
> to compensate for floating point issues when comparing numeric values
> (it was must simpler doing it in Harbour than in the PRG code) - I
> round all values to 8 decimal places before making the comparison - I
> have used this for years with many Harbour builds with MSVC v6.
This is technically wrong. IEE758 double value has 53-bit precision
(nearly 16 decimal digit) but the range is much wider 1024-bit (~308
dec digits) and such hack with fixed number of decimal places breaks
very small numbers comparison and has no effect on very big ones.
> I am trying MS Visual Studio 2005 (MSVC v8?) but there seems to be an
> issue with my changes as they relate to hb_numRound. For example, my
> hb_vmExactlyEqual() code was changed from:
> else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
> hb_vmPushLogical( hb_vmPopNumber() == hb_vmPopNumber() );
> ...to this...
> else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
> {
>double dNumber2 = hb_vmPopNumber();
>double dNumber1 = hb_vmPopNumber();
>dNumber1 = hb_numRound( dNumber1, (int) MY_PRECISION ); //
> MY_PRECISION is defined as 8
>dNumber2 = hb_numRound( dNumber2, (int) MY_PRECISION ); //
> MY_PRECISION is defined as 8
>hb_vmPushLogical( dNumber1 == dNumber2 );
^^
You are adding workaround for float point arithmetic problems
hardcoding exact comparission so it's still wrong. The above
code should be changed to:
/* define precision factor which will reduce precision
* to ~15 digit but it will work for any range of supported
* values.
*/
#define HB_PRECISION_FACTOR 1.005
[...]
else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
{
double dNumber2 = hb_vmPopNumber();
double dNumber1 = hb_vmPopNumber();
BOOL fResult;
if( dNumber1 < dNumber2 )
{
if( dNumber1 < 0 )
fResult = dNumber2 * HB_PRECISION_FACTOR <= dNumber1;
else
fResult = dNumber1 * HB_PRECISION_FACTOR >= dNumber2;
}
else
{
if( dNumber1 < 0 )
fResult = dNumber1 * HB_PRECISION_FACTOR <= dNumber2;
else
fResult = dNumber2 * HB_PRECISION_FACTOR >= dNumber1;
}
hb_vmPushLogical( fResult );
}
This code will be probably faster, it will work for any supported range
numbers and it's not effected by compiler/hardware floating point
arithmetic. The cost is reducing precision to ~15 significant decimal
digits. So the cumulative difference in your code during calculations
should not be bigger. If it's too small for you then increase
HB_PRECISION_FACTOR removing one or more 0. It will also reduce the
precision.
> Again, this works fine in MSVC v6 but the following PRG code fails if
> I build this using VS 2005:
> ? 3.2 == 3.2 // returns .T. in MSVC v6 and .F. in VS 2005.
Nothing amazing - it's expected in such code. You still have FL
comparison problem.
> If I remove the calls to hn_numRound() as...
> else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
> {
>double dNumber2 = hb_vmPopNumber();
>double dNumber1 = hb_vmPopNumber();
> // dNumber1 = hb_numRound( dNumber1, (int) MY_PRECISION );
> // dNumber2 = hb_numRound( dNumber2, (int) MY_PRECISION );
>hb_vmPushLogical( dNumber1 == dNumber2 );
> }
> ...it works ok.
As above. It may work for this number but it may not work for other.
> Can anyone tell my why there is a difference between these 2 C versions?
It's FL arithmetic nature. These two compilers uses different floating
point math libraries or you build Harbour with different math optimization
switches. Such difference can appear even with the same binary program
but executed on different machines due to small difference between
math coprocessors in different CPUs. As above nothing amazing.
You have two choices:
1. check carefully for MSVC math optimization switches used to build
harbour and disable them. It may help for some chosen cases.
2. change the method used to compare numbers, f.e. to the one
I presented but please check me - I've just written this code
by finger without any tests and it's possible that I made some
mistakes but I hope you understand the idea - it's important
because my version behaves differently then yours.
If you do not understand it and you are happy with your current
code then simply change it to:
else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
{
double dNumber2 = hb_vmPopNumber();
double dNumber1 = hb_vmPopNumber();
hb_vmPushLogical( hb_numRound( dNumber1 - dNumber2,
(int) MY_PRECISION ) == 0 );
}
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http:
Re: [Harbour] Will be MT the next step?
On Thu, Aug 14, 2008 at 11:56 AM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote: > I will work on it. For next 10 days I will not be available > but when I'll return then I'll restore my worker MT repository. Many thanks. I also will be on vacation until the end of August. > The very base version I can probably create quite fast but > ... > for final version they will have to update their code. Of course, here we don't have the cli*per blueprint so we will have to "test". > Multiwindow GTs, GT runtime switching, GTNET with remote > ... > Probably each user has his own priority list. Of course, these are simply my priorities. I'm moving my desktop apps to an rpc/xml/web interface but I've found that without MT, web remote apps become quite complicated if not impossible to create. Also I'm heavily using dynamic functions using hrbs that are wonderful replacement of php scripts but here hrb libs are almost necessary to avoid duplication of code. Clearly you and the other core developers are free to set the priorities and the road map. I'll do my best to help. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Issue with hb_numRound in MSVS 2005
Hi Przemek,
Thank you VERY much for that detailed explanation and for your help!
Your second solution...
hb_vmPushLogical( hb_numRound( dNumber1 - dNumber2,
(int) MY_PRECISION ) == 0 );
...is much simpler than the first one - Why should I not use this
second solution instead?
Also, while I have you attention... The only reason I am interested
in upgrading to VS 2005 is that MSVC v6 is no longer supported -
However, v6 has always worked very well for me (and compiles much
faster!) - IYO, is there any reason I should NOT be using v6 anymore?
TIA.
Regards,
Randy.
At 02:28 PM 8/14/2008, you wrote:
On Thu, 14 Aug 2008, Randy Portnoff wrote:
Hi Randy,
> I have changed the numeric comparison functions in my Harbour version
> to compensate for floating point issues when comparing numeric values
> (it was must simpler doing it in Harbour than in the PRG code) - I
> round all values to 8 decimal places before making the comparison - I
> have used this for years with many Harbour builds with MSVC v6.
This is technically wrong. IEE758 double value has 53-bit precision
(nearly 16 decimal digit) but the range is much wider 1024-bit (~308
dec digits) and such hack with fixed number of decimal places breaks
very small numbers comparison and has no effect on very big ones.
> I am trying MS Visual Studio 2005 (MSVC v8?) but there seems to be an
> issue with my changes as they relate to hb_numRound. For example, my
> hb_vmExactlyEqual() code was changed from:
> else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
> hb_vmPushLogical( hb_vmPopNumber() == hb_vmPopNumber() );
> ...to this...
> else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
> {
>double dNumber2 = hb_vmPopNumber();
>double dNumber1 = hb_vmPopNumber();
>dNumber1 = hb_numRound( dNumber1, (int) MY_PRECISION ); //
> MY_PRECISION is defined as 8
>dNumber2 = hb_numRound( dNumber2, (int) MY_PRECISION ); //
> MY_PRECISION is defined as 8
>hb_vmPushLogical( dNumber1 == dNumber2 );
^^
You are adding workaround for float point arithmetic problems
hardcoding exact comparission so it's still wrong. The above
code should be changed to:
/* define precision factor which will reduce precision
* to ~15 digit but it will work for any range of supported
* values.
*/
#define HB_PRECISION_FACTOR 1.005
[...]
else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
{
double dNumber2 = hb_vmPopNumber();
double dNumber1 = hb_vmPopNumber();
BOOL fResult;
if( dNumber1 < dNumber2 )
{
if( dNumber1 < 0 )
fResult = dNumber2 * HB_PRECISION_FACTOR <= dNumber1;
else
fResult = dNumber1 * HB_PRECISION_FACTOR >= dNumber2;
}
else
{
if( dNumber1 < 0 )
fResult = dNumber1 * HB_PRECISION_FACTOR <= dNumber2;
else
fResult = dNumber2 * HB_PRECISION_FACTOR >= dNumber1;
}
hb_vmPushLogical( fResult );
}
This code will be probably faster, it will work for any supported range
numbers and it's not effected by compiler/hardware floating point
arithmetic. The cost is reducing precision to ~15 significant decimal
digits. So the cumulative difference in your code during calculations
should not be bigger. If it's too small for you then increase
HB_PRECISION_FACTOR removing one or more 0. It will also reduce the
precision.
> Again, this works fine in MSVC v6 but the following PRG code fails if
> I build this using VS 2005:
> ? 3.2 == 3.2 // returns .T. in MSVC v6 and .F. in VS 2005.
Nothing amazing - it's expected in such code. You still have FL
comparison problem.
> If I remove the calls to hn_numRound() as...
> else if( HB_IS_NUMERIC( pItem1 ) && HB_IS_NUMERIC( pItem2 ) )
> {
>double dNumber2 = hb_vmPopNumber();
>double dNumber1 = hb_vmPopNumber();
> // dNumber1 = hb_numRound( dNumber1, (int) MY_PRECISION );
> // dNumber2 = hb_numRound( dNumber2, (int) MY_PRECISION );
>hb_vmPushLogical( dNumber1 == dNumber2 );
> }
> ...it works ok.
As above. It may work for this number but it may not work for other.
> Can anyone tell my why there is a difference between these 2 C versions?
It's FL arithmetic nature. These two compilers uses different floating
point math libraries or you build Harbour with different math optimization
switches. Such difference can appear even with the same binary program
but executed on different machines due to small difference between
math coprocessors in different CPUs. As above nothing amazing.
You have two choices:
1. check carefully for MSVC math optimization switches used to build
harbour and disable them. It may help for some chosen cases.
2. change the method used to compare numbers, f.e. to the one
I presented but please check me - I've just written this code
by finger without any tests and it's possible that I made some
[Harbour] Harbour Roadmap - Overview
Hello Everybody Here is a compiled overview of feature set for next version(s) not in a specifc order, though I have tried to put these in order of relevance with present times. [ Przemek's Descriptives in List Form + Few Addums ] [] Multi-Threading Basic Version subject to changes over the development phase Mature Version after settling how resources have to behave i.e. Statics, Globals, Publics, Aliases, Workareas, etc InSight existing modal could be Xbase++ [] Central Event Message Queue [] MultiWindow GT [] GTNET with Remote Resource Sharing and Procedures Calls [] HRB Libraries [] RDDNET [] Strong Typing [] GT Runtime Switching [] New internal DBF* RDD API to not replicate the same code between different indexing RDDs [] SQL Queries for DBFs and other native RDDs [] SQLRDD [] Virtual Handle Support with User-Defined Streams [] Cleaned INET Support with C API [] Finishing i18n Support [] File Cache Support [] Full object support for pointer HB_ITEMs for easy - creating objects at C level and - adding new types to HVM [] Rewriting some part of compiler covered by pure GPL License with New License [] Portable GUI Component Library ( if possible ) Regards Pritpal Bedi, INDIA-USA -- View this message in context: http://www.nabble.com/Harbour-Roadmap---Overview-tp18990552p18990552.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] Harbour Roadmap - Overview
On Thursday 14 August 2008 06:01:46 pm Pritpal Bedi wrote: > Hello Everybody > > Here is a compiled overview of feature set for next > version(s) not in a specifc order, though I have tried to > put these in order of relevance with present times. > > [ Przemek's Descriptives in List Form + Few Addums ] > > [] Multi-Threading > > Basic Version >subject to changes over the development phase > > Mature Version >after settling how resources have to behave >i.e. Statics, Globals, Publics, Aliases, Workareas, etc > >InSight existing modal could be Xbase++ > > [] Central Event Message Queue > > [] MultiWindow GT > > [] GTNET with Remote Resource Sharing and Procedures Calls > > [] HRB Libraries > > [] RDDNET > > [] Strong Typing > > [] GT Runtime Switching > > [] New internal DBF* RDD API to not replicate the same >code between different indexing RDDs > > [] SQL Queries for DBFs and other native RDDs > > [] SQLRDD > > [] Virtual Handle Support with User-Defined Streams > > [] Cleaned INET Support with C API > > [] Finishing i18n Support > > [] File Cache Support > > [] Full object support for pointer HB_ITEMs for easy >- creating objects at C level and >- adding new types to HVM > > [] Rewriting some part of compiler covered by pure >GPL License with New License > > [] Portable GUI Component Library ( if possible ) > > > Regards > Pritpal Bedi, INDIA-USA Do we have a DOM style XML parser? I use that a lot in my current work. -- Waiting for sunspots. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Habour1.0.0 +FWH +BCC551 works very well !
Hi, I tested Harbour 1.0.0 +FWH801+BCC551 +MySQL 5.0. WORKS VERY WELL OK! Thanks Harbour team's hard work ! Shuming Wang Canton,China ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
