[Harbour] hbqt success under Linux, Win, OSX and next step
Today I've been able to build and run demoqt under Ubuntu 9.04, Win XPSP3 and OSX 10.6 using the same harbour tree. I don't know the status of the gc and memory related issues but the demoqt starts and quits on all platforms without errors. The native look and feel is really good and all the controls works as expected. I wonder how many developers are "really" interested to invest time and code in hbqt ( not only suggestions or requests ) and what are the goals ( f.e "port xyz lib code to OSX" or "create new apps" or "port CUI code to GUI" ). Personally I'm much more interested in web technologies but I understand that a multiplatform "Desktop GUI" is important for Harbour and since there isn't a C5x GUI to use as blueprint, I hope that instead to promptly start 5 different incompatible implementations ( in pure xBase style :) we'll take some time to think about how to proceed. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12966] trunk/harbour
Viktor, simple multiple calls to WIN_CREATEFONT(), even in single thread. Sorry but I do not understand. WIN_CREATEFONT() only has a live font eliminating the prior and this font is saved for each DCS to make sure it is removed. It's the logic of the existing function maybe have to be called WIN_CREATEFONTWPDC :) because it is not a function of creating generic fonts rather to print fonts with TPrint() -- Xavi Viktor Szakáts escribió: Hi Xavi, You've converted the static variable to a thread protected variable, but this doesn't solve the real problem. The real problem is not MT, but simple multiple calls to WIN_CREATEFONT(), even in single thread. IMO we don't need any such heavy tricks here. Simply the interface should be descrambled so that it gives back proper handles to caller code, which stores these handles, and they're getting released when going out of scope. Or, if two Windows handles belong to one Harbour level object, a helper structure should be used in garbage collector functions and this way it's possible to release both when the variable goes out of scope. [ I'm also not sure if it's correct to use thread local variables is garbage collector code, but it looks a bit suspicious, since a value may be passed to other thread and live there from that point. ] Apologize if I'm missing something here, which makes this case special, but I can't see it ATM. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12968] trunk/harbour
Revision: 12968 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12968&view=rev Author: vszakats Date: 2009-11-22 03:17:20 + (Sun, 22 Nov 2009) Log Message: --- 2009-11-22 04:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_prn2.c % GETPRINTERS(): Changed to use printer list retrieving on NT systems to the one used on Win9x systems. This greatly simplifies the code. % GETPRINTERS(): Optimized out one PHB_ITEM variable. % GETPRINTERS(): Moved variables closer to their user blocks. * GETPRINTERS(): Using empty strings instead of inconsistent "Error"/"ERROR" texts on error. (INCOMPATIBLE). ; Pls test. * src/common/hbver.c + Some changes to the way LLVM/CLang are detected. One remaining combination was now added also. Pls review me. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/src/common/hbver.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] llvm ident fixup
Hi Tamas, OIndex: src/common/hbver.c > > === > --- src/common/hbver.c(revision 12965) > +++ src/common/hbver.c(working copy) > @@ -623,11 +623,11 @@ > pszName = "EMX/RSXNT/Win32 GNU C"; >#elif defined( __EMX__ ) > pszName = "EMX GNU C"; > - #elif defined( __clang__ ) > - #if defined( __llvm__ ) > - pszName = "Clang/LLVM C"; > + #elif defined( __llvm__ ) > + #if defined( __clang__ ) > + pszName = "LLVM/Clang C"; > #else > - pszName = "Clang/GNU C"; > + pszName = "LLVM/GNU C"; > #endif >#else > pszName = "GNU C"; Seems good to me, but we should also add non-LLVM Clang frontend to the mix. (this still exists f.e. for C++ code) I'll commit something pretty soon, pls take a look at it. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12966] trunk/harbour
Hi Xavi, You've converted the static variable to a thread protected variable, but this doesn't solve the real problem. The real problem is not MT, but simple multiple calls to WIN_CREATEFONT(), even in single thread. IMO we don't need any such heavy tricks here. Simply the interface should be descrambled so that it gives back proper handles to caller code, which stores these handles, and they're getting released when going out of scope. Or, if two Windows handles belong to one Harbour level object, a helper structure should be used in garbage collector functions and this way it's possible to release both when the variable goes out of scope. [ I'm also not sure if it's correct to use thread local variables is garbage collector code, but it looks a bit suspicious, since a value may be passed to other thread and live there from that point. ] Apologize if I'm missing something here, which makes this case special, but I can't see it ATM. Brgds, Viktor On 2009 Nov 22, at 03:36, Xavi wrote: > Please be patient Viktor I have changed all win_prn1.c > This version solves the problem and adapts to MT. > Could you mix your latest changes and update the repository. > > -- > Xavi > > vszak...@users.sourceforge.net escribió: >> Revision: 12966 >> >> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12966&view=rev >> Author: vszakats >> Date: 2009-11-22 02:00:56 + (Sun, 22 Nov 2009) >> Log Message: >> --- >> 2009-11-22 03:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * contrib/hbwin/win_tprn.prg >>! Accidentally missed GetDocumentProperties() method added. >>% Converted all INLINE methods to normal ones (for optimal performance). >> * contrib/hbwin/win_tcom.prg >>% Converted all INLINE methods to normal ones (for optimal performance). >> * contrib/hbwin/win_prn1.c >>% Using hb_arraySet*() APIs. >> * contrib/hbwin/win_prn2.c >>* Minor formatting. >> Modified Paths: >> -- >>trunk/harbour/ChangeLog >>trunk/harbour/contrib/hbwin/win_prn1.c >>trunk/harbour/contrib/hbwin/win_prn2.c >>trunk/harbour/contrib/hbwin/win_tcom.prg >>trunk/harbour/contrib/hbwin/win_tprn.prg >> This was sent by the SourceForge.net collaborative development platform, the >> world's largest Open Source development site. >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour > > > /* > * $Id: $ > */ > > /* > * Harbour Project source code: > * Printing subsystem for Windows using GUI printing > * Copyright 2004 Peter Rees > *Rees Software & Systems Ltd > * > * See COPYING for licensing terms. > * > * www - http://www.harbour-project.org > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation; either version 2, or (at your option ) > * any later version. > * > * This program is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > * > * You should have received a copy of the GNU General Public License > * along with this software; see the file COPYING. If not, write to > * the Free Software Foundation, Inc., 59 Temple Place, Suite 330, > * Boston, MA 02111-1307 USA (or visit the web site http://www.gnu.org/ ). > * > * As a special exception, the Harbour Project gives permission for > * additional uses of the text contained in its release of Harbour. > * > * The exception is that, if you link the Harbour libraries with other > * files to produce an executable, this does not by itself cause the > * resulting executable to be covered by the GNU General Public License. > * Your use of that executable is in no way restricted on account of > * linking the Harbour library code into it. > * > * This exception does not however invalidate any other reasons why > * the executable file might be covered by the GNU General Public License. > * > * This exception applies only to the code released by the Harbour > * Project under the name Harbour. If you copy code from other > * Harbour Project or Free Software Foundation releases into a copy of > * Harbour, as the General Public License permits, the exception does > * not apply to the code that you add in this way. To avoid misleading > * anyone as to the status of such modified files, you must delete > * this exception notice from them. > * > * If you write modifications of your own for Harbour, it is your choice > * whether to permit this exception to apply to your modifications. > * If you do not wish that, delete this exception notice. > */ > > /* > > TPRINT() was designed to make it easy to emulate Clipper Dot Matri
[Harbour] llvm ident fixup
viktor, i believe the following is better at identifying the actual llvm frontend used: tinky:~/w/xhb/hbci/harbour-build$ ../inst/linux/llvm/c/bin/harbour -build 2>&1 | fgrep Compiler Compiler: LLVM/GNU C 4.2.1 (64-bit) tinky:~/w/xhb/hbci/harbour-build$ ../inst/linux/llvm/cpp/bin/harbour -build 2>&1 | fgrep Compiler Compiler: LLVM/GNU C++ 4.2.1 (64-bit) without this, llvm/gcc gets identified as gcc. i don't have clang, but if that doesn't break for you, could you please apply this? thanks, Index: src/common/hbver.c === --- src/common/hbver.c (revision 12965) +++ src/common/hbver.c (working copy) @@ -623,11 +623,11 @@ pszName = "EMX/RSXNT/Win32 GNU C"; #elif defined( __EMX__ ) pszName = "EMX GNU C"; - #elif defined( __clang__ ) - #if defined( __llvm__ ) - pszName = "Clang/LLVM C"; + #elif defined( __llvm__ ) + #if defined( __clang__ ) + pszName = "LLVM/Clang C"; #else - pszName = "Clang/GNU C"; + pszName = "LLVM/GNU C"; #endif #else pszName = "GNU C"; -- [-] mkdir /nonexistentIndex: src/common/hbver.c === --- src/common/hbver.c (revision 12965) +++ src/common/hbver.c (working copy) @@ -623,11 +623,11 @@ pszName = "EMX/RSXNT/Win32 GNU C"; #elif defined( __EMX__ ) pszName = "EMX GNU C"; - #elif defined( __clang__ ) - #if defined( __llvm__ ) - pszName = "Clang/LLVM C"; + #elif defined( __llvm__ ) + #if defined( __clang__ ) + pszName = "LLVM/Clang C"; #else - pszName = "Clang/GNU C"; + pszName = "LLVM/GNU C"; #endif #else pszName = "GNU C"; ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12967] trunk/harbour
Revision: 12967 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12967&view=rev Author: vszakats Date: 2009-11-22 02:37:47 + (Sun, 22 Nov 2009) Log Message: --- 2009-11-22 03:37 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_prn2.c * Further type cleanup. % Using macro instead of storing static number in variable. ! Fixed GETPRINTER() after recent change on Win9x systems. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn2.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12966] trunk/harbour
Revision: 12966 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12966&view=rev Author: vszakats Date: 2009-11-22 02:00:56 + (Sun, 22 Nov 2009) Log Message: --- 2009-11-22 03:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_tprn.prg ! Accidentally missed GetDocumentProperties() method added. % Converted all INLINE methods to normal ones (for optimal performance). * contrib/hbwin/win_tcom.prg % Converted all INLINE methods to normal ones (for optimal performance). * contrib/hbwin/win_prn1.c % Using hb_arraySet*() APIs. * contrib/hbwin/win_prn2.c * Minor formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/hbwin/win_tcom.prg trunk/harbour/contrib/hbwin/win_tprn.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12965] trunk/harbour
Ops, thank you, cut it and forgot to paste it back :/ Brgds, Viktor On 2009 Nov 22, at 00:30, Maurizio la Cecilia wrote: > > Please, Viktor, add this line: > > METHOD GetDocumentProperties() INLINE win_GetDocumentProperties( > ::PrinterName, @::FormType, @::Landscape, @::Copies, @::BinNumber, > @::fDuplexType, @::fPrintQuality ) > > to win_prn class declaration as missed from source of Xavi. > Best regards. > Maurizio > > > vszakats wrote: >> >> Revision: 12965 >> >> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12965&view=rev >> Author: vszakats >> Date: 2009-11-21 23:02:42 + (Sat, 21 Nov 2009) >> >> Log Message: >> --- >> 2009-11-21 00:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * contrib/hbwin/win_prn2.c >>! Fixed PRINTEREXISTS() in UNICODE mode (hidden by wrong cast). >>% Type cleanup (f.e. not using Windows type where not necessary). >>% Cleaned away unnecessary casts. >> >> Modified Paths: >> -- >>trunk/harbour/ChangeLog >>trunk/harbour/contrib/hbwin/win_prn2.c >> >> >> This was sent by the SourceForge.net collaborative development platform, >> the world's largest Open Source development site. >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> >> > > -- > View this message in context: > http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12965--trunk-harbour-tp26461291p26461464.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12965] trunk/harbour
Please, Viktor, add this line: METHOD GetDocumentProperties() INLINE win_GetDocumentProperties( ::PrinterName, @::FormType, @::Landscape, @::Copies, @::BinNumber, @::fDuplexType, @::fPrintQuality ) to win_prn class declaration as missed from source of Xavi. Best regards. Maurizio vszakats wrote: > > Revision: 12965 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12965&view=rev > Author: vszakats > Date: 2009-11-21 23:02:42 + (Sat, 21 Nov 2009) > > Log Message: > --- > 2009-11-21 00:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbwin/win_prn2.c > ! Fixed PRINTEREXISTS() in UNICODE mode (hidden by wrong cast). > % Type cleanup (f.e. not using Windows type where not necessary). > % Cleaned away unnecessary casts. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/hbwin/win_prn2.c > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12965--trunk-harbour-tp26461291p26461464.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12965] trunk/harbour
Revision: 12965 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12965&view=rev Author: vszakats Date: 2009-11-21 23:02:42 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 00:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_prn2.c ! Fixed PRINTEREXISTS() in UNICODE mode (hidden by wrong cast). % Type cleanup (f.e. not using Windows type where not necessary). % Cleaned away unnecessary casts. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn2.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12956] trunk/harbour
Hi Angel, >> I don't know where the misconception comes from about my POV on this, but >> I'd like to stop it now. > > Hi Viktor ! > > Well first of all my english is not very good so I could be misunderstood. > I've said I was in disagree with you when refering backward compatibility > among xbase++ and harbour. For me xbase++ is more like a "philosofy of work" > than a rigid set of rules. If compatibiliy risks the viability of the qt GUI > we need, then I think we can and we should break it. I insist: It's only my > personaly POV. The whole movement started from creating an _Xbase++ compatible GUI class_, which says it clear. (Hence the name of the lib: hbxbp) If we were starting a GUI class "inspired by" Xbase++, or "contains elements of" Xbase++, or "loosely based" on Xbase++, the situation would for sure be different, but this wasn't the original statement / goal. >> If make Xbase++ users life more difficult to move to Harbour, it means >> Harbour userbase can't grow the way it otherwise would. Which isn't very >> good. > > I don´t think hords of xbase users will come here since they are so Windows > headed. They like things like OLE, skins, owner drawn parts, GUI fancy > objects, all kind of non multiplatform M$ toys. Also the false feeling of > support you get when you pay for something. We can force no one to come here and we don't want to. However, if we start to mess up compatibility we for sure lock out all potential users from ever migrating. This is quite bad, as we don't thrive in large user base regarding Harbour, and the best thing we can do is attract users from other parts of the xbase (not the product) arena to keep the project alive and with some sort of purpose. > Anyway the whole idea and consistency of the xbase++ GUI framework is a good > model to follow. It's yet to prove if it's easy to integtrate tools like > qtcreator and qt development style in this model or we'll have to invent a > whole new development philosofy derived from the zillion c++ examples they > have on their page. Yes, I agree. We have other possibilities to achieve this, just to name a few: 1) Create another contrib which is "based-on" or even completely different from hbxbp and build our own general (preferably) or hbqt orientated GUI classes. 2) Solve interoperation of _addons libs_ (classes) and direct hbqt objects with hbxbp. There is more. >> [ about a few technical aspects of extending wisely and in documented way, >> pls see my recent msg. ] > > Yes I've read it and I trust your judjement and the vision of quality you > have imprinted into Harbour project. > This post was only a very personal POV ( I insist ) and has no intention to > harm anyone. No problem at all, and your opinion is very welcome, I just wanted to make it clear that the original proposition about my opinion was wrongly put :) > My best regards and continue with your superb managing of the project. Thank you. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12956] trunk/harbour
Viktor Szakáts escribió: Pritpal Bedi escribió: Hi ... This is the reason I floated the idea of extending Xbase++ framework which has not been accepted by the group by now. Well on this I disagree with Viktor. I dont need backward compatibility with xbase++, so extending claes and/or creating new ones is ok with me. I don't know where the misconception comes from about my POV on this, but I'd like to stop it now. Hi Viktor ! Well first of all my english is not very good so I could be misunderstood. I've said I was in disagree with you when refering backward compatibility among xbase++ and harbour. For me xbase++ is more like a "philosofy of work" than a rigid set of rules. If compatibiliy risks the viability of the qt GUI we need, then I think we can and we should break it. I insist: It's only my personaly POV. This is exactly what I wrote: --- "I don't know, but please document it, we have a long history in Harbour to document extensions, so we should IMO do this also for hbxbp. We don't have any interest in locking in users into Harbour + hbxbp, IOW we should allow them to move to Xbase++, or create apps which work on both platforms. The easiest and recommended way to self-document it is by using a simple macro, f.e. HBXBP_EXTENSION. Which is #defined by default." --- Agreed ! Which seems quite clear, but to clarify further, it means that while I can't decide whether we _should_ extend (I trust Pritpal and actual Xbase++/hbqt users on this), but I know we _may_ extend it, if we stick to a few rules: we extend it wisely and document all extensions in code. These rules should be similar to what we've been using when extending Clipper, maybe not so strict. IMO it's very important to do extensions along a documented procedure, otherwise there is no guarantee whatsoever that Xbase++ compatibility can be kept, or even tested. Which means we cut off Harbour + hbxbp as an upgrade path for Xbase++ users and make the transition a one way step, plus we can't guarantee any sort of parallelism through the transition process (I mean app can't be build for both platforms at the same time). Also agreed ! If make Xbase++ users life more difficult to move to Harbour, it means Harbour userbase can't grow the way it otherwise would. Which isn't very good. I don´t think hords of xbase users will come here since they are so Windows headed. They like things like OLE, skins, owner drawn parts, GUI fancy objects, all kind of non multiplatform M$ toys. Also the false feeling of support you get when you pay for something. Anyway the whole idea and consistency of the xbase++ GUI framework is a good model to follow. It's yet to prove if it's easy to integtrate tools like qtcreator and qt development style in this model or we'll have to invent a whole new development philosofy derived from the zillion c++ examples they have on their page. [ about a few technical aspects of extending wisely and in documented way, pls see my recent msg. ] Yes I've read it and I trust your judjement and the vision of quality you have imprinted into Harbour project. This post was only a very personal POV ( I insist ) and has no intention to harm anyone. My best regards and continue with your superb managing of the project. Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
Hi Phil, >> 1) Use whatever HB_INSTALL_PREFIX we may have at build pass. >> 2) Reapply this parameter on install? (if that's possible) > > probably it can be done using otool. > >> 3) Else? > > I think that on OS X, one is supposed to produce application bundles > which include all libraries not installed by Apple. If you want dylibs > for including into app bundles, you should use @executable_path token > instead of full path in install_name and have no problems. If > install_name (copied to executable from dylib at link time) does not > have a correct full path to dylib or @executable_path, one has to set > DYLD_LIBRARY_PATH envvar for app to locate it. > > It seems that these are the only two dylib relocation options offered. Thank you very much for the information and research. install_name_tool needs old value, so it's not very easy to work with at first sight. I most probably won't have enough time to make deeper changes here now, so if you have free time + motivation, pls feel free to make modifications in that direction. Pbly the easiest would be to embed HB_INSTALL_PREFIX in install name on build when HB_SYSLOC != yes. It would cover most real-life scenarios. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 9:08 PM, Viktor Szakáts wrote: > Just did this on SVN, pls make some tests and > report if there is still something missing. For me now it's ok. Now everything works using DYLD_LIBRARY_PATH=/opt/harbour/lib ./demoqt. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12964] trunk/harbour
Revision: 12964 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12964&view=rev Author: vszakats Date: 2009-11-21 21:51:48 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 22:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_prn2.c ! Fixed few type mis-uses (BOOL instead of DWORD and vice versa) % Optimized hb_isLegacyDevice(). % Marked some static strings as static. % Marked locally used C worker functions as static. This may cause incompatibility if someone used these via undocumented ways. They were never officially published through .h headers. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn2.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12963] trunk/harbour
Revision: 12963 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12963&view=rev Author: vszakats Date: 2009-11-21 21:38:39 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 22:37 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_tprn.prg * contrib/hbwin/win_prn1.c + Added ::GetDocumentProperties() method. + Calling ::GetDocumentProperties() from ::New() to setup defaults. ; Patch submitted by Xavi. Thank you. * contrib/hbwin/win_prn2.c % Modified GETPRINTERS() code to use optimal array creation code, use less redundancy and synced functionally similar code parts with each other, deleted unnecessary code parts. * Greatly cleaned GETPRINTERS() code (names, layout). ! Fixed GETPRINTERS() code. It had fatal flaw in non-NT branch, so I seriously wonder how could it work for anyone in the past. It seems it wasn't even tested by submitter before commited to xhb repository in year 2005. Someone pls test it on Win9x, I don't have any printers installed there. * contrib/hbwin/win_prn1.c * contrib/hbwin/legacy.prg * Moved WIN_GETEXEFILENAME() to legacy function collection, at the same time rewritten to simply call HB_ARGV( 0 ). * contrib/hbwin/win_prn1.c % WIN_FILLRECT(), WIN_ARC(), WIN_ELLIPSE() optimized. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/legacy.prg trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/hbwin/win_tprn.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 11:53 PM, Phil Krylov wrote: > On Sat, Nov 21, 2009 at 11:08 PM, Viktor Szakáts wrote: >> 2) Reapply this parameter on install? (if that's possible) > > probably it can be done using otool. there seems to be a specific tool for this - install_name_tool. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 11:08 PM, Viktor Szakáts wrote: > of dylibs. Plus such requirement makes it not possible > to move around .dylib once it's created (but maybe this > how it's meant to be done on OS X). > > What to do? > > 1) Use whatever HB_INSTALL_PREFIX we may have at build pass. > 2) Reapply this parameter on install? (if that's possible) probably it can be done using otool. > 3) Else? I think that on OS X, one is supposed to produce application bundles which include all libraries not installed by Apple. If you want dylibs for including into app bundles, you should use @executable_path token instead of full path in install_name and have no problems. If install_name (copied to executable from dylib at link time) does not have a correct full path to dylib or @executable_path, one has to set DYLD_LIBRARY_PATH envvar for app to locate it. It seems that these are the only two dylib relocation options offered. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Changes in win_prn in order to not increase gdi objects and read the initial properties of the printer.
> Ok, I think a solution although would be easier to WIN_CREATEFONT return > hFont. :) Indeed, pls feel free to rework it that way. We will simply document it, and I believe not many users use it directly. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Changes in win_prn in order to not increase gdi objects and read the initial properties of the printer.
Ok, I think a solution although would be easier to WIN_CREATEFONT return hFont. :) -- Xavi Viktor Szakáts escribió: Hi Xavi, The document properties feature is okay, buy the font trick seems to breaks if multiple WIN_CREATEFONT() calls are issued (either in ST or MT mode), since it uses a static variable to store GC block related information. Brgds, Viktor On 2009 Nov 21, at 20:34, Xavi wrote: As subject. If no objection, please Viktor, could you update the repository. Thanks. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
> I had fixed this locally by changing > > -install_name "harbour$(DYN_EXT)" > > to > > -install_name "libharbour$(DYN_EXT)" > > in DY_RULE (should probably fix also mkdyn). Just did this on SVN, pls make some tests and report if there is still something missing. > Anyhow, this is a hack as install_name should (usually) be set to the > full installation path. Thank you, this sheds light on the remaining TOFIX. One problem is that we have separate build and install passes and at build time we may not know the final location of dylibs. Plus such requirement makes it not possible to move around .dylib once it's created (but maybe this how it's meant to be done on OS X). What to do? 1) Use whatever HB_INSTALL_PREFIX we may have at build pass. 2) Reapply this parameter on install? (if that's possible) 3) Else? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Changes in win_prn in order to not increase gdi objects and read the initial properties of the printer.
Hi Xavi, The document properties feature is okay, buy the font trick seems to breaks if multiple WIN_CREATEFONT() calls are issued (either in ST or MT mode), since it uses a static variable to store GC block related information. Brgds, Viktor On 2009 Nov 21, at 20:34, Xavi wrote: > As subject. If no objection, please Viktor, could you update the repository. > Thanks. > > -- > Xavi > > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
I had fixed this locally by changing -install_name "harbour$(DYN_EXT)" to -install_name "libharbour$(DYN_EXT)" in DY_RULE (should probably fix also mkdyn). Anyhow, this is a hack as install_name should (usually) be set to the full installation path. --Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
>> Why whole dir is stripped and why 'lib' prefix is stripped >> from dylib reference? Maybe because of -L option with the >> same dir > > Could it be this? > > config/darwin/gcc.mk > ... > DY_RULE = $(DY) $(DFLAGS) -install_name "harbour$(DYN_EXT)" > -compatibility_version $(HB_VER_MAJOR).$(HB_VER_MINOR) > -current_version $(HB_VER_MAJOR).$(HB_VER_MINOR).$(HB_VER_RELEASE) > $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ $^ $(DLIBS) $(DYSTRIP) && > $(LN) $(@F) $(DYN_FILE2) && $(LN) $(@F) > $(DYN_DIR)/$(DYN_PREF)$(DYNNAME2).$(HB_VER_MAJOR)$(DYN_EXT) > ... What do you mean? This is the line responsible for creating dylibs under GNU Make, yes, and that's what I had meant to compare with actual hb-mkslib command executed. Anyway, as a guess, which also worked here, I added lib prefix to one of the parameters and committed it. Dirs still don't work in dylib references. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12962] trunk/harbour
Revision: 12962 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12962&view=rev Author: vszakats Date: 2009-11-21 19:29:18 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 20:28 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/darwin/gcc.mk * config/darwin/icc.mk * config/darwin/clang.mk ! Attempt to fix darwin dylib generation, added lib prefix to install name parameter. ; TOFIX: Adding path to lib reference still doesn't work, so shared binaries will still not work unless Harbour is installed to system location. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/darwin/clang.mk trunk/harbour/config/darwin/gcc.mk trunk/harbour/config/darwin/icc.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
>>> In my local repo I set HB_DLL=no and I use the "old" hb-mkslib logic
>>> that's now commented out in hb-func.sh and it works as expected.
>>>
>>> In the "old way" otool -D /opt/harbour/lib/libharbour.dylib returns
>>> libharbour.dylib in the "svn way" it returns harbour.dylib.
>>
>> Could you post the command that's executed when using hb-mkslib?
>
> from bin/hb-mkdyn.sh
> ...
> if [ "${SLIB_EXT}" = ".dylib" ]; then
>FULLNAME="${BASE}.${VERSION}${SLIB_EXT}"
>libtool -dynamic -install_name "${BASE}${SLIB_EXT}" \
>-compatibility_version ${MAJOR}.${MINOR} -current_version ${VERSION} \
>-flat_namespace -undefined warning -multiply_defined suppress
> -single_module ${HB_USER_DFLAGS} \
>-o "${DSTDIR}/${FULLNAME}" "$@" && \
>ln -sf "${FULLNAME}" "${DSTDIR}${BASE}.${MAJOR}${SLIB_EXT}" && \
>ln -sf "${FULLNAME}" "${DSTDIR}${BASE}${SLIB_EXT}"
> ...
I know this. I'd have been interested in the actual
command executed, for me it's nearly impossible to
reverse engineer all these variables, so it's not
much of a help.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 7:21 PM, Viktor Szakáts wrote: > Why whole dir is stripped and why 'lib' prefix is stripped > from dylib reference? Maybe because of -L option with the > same dir Could it be this? config/darwin/gcc.mk ... DY_RULE = $(DY) $(DFLAGS) -install_name "harbour$(DYN_EXT)" -compatibility_version $(HB_VER_MAJOR).$(HB_VER_MINOR) -current_version $(HB_VER_MAJOR).$(HB_VER_MINOR).$(HB_VER_RELEASE) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ $^ $(DLIBS) $(DYSTRIP) && $(LN) $(@F) $(DYN_FILE2) && $(LN) $(@F) $(DYN_DIR)/$(DYN_PREF)$(DYNNAME2).$(HB_VER_MAJOR)$(DYN_EXT) ... best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 8:09 PM, Viktor Szakáts wrote:
>>> Why whole dir is stripped and why 'lib' prefix is stripped
>>> from dylib reference? Maybe because of -L option with the
>>> same dir?
>>
>> The problem seems not in the hbmk2 but how the libharbour.dylib is generated.
>>
>> In my local repo I set HB_DLL=no and I use the "old" hb-mkslib logic
>> that's now commented out in hb-func.sh and it works as expected.
>>
>> In the "old way" otool -D /opt/harbour/lib/libharbour.dylib returns
>> libharbour.dylib in the "svn way" it returns harbour.dylib.
>
> Could you post the command that's executed when using hb-mkslib?
from bin/hb-mkdyn.sh
...
if [ "${SLIB_EXT}" = ".dylib" ]; then
FULLNAME="${BASE}.${VERSION}${SLIB_EXT}"
libtool -dynamic -install_name "${BASE}${SLIB_EXT}" \
-compatibility_version ${MAJOR}.${MINOR} -current_version ${VERSION} \
-flat_namespace -undefined warning -multiply_defined suppress
-single_module ${HB_USER_DFLAGS} \
-o "${DSTDIR}/${FULLNAME}" "$@" && \
ln -sf "${FULLNAME}" "${DSTDIR}${BASE}.${MAJOR}${SLIB_EXT}" && \
ln -sf "${FULLNAME}" "${DSTDIR}${BASE}${SLIB_EXT}"
...
best regards,
Lorenzo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
>> Why whole dir is stripped and why 'lib' prefix is stripped >> from dylib reference? Maybe because of -L option with the >> same dir? > > The problem seems not in the hbmk2 but how the libharbour.dylib is generated. > > In my local repo I set HB_DLL=no and I use the "old" hb-mkslib logic > that's now commented out in hb-func.sh and it works as expected. > > In the "old way" otool -D /opt/harbour/lib/libharbour.dylib returns > libharbour.dylib in the "svn way" it returns harbour.dylib. Could you post the command that's executed when using hb-mkslib? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 7:21 PM, Viktor Szakáts wrote: > Why whole dir is stripped and why 'lib' prefix is stripped > from dylib reference? Maybe because of -L option with the > same dir? The problem seems not in the hbmk2 but how the libharbour.dylib is generated. In my local repo I set HB_DLL=no and I use the "old" hb-mkslib logic that's now commented out in hb-func.sh and it works as expected. In the "old way" otool -D /opt/harbour/lib/libharbour.dylib returns libharbour.dylib in the "svn way" it returns harbour.dylib. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12961] trunk/harbour
Revision: 12961 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12961&view=rev Author: vszakats Date: 2009-11-21 18:49:50 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 19:48 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbtip/smtpcli.prg ! Fixed long time SMTP protocol implementation bug reported (with patch) by Francesco Perillo. Thank you. The problem manifested itself only with strictly standard compliant SMTP server (setups?) like recent Exim versions. + Upped timeout from 5000 to 5. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbtip/smtpcli.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Please try this sendmail patch
Hi Francesco, > Viktor, I DID try to just raise timeouts and I did some more tests. > > My MTA is exim and it is very "strict" on the protocol. > > Try to issue this command: > telnet 25 > and you will get a > "220 message" > and ONLY IN THIS MOMENT you can issue commands ! > > Exim doesn't accept any command before the 220 is sent ! In the past, > a lot of spam software did send the HELO without waiting for the 220 > banner and exim killed them > > Gmail accepts the message without the patch and probably the same will > happen with other MTAs > > > I want to say that in a particular case (external antivirus + backend > MTA) I have > "220-message 1" > "220 message 2" > and if the backend is down I get a > "5xx error message" Thanks for the explanation, you're right. Before reading through your msg I've also checked RFC821 (http://james.apache.org/server/rfclist/smtp/rfc0821.txt) and it also says what you say in chapter 4.3. I'll make some tests as soon as Win7 reboots itself correctly (2nd attempt) after BSOD-ing on my test build. I did a quick test with gmail and it's okay, plus finally the protocol conversation makes some sense. Thanks for your report, this has been a bug ever since hbtip existed. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
>> This difference is due to the fact that Harbour is installed >> to system location on your system and not on mine. hbmk2 will >> adapt and use full dirspec to link against dylib. Anyhow the >> problem is present in both cases apparently. > > In my local repo I remove all that HB_SYSLOC logic in the global.mk. > I don't understand the need to have different logic for different paths. > Moreover /opt is completely different from /usr since it's never used > by the system. I've explained this several times. Without this logic, only broken shared builds could be created without sudo rights (and/or extra manual configuration). BTW, I personally don't care much about what we consider "system location". We have a list based on past feedback, but we can take in/out any dirs, in this case we can take out /opt, if that causes problems. (and I guess it does as it's indeed not in default lib dir search list) We also have some pending plans to make reforms to system location detection, which also involves looking for actual LD_PATH list to make this decision, but these will be done only after 2.0.0 stable as it shall be done with other build changes causing lots of turbulence on all platforms. > If the user doesn't define a path Harbour should choose a safe default > but if the user defines it I don't see the reason why the build system > should override the choice. Pls remember, that because of strong opinion of *nix users and because most other packages work that way we opted to make the default path a system path. So f.e. I who don't want to pollute non-user areas with Harbour test builds, always have to override install path, yet I don't have these path in LD_PATH, simply because I prefer to not hard-wire such things into my system settings, and keep everything portable/moveable. Well, 'nough said. > However in this case I'm using the standard svn. No doubt and the problem at hand doesn't seem to have much to do with above issue, since it happens in both scenarios. F.e., here is otool (ldd equivalent on OS X) output: --- hbmk2: Linker command: /Developer/usr/bin/clang hbide.o hbmk_5HIQqC.o -lhbxbp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lsupc++ -lhbcplr -lhbdebug /Library/Frameworks/QtCore.framework/QtCore /Library/Frameworks/QtGui.framework/QtGui /Library/Frameworks/QtNetwork.framework/QtNetwork /Users/vszakats/harbour/lib/darwin/clang/libharbour.dylib -o hbide -L/Users/vszakats/harbour/lib/darwin/clang silver:hbide vszakats$ otool -L hbide hbide: QtCore.framework/Versions/4/QtCore (compatibility version 4.6.0, current version 4.6.0) QtGui.framework/Versions/4/QtGui (compatibility version 4.6.0, current version 4.6.0) QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.6.0, current version 4.6.0) harbour.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) --- Why whole dir is stripped and why 'lib' prefix is stripped from dylib reference? Maybe because of -L option with the same dir? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal about hbide
I have to understand how to compile hbide (with Qt) before . :-) Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Please try this sendmail patch
Viktor, I DID try to just raise timeouts and I did some more tests. My MTA is exim and it is very "strict" on the protocol. Try to issue this command: telnet 25 and you will get a "220 message" and ONLY IN THIS MOMENT you can issue commands ! Exim doesn't accept any command before the 220 is sent ! In the past, a lot of spam software did send the HELO without waiting for the 220 banner and exim killed them Gmail accepts the message without the patch and probably the same will happen with other MTAs I want to say that in a particular case (external antivirus + backend MTA) I have "220-message 1" "220 message 2" and if the backend is down I get a "5xx error message" > Second because GetOK() _is_ actually called after HELO and > EHLO requests in line 124 and 143. It is correct that it is called after HELO/EHLO ! But the reply must be correctly checked ! Finally, please try the patch Thanks, Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 6:39 PM, Viktor Szakáts wrote: > This difference is due to the fact that Harbour is installed > to system location on your system and not on mine. hbmk2 will > adapt and use full dirspec to link against dylib. Anyhow the > problem is present in both cases apparently. In my local repo I remove all that HB_SYSLOC logic in the global.mk. I don't understand the need to have different logic for different paths. Moreover /opt is completely different from /usr since it's never used by the system. If the user doesn't define a path Harbour should choose a safe default but if the user defines it I don't see the reason why the build system should override the choice. However in this case I'm using the standard svn. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
Hi Lorenzo, >> Rather hbmk2 should be modified if possible to load >> it without requiring such links. > > hbmk2 -traceonly demoqt > gcc demoqt.o hbmk_gvsy4s.o -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork > -lsupc++ -lhbcplr -lhbdebug -lharbour > /Library/Frameworks/QtCore.framework/QtCore > /Library/Frameworks/QtGui.framework/QtGui > /Library/Frameworks/QtNetwork.framework/QtNetwork -bind_at_load -o > demoqt -L/opt/harbour/lib/harbour > > I see a difference: I have a -lharbour you have > /Users/vszakats/harbour/lib/darwin/gcc/libharbour.dylib > I've tried to add -shared but it doesn't change. This difference is due to the fact that Harbour is installed to system location on your system and not on mine. hbmk2 will adapt and use full dirspec to link against dylib. Anyhow the problem is present in both cases apparently. What I don't understand is how come hbmk2 links against libharbour.dylib, yet when running it, it's looking for harbour.dylib ? (I also have the impression this is a regression) --- silver:hbide vszakats$ ../../bin/hbmk2 hbide -shared -trace [...] hbmk2: Linker command: /Developer/usr/bin/clang hbide.o hbmk_oeG2NQ.o -lhbxbp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lsupc++ -lhbcplr -lhbdebug /Library/Frameworks/QtCore.framework/QtCore /Library/Frameworks/QtGui.framework/QtGui /Library/Frameworks/QtNetwork.framework/QtNetwork /Users/vszakats/harbour/lib/darwin/clang/libharbour.dylib -o hbide -L/Users/vszakats/harbour/lib/darwin/clang silver:hbide vszakats$ ./hbide dyld: Library not loaded: harbour.dylib Referenced from: /Users/vszakats/harbour/contrib/hbide/./hbide Reason: image not found Trace/BPT trap --- Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12960] trunk/harbour
Revision: 12960 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12960&view=rev Author: vszakats Date: 2009-11-21 17:15:56 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 18:13 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg + Added clang support to link to dylib with full dirspec (when Harbour is not used/installed in a system location) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12956] trunk/harbour
> Pritpal Bedi escribió: >> Hi >> ... >> This is the reason I floated the idea of extending Xbase++ framework >> which has not been accepted by the group by now. > > Well on this I disagree with Viktor. I dont need backward compatibility with > xbase++, so extending claes and/or creating new ones is ok with me. I don't know where the misconception comes from about my POV on this, but I'd like to stop it now. This is exactly what I wrote: --- "I don't know, but please document it, we have a long history in Harbour to document extensions, so we should IMO do this also for hbxbp. We don't have any interest in locking in users into Harbour + hbxbp, IOW we should allow them to move to Xbase++, or create apps which work on both platforms. The easiest and recommended way to self-document it is by using a simple macro, f.e. HBXBP_EXTENSION. Which is #defined by default." --- Which seems quite clear, but to clarify further, it means that while I can't decide whether we _should_ extend (I trust Pritpal and actual Xbase++/hbqt users on this), but I know we _may_ extend it, if we stick to a few rules: we extend it wisely and document all extensions in code. These rules should be similar to what we've been using when extending Clipper, maybe not so strict. IMO it's very important to do extensions along a documented procedure, otherwise there is no guarantee whatsoever that Xbase++ compatibility can be kept, or even tested. Which means we cut off Harbour + hbxbp as an upgrade path for Xbase++ users and make the transition a one way step, plus we can't guarantee any sort of parallelism through the transition process (I mean app can't be build for both platforms at the same time). If make Xbase++ users life more difficult to move to Harbour, it means Harbour userbase can't grow the way it otherwise would. Which isn't very good. [ about a few technical aspects of extending wisely and in documented way, pls see my recent msg. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 12:16 PM, Viktor Szakáts wrote: > Rather hbmk2 should be modified if possible to load > it without requiring such links. hbmk2 -traceonly demoqt hbmk2: Processing environment options: -compiler=gcc hbmk2: Processing local make script: hbmk.hbm hbmk2: Processing configuration: /opt/harbour/bin/hbmk.cfg hbmk2: Harbour compiler command (embedded): (/opt/harbour/bin/harbour) -n2 demoqt.prg -w3 -es2 -i/opt/harbour/include/harbour -i.. hbmk2: C compiler command: gcc -c -O3 -Wall -W -I/opt/harbour/include/harbour -I.. demoqt.c /var/folders/5Y/5Yrw2w+kGvqg7LiwM4q2Yk+++TI/-Tmp-/hbmk_gvsy4s.c hbmk2: Linker command: gcc demoqt.o hbmk_gvsy4s.o -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lsupc++ -lhbcplr -lhbdebug -lharbour /Library/Frameworks/QtCore.framework/QtCore /Library/Frameworks/QtGui.framework/QtGui /Library/Frameworks/QtNetwork.framework/QtNetwork -bind_at_load -o demoqt -L/opt/harbour/lib/harbour I see a difference: I have a -lharbour you have /Users/vszakats/harbour/lib/darwin/gcc/libharbour.dylib I've tried to add -shared but it doesn't change. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12956] trunk/harbour
Pritpal Bedi escribió: Hi ... This is the reason I floated the idea of extending Xbase++ framework which has not been accepted by the group by now. Well on this I disagree with Viktor. I dont need backward compatibility with xbase++, so extending claes and/or creating new ones is ok with me. Once this class framework is ready for production apps I wont look back to Alaska's product. And since I intend to develop cross platforms apps compatibility is in fact impossible. This is just my oppinion of course, you are the Master and hbxbp is your child. Best Regards Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Please try this sendmail patch
Hi Francesco,
> If it works for you or doesn't, please test this patch in
> contrib\hbtip and report.
The additional two GetOK() calls don't look correct to me,
first of all because they happen right after opening the
connection when no request has been sent out to SMTP server
yet.
Second because GetOK() _is_ actually called after HELO and
EHLO requests in line 124 and 143.
Can you try whether upping the timeout by itself solves your
problems?
Brgds,
Viktor
>
> Index: smtpcli.prg
> ===
> --- smtpcli.prg (revision 12954)
> +++ smtpcli.prg (working copy)
> @@ -96,10 +97,11 @@
> bTrace := {| cMsg | iif( PCount() > 0, oLog:Add( cMsg ), oLog:Close() )
> }
>ENDIF
>
>::super:New( oUrl, bTrace, oCredentials )
>
>::nDefaultPort := iif( ::oUrl:cProto == "smtps", 465, 25 )
> - ::nConnTimeout := 5000
> + ::nConnTimeout := 5
>::nAccessMode := TIP_WO // a write only
>
>RETURN Self
> @@ -110,6 +112,10 @@
> RETURN .F.
>ENDIF
>
> + IF ! ::GetOk()
> + RETURN .F.
> + ENDIF
> +
>DEFAULT lTLS TO .F.
>
>IF lTLS
> @@ -129,6 +135,10 @@
> RETURN .F.
>ENDIF
>
> + IF ! ::GetOk()
> + RETURN .F.
> + ENDIF
> +
>DEFAULT lTLS TO .F.
>
>IF lTLS
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12958] trunk/harbour
Revision: 12958 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12958&view=rev Author: vszakats Date: 2009-11-21 11:38:44 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 12:38 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg ! Fixed to make clang behave like gcc when decorating lib references. ! Fixed to include clang in 'allgcc' filter. + Added native header detection when using clang. ! Internal change to use detected c compiler name instead of hard-wired 'gcc' when doing native header detection for .c files (using -MM option). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: SF.net SVN: harbour-project:[12956] trunk/harbour
I confirm this behaviour. And i suggest also to take in count of the .INI files in the project structure, as could be useful to rebuild the app after a change in one of these files. xMate hitself has support for ini files, but don't includes this files in the search and replace function. I think that, because often the content of ini file is related to code, we could include also this type in selection of search and replace function. Thanks for the great work you're making, Pritpal. Best regards. Maurizio > -Messaggio originale- > Da: Angel Pais [mailto:amigo...@adinet.com.uy] > Inviato: sabato 21 novembre 2009 3.12 > A: harbour@harbour-project.org > Oggetto: [Harbour] Re: SF.net SVN: harbour-project:[12956] > trunk/harbour > > vouch...@users.sourceforge.net escribió: > > * contrib/hbide/hbide.prg > > + Implemented prototype of . > > Also play with various icons. Docks at the right and > at the bottom can be collapsed. > > Please forward suggesstions. > > Hi Pritpal > > I was playing with the new toy and noticed something weird: > > Open the app, then click on close button and everything is ok. > Open it again, then open hbide.prg with the source editor, close both > tabs and try to close the app. It freezes and has to be > killed with the > task manager. > > SO: win XP, harbour+mingw > > Regards > Angel > > > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12959] trunk/harbour/ChangeLog
Revision: 12959 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12959&view=rev Author: vszakats Date: 2009-11-21 12:53:58 + (Sat, 21 Nov 2009) Log Message: --- Typo in ChangeLog entry: 2009-11-20 13:18 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) [...] * contrib/hbwin/win_osc.c + Added OS_ISWIN7(). Borrowed from xhb / Patrick Mast. Modified Paths: -- trunk/harbour/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
Rather hbmk2 should be modified if possible to load it without requiring such links. Any ideas how to do this? This is current link command when using -shared mode: --- hbmk2: Linker command: /Developer/usr/bin/gcc hbide.o hbmk_KNOaaX.o -lhbxbp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lsupc++ -lhbcplr -lhbdebug /Library/Frameworks/QtCore.framework/QtCore /Library/Frameworks/QtGui.framework/QtGui /Library/Frameworks/QtNetwork.framework/QtNetwork /Users/vszakats/harbour/lib/darwin/gcc/libharbour.dylib -bind_at_load -o hbide -L/Users/vszakats/harbour/lib/darwin/gcc --- Brgds, Viktor On 2009 Nov 21, at 05:39, Lorenzo Fiorini wrote: > To get ./demoqt working after hbmk2 demoqt I have to do ln -s > libharbour.dylib harbour.dylib. > > Any comment? > > best regards, > Lorenzo > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbide RTE
Hi Pritpal, I still can't simply close hbide window with close button or normal app/window closing means. While I've been trying, I got this: --- Error BASE/1004 No exported method: ACHILDREN Called from ACHILDREN(0) Called from XBPTABPAGE:DESTROY(0) Called from (b)XBPWINDOW_DESTROY(0) Called from AEVAL(0) Called from XBPWINDOW:DESTROY(0) Called from XBPTABWIDGET:DESTROY(0) Called from (b)XBPWINDOW_DESTROY(0) Called from AEVAL(0) Called from XBPDRAWINGAREA:DESTROY(0) Called from (b)XBPWINDOW_DESTROY(0) Called from AEVAL(0) Called from XBPDIALOG:DESTROY(0) Called from HBIDE:CREATE(325) Called from MAIN(104) Segmentation fault --- OS X 10.6.2 64-bit with QT 4.6 RC. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTwin console window
Thanks for the clarification. Anyway, i tested the gtwvt approach and crashed in the double console window problem. Also compiling wvtext.prg in tests folder with the command: hbmk2 wvtest.prg gives me the same result. The gtapi.txt in the doc folder gives some directive to avoid this empty console window added, but i don't resolve to obtain the only wvt window be displayed. Sorry for my sure misunderstood. Best regards. Maurizio Viktor Szakáts wrote: > >> Ther'is a way to maximize the windows of a console application (GTwin)? >> I means no fullscreen mode, but resize avoiding any scrollbar. >> In my compiled app, the horizontal size don't match the 80 chars * >> charwidth >> pixel and is needed to click the maximize button on the titlebar to avoid >> the display of the horizontal scrollbar. >> Any hint? > > There is no programmatic way to control native win console window > look/behavior besides setting the number of rows/cols of screen area. > > Solution: Use GTWVT. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/GTwin-console-window-tp26443609p26455726.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTwin console window
Forget previous message... Found the -gui switch and solved the problem. Best regards. Maurizio Maurizio la Cecilia wrote: > > Thanks for the clarification. > Anyway, i tested the gtwvt approach and crashed in the double console > window problem. > Also compiling wvtext.prg in tests folder with the command: > hbmk2 wvtest.prg > gives me the same result. > The gtapi.txt in the doc folder gives some directive to avoid this empty > console window added, but i don't resolve to obtain the only wvt window be > displayed. > Sorry for my sure misunderstood. > Best regards. > Maurizio > > > Viktor Szakáts wrote: >> >>> Ther'is a way to maximize the windows of a console application (GTwin)? >>> I means no fullscreen mode, but resize avoiding any scrollbar. >>> In my compiled app, the horizontal size don't match the 80 chars * >>> charwidth >>> pixel and is needed to click the maximize button on the titlebar to >>> avoid >>> the display of the horizontal scrollbar. >>> Any hint? >> >> There is no programmatic way to control native win console window >> look/behavior besides setting the number of rows/cols of screen area. >> >> Solution: Use GTWVT. >> >> Brgds, >> Viktor >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> >> > > -- View this message in context: http://old.nabble.com/GTwin-console-window-tp26443609p26455796.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal about hbide
You can start adding 2009/11/20 francesco perillo : > Hi, > I was told that hbide will integrate support for svn... > > Since I'm an user of Mercurial I'd like to talk with you to cooperate > to add support for this dvcs... > > Francesco > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano Iscritto all'albo dei CTU presso il Tribunale di Novara per materia Informatica Delta Informatica S.r.l. (http://www.deltain.it/) (+39 0321 455962) Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12957] trunk/harbour
Revision: 12957 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12957&view=rev Author: vszakats Date: 2009-11-21 10:11:32 + (Sat, 21 Nov 2009) Log Message: --- 2009-11-21 11:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbsetup.h * utils/hbmk2/hbmk2.prg * config/darwin/clang.mk + Using __clang__ for Clang detection instead of locally rolled solution. * src/common/hbver.c + Added Clang compiler detection. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/darwin/clang.mk trunk/harbour/include/hbsetup.h trunk/harbour/src/common/hbver.c trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12943] trunk/harbour
Hi Przemek, On 2009 Nov 20, at 14:29, Przemysław Czerpak wrote: > On Fri, 20 Nov 2009, Szak�ts Viktor wrote: > > Hi, > >> I'd say go for it. > > I'll commit it in a while. Thank you, I saw you did it since. >> Any reason we don't seem to have HB_FM_DLMT_ALLOC >> enabled by default when building vmmt lib? I think >> we should enable it. > > For all platforms which now uses DLMALLOC I think it can be enabled. > For sure for 64bit builds. Using many mspaces on 32bit platforms may > cause memory fragmentation. For 99% of programs it should not be a > problem but if someone created code which allocates very large memory > blocks containg hundreds of megabytes then it may create problems. > On 64bit platforms the address space is large enough to fully eliminate > this problem. > There is also yet another problem with DLMALLOC. Valgrind does not > recognize it so it cannot create some memory statistics when it's used > instead of default memory manager which is replaced dynamically by > valgrind. It means that for Linux it should be optional. > Anyhow I've just made some test with suse11.2-...@64 and DLMALLOC > compiled with hvmall.c is noticeable faster then default memory > manager and speed difference is quite huge (~15% in speedtst.prg). > so in some cases it can be important extension for final code. Well, pls feel free to decide, to me, from your words it seems it can be enabled for win/os2 platforms without any restrictions. For "valgrind platforms", IMO we may also enable it by default and disable it for debug builds only, since I believe the latter is typically used for valgrind testing. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12956] trunk/harbour
> Bruno Luciani wrote: >> >> Error compiling HBIDE last SVN Ubuntu Linux 9.10 >> >> 'QMAINWINDOW_ALLOWTABBEDDOCKS' >> > > I expect some mature messages though you have quickly reverted it. It's FAQ by now: It happens when older hbqt headers are present in central Harbour include dir, or in any dir user specifies using INCLUDE envvar. [ BTW, INCLUDE var usage is generally not a recommended pattern to follow. ] There are two solutions: 1) Update hbqt.ch in this/these locations. As for central Harbour dir, this needs 'make install' (just as Bruno wrote replying his own e-mail) 2) Delete hbqt.ch from this/these locations. This way hbide and all Harbour samples will still build properly, but it may break local dev environment depending on what setup is used, so use it with caution. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12956] trunk/harbour
Hi Pritpal, >> SO: win XP, harbour+mingw >> > > I know. I will concentrate on it once I will establish the parent/childs > relations for all the interface widgets. It is message loop which has gone > weired because not all the widgets are created through Xbp* class framework. > This tool is of hibrid mode using Xbp class framework with HBQT classes for > some widgets which are not available in Xbp. > > This is the reason I floated the idea of extending Xbase++ framework > which has not been accepted by the group by now. > > But I am feeling the pinch of this omission. AFAIK the only one reaction came from me telling you _can_ extend it, just guard all the extensions with HBXBP_EXTENSION. This looks like a pretty simple thing to do (although it needs some paying attention of course), and not a huge price to pay to create extensions. Since I assume clean extensions come in the form of new classes or new methods/vars in existing Xbase++ compatibility classes, another solution is to mark all these class/ method/var names with distinctive prefix (hb_/hb). I'd advise against hidden extensions like new parameters to existing methods or change of behavior, since these are much difficult to handle, but if you need to do such thing, the HBXBP_EXTENSION trick would work as well. Any of above is even useful for yourself if you ever want to do any Xbase++ compatibility testing of hbxbp code. Two more thoughs: 1) Apart from this, IMO it would be a great plus if users could mix hbxbp and hbqt usage in one app, as I'm sure there will ever be someone who find hbxbp feature not enough for their apps, and wants to use some hbqt features directly (and don't have the freedom or will to extend hbxbp). I assume it's not always nice to extend base hbxbp classes for _every_ need that appears when coding hbide. 2) hbide could be a nice showcase to present elegant way of hbxbp programming and if/where needed a nice showcase of mixing hbxbp and hbqt the "proper" way. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
