Re: [Harbour] Harbour 2.0.0: Released
Tuesday 22 December 2009 23:07:46 je Viktor Szakáts napisal: > I'd like to ask developers to create the binary builds, > I will now start to create the 'unified' Windows release > and .tgz, .bz2 source packages. They will be ready by > tomorrow. Mandriva binaries uploaded. LP, Tomaž ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13393] trunk/harbour
Revision: 13393 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13393&view=rev Author: april Date: 2009-12-24 03:25:54 + (Thu, 24 Dec 2009) Log Message: --- 2009-12-23 22:26 UTC+0500 April White (april users.sourceforge.net) * contrib/hbbtree/hb_btree.c * bug fix: array access was in bounds but to wrong value [TOMERGE 2.0] Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbtree/hb_btree.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13392] trunk/harbour
Revision: 13392 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13392&view=rev Author: vouchcac Date: 2009-12-24 02:46:59 + (Thu, 24 Dec 2009) Log Message: --- 2009-12-23 18:40 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/filelist.mk + contrib/hbqt/hbqt_errorsys.prg * contrib/hbqt/hbqt_misc.prg * contrib/hbxbp/xbpdialog.prg * contrib/hbxbp/xbpgeneric.prg * contrib/hbxbp/xbpqtuiloader.prg * contrib/hbxbp/xbpwindow.prg * contrib/hbide/hbide.prg * contrib/hbide/resources/mainwindow.ui + Implemented hbqt_errorSys(). It is actually original rtl/errorsys.prg tuned to display error in a message-box. ! An experimental stage passed, leaning towards next. Please bear with me if you see a little clumsy hbide. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/resources/mainwindow.ui trunk/harbour/contrib/hbqt/filelist.mk trunk/harbour/contrib/hbqt/hbqt_misc.prg trunk/harbour/contrib/hbxbp/xbpdialog.prg trunk/harbour/contrib/hbxbp/xbpgeneric.prg trunk/harbour/contrib/hbxbp/xbpqtuiloader.prg trunk/harbour/contrib/hbxbp/xbpwindow.prg Added Paths: --- trunk/harbour/contrib/hbqt/hbqt_errorsys.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
Congratulations! Seasons greetings and the Very Best for the new year! Thanks. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour next major release wishlist
> Angel Pais escreveu: >> - Invite Marcos Antonio gambeta to integrate xhgtk into harbour`s tree. > > I am not against this idea. But i have one question (maybe more than one): > > xHarbour developers have interest in the library too. If the developmente of > the xhgtk move to /harbour/contrib, what will happen to the compatibility > with the xHarbour ? It's my personal opinion, but since it's so much complicated to maintain code which builds also with xhb, and such development needs very special requirement from build tools, testing/development environment, etc, plus we all have finite resources here, I'm not in favor of spending time on code enclosed between #if __XHARBOUR__. Notice we have already an extremely large although well defined set of compatibility needs and that is already quite a feat to keep maintained and tested. We currently have _no_ such code in Harbour repository, and for our own good, IMO we should keep it this way. (*) So, if xhb compatibility can be achieved by using code which automatically work also in xhb, plus it's not a problem to stick to pure Harbour build tools, for me it's okay, but if not, we should rather keep it out from our SVN. Even more generally speaking we should carefully check what benefits such merging can give. It has a lot of "costs", f.e. we inevitable take over many 'cleanup', testing and other jobs, and it's much more difficult to create a release, so eventually it can hold back frequent core releases. In fact the overall goal is the opposite: Allow developers to create addons completely independently from Harbour code, yet make them easily manageable and pluggable for users. That's what I'd like to encourage 3rd party developers. In any case, it's a good start to start adopting Harbour code coding rules and tools (build tools, SVN) and whatnot, so it's easier to jump between projects. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour next major release wishlist
Marcos Gambeta escreveu: xHarbour developers have interest in the library too. Only to clarify: i'm talking about developers that use xHarbour and not the developers that develop the xHarbour. -- Regards, Marcos Antonio Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour next major release wishlist
Angel Pais escreveu: - Invite Marcos Antonio gambeta to integrate xhgtk into harbour`s tree. I am not against this idea. But i have one question (maybe more than one): xHarbour developers have interest in the library too. If the developmente of the xhgtk move to /harbour/contrib, what will happen to the compatibility with the xHarbour ? For now, I'm changing the way the wrappers are generated (from manual to automatic). After this step, we can take a final decision. Meanwhile, ideas and comments are welcome. -- Regards, Marcos Antonio Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Some changes on Harbour Web Page
Hi Massimo, Immediately I only focused the new release in order to provide the links to downloads and news to everyone who does not have the habit of reading this mailing. You got to carefully read my other post where I mentioned that "I still have to make some changes" ... Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour next major release wishlist
Viktor Szakáts escribió: Hi All, In the spirit of release enthusiasm it's now also a good time to brainstorm a little on things which we would like to make it into next major Harbour release. Hi Viktor, You've opened Pandora's box here :) My 5 minutes brainstorming list: - A RPC protocol based on NETIO to allow 2/3 tier multiplattform apps. - Invite Marcos Antonio gambeta to integrate xhgtk into harbour`s tree. - Invite Teo Fourounge (forgive mispelling) to integrate wxwidgets into harbour`s tree. - Invite Carozo de Quilmes to integrate his hbqtcommand (minigui compatible command layer based on QT ) into harbour's tree. - Make Harbour a standard package on linux ( at least ubuntu ) distributions. - An SQL interpreter for DBF files so we can work in mixed navigational- recorset based mode depending of the kind of problem to solve. - Start a big collaboration effor to scatter compile edit and publish a more professional multilevel documentation (users-developpers-etc). Regards Angel Pais ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour next major release wishlist
Viktor Szakáts wrote: In the spirit of release enthusiasm it's now also a good time to brainstorm a little on things which we would like to make it into next major Harbour release. - A full featured SQL RDD with support for all major databses, keeping the same behavior across different backends. - Mulplatform GUI supporting classes defined on Clipper 5.3: CheckBox, Get, ListBox, MenuItem, PopupMenu, PushButton, RadioButton, RadioGroup, ScrollBar, TBColumn, TBrowse and TopBarMenu (it could be expanded in later releases). - Development of a translator or code generator for Harbour CGI applications, capable of generate HTML+JavaScript code from the 5.3 GUI classes. Such code could include asynchronous calls to the server to mimic the behavior of desktop applications. Regards, Roberto. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
> add hbqt , hbxbp,gtqtc, hbide (experimental stage) > remove apollo,rddado > at http://www.harbour-project.org/download_contrib.html gtqtc is not an enabled contrib yet, since it needs more work to be usable in practice. I was thinking to move it inside hbqt. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Some changes on Harbour Web Page
Can be done? 2009/12/11 Vailton Renato : > In reality there were not "several times" but the truth is that it was > "only once" ... and since then the site has not been updated. For this > reason alone there is still no reference to your name there ... but > for the next update must already be included. So much as I said at the > beginning of this thread, I am preparing to change some details in the > site ... then it was already to be included anyway. > > Vailton Renato -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
add hbqt , hbxbp,gtqtc, hbide (experimental stage) remove apollo,rddado at http://www.harbour-project.org/download_contrib.html 2009/12/23 Vailton Renato : > I updated the pages of your site and also the news page. I still have > to make some changes, but the current already has highlighted the new > version 2.0! Suggestions or comments are welcome. > > And I would like to congratulate everyone for the great achievement > that this version is for the project! > > Regards, > Vailton Renato > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour next major release wishlist
hbide demostrate the reliability of HBQT & HBXBP my wishlist: 1)A way for easy convert application to hbxbp mix traditional SAY/GET/TBrowse() with graphical user interface elements for an easy and fast migration 2) Followinng the Next Generation Hybrid Applications with Qt we must interact with webservice http://www.slideshare.net/pkosonen/next-generation-hybrid-applications-with-qt-presentation-for-see-2009 . 2009/12/23 Pritpal Bedi > > - HBIDE - The standard way to build Harbour applications > - HBXBP - To match and possibly surpass Xbase++ > - If HBQT + HBXBP does not provide official GUI support then > lookups for the alternatives. > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour next major release wishlist
Hi All, First, many thank for the great work of the Harbour Team, and my whish list is : XML support XML DSIG suppor I now is only for window, but, : ability to create ole server. Thank again, and sorry for my bad english, Lautaro Moreira El 23/12/2009 17:54, Viktor Szakáts escribió: Hi All, In the spirit of release enthusiasm it's now also a good time to brainstorm a little on things which we would like to make it into next major Harbour release. You're welcome to post your idea, whatever that is. My list on the top of my head: - Complete Unicode support - Type cleanup (planned) - GTNET - Oracle accessibility (sddora, hbora) - Dir layout scheme cleanup (planned) - Multi-OS binary distribution for WIN/DOS/OS2 world - Becoming a std Linux package - Ironing out HBQT remaining grey areas (memory management, .prg level indestructibility, proper componentization) - HBBMCDX integrated into core. - XML support Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour next major release wishlist
Hello Viktor Viktor Szakáts wrote: > > In the spirit of release enthusiasm it's now also > a good time to brainstorm a little on things which > we would like to make it into next major Harbour > release. > > You're welcome to post your idea, whatever that is. > > My list on the top of my head: > > - Complete Unicode support > - Type cleanup (planned) > - GTNET > - Oracle accessibility (sddora, hbora) > - Dir layout scheme cleanup (planned) > - Multi-OS binary distribution for WIN/DOS/OS2 world > - Becoming a std Linux package > - Ironing out HBQT remaining grey areas > (memory management, .prg level indestructibility, > proper componentization) > - HBBMCDX integrated into core. > - XML support > - HBIDE - The standard way to build Harbour applications - HBXBP - To match and possibly surpass Xbase++ - If HBQT + HBXBP does not provide official GUI support then lookups for the alternatives. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/Harbour-next-major-release-wishlist-tp26907413p26907647.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour next major release wishlist
Extend rdd to allow easy conversion to sql Easy coversion to GUI Clean path to web application 2009/12/23 Viktor Szakáts : > Hi All, > > In the spirit of release enthusiasm it's now also > a good time to brainstorm a little on things which > we would like to make it into next major Harbour > release. > > You're welcome to post your idea, whatever that is. > > My list on the top of my head: > > - Complete Unicode support > - Type cleanup (planned) > - GTNET > - Oracle accessibility (sddora, hbora) > - Dir layout scheme cleanup (planned) > - Multi-OS binary distribution for WIN/DOS/OS2 world > - Becoming a std Linux package > - Ironing out HBQT remaining grey areas > (memory management, .prg level indestructibility, > proper componentization) > - HBBMCDX integrated into core. > - XML support > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > ok, so there are two places where this is used, in src/rtl/math.c:334 > onwards and src/vm/itemapi.c:2250 onwards. Three. src/common/hbprintf.c also includes it. Here is the only one place when we try to use different C99 FL functions not only finite() and we can use as argument 'long double' values not only double ones. It means that if possible we should not force arguments conversion to double because on some hardware or (and) when some fast math optimization switches are enabled it may cause SIGFPE if argument is not valid FL number. Harbour itself does not use any NaN values so it's not a problem for valid code but in some wrong user code it may cause detecting the source of problem harder. > they are even used for the same purpose, to check whether or not to > signal a range error of sorts on a numeric argument. In itemapi.c we only try to detect finite double values. In math.c when HB_MATH_ERRNO is set we try to detect also NaN values and we should cleaned this code because now it's possible that it will not work with compilers not supporting C++ isnan()/isinf() macros. In hb_snprintf() we additionally try to detect type of infinity and sign bit. I agree that it will be nice to use common macros set in all three files defined in some separate header file, i.e. hbfloat.h which will make all platform dependent #includes and define some HB_*() macros which we can use in other code. > yet the one in itemapi.c is a macro with a screenful of tests for > platforms and compilers and whatnot, whereas the one in math.c is a > very simple conditional for os2-sunos-all-the-rest. notably, it > doesn't have a special case for os/2 -- nb i do not know if > "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if > it does, then scratch this last remark, but then the notation is > inconstent. > why is this difference? The code in math.c was enabled only in some GCC builds so this trivial condition was working but in fact it's wrong and should be updated to use more precise logic. In some spare time I'll check if I can easy create hbfloat.h file which can be easy used also with hbprintf.c and if yest then I'll commit it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour next major release wishlist
Hi All, In the spirit of release enthusiasm it's now also a good time to brainstorm a little on things which we would like to make it into next major Harbour release. You're welcome to post your idea, whatever that is. My list on the top of my head: - Complete Unicode support - Type cleanup (planned) - GTNET - Oracle accessibility (sddora, hbora) - Dir layout scheme cleanup (planned) - Multi-OS binary distribution for WIN/DOS/OS2 world - Becoming a std Linux package - Ironing out HBQT remaining grey areas (memory management, .prg level indestructibility, proper componentization) - HBBMCDX integrated into core. - XML support Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
Este es el mejor regalo de Navidad... Felicitaciones a todos los que están participando en el proyecto y... GRACIAS Saludos Manu Expósito - This is the best Christmas gift ... Congratulations to all who are participating in the project y. .. THANKS Greetings Manu Exposito 22/12/2009 23:07, Viktor Szakáts escribió: Hi All, I'm glad to announce that after a very heavy 16 months of development, the final, stable version 2.0.0 is finally released. Thanks to everyone who took part of this huge work in any ways. I'd like to ask developers to create the binary builds, I will now start to create the 'unified' Windows release and .tgz, .bz2 source packages. They will be ready by tomorrow. Another remaining task is to make this announcement on various forums and update the web page and other places where needed. HOW TO GET -- From SVN: svn export https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/tags/harbour-2.0.0 From sf.net: http://sourceforge.net/projects/harbour-project/files/source/2.0.0/ RELEASE NOTES - Please check RELNOTES file, this contains mostly generic release notes plus a few 'unified' binary release specific ones, overall it's a good brief list of the things changes since beta3, and it includes previous beta release notes as well. You may also want to check doc/whatsnew.txt which has a more details, but partial list of some past changes since 1.0.1. DEVELOPER NOTES --- The new 2.0.x branch has been created here: http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/branches/harbour-2.0/ Development goes onwards in trunk, but we should mark patches in ChangeLog which should be eventually merged to 2.0.x branch with '[TOMERGE 2.0]' (without quotes). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Video and presentation about Qt license
> The harbour exception allow create commercial application > so it can be used for Making commercial application buyng a commercial licenze > but agree space question It's not about the Harbour license limitation, but the QT LGPL license limitation. No one said it's not possible to create a Harbour+QT commercial app with statically linked QT libs, but it requires commercial QT license. Which, I presume very few Harbour developers have. So the extra effort to offer this to _everyone by default_ is a waste of resources. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 Key Features
Hi Przemysław Which consequence for ASCII based limitation? What is harbour at present? Which Future you plan? Why you use harbour as developement system? What are power of harbour as development system? 2009/12/23 Przemysław Czerpak : > On Wed, 23 Dec 2009, Massimo Belgrano wrote: > >> Harbour is without any hacks in core code which introduce such >> limitation like 32/64? > > Yes. It can work with any pointer size if compiler supports some > integer types larger enough to hold such pointers so it will work > also with 128 if we ever have such systems or some more exotic ones > like 48bits. It means that core code is not limited to work only with > some chosen fixed pointer sizes like 32 or 64 bits. > The only two limitations we have are 8bit byte size and ASCII based > character set due to hard coded some strict Clipper compatibility. > Removing both limits is possible but it needs a lot of work and not > all things can be ported to such systems (i.e. some binary file > formats). In current days such systems are used very seldom (i,e, > some IBM mainframes) so I do not have enough motivation to made it. > Also without regular access to the hardware it will be hard to keep > such ports alive. > > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Video and presentation about Qt license
The harbour exception allow create commercial application so it can be used for Making commercial application buyng a commercial licenze but agree space question 2009/12/23 Viktor Szakáts : > To keep the free spirit of Harbour, I will (if I do it > that is) drop the HBQT static libs from the next official > Harbour binary distribution, I don't think too many > developers need it either as it clearly requires a paid > QT license, which severely limits the number of users > who may benefit from these libs. Anyway they can be easily > build locally, so overall the loss will be minimal, > but the installed size will 20MB less, build time and > download size as well. > > Brgds, > Viktor > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
My suggestion is : Give importance to xhb-diff.dco text Give a feature list Easy Unified setup for windows Unicode support dramatically improve application speed product usability and reliability 2009/12/23 Vailton Renato : > I updated the pages of your site and also the news page. I still have > to make some changes, but the current already has highlighted the new > version 2.0! Suggestions or comments are welcome. > > > Regards, > Vailton Renato > ___ ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
Thanks a lot Vailton. Brgds, Viktor On 2009 Dec 23, at 20:52, Vailton Renato wrote: > I updated the pages of your site and also the news page. I still have > to make some changes, but the current already has highlighted the new > version 2.0! Suggestions or comments are welcome. > > And I would like to congratulate everyone for the great achievement > that this version is for the project! > > Regards, > Vailton Renato > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Video and presentation about Qt license
To keep the free spirit of Harbour, I will (if I do it that is) drop the HBQT static libs from the next official Harbour binary distribution, I don't think too many developers need it either as it clearly requires a paid QT license, which severely limits the number of users who may benefit from these libs. Anyway they can be easily build locally, so overall the loss will be minimal, but the installed size will 20MB less, build time and download size as well. Brgds, Viktor On 2009 Dec 23, at 20:49, Marcos Gambeta wrote: >> http://www.slideshare.net/qtbynokia/qt-licensing-explained > > In the presentation, see pages 5 and 14 about dynamic and static linking. > > > -- > Regards, > Marcos Antonio Gambeta > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Harbour 2.0.0: Released
Simply fantastic. Congratulations to all developers for this wonderful achievement. Congratulations to all Antonio Carlos From: antonioc_si...@msn.com To: harbour@harbour-project.org Subject: RE: [Harbour] Re: Harbour 2.0.0: Released Date: Wed, 23 Dec 2009 19:55:57 + Simplesmente fantastico. Parabens a todos os desenvolvedores por essa maravilhosa conquista. Congratulações a todos Antonio Carlos > To: harbour@harbour-project.org > From: amigo...@adinet.com.uy > Date: Wed, 23 Dec 2009 11:51:22 -0200 > Subject: [Harbour] Re: Harbour 2.0.0: Released > > Viktor Szakáts escribió: > > Hi All, > > > > I'm glad to announce that after a very heavy 16 months > > of development, the final, stable version 2.0.0 is finally > > released. > > > > Congratulations and thank your all. > You are all an amazing group of programmers with a straight vision on > quality and multiplatform compatibility issues. > This compiler assures the survival of our beloved favorite programming > language. > The best it's yet to come ! > Merry Christmas to all ! > > Angel Pais > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour Agora a pressa é amiga da perfeição. Chegou Windows 7. Conheça. _ Navegue com segurança com o Novo Internet Explorer 8. Baixe agora, é gratis! http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmail&utm_medium=Tagline&utm_content=Tag4&utm_campaign=IE8___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Harbour 2.0.0: Released
Simplesmente fantastico. Parabens a todos os desenvolvedores por essa maravilhosa conquista. Congratulações a todos Antonio Carlos > To: harbour@harbour-project.org > From: amigo...@adinet.com.uy > Date: Wed, 23 Dec 2009 11:51:22 -0200 > Subject: [Harbour] Re: Harbour 2.0.0: Released > > Viktor Szakáts escribió: > > Hi All, > > > > I'm glad to announce that after a very heavy 16 months > > of development, the final, stable version 2.0.0 is finally > > released. > > > > Congratulations and thank your all. > You are all an amazing group of programmers with a straight vision on > quality and multiplatform compatibility issues. > This compiler assures the survival of our beloved favorite programming > language. > The best it's yet to come ! > Merry Christmas to all ! > > Angel Pais > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _ Fique protegido de ameças utilizando o Novo Internet Explorer 8. Baixe já, é grátis! http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmail&utm_medium=Tagline&utm_content=Tag1&utm_campaign=IE8___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
I updated the pages of your site and also the news page. I still have to make some changes, but the current already has highlighted the new version 2.0! Suggestions or comments are welcome. And I would like to congratulate everyone for the great achievement that this version is for the project! Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Video and presentation about Qt license
http://www.slideshare.net/qtbynokia/qt-licensing-explained In the presentation, see pages 5 and 14 about dynamic and static linking. -- Regards, Marcos Antonio Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Video and presentation about Qt license
Hi all, Links for video and presentation about the Qt license: http://qt.nokia.com/developer/learning/online/talks/developerdays2009/qt-in-use/making-the-licensing-decision2014lgpl-vs.-commercial http://www.slideshare.net/qtbynokia/qt-licensing-explained -- Regards, Marcos Antonio Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
I'm glad to announce that after a very heavy 16 months of development, the final, stable version 2.0.0 is finally released. Thanks to all the team for this GREAT release! Regards, Roberto. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
Hello Team harbour, I am so happy to not have chosen Delphi or VB as my tools to work, therefore Harbour gives me everything I need and more. I think the leaders of the Harbour as geniuses by the ability to provide tools so incredible. Harbour is my home :) Special thanks to Vailtom for their contributions and the translation of the Harbour for the Portuguese. Thank you all for this grandeur. Best Regards, Rossine. -- View this message in context: http://old.nabble.com/Harbour-2.0.0%3A-Released-tp26895087p26906067.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
Tamas TEVESZ wrote: > doesn't have a special case for os/2 -- nb i do not know if > "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if > it does, then scratch this last remark, but then the notation is > inconstent. > Tamas, the answer to your question is: no. There is OpenWatcom on OS/2 which should define neither one. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13391] trunk/harbour
Revision: 13391 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13391&view=rev Author: vouchcac Date: 2009-12-23 17:11:04 + (Wed, 23 Dec 2009) Log Message: --- 2009-12-23 09:07 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/resources/mainwindow.ui * contrib/hbxbp/xbpbrowse.prg * contrib/hbxbp/xbpdialog.prg + Added an experimental protocol scheduled to be polished in next few days. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbxbp/xbpbrowse.prg trunk/harbour/contrib/hbxbp/xbpdialog.prg Added Paths: --- trunk/harbour/contrib/hbide/resources/mainwindow.ui This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] two small portability enhancements
hi,
the attached and below inlined does the following:
- hunk #1 prepares for when IPV6_ADD_MEMBERSHIP is defined by the
system; it is very synonymous with IPV6_JOIN_GROUP.
- hunk #2 makes initseg startup work with coff executables. (ok,
despite the heritage, i really don't know whether this includes pe
too :)
for #2, it might be that a simpler solution exists (macro-wise), but i
am not smart enough to have that figured out.
Index: src/rtl/hbsocket.c
===
--- src/rtl/hbsocket.c (revision 13390)
+++ src/rtl/hbsocket.c (working copy)
@@ -2484,6 +2484,9 @@
if( err > 0 )
{
mreq.ipv6mr_interface = 0;
+#if !defined( IPV6_JOIN_GROUP ) && defined( IPV6_ADD_MEMBERSHIP )
+# define IPV6_JOIN_GROUP IPV6_ADD_MEMBERSHIP
+#endif
ret = setsockopt( sd, IPPROTO_IPV6, IPV6_JOIN_GROUP, ( const char * )
&mreq, sizeof( mreq ) );
hb_socketSetOsError( ret != -1 ? 0 : HB_SOCK_GETERROR() );
return ret;
Index: include/hbinit.h
===
--- include/hbinit.h(revision 13390)
+++ include/hbinit.h(working copy)
@@ -136,13 +136,20 @@
static void func( void ) \
{
- #define HB_CALL_ON_STARTUP_END( func ) \
- } \
- HB_INIT_FUNCTION_REF( func ) \
- HB_EXTERN_END \
- asm ( ".section .init\n\tcall " HB_MACRO2STRING( func ) "\n\t.section
.text\n\t" );
+ #if defined( _M_COFF )
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( ".section .init, \"x\"\n\tcall " HB_MACRO2STRING( func )
"\n\t.section .text\n\t" );
+ #else
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( ".section .init\n\tcall " HB_MACRO2STRING( func ) "\n\t.section
.text\n\t" );
+ #endif
-
#define HB_INIT_FUNCTION_REF( func )\
extern void * func##_ref_( void ); \
void * func##_ref_( void ) \
--
[-]
mkdir /nonexistentIndex: src/rtl/hbsocket.c
===
--- src/rtl/hbsocket.c (revision 13390)
+++ src/rtl/hbsocket.c (working copy)
@@ -2484,6 +2484,9 @@
if( err > 0 )
{
mreq.ipv6mr_interface = 0;
+#if !defined( IPV6_JOIN_GROUP ) && defined( IPV6_ADD_MEMBERSHIP )
+# define IPV6_JOIN_GROUP IPV6_ADD_MEMBERSHIP
+#endif
ret = setsockopt( sd, IPPROTO_IPV6, IPV6_JOIN_GROUP, ( const char * ) &mreq, sizeof( mreq ) );
hb_socketSetOsError( ret != -1 ? 0 : HB_SOCK_GETERROR() );
return ret;
Index: include/hbinit.h
===
--- include/hbinit.h (revision 13390)
+++ include/hbinit.h (working copy)
@@ -136,13 +136,20 @@
static void func( void ) \
{
- #define HB_CALL_ON_STARTUP_END( func ) \
- } \
- HB_INIT_FUNCTION_REF( func ) \
- HB_EXTERN_END \
- asm ( ".section .init\n\tcall " HB_MACRO2STRING( func ) "\n\t.section .text\n\t" );
+ #if defined( _M_COFF )
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( ".section .init, \"x\"\n\tcall " HB_MACRO2STRING( func ) "\n\t.section .text\n\t" );
+ #else
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( ".section .init\n\tcall " HB_MACRO2STRING( func ) "\n\t.section .text\n\t" );
+ #endif
-
#define HB_INIT_FUNCTION_REF( func )\
extern void * func##_ref_( void ); \
void * func##_ref_( void ) \
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Przemysław Czerpak wrote: hi, sorry to be so blunt, but the more i read, the less i understand ;) > isinf() and isfinite() are C99 extensions so they are not available if > C99 features are not enabled. > There is problem with non GCC unix builds - they do not use HB_MATH_ERRNO > handler (I'll fix it in next commit) and it's the reason why current > src/rtl/math.c. do not need ieeefp.h. ok, so there are two places where this is used, in src/rtl/math.c:334 onwards and src/vm/itemapi.c:2250 onwards. they are even used for the same purpose, to check whether or not to signal a range error of sorts on a numeric argument. yet the one in itemapi.c is a macro with a screenful of tests for platforms and compilers and whatnot, whereas the one in math.c is a very simple conditional for os2-sunos-all-the-rest. notably, it doesn't have a special case for os/2 -- nb i do not know if "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if it does, then scratch this last remark, but then the notation is inconstent. why is this difference? (i probably should have picked something less hardcore...) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
Hi Przemek, > It means that you had to take above code from xHarbour. > I've just check that above fix were committed to xHarbour CVS by Paul at: > 2006-07-01 18:35 UTC-0500 Paul Tucker Mea Culpa! I understand that don't know much about history :( Thank you for correcting me. Best regards, Saulius ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour 2.0.0 unified Windows binary release
Hi All, Harbour 2.0.0 (r13372) source archives and Windows binary releases are available for download on sourceforge.net: http://sourceforge.net/projects/harbour-project/files/ Make sure to check INSTALL doc "QUICK START" section and visit our user forums at: http://sourceforge.net/apps/phpbb/harbour-project/ Release notes: --- Unified Windows release for most supported compilers and x86, x64, WinCE/ARM, MS-DOS, OS/2, Linux target platforms. Installed size: 214MB (54MB - 339MB) The default installation will install MinGW compiler + x86 static and shared libs, MSVC and BCC x86 libs and examples. Options: x86 shared tools, x64 shared tools, MinGW x64 and WinCE-ARM libs, MSVC x64 libs, Open Watcom x86 libs, shared x64/WinCE-ARM libs, MS-DOS (watcom) libs, OS/2 (watcom) libs, Linux (watcom) libs. Usage: 1) install/unpack to any directory (C:\hb20) 2) go to bin dir (optional if you specify path for hbmk2) 3) For x86 executable, type: 'hbmk2 ../tests/hello.prg' 4) For x64 executable, type: 'hbmk2 ../tests/hello.prg -compiler=mingw64' [needs mingw64 to be installed in 'comp/mingw64' dir beforehand] 5) For WinCE/ARM executable, type: 'hbmk2 ../tests/hello.prg -platform=wce' [needs cegcc to be installed in 'comp/mingwarm' dir beforehand] 6) For MS-DOS executable, type: 'hbmk2 ../tests/hello.prg -platform=dos' [needs OpenWatcom to be installed in 'comp/watcom' dir beforehand] 7) For Linux executable, type: 'hbmk2 ../tests/hello.prg -platform=linux' [needs OpenWatcom to be installed in 'comp/watcom' dir beforehand] Tool/lib versions used to create this package: --- Compiler tools -- MinGW GNU C 4.4.1 TDM-2 (included) MinGW w64 GNU C 4.5.0-20091118 MinGW CEGCC 4.4.0 MSVC 2008 (version bundled with MS Windows SDK 7) Open Watcom C 1.8 Borland C/C++ 5.5.1 External lib dependencies - ACE 9.10 Allegro 4.2.2 Blat 2.6.2 Cairo 1.8.8 libcurl 7.19.6 Firebird 2.1.3 FreeImage 3.13.0 GD 2.0.35 MySQL 5.1.41 OpenSSL 0.9.8k PostgreSQL 8.4.2-1 QT 4.5.3 WATTCP 2.2.10 Changes since previous (2.0.0beta3 20090905) release: --- - Harbour updated to r13359 (from r12422) - MinGW CEGCC updated to 4.4.0 - upx updated to 3.04. - MinGW 4.4.1 updated to TDM-2 release fixing a performance problem. - MinGW w64 updated to latest binary release. - DJGPP build in unified release replaced with OpenWatcom MS-DOS build. - External libs updated (except OpenSSL and libcurl). - hbwin cleanups/fixes (printer handling) and improvements (mutex, MAPI, misc) - hbwin OLE2, ActiveX support improved and finalized. - hbwin full UNICODE support and cleanups. - hbwin basic win64 .dll support. - hbtip POP3/SMTP fixes, encoding/charset support. - Added hbmemio contrib. - hbnetio finalized. - hbqt cleanups and improvements, QT 4.6 support. - hbide (early development stage). - Documentation enhancements: INSTALL and doc/xhb-diff.txt. - hbmk2 got support to convert xMate, hbmake and xbuild make files to .hbp format. - Added hbsms contrib library (to send SMS text messages in multiplatform way). - gtwvg now builds in win64 mode. - Rudimentary port of GTWVW (find it in examples) - New hbcairo wrapper for cairo lib. - Improved code portability for startup code, C++ mode and to support for old GCC versions. - Added public Harbour C level API to handle GC collected pure pointers. - Added workaround fox Pelles C 6.0 bug, so now it can be used with Harbour for win32 and wince. Win64 build still doesn't work, due to other POCC6 bugs. - Fixed to support MSVC 6.0. - dlmalloc memory allocator now also optimized for MT mode. - DJGPP builds received support for .dxe dynamic libs. - MS-DOS build included in unified release package is now built with OpenWatcom rather than DJGPP. - OpenWatcom now builds in plain C mode (instead of C++) - Included MSVC build is now a UNICODE build. - Changed all Harbour to use WIDE Windows API calls only in UNICODE mode. - New Harbour C level UTF-8 and UTF-16 string handling functions. - Rewritten internal codepage and collation support. Collations are now ensured to be CA-Cl*pper compatible. - HB_TRANSLATE() now supports UTF-8. - OS/2 platform support improvements (watcom, .dll support, GCC OMF support). - gtxwc fixes. - General finalization to *nix Harbour dynamic library generation built into build system. - Generalized the way zlib and pcre embedded sources are handled. - Finalized new pure GNU Make based build system. - Embedded libharu made available for MS-DOS Harbour builds, plus many other leveling of MS-DOS port. - Added Blowfish encryption functions to core. - Added experimental win64 binary build of GNU Make. - Synced with some new features that appeared in xhb, plus some missing features f
[Harbour] Re: Harbour 2.0.0: Released
Viktor Szakáts escribió: Hi All, I'm glad to announce that after a very heavy 16 months of development, the final, stable version 2.0.0 is finally released. Congratulations and thank your all. You are all an amazing group of programmers with a straight vision on quality and multiplatform compatibility issues. This compiler assures the survival of our beloved favorite programming language. The best it's yet to come ! Merry Christmas to all ! Angel Pais ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
Przemysław Czerpak pisze: The real problem is the fact that you didn't start new thread but simply used "replay" option in your mail program so your both messages still belongs to the same initial thread. The context of subject is unimportant for mail programs which can follow threads. Just look at: http://lists.harbour-project.org/pipermail/harbour/2009-December/thread.html#29367 If you want to start new thread then please remember to not use "replay" but always create new clean message and if you want to replay then always use "replay" option in your mail program instead of creating new message. Thanks for remainding. As my email client is not configured to recognize threads, it is easy to forget and go the 'easier' way ... Jacek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
Yes, you are right. Strange that no one reported it for such long time.
Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
...
/* Special case */
if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetMode( usRows, _GetScreenWidth() ));
}
else if ( usRows > _GetScreenHeight() && usCols < _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetMode( _GetScreenHeight(), usCols ));
}
...
Later somehow this disappears.
Best regards,
Saulius
Above fragment dosn't seem to do what's expected. The resulting console
size is not usRows X usCols. Maybe that's why somebody removed the code.
Jacek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13390] trunk/harbour
Revision: 13390 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13390&view=rev Author: vszakats Date: 2009-12-23 12:32:02 + (Wed, 23 Dec 2009) Log Message: --- 2009-12-23 13:31 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * package/winuni/mpkg_win_uni_extra_copy.bat + Added automatized (but not generic) logic to assemble 'unified' package. [TOMERGE 2.0] Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/package/winuni/mpkg_win_uni_extra_copy.bat This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
Hi, Many thanks for all team for this great work!! Regards, José Luis Capel El 23 de diciembre de 2009 12:09, ToninhoFWi escribió: > >I'm glad to announce that after a very heavy 16 months > >of development, the final, stable version 2.0.0 is finally > >released. > > Thanks to all team for this great release. > > Congratulations ! > > > > Toninho. > > __ > Faça ligações para outros computadores com o novo Yahoo! Messenger > http://br.beta.messenger.yahoo.com/ > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13389] trunk/harbour
Revision: 13389 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13389&view=rev Author: druzus Date: 2009-12-23 12:00:07 + (Wed, 23 Dec 2009) Log Message: --- 2009-12-23 12:59 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/harbour-win-spec * harbour/harbour-wce-spec ! removed unused hbmk.cfg files which break RPM build process [TOMERGE 2.0] TODO: add support for hbmk2 configuration which cab be used with above Win32/64 and WinCE binaries Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/harbour-wce-spec trunk/harbour/harbour-win-spec This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13388] trunk/harbour
Revision: 13388 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13388&view=rev Author: druzus Date: 2009-12-23 11:31:15 + (Wed, 23 Dec 2009) Log Message: --- 2009-12-23 12:31 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbmath.h ! enable HB_MATH_ERRNO in all *unix builds not only in GCC ones * harbour/src/vm/itemapi.c ! use finite() to check for valid double values - looks that SunCC does not report iDODO warnings so we were not informed about the problem * harbour/include/hbdefs.h * harbour/src/common/hbprintf.c % use also _STDC_C99 macro not only _ISOC99_SOURCE to detect C99 mode and do not reduce such detection to GCC [TOMERGE 2.0] Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbdefs.h trunk/harbour/include/hbmath.h trunk/harbour/src/common/hbprintf.c trunk/harbour/src/vm/itemapi.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 Key Features
On Wed, 23 Dec 2009, Massimo Belgrano wrote: > Harbour is without any hacks in core code which introduce such > limitation like 32/64? Yes. It can work with any pointer size if compiler supports some integer types larger enough to hold such pointers so it will work also with 128 if we ever have such systems or some more exotic ones like 48bits. It means that core code is not limited to work only with some chosen fixed pointer sizes like 32 or 64 bits. The only two limitations we have are 8bit byte size and ASCII based character set due to hard coded some strict Clipper compatibility. Removing both limits is possible but it needs a lot of work and not all things can be ported to such systems (i.e. some binary file formats). In current days such systems are used very seldom (i,e, some IBM mainframes) so I do not have enough motivation to made it. Also without regular access to the hardware it will be hard to keep such ports alive. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
On Wed, 23 Dec 2009, Saulius Zrelskis wrote:
Hi,
> > Yes, you are right. Strange that no one reported it for such long time.
> Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
> ...
> /* Special case */
> if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
> {
> HB_GT_FUNC(gt_SetMode( usRows, _GetScreenWidth() ));
> }
> else if ( usRows > _GetScreenHeight() && usCols < _GetScreenWidth() )
> {
> HB_GT_FUNC(gt_SetMode( _GetScreenHeight(), usCols ));
> }
> ...
> Later somehow this disappears.
I do not think so. The above code use old static multi GT API which
I implemented only in xHarbour and it was never part of Harbour where
I created dynamic multi GT API committed at:
2006-02-04 17:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
which now it used by both projects.
In Harbour the problem exists from 2002 and it was introduced when
Paul committed my initial alternative GTWIN implementation at:
2002-10-19 16:50 UTC-0500 Paul Tucker
It means that you had to take above code from xHarbour.
I've just check that above fix were committed to xHarbour CVS by Paul at:
2006-07-01 18:35 UTC-0500 Paul Tucker
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
>I'm glad to announce that after a very heavy 16 months >of development, the final, stable version 2.0.0 is finally >released. Thanks to all team for this great release. Congratulations ! Toninho. __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 Key Features
Harbour is without any hacks in core code which introduce such limitation like 32/64? Please help do a good key feature list ispired by your knoledge 2009/12/23 Przemysław Czerpak : > On Wed, 23 Dec 2009, Massimo Belgrano wrote: > > Hi. > >> High-performance multiplatform compiler 32/64 -bit > > The best in Harbour is that is neither 32 nor 64 bit compiler > because we do not have any hacks in core code which introduce > such limitation :-) > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > > Probably nothing though sometimes is good to check the details in > > platform documentation. It's possible that in ieeefp.h some functionality > > is extended, i.e. some math functions from math.h can be replaced by > > C99 compatible macros which can operate on any floating point types. > so, if available, using these is desirable? It really depends what it exactly does on given platform. If it's not necessary at all then it's preferred to not include it at all to not confuse users and increase dependency list. > i'm asking because looking at current src/rtl/math.c, except for a few > specific cases, isinf() is used: > 334 # if defined( HB_OS_SUNOS ) > 335 else if( !finite( dResult ) ) > 336 # elif defined( HB_OS_OS2 ) > 337 else if( !isfinite( dResult ) ) > 338 # else > 339 else if( isinf( dResult ) ) > 340 # endif > > at the same time, looking at the solaris manuals for finite(), > isinf() and finite() here (won't have access to my sol box till next > year): > > http://docs.sun.com/app/docs/doc/819-2246/isinf-3m?l=Ja&a=view > http://docs.sun.com/app/docs/doc/819-2246/isfinite-3m?l=Ja&a=view > http://docs.sun.com/app/docs/doc/801-6680-03/6i11qck75?a=view > > it seems that the currently special-cased finite() for hb_os_sunos > specifically fits your above explanation less than as if it was to let > use isinf() as well. > i may very well be misunderstanding you, though.. isinf() and isfinite() are C99 extensions so they are not available if C99 features are not enabled. There is problem with non GCC unix builds - they do not use HB_MATH_ERRNO handler (I'll fix it in next commit) and it's the reason why current src/rtl/math.c. do not need ieeefp.h. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour 2.0.0: Released
Congrats and thank you very much for your great efforts !! Merry christmas ! Viktor Szakáts escribió en mensaje <9c8850b0-a71e-4271-a846-7d91b1b98...@syenar.hu>... Hi All, I'm glad to announce that after a very heavy 16 months of development, the final, stable version 2.0.0 is finally released. Thanks to everyone who took part of this huge work in any ways. I'd like to ask developers to create the binary builds, I will now start to create the 'unified' Windows release and .tgz, .bz2 source packages. They will be ready by tomorrow. Another remaining task is to make this announcement on various forums and update the web page and other places where needed. HOW TO GET -- From SVN: svn export https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/tags/har bour-2.0.0 From sf.net: http://sourceforge.net/projects/harbour-project/files/source/2.0.0/ RELEASE NOTES - Please check RELNOTES file, this contains mostly generic release notes plus a few 'unified' binary release specific ones, overall it's a good brief list of the things changes since beta3, and it includes previous beta release notes as well. You may also want to check doc/whatsnew.txt which has a more details, but partial list of some past changes since 1.0.1. DEVELOPER NOTES --- The new 2.0.x branch has been created here: http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/branches/h arbour-2.0/ Development goes onwards in trunk, but we should mark patches in ChangeLog which should be eventually merged to 2.0.x branch with '[TOMERGE 2.0]' (without quotes). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 Key Features
On Wed, 23 Dec 2009, Massimo Belgrano wrote: Hi. > High-performance multiplatform compiler 32/64 -bit The best in Harbour is that is neither 32 nor 64 bit compiler because we do not have any hacks in core code which introduce such limitation :-) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF bug tracker#2919327: watcom/dos RDD problem
On Wed, 23 Dec 2009, Chen Kedem wrote: Hi, > A user reported the following on the SF bug tracker: > http://sourceforge.net/tracker/?func=detail&atid=100681&aid=2919327&group_id=681 > I don't know which Harbour version he is using or the type of problem. > Maybe it is a missing SHARE support in that dos environment > (need to run share.exe?) [...] >> Multptform Make procedure in Vista >> HBMK2 test.prg -plat=dos -comp=watcom >> >> Program works in windows dos comand >> but not work in FreeDOS, DOSBOX. >> Only work to first dbCloseArea() and go to blank screen at next dbSetindex() >> command. >> >> Can samone confirm this. I tested it using FreeDOS in DOSEMU and it works as expected just like in my Linux box. I do not think that such problems can be caused by Harbour. Maybe it's side effect caused by some TSRs installed in this FreeDOS session or by DOSBOX, i.e. when program is executed on virtual disks or shared volumes provided by DOSBOX. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
> Yes, you are right. Strange that no one reported it for such long time.
Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
...
/* Special case */
if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetMode( usRows, _GetScreenWidth() ));
}
else if ( usRows > _GetScreenHeight() && usCols < _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetMode( _GetScreenHeight(), usCols ));
}
...
Later somehow this disappears.
Best regards,
Saulius
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour 2.0 Key Features
Please Reply revising the list Sequent High-performance multiplatform compiler 32/64 -bit Full functional MultiThread with SYNC class method Compatible with xBase++ behavior, supports xBase++ concept of moving workareas between threads Support modern tecnologies: XML, FTP, TCP/IP, etc Native SQL, ODBC Support (rddsql.lib) Capabilty of access to in client server to server side (hbnetio..lib) The GUI based on QT 4.5 (hbqt.lib) Xbase Part Compatible Framework based on hbqt (hbxbp.lib) Make system by Command line (hbmk2.exe) -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Przemysław Czerpak wrote: hi, > > on platforms where available, what is the significance of including > > ieeefp.h, given that even without it, things seem to be doing OK? > > Probably nothing though sometimes is good to check the details in > platform documentation. It's possible that in ieeefp.h some functionality > is extended, i.e. some math functions from math.h can be replaced by > C99 compatible macros which can operate on any floating point types. so, if available, using these is desirable? i'm asking because looking at current src/rtl/math.c, except for a few specific cases, isinf() is used: 334 # if defined( HB_OS_SUNOS ) 335 else if( !finite( dResult ) ) 336 # elif defined( HB_OS_OS2 ) 337 else if( !isfinite( dResult ) ) 338 # else 339 else if( isinf( dResult ) ) 340 # endif at the same time, looking at the solaris manuals for finite(), isinf() and finite() here (won't have access to my sol box till next year): http://docs.sun.com/app/docs/doc/819-2246/isinf-3m?l=Ja&a=view http://docs.sun.com/app/docs/doc/819-2246/isfinite-3m?l=Ja&a=view http://docs.sun.com/app/docs/doc/801-6680-03/6i11qck75?a=view it seems that the currently special-cased finite() for hb_os_sunos specifically fits your above explanation less than as if it was to let use isinf() as well. i may very well be misunderstanding you, though.. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13386] trunk/harbour
suggest add [TOMERGE 2.0] 2009/12/23 : > Revision: 13386 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13386&view=rev > Author: druzus > Date: 2009-12-23 04:37:00 + (Wed, 23 Dec 2009) > > Log Message: > --- > 2009-12-23 05:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/gtwin/gtwin.c > ! applied a little bit modified the patch from Jacek Potempa for > setmode() in GTWIN - many thanks. Please test. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/src/rtl/gtwin/gtwin.c > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
