Re: [xHarbour-developers] NEW RELEASE
Hey Jose, Przemek, Przemek, thank you for your detailed text ;-) In Xailer, we use 4 scopes: PUBLISHED, PUBLIC (EXPORTED), PROTECTED and > PRIVATE (HIDDEN). Recently, when migrating Xailer to Harbour, we had to > make a trick to support PUBLISHED scope, since it's not present in > Harbour, but of course, I'd like to drop that hack if it were natively > available ;-) > > I don't know how VXH works, but I think it should be very like this. > Yes, VXH uses very simular approach. Patrick -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
Przezmek, sorry for jumping here, but I belive I have one thing to say about this: > why xHarbour > has PUBLISHED scope. Looks that it's the same as EXPORT + persistent > flag or at least it duplicates such functionality but with separate > set of functions (also duplicated). PUBLISHED scope only means when using an IDE (like Xailer or VXH), and it means that a PROPERTY will be shown in an object inspector. Almost PUBLISHED properties are also PERSISTENT, but not always. A very few times, you need to show a property in the object inspector, but not to be saved or serialized, but only for other purpose. That's why PUBLISHED is a separated scope. In Xailer, we use 4 scopes: PUBLISHED, PUBLIC (EXPORTED), PROTECTED and PRIVATE (HIDDEN). Recently, when migrating Xailer to Harbour, we had to make a trick to support PUBLISHED scope, since it's not present in Harbour, but of course, I'd like to drop that hack if it were natively available ;-) I don't know how VXH works, but I think it should be very like this. BTW, I'll ve very happy if xHarbour reborn from its ashes, like the Phoenix ;-) Regards, Jose F. Gimenez http://www.xailer.com http://www.xailer.info -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
On Mon, 28 Jan 2013, Ron Pinkas wrote: Hi, Sorry for late respone. > >Please only remember that I was not alone in Harbour modifications in > >last years. Viktor made really great job in general code and used types > >cleanup. Mindaugas added important extensions to compiler and HVM/RTL > >code, Pritapl is extensively working on set of addons like HBIDE, HBQT, > >HBXBPP. Also many other people worked on Harbour. > Thanks for your modesty, but I am convinced that none of this would > ever take place, unless you first revived Harbour, single handedly, > as you did, and even after, those IMO, are minor, and superficial > contributions, compared to your work. :-) Thanks for nice words but it's not really true. I think that people using HBMK2 found Viktor modifications as the most important ones because they allow him to easy move to Harbour and without any doubts such basic functionality is the most important for them so for sure it was extremely important for the whole project. Anyhow I'm most interested in the future of both projects so lets leave this discussion. I feel that I can hurt someone continuing it, i.e it was not my intention to discard Andi work. I only wanted to point that some not working ports may create false imaginations about real functionality of original code and competitions of its authors. I hope that Andi seriously rethink his decision because I'm finding him as the very important person in the future modifications. > >In Harobur there is text filewhere I tried to discribe main differences > >between both projects: > >http://http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/trunk/harbour/doc/xhb-diff.txt?view=log > >This may show you what should be done. I'll try to update this file > >and add some information about other differences. > >As you can seen not too much. I think that in less then month all > >modifications can be finished. > Actually this is not shocking for me, and I was debating it my self. > I am not sure what would be easier, as it mostly depends on the > DRIVE of the specific individual[s] interested in caring this task. > Sadly, I am not in a position to volunteer for this Job, for many > personal reasons, so I can not suggest what would be easier. I trust > that the person willing to take on this Job, will have his > preference. The most important differences between both project are well known. Anyhow it's also something that it was not very popular in news list but it's very important for general language description in the future: small incompatibilities to Clipper and anomalies in implementation (also in Clipper) which where cleaned or at least documented in Harbour. We do not have to follow exactly some decisions anyhow it's much easier to operate on code where some problems are resolved even to add again some extensions because programmer can see some interactions which were unknown for him in initial implementation. It also allows to eliminate duplicated code or code which is to danger and may break HVM code. Good example is OOP implementation. Many of __cls*() and __obj*() functions are repeated or very similar and I can onlu guess that no one exactly knows what each of them and what are the differences without careful xHarbour core code analyzing. Here the situation in Harbour is also bad. I left many functions just for backward compatibility but without any doubts some of them should be removed and rest replaced by new small set of functions with precisely defined actions. We should also agree some extensions so they can be implemented in all places. If we do not understand something in current implementation then we should remove it - I'm serious there are things which never worked or stop to work correctly long time ago and now it's not possible to guess why we have them and what they should exactly do. In last week I tried to document xHarbour HVM OOP functions and compare the to Harbour. Also with other functionality and it's really gray area. I.e. why xHarbour has PUBLISHED scope. Looks that it's the same as EXPORT + persistent flag or at least it duplicates such functionality but with separate set of functions (also duplicated). For serialization code new duplicated functions were added which tries to merge both functionality. To make it more complicated we have yet another serialization method by HBPRESISTENT class which is merged with other serializations with many side effects, etc. > >The windows only extensions and windows API wrappers have WIN_ and > >WAPI_ prefixes in Harbour and are part of HBWIN library. I think it's > >good solution because it well separates non portable MS-Windows only > >code what helps users to create portable programs and isolate local > >to system extensions. > Agree, except, I would in general prefer resolution by means of > namespace support. IMO, NameSpaces are critical feature of any > modern compiler, and long ago we should have implemented and > standardized namespace usage to have code lik
Re: [xHarbour-developers] NEW RELEASE
Hi Przemek, > I agree. Both projects benefited from each other. > A lot of code was borrowed from Harbour to xHarbour and from xHarbour to > Harbour after the fork. Also ideas were shared even if the implementations > were completely different. :-) > I can try to help you in some spare time but recently I'm really busy > due my business jobs and so called "spare time" is something really rare > in my life :( > Please only remember that I was not alone in Harbour modifications in > last years. Viktor made really great job in general code and used types > cleanup. Mindaugas added important extensions to compiler and HVM/RTL > code, Pritapl is extensively working on set of addons like HBIDE, HBQT, > HBXBPP. Also many other people worked on Harbour. Thanks for your modesty, but I am convinced that none of this would ever take place, unless you first revived Harbour, single handedly, as you did, and even after, those IMO, are minor, and superficial contributions, compared to your work. :-) > If you think about real milestone in xHarbour developing then I would like > to say sth what may be a shock for you but I strongly suggest to seriously > rethink it before you answer. > Updating current xHarbour code will be time consuming process which in > practice would mean that Harbour code is copied to xHarbour and then > adopted. Many problems and bugs can appear even due to stupid typos. > So I suggest you to create new branch and copy whole current Harbour code > just as is. Then working on this branch add or enable xHarbour extensions > you think are really usable. Some of them you can be added as > modifications > in core code some others in separate libraries. As you can see most of > xHarbour extensions were replicated in Harbour inside XHB library so it > should not be hard job. > If you want we can discuss each of them before commit and I'll try to > tell you how it can be implemented and how it may interact with some > other code or future extensions. > This should help to sync code between both projects what can help in > the future in code exchanging, i.e. 3-rd party projects can work with > both Harbour and xHarbour without or with minimal modifications. > In Harobur there is text filewhere I tried to discribe main differences > between both projects: > http://http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/trunk/harbour/doc/xhb-diff.txt?view=log > This may show you what should be done. I'll try to update this file > and add some information about other differences. > As you can seen not too much. I think that in less then month all > modifications can be finished. Actually this is not shocking for me, and I was debating it my self. I am not sure what would be easier, as it mostly depends on the DRIVE of the specific individual[s] interested in caring this task. Sadly, I am not in a position to volunteer for this Job, for many personal reasons, so I can not suggest what would be easier. I trust that the person willing to take on this Job, will have his preference. > The main problem I can see are some classes like TBROWSE, TGET and > TIP library. The RTL TBROWSE and TGET classes in Harbour are much > more compatible with Clipper then xHarbour ones. It greatly helps > Clipper users but may create some problems for xHarbour users who > used some specific to xHarbour only behavior. Probably it will be > necessary to keep the previous implementation in separated library, > i.e. as TBROWSEOLD. The TIP library is sth what I do not want to > comment - I'm not familiar with this code. I have no idea how it's > compatible with Harbour. Agree. > The windows only extensions and windows API wrappers have WIN_ and > WAPI_ prefixes in Harbour and are part of HBWIN library. I think it's > good solution because it well separates non portable MS-Windows only > code what helps users to create portable programs and isolate local > to system extensions. Agree, except, I would in general prefer resolution by means of namespace support. IMO, NameSpaces are critical feature of any modern compiler, and long ago we should have implemented and standardized namespace usage to have code like this: USING NAMESPACE Clipper To force usage of STRICT Clipper compatible RTL Functions, vs. USING NAMESPACE Harbour To prefer EXTENDED Clipper RTL. or of course manual overrriding: Clipper.SubStr(...) vs. Harbour.SubStr(), etc. As well as: USING NAMESPACE Windows I hope you agree that it is more flexible, and elegant, then using prefixes. > xHarbour support directly windows printers in SET PRINTER TO command. > Harbour doesn't so it have to be added. I would suggest to make it > using replaceable FILE IO API so it won't be necessary to introduce > platform oriented code to HVM. It also add possibilities to register > other printing systems, i.e. for terminal server programs. Agree. > The namespace support is sth what you will have to make yourselves. > I'm not familiar with this c
Re: [xHarbour-developers] NEW RELEASE
Thank you Przemek! ;-) On Wed, Jan 23, 2013 at 2:43 AM, Przemyslaw Czerpak wrote: > On Mon, 21 Jan 2013, Przemyslaw Czerpak wrote: > > Hi, > > > The real problem can appear at runtime and is caused by binary > > compatibility with older code. > > HB_SERIALIZE() gives incompatible results. It means that > > HB_DESERIALIZE() from Harbour cannot decode data encoded by > > current xHarbour HB_SERIALIZE(). > > HB_SERIALIZE() is used by SQLRD so this problem is not such trivial > > because it may block migrating to new xHarbour version. > > Probably this can be resolved adding support for signatures used > > by xHarbour in serialization code. I haven't though about it > > before. I'll look at it closer and if it's possible I'll commit > > such patch to Harbour. > > I've just committed it: > > 2013-01-21 16:36 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl) > * harbour/src/rtl/itemseri.c > + added support for deserialization xHarbour HB_SERIALIZE() output. > All types except codeblocks are supported. I haven't added support > for xHarbour serialized data with cyclic references. If it will be > really necessary then I can implement it. > I also added workaround for bug in xHarbour serialization code so > now Harbour correctly decodes data with LONGLONG numbers though > xHarbour cannot correctly decode its own stream. > Now Harbour can deserialize xHarbour data encoded by HB_SERIALIZE() > and stored somewhere. It can be important in migration process, i.e. > SQLRDD uses HB_SERIALIZE() to encode data in memos so now SQLRDD > port for Harbour should read old tables and decode xHarbour items > correctly. The same is for any other tool which saved HB_SERIALIZE() > output in xHarbour. > > best regards, > Przemek > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > -- Patrick -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
On Mon, 21 Jan 2013, Przemyslaw Czerpak wrote: Hi, > The real problem can appear at runtime and is caused by binary > compatibility with older code. > HB_SERIALIZE() gives incompatible results. It means that > HB_DESERIALIZE() from Harbour cannot decode data encoded by > current xHarbour HB_SERIALIZE(). > HB_SERIALIZE() is used by SQLRD so this problem is not such trivial > because it may block migrating to new xHarbour version. > Probably this can be resolved adding support for signatures used > by xHarbour in serialization code. I haven't though about it > before. I'll look at it closer and if it's possible I'll commit > such patch to Harbour. I've just committed it: 2013-01-21 16:36 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl) * harbour/src/rtl/itemseri.c + added support for deserialization xHarbour HB_SERIALIZE() output. All types except codeblocks are supported. I haven't added support for xHarbour serialized data with cyclic references. If it will be really necessary then I can implement it. I also added workaround for bug in xHarbour serialization code so now Harbour correctly decodes data with LONGLONG numbers though xHarbour cannot correctly decode its own stream. Now Harbour can deserialize xHarbour data encoded by HB_SERIALIZE() and stored somewhere. It can be important in migration process, i.e. SQLRDD uses HB_SERIALIZE() to encode data in memos so now SQLRDD port for Harbour should read old tables and decode xHarbour items correctly. The same is for any other tool which saved HB_SERIALIZE() output in xHarbour. best regards, Przemek -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
On Sun, 20 Jan 2013, Ron Pinkas wrote: Hi, > I fully agree with Przemek, that we can NOT aford to drop support for Linux. > There are too many reasons to count, and Przmek did mention most of them. > I would only add, that many prospective open source contributors are Linux > users. > > As to the other obsevations and comments of Przemek, I must sadly agree. > It is time for a serious cleanup of our code base, and a serious commitment > to avoid localized hiding of Compiler warnings. > > Finally, I would like to personally invite Przemek, to help us. I sincerely > believe that you, Przemek, understand the important role of xHarbour in the > development of Harbour, and I hope that you do recognize that the difference > in spirit, between the 2 projects is still very important. While at THIS > point in time, we are clearly behind, in terms of stability, performance, > and code quality, we still pionereed many innovations, and for many years > it was Harbour, that was dormant, and clearly behind. I hope you agree that > Harbour would not be what it is today, without xHarbour. I agree. Both projects benefited from each other. A lot of code was borrowed from Harbour to xHarbour and from xHarbour to Harbour after the fork. Also ideas were shared even if the implementations were completely different. > Przemek, since you personally have revived Harbour, practically > single-handedly, and you are intimately familiar with all the issues > that you already fixed, and rewrote, for Harbour, I would like to > wholeheartedly invite you, to help us, so that our creative differences > may once again bring new life to both projects. I can try to help you in some spare time but recently I'm really busy due my business jobs and so called "spare time" is something really rare in my life :( Please only remember that I was not alone in Harbour modifications in last years. Viktor made really great job in general code and used types cleanup. Mindaugas added important extensions to compiler and HVM/RTL code, Pritapl is extensively working on set of addons like HBIDE, HBQT, HBXBPP. Also many other people worked on Harbour. If you think about real milestone in xHarbour developing then I would like to say sth what may be a shock for you but I strongly suggest to seriously rethink it before you answer. Updating current xHarbour code will be time consuming process which in practice would mean that Harbour code is copied to xHarbour and then adopted. Many problems and bugs can appear even due to stupid typos. So I suggest you to create new branch and copy whole current Harbour code just as is. Then working on this branch add or enable xHarbour extensions you think are really usable. Some of them you can be added as modifications in core code some others in separate libraries. As you can see most of xHarbour extensions were replicated in Harbour inside XHB library so it should not be hard job. If you want we can discuss each of them before commit and I'll try to tell you how it can be implemented and how it may interact with some other code or future extensions. This should help to sync code between both projects what can help in the future in code exchanging, i.e. 3-rd party projects can work with both Harbour and xHarbour without or with minimal modifications. In Harobur there is text filewhere I tried to discribe main differences between both projects: http://http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/trunk/harbour/doc/xhb-diff.txt?view=log This may show you what should be done. I'll try to update this file and add some information about other differences. As you can seen not too much. I think that in less then month all modifications can be finished. The main problem I can see are some classes like TBROWSE, TGET and TIP library. The RTL TBROWSE and TGET classes in Harbour are much more compatible with Clipper then xHarbour ones. It greatly helps Clipper users but may create some problems for xHarbour users who used some specific to xHarbour only behavior. Probably it will be necessary to keep the previous implementation in separated library, i.e. as TBROWSEOLD. The TIP library is sth what I do not want to comment - I'm not familiar with this code. I have no idea how it's compatible with Harbour. The windows only extensions and windows API wrappers have WIN_ and WAPI_ prefixes in Harbour and are part of HBWIN library. I think it's good solution because it well separates non portable MS-Windows only code what helps users to create portable programs and isolate local to system extensions. xHarbour support directly windows printers in SET PRINTER TO command. Harbour doesn't so it have to be added. I would suggest to make it using replaceable FILE IO API so it won't be necessary to introduce platform oriented code to HVM. It also add possibilities to register other printing systems, i.e. for terminal server programs. The namespace support is sth what you will have to make yourselves. I'm not familiar with t
Re: [xHarbour-developers] NEW RELEASE
Em 20/01/2013 16:16, Ron Pinkas escreveu: > I fully agree with Przemek, that we can NOT aford to drop support for Linux. > There are too many reasons to count, and Przmek did mention most of them. I > would only add, that many prospective open source contributors are Linux > users. And I fully agree with Przemek and Ron. Windows is the most used OS, but there are others OS's growing (iOS, Android, Blackberry OS, ...). Some of them use Linux or similar OS. xHarbour must be a multiplataform tool. Regards, Marcos Gambeta -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
I fully agree with Przemek, that we can NOT aford to drop support for Linux. There are too many reasons to count, and Przmek did mention most of them. I would only add, that many prospective open source contributors are Linux users. As to the other obsevations and comments of Przemek, I must sadly agree. It is time for a serious cleanup of our code base, and a serious commitment to avoid localized hiding of Compiler warnings. Finally, I would like to personally invite Przemek, to help us. I sincerely believe that you, Przemek, understand the important role of xHarbour in the development of Harbour, and I hope that you do recognize that the difference in spirit, between the 2 projects is still very important. While at THIS point in time, we are clearly behind, in terms of stability, performance, and code quality, we still pionereed many innovations, and for many years it was Harbour, that was dormant, and clearly behind. I hope you agree that Harbour would not be what it is today, without xHarbour. Przemek, since you personally have revived Harbour, practically single-handedly, and you are intimately familiar with all the issues that you already fixed, and rewrote, for Harbour, I would like to wholeheartedly invite you, to help us, so that our creative differences may once again bring new life to both projects. BTW, again I would like to offer my sincerest apology, for having offended you, many years ago. I give you my word again, that I sincerely did not mean to be offensive, it was a simple misunderstanding due to a language difference. Now that I have lived for some 7 years, in a non English speaking culture, I better understand why you got so offended from the term "creature", but I gurantee you that in English, the the phrase, "what a funny creature, you are" is not used in that offensive context, rather, it is a fairly common, synical phrase. Eitherway, please accept my sincere apology. Ron On Jan 19, 2013, at 2:24 PM, Przemyslaw Czerpak wrote: > On Sat, 19 Jan 2013, Andi Jahja wrote: > > Hi Andi, > >> Seems no comment at all, particularly from what ppl call *nix users. BTW, >> does anyone here have a thought about it? > > I think that xHarbour lost most of them. > >> FYI, we stuck releasing versions officially because there's no-one >> interested in building that *nix stuffs. > > In the last year you made a lot to break *nix builds. Now after your > recent modifications you break them again so maybe few really advanced > users who are patient enough to fix your modifications can create *nix > xHarbour builds - others migrated to Harbour. > >> I would suggest to leave *nix if there's no longer interest in it. >> Usability is much more important than what is called portability. >> Furthermore, I'd swear that 99.99% of xHarbour users are on Windows OS, >> so the rest 0.01% can be disregarded (read: not worthy) > > Bad idea, it will only help to hide bugs which appeared recently in > xHarbour. Some of them can be exploited also on MS-Windows, i.e. custom > memcpy() broke all 64bit builds. Also WIN 64 ones though here xHarbour > applications GPFs when user address space reach 2^32. On serious platforms > such addresses are default at application startup just to catch such buggy > code ASAP and fix it. To be more funny advanced compilers make such > optimizations much better with optimized autoinlined code so it also > reduces the speed. > > There are other serious development reasons to keep support for *nixes, > i.e. there is no tool like VALGRIND for MS-Windows so you won't be able > to catch some serious problems, i.e. I see that in last weeks you started > to fix memory leaks in xHarbour compiler code. But you haven't discovered > yet that it's not possible to make it well in classic way due to bison > behavior. Bison authors also saw this problem so they introduced > expression destructors which should help in such process. Anyhow these > functionality still does not work as expected in some cases what can be > well seen in valgrind logs and you want to drop support for platforms > were such important tool can be used. In practice it means that there is > very small chance that you will ever reach sufficient results in compiler > memory leak fixes. > BTW I've seen your message on xHarbour user list that such memory leaks are > only in compiler. It's not true. Memory leaks which appear due to wrong > syntax are usually caused by unreleased bison grammar expressions so they > exist also in macrocompiler and are runtime memory leaks which can be > exploited in all programs which macrocompile user expressions. > To resolve this problem in Harbour few years ago I created garbage collector > for expressions. To not hide other memory leaks in compiler mode it's > activated on syntax errors only. This job is still before you and you want > to drop support for platform were important helper tools can be used. > Finally it means that you want to drop support for platforms
Re: [xHarbour-developers] NEW RELEASE
On Sat, 19 Jan 2013, Andi Jahja wrote: Hi Andi, > Seems no comment at all, particularly from what ppl call *nix users. BTW, > does anyone here have a thought about it? I think that xHarbour lost most of them. > FYI, we stuck releasing versions officially because there's no-one > interested in building that *nix stuffs. In the last year you made a lot to break *nix builds. Now after your recent modifications you break them again so maybe few really advanced users who are patient enough to fix your modifications can create *nix xHarbour builds - others migrated to Harbour. > I would suggest to leave *nix if there's no longer interest in it. > Usability is much more important than what is called portability. > Furthermore, I'd swear that 99.99% of xHarbour users are on Windows OS, > so the rest 0.01% can be disregarded (read: not worthy) Bad idea, it will only help to hide bugs which appeared recently in xHarbour. Some of them can be exploited also on MS-Windows, i.e. custom memcpy() broke all 64bit builds. Also WIN 64 ones though here xHarbour applications GPFs when user address space reach 2^32. On serious platforms such addresses are default at application startup just to catch such buggy code ASAP and fix it. To be more funny advanced compilers make such optimizations much better with optimized autoinlined code so it also reduces the speed. There are other serious development reasons to keep support for *nixes, i.e. there is no tool like VALGRIND for MS-Windows so you won't be able to catch some serious problems, i.e. I see that in last weeks you started to fix memory leaks in xHarbour compiler code. But you haven't discovered yet that it's not possible to make it well in classic way due to bison behavior. Bison authors also saw this problem so they introduced expression destructors which should help in such process. Anyhow these functionality still does not work as expected in some cases what can be well seen in valgrind logs and you want to drop support for platforms were such important tool can be used. In practice it means that there is very small chance that you will ever reach sufficient results in compiler memory leak fixes. BTW I've seen your message on xHarbour user list that such memory leaks are only in compiler. It's not true. Memory leaks which appear due to wrong syntax are usually caused by unreleased bison grammar expressions so they exist also in macrocompiler and are runtime memory leaks which can be exploited in all programs which macrocompile user expressions. To resolve this problem in Harbour few years ago I created garbage collector for expressions. To not hide other memory leaks in compiler mode it's activated on syntax errors only. This job is still before you and you want to drop support for platform were important helper tools can be used. Finally it means that you want to drop support for platforms which begins to be the most popular one on the all world used in most "smart" devices so it will be very important signal about xHarbour future for users. > We should not stop because of it. IMHO before new release you should fix some critical problems introduced in last months. Porting some things from Harbour you made few typos which later have unpredictable results, i.e. typo in really small patch which fixed very slow source code browsing in debugger caused that Luiz (who wrongly check that the problem was fixed in Harbour) used in xHarbour debugger RTL classes so now it's not possible to debug them or even use debugger by users who overloaded some part of RTL classes used in debugger. Your "improvements" in macro compiler speed caused that now maximum macrocompiler string size is 8191 bytes in xHarbour. Before your modifications it was ~32768 and longer strings could cause unpredictible results (memory corruption) due to bugs in HVM part of macro compiler code. In Harbour all such bugs have been fixed long time ago and it's guarantied that Harbour can compile any macro expression up to 16MB and if longer expressions cannot be compiled then it's guarantied that clean RT error is generated without any hidden memory corruption. And to compare Harbour macro compiler is about 3 times faster then xHarbour ones and is fully reentrant safe so it does not need and MT locks. The whole MT mode in xHarbour is sth what should be rewritten from scratch. Now number of MT applications in [x]Harbour community is growing up and they have to be compiled by Harbour because xHarbour MT mode is unusable for code which needs stability and some more advanced MT functionality. Good example is LETO server which cannot be compiled by xHarbour due to critical xHarbour bugs, missing functionality and wrong MT model. There are also other problems introduced recently like wrong casting which pacified warnings when in fact they were bugs exploited in 64bit mode. Now it's horrible job to clean xHarbour code and make it fully functional for Win64 bit mode - you hide the most helpful thing: compiler war
Re: [xHarbour-developers] NEW RELEASE
Hey Andi, I know a few Linux users, but not that many. Maybe we should ask on the NG to see how many Linux users we have? I only use Windows ;-) Patrick On Sat, Jan 19, 2013 at 5:09 PM, Andi Jahja wrote: > Seems no comment at all, particularly from what ppl call *nix users. BTW, > does anyone here have a thought about it? > > FYI, we stuck releasing versions officially because there's no-one > interested in building that *nix stuffs. > > I would suggest to leave *nix if there's no longer interest in it. > Usability is much more important than what is called portability. > Furthermore, I'd swear that 99.99% of xHarbour users are on Windows OS, > so the rest 0.01% can be disregarded (read: not worthy) > > We should not stop because of it. > > Andi > > > On Fri, 18 Jan 2013 19:47:51 -0430 > Ron Pinkas wrote: > > > I just subscribed Saulius, so he should now accecable here. :-) > > > > Saulius, please make sure to use your email client "Reply to All" o that > it will be psted to the list. > > > > Sent from my iPad > > > > On Jan 17, 2013, at 9:11 PM, Andi Jahja wrote: > > > > > On Thu, 17 Jan 2013 06:43:36 -0800 > > > Ron Pinkas wrote: > > > > > >> Hi All, > > >> > > >> First happy new year to every one, and thanks for your kind > contributions in > > >> 2012.. :-) > > > > > > Happy New Year too.. > > > > > > > > >> Welcome aboard to our new developer, Saulius. Saulius has contributed > few > > >> important fixes to memory leaks in the compiler, and it is great to > welcome > > >> someone that an contribute to the compiler code. > > > > > > I hope he is here already, welcome aboard Saulius, again... > > > > > >> Finally, I believe this may be a good point to start preparing for a > new > > >> stable release. I would like to invite anyone actively working on some > > >> development to share their plan, so we may agree on some time table > for our > > >> next BUG FREEZE. > > > > > > Yes, I think so, I'll make some code clean ups, removing crappy codes, > > > particularly from contribs... > > > > > > > > >> Also, it would be great if we could start compiling text describing > changes > > >> since last release. > > > > > > Yes, please... I'm sorry I could not help in this field, as usual -> I > > > am a very lazy document writter :-) > > > > > > Andi > > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122912 > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > -- Patrick -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
On Sat, 19 Jan 2013 17:29:31 +0100 Patrick Mast wrote: > Hey Andi, > > I know a few Linux users, but not that many. Maybe we should ask on the NG > to see how many Linux users we have? > > I only use Windows ;-) Same here. I only use Windows. No time to experiment with uncertain/lower grade OS. :-)) Andi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
Seems no comment at all, particularly from what ppl call *nix users. BTW, does anyone here have a thought about it? FYI, we stuck releasing versions officially because there's no-one interested in building that *nix stuffs. I would suggest to leave *nix if there's no longer interest in it. Usability is much more important than what is called portability. Furthermore, I'd swear that 99.99% of xHarbour users are on Windows OS, so the rest 0.01% can be disregarded (read: not worthy) We should not stop because of it. Andi On Fri, 18 Jan 2013 19:47:51 -0430 Ron Pinkas wrote: > I just subscribed Saulius, so he should now accecable here. :-) > > Saulius, please make sure to use your email client "Reply to All" o that it > will be psted to the list. > > Sent from my iPad > > On Jan 17, 2013, at 9:11 PM, Andi Jahja wrote: > > > On Thu, 17 Jan 2013 06:43:36 -0800 > > Ron Pinkas wrote: > > > >> Hi All, > >> > >> First happy new year to every one, and thanks for your kind contributions > >> in > >> 2012.. :-) > > > > Happy New Year too.. > > > > > >> Welcome aboard to our new developer, Saulius. Saulius has contributed few > >> important fixes to memory leaks in the compiler, and it is great to > >> welcome > >> someone that an contribute to the compiler code. > > > > I hope he is here already, welcome aboard Saulius, again... > > > >> Finally, I believe this may be a good point to start preparing for a new > >> stable release. I would like to invite anyone actively working on some > >> development to share their plan, so we may agree on some time table for > >> our > >> next BUG FREEZE. > > > > Yes, I think so, I'll make some code clean ups, removing crappy codes, > > particularly from contribs... > > > > > >> Also, it would be great if we could start compiling text describing > >> changes > >> since last release. > > > > Yes, please... I'm sorry I could not help in this field, as usual -> I > > am a very lazy document writter :-) > > > > Andi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
I just subscribed Saulius, so he should now accecable here. :-) Saulius, please make sure to use your email client "Reply to All" o that it will be psted to the list. Sent from my iPad On Jan 17, 2013, at 9:11 PM, Andi Jahja wrote: > On Thu, 17 Jan 2013 06:43:36 -0800 > Ron Pinkas wrote: > >> Hi All, >> >> First happy new year to every one, and thanks for your kind contributions in >> 2012.. :-) > > Happy New Year too.. > > >> Welcome aboard to our new developer, Saulius. Saulius has contributed few >> important fixes to memory leaks in the compiler, and it is great to welcome >> someone that an contribute to the compiler code. > > I hope he is here already, welcome aboard Saulius, again... > >> Finally, I believe this may be a good point to start preparing for a new >> stable release. I would like to invite anyone actively working on some >> development to share their plan, so we may agree on some time table for our >> next BUG FREEZE. > > Yes, I think so, I'll make some code clean ups, removing crappy codes, > particularly from contribs... > > >> Also, it would be great if we could start compiling text describing changes >> since last release. > > Yes, please... I'm sorry I could not help in this field, as usual -> I > am a very lazy document writter :-) > > Andi > > > -- > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] NEW RELEASE
On Thu, 17 Jan 2013 06:43:36 -0800 Ron Pinkas wrote: > Hi All, > > First happy new year to every one, and thanks for your kind contributions in > 2012.. :-) Happy New Year too.. > Welcome aboard to our new developer, Saulius. Saulius has contributed few > important fixes to memory leaks in the compiler, and it is great to welcome > someone that an contribute to the compiler code. I hope he is here already, welcome aboard Saulius, again... > Finally, I believe this may be a good point to start preparing for a new > stable release. I would like to invite anyone actively working on some > development to share their plan, so we may agree on some time table for our > next BUG FREEZE. Yes, I think so, I'll make some code clean ups, removing crappy codes, particularly from contribs... > Also, it would be great if we could start compiling text describing changes > since last release. Yes, please... I'm sorry I could not help in this field, as usual -> I am a very lazy document writter :-) Andi -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] NEW RELEASE
Hi All, First happy new year to every one, and thanks for your kind contributions in 2012.. :-) . Welcome aboard to our new developer, Saulius. Saulius has contributed few important fixes to memory leaks in the compiler, and it is great to welcome someone that an contribute to the compiler code. Finally, I believe this may be a good point to start preparing for a new stable release. I would like to invite anyone actively working on some development to share their plan, so we may agree on some time table for our next BUG FREEZE. Also, it would be great if we could start compiling text describing changes since last release. Thanks again, Ron -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
No se si no entiendes, pero podria explicarte en castellano. hay 2 branchs en xharbour la marcada 1.2.0 que se usa para finalizar dicha version y la main para poder seguir trabajando, usa la que necesites en cada momento. Saludos Miguel Angel Marchuet Not if you do not understand, but could explain in Castilian. there are 2 branchs in xHarbour the 1.2.0 marked that can be used to complete this version and the main power to continue working, you need to use every moment. Greetings Miguel Angel Marchuet Eduardo Fernandes escribió: > Yes, if up to 1.2.0 tag (where 1.1.0 reached) is considerated as stable code > for release. I think the 1.2.0 branch is unstable. > > Eduardo > > > --- Em qua, 5/11/08, Patrick Mast, xHarbour. <[EMAIL PROTECTED]> escreveu: > >> De: Patrick Mast, xHarbour. <[EMAIL PROTECTED]> >> Assunto: Re: [xHarbour-developers] New Release >> Para: xharbour-developers@lists.sourceforge.net >> Data: Quarta-feira, 5 de Novembro de 2008, 0:35 >> Eduardo, >> >>> Can you untag the 1.2.0 for me commit last tbrowse.prg >> and restore hbver.h >>> from 1.1.0 version before release ? >> >> Meaning you committed your changes to the head branche and >> you want it also >> in branche 1-2-0? >> >> Patrick >> - >> This SF.Net email is sponsored by the Moblin Your Move >> Developer's challenge >> Build the coolest Linux based applications with Moblin SDK >> & win great prizes >> Grand prize is a trip for two to an Open Source event >> anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/___ >> xHarbour-developers mailing list >> xHarbour-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > > Novos endereços, o Yahoo! que você conhece. Crie um email novo com a > sua cara @ymail.com ou @rocketmail.com. > http://br.new.mail.yahoo.com/addresses > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > __ Información de ESET NOD32 Antivirus, versión de la base de firmas > de virus 3584 (20081105) __ > > ESET NOD32 Antivirus ha comprobado este mensaje. > http://www.eset.com > > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
Yes, if up to 1.2.0 tag (where 1.1.0 reached) is considerated as stable code for release. I think the 1.2.0 branch is unstable. Eduardo --- Em qua, 5/11/08, Patrick Mast, xHarbour. <[EMAIL PROTECTED]> escreveu: > De: Patrick Mast, xHarbour. <[EMAIL PROTECTED]> > Assunto: Re: [xHarbour-developers] New Release > Para: xharbour-developers@lists.sourceforge.net > Data: Quarta-feira, 5 de Novembro de 2008, 0:35 > Eduardo, > > > Can you untag the 1.2.0 for me commit last tbrowse.prg > and restore hbver.h > > from 1.1.0 version before release ? > > > Meaning you committed your changes to the head branche and > you want it also > in branche 1-2-0? > > Patrick > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
Eduardo, > Can you untag the 1.2.0 for me commit last tbrowse.prg and restore hbver.h > from 1.1.0 version before release ? Meaning you committed your changes to the head branche and you want it also in branche 1-2-0? Patrick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
Patrick, Can you untag the 1.2.0 for me commit last tbrowse.prg and restore hbver.h from 1.1.0 version before release ? regards, Eduardo --- Em seg, 3/11/08, Patrick Mast <[EMAIL PROTECTED]> escreveu: > De: Patrick Mast <[EMAIL PROTECTED]> > Assunto: [xHarbour-developers] New Release > Para: "xHarbour-Developers" > Data: Segunda-feira, 3 de Novembro de 2008, 12:44 > Hello, > Seems we have some confusion on the new 1.2.0 release > binaries. > > I have created a branch for xHarbour 1.2.0. This branch was > created from the > tagged CVS 1.2.0. This was just before Miguel's changes > done in VM. The > branche is called "branche-1-2-0" > > So, if we need to fix something for the 1.2.0 release, > please us the 1.2.0 > branch. > > This way we don't need a release freeze on current head > branch and people > can continue commit fixes and/or enhancements. > > If you have any questions, please don't hesitate to > ask. We need to get this > new 1.2.0 release out ASAP! > > Patrick > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
Peter Rees escribió: > Hi Ron, > > Ignore my previous reply > > I've discovered that with a recent change, the CFLAG define -DHB_NO_PROFILER > must be the same when creating user EXE from PRG source as it was when > HARBOUR.EXE was built. (see c:\xharbour\include\classes.h). > > Is it a good idea? if you read previous messages you can read that is in process of solution, please if you want to use MAIN CVS then don't use -DHB_NO_PROFILER by the moment. because we are removing unnecessary structure longs when is used -DHB_NO_PROFILER but is not finished yet. Best regards, Miguel Angel Marchuet - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
> Unless there are reports of problems with current CVS (I'm not aware of > any), I see no reason to complicate this issue. Are you or anyone else > aware of any show stopper in current CVS? I don't finish to upload changes to actual CVS. 1) I need to solve HB_NO_TRACE flag actually doesn't works 2) rdd at MT mode is not finished too, I'm talking with Walter to solve some important questions and finish SET WORKAREA [SHARED|PRIVATE] and initialize if needed some mutex. And possible clean unneeded mutex. 3) upload some utf8 functions. 4) add entries to hbtest, and upload some solutions that i've in test process. I think MAIN cvs is not stable yet, is better to use branch for this purposes Best regards, Miguel Angel Marchuet > > Otherwise, please let's start sending HBTEST and BUILD reports for all > environments, and let's proceed to releasing. > > Ron > > *From:* Patrick Mast <mailto:[EMAIL PROTECTED]> > *Sent:* Monday, November 03, 2008 10:14 AM > *To:* xHarbour-Developers > <mailto:xharbour-developers@lists.sourceforge.net> > *Subject:* [xHarbour-developers] New Release > > Hello, > > Seems we have some confusion on the new 1.2.0 release binaries. > > I have created a branch for xHarbour 1.2.0. <http://1.2.0.> This branch > was created from the tagged CVS 1.2.0. <http://1.2.0.> This was just > before Miguel's changes done in VM. The branche is called "branche-1-2-0" > > So, if we need to fix something for the 1.2.0 release, please us the > 1.2.0 branch. > > This way we don't need a release freeze on current head branch and > people can continue commit fixes and/or enhancements. > > If you have any questions, please don't hesitate to ask. We need to get > this new 1.2.0 release out ASAP! > > Patrick > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > > __ Información de ESET NOD32 Antivirus, versión de la base de > firmas de virus 3578 (20081103) __ > > ESET NOD32 Antivirus ha comprobado este mensaje. > http://www.eset.com > > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > __ Información de ESET NOD32 Antivirus, versión de la base de firmas > de virus 3578 (20081103) __ > > ESET NOD32 Antivirus ha comprobado este mensaje. > http://www.eset.com > > > > > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > > > __ Información de ESET NOD32 Antivirus, versión de la base de firmas > de virus 3578 (20081103) __ > > ESET NOD32 Antivirus ha comprobado este mensaje. > http://www.eset.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
Hi Ron, I have just done a complete new download of CVS, total clean build of our application and I get a GPF. Build parameters - CFLAGS=-DHB_NO_PROFILER -DHB_NO_TRACE -DHB_OPT_GUI -DHB_FM_STATISTIC_OFF -DHB_EXT_INKEY -DHARBOUR_MAX_RDD_ALIAS_LENGTH=63 -DHB_FM_WIN32_ALLOC -DHB_RDD_MAX_ALIAS_LEN=63 HARBOURFLAGS=/DHB_EXT_INKEY /D__WIN32__ If I change CFLAGS to remove -DHB_NO_PROFILER then no GPF So I suggest that no release is done with the current CVS until this problem is found. I don't use any 3rd party libs. Regards Peter Rees _ From: Ron Pinkas [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2008 11:53 AM To: Patrick Mast; xHarbour-Developers Subject: Re: [xHarbour-developers] New Release Patrick, Unless there are reports of problems with current CVS (I'm not aware of any), I see no reason to complicate this issue. Are you or anyone else aware of any show stopper in current CVS? Otherwise, please let's start sending HBTEST and BUILD reports for all environments, and let's proceed to releasing. Ron From: Patrick Mast <mailto:[EMAIL PROTECTED]> Sent: Monday, November 03, 2008 10:14 AM To: xHarbour-Developers <mailto:xharbour-developers@lists.sourceforge.net> Subject: [xHarbour-developers] New Release Hello, Seems we have some confusion on the new 1.2.0 release binaries. I have created a branch for xHarbour 1.2.0. This branch was created from the tagged CVS 1.2.0. This was just before Miguel's changes done in VM. The branche is called "branche-1-2-0" So, if we need to fix something for the 1.2.0 release, please us the 1.2.0 branch. This way we don't need a release freeze on current head branch and people can continue commit fixes and/or enhancements. If you have any questions, please don't hesitate to ask. We need to get this new 1.2.0 release out ASAP! Patrick _ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] New Release
Hi Ron, Ignore my previous reply I've discovered that with a recent change, the CFLAG define -DHB_NO_PROFILER must be the same when creating user EXE from PRG source as it was when HARBOUR.EXE was built. (see c:\xharbour\include\classes.h). Is it a good idea? Regards Peter - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release
Patrick, Unless there are reports of problems with current CVS (I'm not aware of any), I see no reason to complicate this issue. Are you or anyone else aware of any show stopper in current CVS? Otherwise, please let's start sending HBTEST and BUILD reports for all environments, and let's proceed to releasing. Ron From: Patrick Mast Sent: Monday, November 03, 2008 10:14 AM To: xHarbour-Developers Subject: [xHarbour-developers] New Release Hello, Seems we have some confusion on the new 1.2.0 release binaries. I have created a branch for xHarbour 1.2.0. This branch was created from the tagged CVS 1.2.0. This was just before Miguel's changes done in VM. The branche is called "branche-1-2-0" So, if we need to fix something for the 1.2.0 release, please us the 1.2.0 branch. This way we don't need a release freeze on current head branch and people can continue commit fixes and/or enhancements. If you have any questions, please don't hesitate to ask. We need to get this new 1.2.0 release out ASAP! Patrick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] New Release
Hello, Seems we have some confusion on the new 1.2.0 release binaries. I have created a branch for xHarbour 1.2.0. This branch was created from the tagged CVS 1.2.0. This was just before Miguel's changes done in VM. The branche is called "branche-1-2-0" So, if we need to fix something for the 1.2.0 release, please us the 1.2.0 branch. This way we don't need a release freeze on current head branch and people can continue commit fixes and/or enhancements. If you have any questions, please don't hesitate to ask. We need to get this new 1.2.0 release out ASAP! Patrick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Patrick I know one from Eduardo Fernandes due an problem on last dbedit.prg commit Regards Luiz - Original Message - From: Patrick Mast, xHarbour.com To: xHarbour-Developers Sent: Monday, August 18, 2008 6:55 AM Subject: Re: [xHarbour-developers] New release Hey guys, Do we have more pending commits? Paul, how close are you with finishing GT? Patrick On Sat, Aug 2, 2008 at 12:52 PM, Patrick Mast, xHarbour.com <[EMAIL PROTECTED]> wrote: Hey Guys, I'd like to call for a release freeze if there are no pending bug fixes. Paul, do you think you can finish GT for this release? Thanks! Patrick -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Hey guys, Do we have more pending commits? Paul, how close are you with finishing GT? Patrick On Sat, Aug 2, 2008 at 12:52 PM, Patrick Mast, xHarbour.com < [EMAIL PROTECTED]> wrote: > Hey Guys, > I'd like to call for a release freeze if there are no pending bug fixes. > > Paul, do you think you can finish GT for this release? > Thanks! > > Patrick > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Paul, > PMx> Now, don't wanne rush you but.. We are kinda waiting for you to get a > PMx> new release out. ;-) > PMx> Can you give me any time frame for your commit? > > Yes I know :-( I'll crank the rest out just as soon as I can. By the > weekend is the best I can do. Perfect! Thanks. Patrick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
PMx> Now, don't wanne rush you but.. We are kinda waiting for you to get a PMx> new release out. ;-) PMx> Can you give me any time frame for your commit? Yes I know :-( I'll crank the rest out just as soon as I can. By the weekend is the best I can do. Paul - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Paul, > PMx> Paul, do you think you can finish GT for this release? > PMx> Thanks! > > That is the plan... I've been studying how the gt works now, and trying to > understand what Prezmeks issue is with how maxrow/col worked before. One > of > us must be missing something, and I'm fairly sure it's not me. Ok, great! Now, don't wanne rush you but.. We are kinda waiting for you to get a new release out. ;-) Can you give me any time frame for your commit? Thanks! Patrick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Patrick, PMx> Paul, do you think you can finish GT for this release? PMx> Thanks! That is the plan... I've been studying how the gt works now, and trying to understand what Prezmeks issue is with how maxrow/col worked before. One of us must be missing something, and I'm fairly sure it's not me. Paul - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
I use this functions as normal, can you send me a reduced example that fails. Then i can help to you, I need to do some changes at kernel to eliminate some restrictions. about INET Best regards, Miguel Angel Marchuet bhays escribió: > Has anyone fully tested InetRecvAll() ? > > We have an unresolved problem with the Internet communication functions. > We've been unable to reduce it to a small sample, so I don't expect this to > stop finalizing a release. But it would be good to know if a lot of people > have > done a lot of testing of the changes from a few months back regarding > buffers. > > We have two programs, a server and a client, that talk to each other > ultimately using >nLength := InetRecv( ::Socket, @s_cRequest ) >nBytesRead := InetRecvAll( ::Socket, @s_cResponse, nLength ) > and >METHOD Send( cSend, nLen )INLINE InetSend( ::Socket, cSend, nLen ) >METHOD SendAll( cSend, nLen ) INLINE InetSendAll( ::Socket, cSend, nLen ) > > Initial custom "handshaking" using InetRecv() works fine to establish the > length of the real > buffer to transfer down from the server (current test is just 270 bytes). > But when the server sends it, the client fails on the first call to >InetRecvAll() > which just reports zero bytes read. > > This code was working great for years, the last build was with last > September's xHarbour. > We didn't need to touch until this past April when we found the problem, and > we've > gone in circles a couple of times trying to chase it. > > The real problem is that it is intermittent. Using the exact same > executables, if I start the server and test the client it may work. > If it does, it usually will work for even a dozen tests. Eventually it > fails. > If I restart the server, the client may fail the first time. When it does, > it usually fails consistently. > So behavior seems to be dependent upon random startup issues, who knows > what... > Perhaps it works if the server is started during on an even-numbered > second but not if the time is on and odd-numbered second. It's very weird, > and hard to debug. > > Does anyone have any ideas? > > TIA, > > -- > Brian Hays > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Patrick Mast, xHarbour.com > Sent: Saturday, August 02, 2008 3:52 AM > To: xHarbour-Developers > Subject: [xHarbour-developers] New release > > Hey Guys, > > I'd like to call for a release freeze if there are no pending bug fixes. > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > __ Información de NOD32, revisión 3303 (20080728) __ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Brian I use the inetrecvall function with out problems, but i dont call inetrecv regards Luiz - Original Message - From: "bhays" <[EMAIL PROTECTED]> To: "'xHarbour-Developers'" Sent: Saturday, August 02, 2008 7:57 PM Subject: Re: [xHarbour-developers] New release > Has anyone fully tested InetRecvAll() ? > > We have an unresolved problem with the Internet communication functions. > We've been unable to reduce it to a small sample, so I don't expect this > to > stop finalizing a release. But it would be good to know if a lot of > people > have > done a lot of testing of the changes from a few months back regarding > buffers. > > We have two programs, a server and a client, that talk to each other > ultimately using > nLength := InetRecv( ::Socket, @s_cRequest ) > nBytesRead := InetRecvAll( ::Socket, @s_cResponse, nLength ) > and > METHOD Send( cSend, nLen )INLINE InetSend( ::Socket, cSend, nLen ) > METHOD SendAll( cSend, nLen ) INLINE InetSendAll( ::Socket, cSend, > nLen ) > > Initial custom "handshaking" using InetRecv() works fine to establish the > length of the real > buffer to transfer down from the server (current test is just 270 bytes). > But when the server sends it, the client fails on the first call to > InetRecvAll() > which just reports zero bytes read. > > This code was working great for years, the last build was with last > September's xHarbour. > We didn't need to touch until this past April when we found the problem, > and > we've > gone in circles a couple of times trying to chase it. > > The real problem is that it is intermittent. Using the exact same > executables, if I start the server and test the client it may work. > If it does, it usually will work for even a dozen tests. Eventually it > fails. > If I restart the server, the client may fail the first time. When it does, > it usually fails consistently. > So behavior seems to be dependent upon random startup issues, who knows > what... > Perhaps it works if the server is started during on an even-numbered > second but not if the time is on and odd-numbered second. It's very > weird, > and hard to debug. > > Does anyone have any ideas? > > TIA, > > -- > Brian Hays > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Patrick Mast, xHarbour.com > Sent: Saturday, August 02, 2008 3:52 AM > To: xHarbour-Developers > Subject: [xHarbour-developers] New release > > Hey Guys, > > I'd like to call for a release freeze if there are no pending bug fixes. > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Has anyone fully tested InetRecvAll() ? We have an unresolved problem with the Internet communication functions. We've been unable to reduce it to a small sample, so I don't expect this to stop finalizing a release. But it would be good to know if a lot of people have done a lot of testing of the changes from a few months back regarding buffers. We have two programs, a server and a client, that talk to each other ultimately using nLength := InetRecv( ::Socket, @s_cRequest ) nBytesRead := InetRecvAll( ::Socket, @s_cResponse, nLength ) and METHOD Send( cSend, nLen )INLINE InetSend( ::Socket, cSend, nLen ) METHOD SendAll( cSend, nLen ) INLINE InetSendAll( ::Socket, cSend, nLen ) Initial custom "handshaking" using InetRecv() works fine to establish the length of the real buffer to transfer down from the server (current test is just 270 bytes). But when the server sends it, the client fails on the first call to InetRecvAll() which just reports zero bytes read. This code was working great for years, the last build was with last September's xHarbour. We didn't need to touch until this past April when we found the problem, and we've gone in circles a couple of times trying to chase it. The real problem is that it is intermittent. Using the exact same executables, if I start the server and test the client it may work. If it does, it usually will work for even a dozen tests. Eventually it fails. If I restart the server, the client may fail the first time. When it does, it usually fails consistently. So behavior seems to be dependent upon random startup issues, who knows what... Perhaps it works if the server is started during on an even-numbered second but not if the time is on and odd-numbered second. It's very weird, and hard to debug. Does anyone have any ideas? TIA, -- Brian Hays From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Mast, xHarbour.com Sent: Saturday, August 02, 2008 3:52 AM To: xHarbour-Developers Subject: [xHarbour-developers] New release Hey Guys, I'd like to call for a release freeze if there are no pending bug fixes. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] New release
Hey Guys, I'd like to call for a release freeze if there are no pending bug fixes. Paul, do you think you can finish GT for this release? Thanks! Patrick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Miguel, 1. I'm not witnessing any GPF trap with -W3. Please point me to an actual code which triggers such gpf. 2. The wrong warnings were due to minor typo, related to -W3 (strong typing) being disabled because it must be recoded from scratch. In the mean time IIRC -W2 is the highest functional warning level. IAE the typo should be fixed after: 2008-06-03 06:12 UTC-0430 Ron Pinkas Ron On Jun 3, 2008, at 2:07 AM, Miguel Angel Marchuet wrote: > Another problem for release: > > If you use -w3 easily GPF is produced > > and they are wrong warnings. for example says: > > at line 36 > > PROCEDURE Main( cAppArg ) > > says: > > prg\Senior.prg(234) Warning W0003 Variable: 'CAPPARG' declared but > not used in function: 'MAIN(36)' > > but is used at line 96 > > oApp:Init( cAppArg, 'SENLOCAL.INI', 'SENIOR.INI', PRG_EXENAME + > '.HLP' ) > > Best regards > Miguel Angel marchuet > > MAKE Version 5.2 Copyright (c) 1987, 2000 Borland > C:\CVS-Developers\xharbour\bin\harbour.exe -q0 -n -m -w3 -es2 -gc0 > -dTPV > -iinclude;c:\utl\fwh705\include;C:\CVS-Developers\xharbour\include - > dDESARROLLO -dBMFILTER prg\Senior.prg > -oobj32\develop\TPVPro\Senior.c > > prg\Senior.prg(234) Warning W0003 Variable: 'CAPPARG' declared but > not used in function: 'MAIN(36)' > > prg\Senior.prg(234) Warning W0003 Variable: 'OFONT' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'OBMP' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'ACFCHECK' declared > but not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'ACFCOPY' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'NITEM' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'CCLSID' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'CPROGID' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(234) Warning W0003 Variable: 'CSERVER' declared but > not used in function: 'MAIN(38)' > > prg\Senior.prg(263) Warning W0003 Variable: 'OBMP' declared but > not used in function: 'LVALIDWNDMAIN(234)' > > prg\Senior.prg(346) Warning W0003 Variable: 'NPOS' declared but > not used in function: 'SALIR$(286)' > > prg\Senior.prg(346) Warning W0003 Variable: 'CLOG' declared but > not used in function: 'SALIR$(286)' > > prg\Senior.prg(346) Warning W0003 Variable: 'HRES' declared but > not used in function: 'SALIR$(286)' > > prg\Senior.prg(360) Warning W0003 Variable: 'DISCO' declared but > not used in function: 'CINSTALACION(346)' > > prg\Senior.prg(360) Warning W0003 Variable: 'PROTSERIE' declared > but not used in function: 'CINSTALACION(346)' > > prg\Senior.prg(360) Warning W0003 Variable: 'OPCIONES' declared > but not used in function: 'CINSTALACION(346)' > > prg\Senior.prg(360) Warning W0003 Variable: 'CSERIE' declared but > not used in function: 'CINSTALACION(347)' > > prg\Senior.prg(360) Warning W0003 Variable: 'COPCIONES' declared > but not used in function: 'CINSTALACION(347)' > > prg\Senior.prg(360) Warning W0003 Variable: 'CCODIGO' declared but > not used in function: 'CINSTALACION(348)' > > C:\CVS-Developers\xharbour\include\hbexcept.ch(76) Warning W0003 > Variable: 'LINFO' declared but not used in function: > 'INITPROFILER(360)' > > C:\CVS-Developers\xharbour\include\hbexcept.ch(76) Warning W0003 > Variable: 'OPROFILE' declared but not used in function: > 'INITPROFILER(362)' > > prg\Senior.prg(521) Warning W0003 Variable: 'EXCEPTION' declared > but not used in function: 'GPFHANDLER(419)' > > prg\Senior.prg(521) Warning W0003 > ** error -1073741819 ** deleting obj32\develop\TPVPro\Senior.c > > > > > -- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Another problem for release: If you use -w3 easily GPF is produced and they are wrong warnings. for example says: at line 36 PROCEDURE Main( cAppArg ) says: prg\Senior.prg(234) Warning W0003 Variable: 'CAPPARG' declared but not used in function: 'MAIN(36)' but is used at line 96 oApp:Init( cAppArg, 'SENLOCAL.INI', 'SENIOR.INI', PRG_EXENAME + '.HLP' ) Best regards Miguel Angel marchuet MAKE Version 5.2 Copyright (c) 1987, 2000 Borland C:\CVS-Developers\xharbour\bin\harbour.exe -q0 -n -m -w3 -es2 -gc0 -dTPV -iinclude;c:\utl\fwh705\include;C:\CVS-Developers\xharbour\include -dDESARROLLO -dBMFILTER prg\Senior.prg -oobj32\develop\TPVPro\Senior.c prg\Senior.prg(234) Warning W0003 Variable: 'CAPPARG' declared but not used in function: 'MAIN(36)' prg\Senior.prg(234) Warning W0003 Variable: 'OFONT' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'OBMP' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'ACFCHECK' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'ACFCOPY' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'NITEM' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'CCLSID' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'CPROGID' declared but not used in function: 'MAIN(38)' prg\Senior.prg(234) Warning W0003 Variable: 'CSERVER' declared but not used in function: 'MAIN(38)' prg\Senior.prg(263) Warning W0003 Variable: 'OBMP' declared but not used in function: 'LVALIDWNDMAIN(234)' prg\Senior.prg(346) Warning W0003 Variable: 'NPOS' declared but not used in function: 'SALIR$(286)' prg\Senior.prg(346) Warning W0003 Variable: 'CLOG' declared but not used in function: 'SALIR$(286)' prg\Senior.prg(346) Warning W0003 Variable: 'HRES' declared but not used in function: 'SALIR$(286)' prg\Senior.prg(360) Warning W0003 Variable: 'DISCO' declared but not used in function: 'CINSTALACION(346)' prg\Senior.prg(360) Warning W0003 Variable: 'PROTSERIE' declared but not used in function: 'CINSTALACION(346)' prg\Senior.prg(360) Warning W0003 Variable: 'OPCIONES' declared but not used in function: 'CINSTALACION(346)' prg\Senior.prg(360) Warning W0003 Variable: 'CSERIE' declared but not used in function: 'CINSTALACION(347)' prg\Senior.prg(360) Warning W0003 Variable: 'COPCIONES' declared but not used in function: 'CINSTALACION(347)' prg\Senior.prg(360) Warning W0003 Variable: 'CCODIGO' declared but not used in function: 'CINSTALACION(348)' C:\CVS-Developers\xharbour\include\hbexcept.ch(76) Warning W0003 Variable: 'LINFO' declared but not used in function: 'INITPROFILER(360)' C:\CVS-Developers\xharbour\include\hbexcept.ch(76) Warning W0003 Variable: 'OPROFILE' declared but not used in function: 'INITPROFILER(362)' prg\Senior.prg(521) Warning W0003 Variable: 'EXCEPTION' declared but not used in function: 'GPFHANDLER(419)' prg\Senior.prg(521) Warning W0003 ** error -1073741819 ** deleting obj32\develop\TPVPro\Senior.c - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
I think is not prepared yet: PROCEDURE Main() LOCAL b := <|| RETURN Nil > --- compile error --- RETURN this sample says test.prg(5) Error E0030 Syntax error: "syntax error at 'ERROR'" when it should to say test.prg(7) Error E0030 Syntax error: "syntax error at 'ERROR'" Best regards, Miguel Angel Marchuet Ron Pinkas escribió: > Unless some problems are reported with regard to: > > 2008-06-03 00:17 UTC-0430 Ron Pinkas > > I have no pending changes. Once GT and ADS are cleared we should go > ahead with a new release. > > Ron > > On May 30, 2008, at 11:51 PM, Patrick Mast, xHarbour.com wrote: > >> Hey guys, >> >> How close are we to a new release? Who has pending code and/or >> fixes need to be done before we cn release? >> Can you guys give me an estimate time frame? >> >> Brian. are you working on ADS? >> Paul, are you working on GT? >> Ron, are you working on more fixes? >> >> Thanks! >> >> Patrick >> -- >> --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >> ___ >> xHarbour-developers mailing list >> xHarbour-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Unless some problems are reported with regard to: 2008-06-03 00:17 UTC-0430 Ron Pinkas I have no pending changes. Once GT and ADS are cleared we should go ahead with a new release. Ron On May 30, 2008, at 11:51 PM, Patrick Mast, xHarbour.com wrote: > Hey guys, > > How close are we to a new release? Who has pending code and/or > fixes need to be done before we cn release? > Can you guys give me an estimate time frame? > > Brian. are you working on ADS? > Paul, are you working on GT? > Ron, are you working on more fixes? > > Thanks! > > Patrick > -- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
RP> FWIW, I'm using MSVC too (VS 2005) and while I didn't make any speed RP> comparisons, the new make system appears faster. Additionaly the RP> older system was forcing me to manually delete files to force a RP> rebuild - f.e. every time I made any modification to ppcore.c I'd RP> have to delete ppcore.obj, and harbour.exe to force a rebuild. RP> Similar issues every time I touched harbour.sly, and/or harbour.slx. RP> You might remebber I reported this long ago and you promised to take RP> a look. I don't, and I did? Sorry. RP> IMO, even if the new make system would be slower, between the RP> resolution of long standing problems as above, to the centralization RP> and unification of all make files, it's a minor cost to pay. RP> FWIW, I suppose the speed issue must be related to using a NW drive, RP> which I don't use. I certainly agree something needed to be done. Eventually, I'll dig though the new system and see if I can speed it up any. Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Paul, FWIW, I'm using MSVC too (VS 2005) and while I didn't make any speed comparisons, the new make system appears faster. Additionaly the older system was forcing me to manually delete files to force a rebuild - f.e. every time I made any modification to ppcore.c I'd have to delete ppcore.obj, and harbour.exe to force a rebuild. Similar issues every time I touched harbour.sly, and/or harbour.slx. You might remebber I reported this long ago and you promised to take a look. IMO, even if the new make system would be slower, between the resolution of long standing problems as above, to the centralization and unification of all make files, it's a minor cost to pay. FWIW, I suppose the speed issue must be related to using a NW drive, which I don't use. Ron On May 31, 2008, at 7:18 PM, Paul Tucker wrote: > > RP> Do you have any specifics on why would compile time be slower? My > RP> experience has been the opposite - I think this new make > system is a > RP> great improvement. > > I'm using MSVC. > > I'll not argue the fact that the original system left something to be > desired, but I can't see how your experience can be possible. > > Generally speaking, with the previous system, all c files for a lib > were > compiled with the same invocation of cl (sure there are exeptions > to that) - > with this system, it's all done 1 file at a time. > > I have a 750gig raid 0 drive which gives decent throughput and I > can set up > an e:drive by either using subst e: c:\drives\edrive or share that > location > as 'edrive' and net use e: \\paul\edrive. (my development drive is > e:) > > When set up as a network share, speed drops because (I guess), the > cacheing > no longer works the same as it does for a 'real' drive. > > substnetwork > old makallvc clean/makallvc:8min 45min > new make_vc clean: 13min 75min > > The 'old' system is from may 26 2007 and certainly could be > improved upon by > at least correcting the way the dll is built. > > Paul > > > -- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
RP> Do you have any specifics on why would compile time be slower? My RP> experience has been the opposite - I think this new make system is a RP> great improvement. I'm using MSVC. I'll not argue the fact that the original system left something to be desired, but I can't see how your experience can be possible. Generally speaking, with the previous system, all c files for a lib were compiled with the same invocation of cl (sure there are exeptions to that) - with this system, it's all done 1 file at a time. I have a 750gig raid 0 drive which gives decent throughput and I can set up an e:drive by either using subst e: c:\drives\edrive or share that location as 'edrive' and net use e: \\paul\edrive. (my development drive is e:) When set up as a network share, speed drops because (I guess), the cacheing no longer works the same as it does for a 'real' drive. substnetwork old makallvc clean/makallvc:8min 45min new make_vc clean: 13min 75min The 'old' system is from may 26 2007 and certainly could be improved upon by at least correcting the way the dll is built. Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Paul, Do you have any specifics on why would compile time be slower? My experience has been the opposite - I think this new make system is a great improvement. Ron On May 31, 2008, at 9:47 AM, Paul Tucker wrote: > > PMx> Paul, are you working on GT? > > I am - and while I've been putting up with how things are, I must > say, I am > severly annoyed that this make process was implemented. The > compile time is > astounding and is most of the reason this wasn't done the first > time it was > brought up. > > I am also annoyed that the supposed 'generic' system now has paths > included > with instructions that this should not be changed except on the local > machine. If the author truly wants this to be generic, please find > another > way to do this so that I and every other developer doesn't have to > now edit > this 'generic' file everytime a download is done. > > Paul > > > -- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
PT> I am - and while I've been putting up with how things are, I must say, PT> I am severly annoyed that this make process was implemented. The PT> compile time is astounding and is most of the reason this wasn't done PT> the first time it was brought up. ok - I re-worked my machine back to using a subst drive instead of a network share to the same location. Still seems a shame to not use 'batch mode' for make. Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
PMx> Paul, are you working on GT? I am - and while I've been putting up with how things are, I must say, I am severly annoyed that this make process was implemented. The compile time is astounding and is most of the reason this wasn't done the first time it was brought up. I am also annoyed that the supposed 'generic' system now has paths included with instructions that this should not be changed except on the local machine. If the author truly wants this to be generic, please find another way to do this so that I and every other developer doesn't have to now edit this 'generic' file everytime a download is done. Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Patrick, MT is still broken. Unfortunately, I am not smart enough to debug the internals :-( I think we should just wait. -- Andi On Sat, 31 May 2008 08:51:01 +0200 "Patrick Mast, xHarbour.com" <[EMAIL PROTECTED]> wrote: > Hey guys, > > How close are we to a new release? Who has pending code and/or fixes need to > be done before we cn release? > Can you guys give me an estimate time frame? > > Brian. are you working on ADS? > Paul, are you working on GT? > Ron, are you working on more fixes? > > Thanks! > > Patrick - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Patrick even gtwvw are in contrib part, i think we need to release with it. i know many people that use gtwvw. and i think the best person to port this is Phil or Paul Atenciosamente Luiz Rafael Culik Guimaraes Suporte Xharbour www.xharbour.com.br Sat, 31 May 2008 08:51:01 +0200, "Patrick Mast, xHarbour.com" escreveu: Hey guys, How close are we to a new release? Who has pending code and/or fixes need to be done before we cn release? Can you guys give me an estimate time frame? Brian. are you working on ADS? Paul, are you working on GT? Ron, are you working on more fixes? Thanks! Patrick - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] New release
Hey guys, How close are we to a new release? Who has pending code and/or fixes need to be done before we cn release? Can you guys give me an estimate time frame? Brian. are you working on ADS? Paul, are you working on GT? Ron, are you working on more fixes? Thanks! Patrick - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New Release?
Patrick, there is an issue with by-reference variables due to syncing xharbour and harbour code which I think should be fixed before the release. I did look at this issue but I was not able to find out what is wrong, so I hope Phil and/or Ron can, at least, point me in the right direction. Best regards. Maurilio. > Hey guys, > > How close are we to a new release? I suggest to make a new BETA > release first as this gives us the opportunity to fine tune current > CVS code. Our users are our best testers. ;) > > What needs to be done before we can start building a new BETA release? > > Thanks! > > Patrick > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] New Release?
Hey guys, How close are we to a new release? I suggest to make a new BETA release first as this gives us the opportunity to fine tune current CVS code. Our users are our best testers. ;) What needs to be done before we can start building a new BETA release? Thanks! Patrick - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
