Re: [Harbour] DBF encryption
Przemysław Czerpak wrote: All such modifications will effect SIX3 compatibility. To touch it will have to repeat some tests with SIX3 and document differences and it will be time consuming process due to bugs in SIX3 library. I do not have time for it now, sorry. No problem, thanks for the response. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbide_pathProc() - Merging Paths - Clarification
Hello Viktor This is the changelog entry: * contrib/hbide/idemisc.prg + hbide_PathProc() This function can combine relative paths together so it's the key to avoid macros dealing with placing paths to their intended location. It can replace current method of = hb_dirBase(). F.e.: hbide_PathProc( "src/mysource_in_project.prg", "projects_dir/" ) -> "projects_dir/src/mysource_in_project.prg" hbide_PathProc( "projects/myproject.hbi", hb_dirBase() ) -> "C:/harbour/contrib/hbide/projects/myproject.hbi" Please use it. And I was experimenting with it. But I could not got the desired results. This is what I tried: filename_to_be_stored project_location hbide_pathProc( "C:\dev_sources\vouch\abc.prg", "C:\harbour\contrib\hbide\projects\hbide.hbi" ) and received: C:\dev_sources\vouch\abc.prg whereas I was expecting something like: ../../../../dev_sources/vouch/abc.prg this way only I can retain the relative paths in .hbi which will be transferable to any system and drive. Drive letter or root path is assumed the same. Or I am making a mistake ? - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/hbide-pathProc-Merging-Paths-Clarification-tp4505657p4505657.html Sent from the harbour-devel 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] Re: Alert() / print buffer Clipper -> Harbour difference
El 03/02/2010 1:22, smu johnson escribió: Hi, I found a problem that is very noticeable when using the ALERT() func. If your MS Windows buffer size setting ( http://209.97.219.2/sjohnson/misc/alert_problem_buffer500-set.png ) is to > 25, position screws up. This is not a problem with Clipper 5.2e (using Blinker). The alert box shows up like this: http://209.97.219.2/sjohnson/misc/alert_problem_buffer500.png ... but like I said, this difference does not show up if you keep the buffer height set to 25. But since Clipper does not have this problem, no matter what the value is set to, I thought I'd ask here. Thanks for reading. What can I do? -- smu johnson mailto:smujohn...@gmail.com>> You must put at the beggining of your main.prg: SetMode(25,80) HTH Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Alert() / print buffer Clipper -> Harbour difference
Hi, I found a problem that is very noticeable when using the ALERT() func. If your MS Windows buffer size setting ( http://209.97.219.2/sjohnson/misc/alert_problem_buffer500-set.png ) is to > 25, position screws up. This is not a problem with Clipper 5.2e (using Blinker). The alert box shows up like this: http://209.97.219.2/sjohnson/misc/alert_problem_buffer500.png ... but like I said, this difference does not show up if you keep the buffer height set to 25. But since Clipper does not have this problem, no matter what the value is set to, I thought I'd ask here. Thanks for reading. What can I do? -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
To Viktor, El 03/02/2010 0:09, Viktor Szakáts escribió: for GPF at application startup caused by accessing TSD before HVM stack is initialized. It seems to work though it can be greatly simplified and of course the GPF in startup code and non HVM threads has to be fixed. That pretty much sums up what I didn't like about the implementation without even knowing the exact details (I'd have bet that MT mode had problems f.e.) That's great!. No Comments. :-) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
I have the test which has been proven with our Clipper 5.2e running on DOS
of a difference in Harbour below is an explanation I received by e-mail:
== start here
If eval({||devout("hello"),.f.)}) .or. .t.
endif
In Clipper the eval() will process (even though it appears redundant because
.t. will make the IF statement always return .t.
Harbour does not process the eval()
Unfortunately, my code could be scattered with situations where I have used
the Clipper behaviour to do something intentional (as in my search routine).
I will need to look for other places (or more likely wait for things to
break) and change the logic to get around this unless Harbour is interested
in making this fully compatible.
==
Any thoughts? Is it because the guy who showed me this line of code relied
too much on Clipper bugs when programming?
Thanks Przemek
On Thu, Jan 28, 2010 at 3:42 AM, smu johnson wrote:
> Thanks for the reply.
>
> As far as I can tell, I have found a difference in Clipper and Harbour in
> terms of these evaluations. But as I said earlier, I could be completely
> mistaken. I have done a lot of little tests to check the -z flag but
> unfortunately I'm not that good at Clipper as one of my friends is. (I'm
> better at Perl, etc). But if I can demonstrate the problem in a small Hello
> World type example, I will post it, to try to figure out what is happening,
> with your help. :) The only reason I bring this up, is because I am trying
> to compile an old DOS16 app and it is behaving differently on these .or.
> lines.
>
> Thanks again for reading!!! I have read your informative reply, and will
> test what you said out for myself to try to figure out what is going on.
>
>
> 2010/1/28 Przemysław Czerpak
>
>> On Thu, 28 Jan 2010, smu johnson wrote:
>>
>>
>> Hi!
>>
>> > I noticed the -z switch allows to stop using shortcuts for .and. and
>> .or.
>> > Clipper conditions.
>> > Without -z, if I do:
>> > eval(something) .or. .t. // will recognize that it's already true, and
>> not
>> > make the eval
>> > When -z is enabled:
>> > .f. .and. eval(something) // will try to eval 'something', despite the
>> fact
>> > that .f. already failed.
>>
>> Exactly just like in Clipper.
>>
>> > ... If what I said is actually true, is there any sort of secondary -z
>> > switch that can be done to make it simply not be lazy, yet fail on first
>> > condition?
>>
>> It's default behavior. Just simply do not use -z or better use the same
>> switches as in Clipper.
>>
>> > ... If what I said is complete nonsense and complete BS, I will have to
>> go
>> > through the code I'm trying to compile that someone else wrote and see
>> > what's up. By the way, I realize that the above examples are not the
>> best
>> > way to do things... and I sure as heck wouldn't do it that way myself.
>> Just
>> > trying to get some existing Clipper functioning code to behave the same
>> way
>> > in Harbour.
>>
>> You mixed two different things which confuse you:
>> 1. compile time optimizations
>> 2. lazy boolean expression evaluation
>>
>> Both Harbour and Clipper support -z switch to control lazy expression
>> evaluation. It works in the same way. This code illustrate it:
>>
>> proc main()
>> local f:=.F., t:=.T.
>> ?; ?? .t. .or. f()
>> ?; ?? .f. .and. f()
>> ?; ?? f() .or. .t.
>> ?; ?? f() .and. .f.
>> ?
>> ?; ?? t .or. f()
>> ?; ?? f .and. f()
>> ?; ?? f() .or. t
>> ?; ?? f() .and. f
>> ?
>> return
>> func f()
>> ?? "[F()] "
>> return .T.
>>
>> compile it with and without -z switch using Harbour and Clipper and
>> compare results. Please note that when -z is not used then first 4
>> expressions are optimized at compile time and next 4 ones are optimized
>> at runtime. Compile time optimization calculates final result and
>> replace the code with simple .F. or .T. so F() function is never
>> execute. It's also Clipper compatible behavior.
>> Anyhow Clipper does not optimize all expressions (i.e. it does not
>> optimize if message is send to it: :msg()) and cannot strip
>> parenthesis in optimization process. Harbour does not make any exceptions
>> here and optimize all end everywhere if it's possible what seems to be
>> correct behavior. You can add these lines to above test to see the
>> difference:
>>
>> ?; ?? (.t.) .or. f()
>> ?; ?? (.f.) .and. f()
>> ?; ?? f() .or. (.t.)
>> ?; ?? f() .and. (.f.)
>> ?
>> ?; ?? ( .t. .or. f() ):classname
>> ?; ?? ( .f. .and. f() ):classname
>> ?; ?? ( f() .or. .t. ):classname
>> ?; ?? ( f() .and. .f. ):classname
>> ?
>>
>> compile it without -z switch and compare Clipper and Harbour results.
>> If you want to replicate also this Clipper behavior then you can use
>> -kc switch which disables all Harbour extensions though I cannot promise
>> that we located all places were Clipper does not make compile time
>> optimization and added necessary protection for -kc switch. If you will
>> find
[Harbour] SF.net SVN: harbour-project:[13750] trunk/harbour
Revision: 13750 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13750&view=rev Author: druzus Date: 2010-02-03 02:45:32 + (Wed, 03 Feb 2010) Log Message: --- 2010-02-03 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/hvm.c * harbour/src/vm/itemapi.c * harbour/src/rtl/errapi.c * harbour/contrib/xhb/cstructc.c * changed HB_TRACE_STEALTH() to HB_TRACE() * harbour/include/hbtrace.h * harbour/include/hbstack.h * harbour/src/vm/estack.c * harbour/src/nortl/nortl.c + added hb_traceset() and hb_traceinfo() * harbour/include/hbtrace.h * harbour/src/common/hbtrace.c * use hb_traceset()/hb_traceinfo() instead of hb_tr_file_, hb_tr_line_, hb_tr_level_ - removed hb_tr_file_, hb_tr_line_, hb_tr_level_ + added hb_tr_stealth() function and modified HB_TRACE_STEALTH() macro to not touch any of hb_tr_*_ global variables + added HB_TR_FM macro which can be used to infrom FM statistic module that it should take filename and line number from hb_tr_*_ global variables * harbour/src/vm/fm.c - removed dummy code with HB_TR_LEVEL setting - HB_TR_LEVEL is always defined by hbtrace.h * use hb_traceset()/hb_traceinfo() instead of hb_tr_file_, hb_tr_line_, hb_tr_level_ * respect HB_TR_FM * harbour/src/rtl/gttrm/gttrm.c * formatting * harbour/src/vm/itemapi.c * harbour/src/vm/extend.c * harbour/src/rtl/descend.c * harbour/src/rtl/hbgtcore.c * harbour/src/rtl/mtran.c * harbour/src/rtl/samples.c * harbour/src/common/hbstr.c * harbour/src/common/hbdate.c ! fixed possible GPF traps in HB_TRACE() messages caused by %s used for not \0 terminated strings or uninitialized buffers Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/cstructc.c trunk/harbour/include/hbstack.h trunk/harbour/include/hbtrace.h trunk/harbour/src/common/hbdate.c trunk/harbour/src/common/hbstr.c trunk/harbour/src/common/hbtrace.c trunk/harbour/src/nortl/nortl.c trunk/harbour/src/rtl/descend.c trunk/harbour/src/rtl/errapi.c trunk/harbour/src/rtl/gttrm/gttrm.c trunk/harbour/src/rtl/hbgtcore.c trunk/harbour/src/rtl/mtran.c trunk/harbour/src/rtl/samples.c trunk/harbour/src/vm/estack.c trunk/harbour/src/vm/extend.c trunk/harbour/src/vm/fm.c trunk/harbour/src/vm/hvm.c trunk/harbour/src/vm/itemapi.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
On Tue, 02 Feb 2010, April White wrote:
Hi,
> Thank you Przemek. I've tried your suggestion but my implementation
> does not work as expected, the stats output is:
>fm.c:1134: HB_TR_ERROR Block 1 (size 40) HB_BTREEINSERT(0),
> "F8A454004001550058D
>C4B00010001001000F03F0A000200"
> But I know the memory allocation is in a sub-function.
You haven't set DEBUG tracing level. You can do that setting
HB_TR_LEVEL envvar, i.e.:
export HB_TR_LEVEL=HB_TR_DEBUG
or in DOS/Windows:
set HB_TR_LEVEL=HB_TR_DEBUG
Just try.
I'll commit in a while modifications which allow to eliminate
setting HB_TR_LEVEL using HB_TR_FM message level.
You will have to modify your code to:
void * hb_xgrab_fm( void *buffer, ULONG ulSize,
const char * szFile, int iLine )
{
hb_traceset( HB_TR_FM, szFile, iLine, NULL );
return hb_xrealloc( buffer, ulSize );
}
You can use hb_xrealloc( NULL, ulSize ) to allocate memory so you do not
need additional condition in hb_xgrab_fm() function.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
Thank you Przemek. I've tried your suggestion but my implementation
does not work as expected, the stats output is:
fm.c:1134: HB_TR_ERROR Block 1 (size 40) HB_BTREEINSERT(0),
"F8A454004001550058D
C4B00010001001000F03F0A000200"
But I know the memory allocation is in a sub-function.
My implementation is different from yours but keeps the spirit. I added
some debug code not shown below so I know it is compiling this code and
executing it. My system is:
WinXP SP2
MinGW32 from Qt installer
HB_USER_CFLAGS to compile harbour:
-O3 -Wall -Wunused-variable -Wpointer-arith -DHB_FM_STATISTICS
HB_USER_CFLAGS to compile this project:
-O3 -Wall -Wunused-variable -Wpointer-arith -DHB_FM_STATISTICS
-DHB_TR_LEVEL=5
My existing code already uses a local function to memory allocation, a
wrapper for hb_xgrab() or hb_xrealloc().
#if HB_TR_LEVEL >= HB_TR_DEBUG
#define BufferAlloc(n) hb_xgrab_fm( NULL, (n), __FILE__, __LINE__ )
#define BufferRealloc(p,n) hb_xgrab_fm( (p), (n), __FILE__, __LINE__ )
extern HB_EXPORT void * hb_xgrab_fm( void *buffer, ULONG ulSize, const
char * szFile, int iLine )
{
void *tmpBuffer;
hb_tr_file_ = szFile;
hb_tr_line_ = iLine;
tmpBuffer = buffer ? hb_xrealloc( buffer, ulSize ) : hb_xgrab( ulSize );
return tmpBuffer;
}
#else
...
#endif
--
Without facts, the decision cannot be made logically. You must rely on your
human intuition.
- Spock, 'Assignment: Earth', stardate unknown
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Go Programming Language vs Harbour Programming Languages
I am pleased to announce that the GCC Steering Committee has accepted the contribution of the gccgo front-end and gcc-specific runtime for the Go language with Ian Taylor appointed maintainer. The GCC Release Managers will decide the details about the timing of the merge and inclusion in GCC 4.5 or later. Please join me in congratulating and thanking Ian and the Go language developers. Please update your listing in the MAINTAINERS file. Happy hacking! David http://article.gmane.org/gmane.comp.gcc.devel/111603 Best regards, Itamar M. Lins Jr. ___ 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:[13749] trunk/harbour
Revision: 13749 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13749&view=rev Author: vouchcac Date: 2010-02-03 00:39:51 + (Wed, 03 Feb 2010) Log Message: --- 2010-02-02 16:24 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.hbp * contrib/hbide/hbide.prg * contrib/hbide/idedocks.prg * contrib/hbide/idefindreplace.prg * contrib/hbide/idemisc.prg * contrib/hbide/ideprojmanager.prg * contrib/hbide/iderequests.prg * contrib/hbide/idethemes.prg * contrib/hbide/resources/projectproperties.ui + contrib/hbide/resources/finddialog.uic + contrib/hbide/resources/findinfiles.uic + contrib/hbide/resources/findsource.uic + contrib/hbide/resources/mainwindow.uic + contrib/hbide/resources/projectproperties.uic + contrib/hbide/resources/selectionlist.uic + contrib/hbide/resources/selectproject.uic + contrib/hbide/resources/themes.uic * contrib/hbqt/hbqt.ch * contrib/hbqt/qtgui/QLabel.cpp * contrib/hbqt/qtgui/QSizePolicy.cpp * contrib/hbqt/qtgui/QSpacerItem.cpp * contrib/hbqt/qth/QLabel.qth * contrib/hbqt/qth/QSizePolicy.qth * contrib/hbqt/qth/QSpacerItem.qth * contrib/hbqt/THbQtUI.prg * contrib/hbxbp/xbpdialog.prg * contrib/hbxbp/xbpwindow.prg + This commit implements .uic files generated via uic.exe of Qt distribution given a .ui file. And hence eliminated the wooping cargo of QtUiTools.lib which consumes arount 23+ MB over and above of application load. All the dialogs/windows used in hbIDE are fully functional. This implementation is in parallel of previous one and either can be used. The difference in syntax is ( and as used in hbIDE ) #ifdef HBIDE_USE_UIC oDlg := HbQtUI():new( ::oIDE:resPath + "selectproject.uic", ::oDlg:oWidget ):build() #else oDlg := HbQtUI():new( ::oIDE:resPath + "selectproject.ui", ::oDlg:oWidget ):create() #endif To take advantage of this feature you need to compile hbIDE with -dHBIDE_USE_UIC. You can examine the task manager for memory usage, with and without -dHBIDE_USE_UIC. Please note that this implementation is not 100% complete. I could synchronize the dialogs of hbIDE only. Though most of the code is good for daily-use widgets still we need to add some more functionality into the code. But it is simple. Mainly we be needing more constants included in hash to convert string defines to numeric representation. Please test and report any issues. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.hbp trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idedocks.prg trunk/harbour/contrib/hbide/idefindreplace.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/iderequests.prg trunk/harbour/contrib/hbide/idethemes.prg trunk/harbour/contrib/hbide/resources/projectproperties.ui trunk/harbour/contrib/hbqt/THbQtUI.prg trunk/harbour/contrib/hbqt/hbqt.ch trunk/harbour/contrib/hbqt/qtgui/QLabel.cpp trunk/harbour/contrib/hbqt/qtgui/QSizePolicy.cpp trunk/harbour/contrib/hbqt/qtgui/QSpacerItem.cpp trunk/harbour/contrib/hbqt/qth/QLabel.qth trunk/harbour/contrib/hbqt/qth/QSizePolicy.qth trunk/harbour/contrib/hbqt/qth/QSpacerItem.qth trunk/harbour/contrib/hbxbp/xbpdialog.prg trunk/harbour/contrib/hbxbp/xbpwindow.prg Added Paths: --- trunk/harbour/contrib/hbide/resources/finddialog.uic trunk/harbour/contrib/hbide/resources/findinfiles.uic trunk/harbour/contrib/hbide/resources/findsource.uic trunk/harbour/contrib/hbide/resources/mainwindow.uic trunk/harbour/contrib/hbide/resources/projectproperties.uic trunk/harbour/contrib/hbide/resources/selectionlist.uic trunk/harbour/contrib/hbide/resources/selectproject.uic trunk/harbour/contrib/hbide/resources/themes.uic 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:[13748] trunk/harbour
Revision: 13748 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13748&view=rev Author: vszakats Date: 2010-02-02 23:41:42 + (Tue, 02 Feb 2010) Log Message: --- 2010-02-03 00:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbpgsql/postgres.c % Optimizations. * contrib/hbpgsql/postgres.c * contrib/hbgd/gdwrp.c * contrib/hbbmcdx/bmdbfcdx.c % 'hb_itemRelease( hb_itemReturnForward( p ) )' -> 'hb_itemReturnRelease( p )' Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbgd/gdwrp.c trunk/harbour/contrib/hbpgsql/postgres.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] Debugging c code
To Xavi and All,
>> Thank you Przemek. It's not so easy because these solutions don't
>> work with C++ new operator.
>
> If you want to include memory allocated by C++ code to FM static
> then it's necessary to overload new and delete operators and redirect
> them to hb_xgrab()/hb_xfree(). hbmk2 has an option to enable such
> overloading. Anyhow C preprocessor is too week to automatically insert
> instruction which can safe __FILE__ and __LINE__ values so it cannot
> be cleanly done. Using macros like HB_TRACEFM( x ) you send is not
> solution too because in C++ code NEW/DELETE operators can be executed
> indirectly. I.e.:
> {
> my_type x;
> f( &x );
> }
> can activate code constructor and destructors which executes indirectly
> some other code which can allocated new memory. To correctly set file
> and line information in such code you will have to make sth like:
> {
> HB_TRACEFM( my_type x ); // this code is illegal in ANSI C mode !!!
> HB_TRACEFM( f( &x ) );
> HB_TRACEFM( ) // dummy call to set valid line and file info for
> // destructors which also can allocate some memory
> }
>
> In fact for real C++ code using extensively constructors and destructors
> you will have to enclose nearly _each_ line of code inside HB_TRACEFM()
> so for me HB_TRACEFM() isn't reasonable solution, too.
>
> Please also note that:
> HB_TRACEFM( my_type x );
> just like:
> HB_TRACEFM( void * ptr = hb_xgrab( 100 ) );
...
> generates in hidden way code which is not ANSI C compatible what creates
> yet another problem.
>
> Instead of using such HB_TRACEFM() macro I suggest to simply define
> macro which will set file and line number for FM module, i.e.:
>
> #define HB_TR_SET_CREATE(l) do { \
> hb_tr_level_ = l; \
> hb_tr_file_ = __FILE__; \
> hb_tr_line_ = __LINE__; \
>} while( 0 )
>
> #if HB_TR_LEVEL >= HB_TR_DEBUG
> #define HB_TR_SET_HB_TR_DEBUG() HB_TR_SET_CREATE(HB_TR_DEBUG)
> #else
> #define HB_TR_SET_HB_TR_DEBUG()
> #endif
> [...]
> #if 1 /* always! */
> #define HB_TR_SET_HB_TR_ALWAYS()HB_TR_SET_CREATE(HB_TR_ALWAYS)
> #else
> #define HB_TR_SET_HB_TR_ALWAYS()
> #endif
>
> #define HB_TR_SET(l) HB_TR_SET_##l()
>
> so user can mark any place in his code before calling hb_xgrab()
> or activating any other code which may allocates new memory by simple
> adding HB_TR_SET( HB_TR_DEBUG ); i.e.
>
> HB_TR_SET( HB_TR_DEBUG ); // code marker, store file and line info
> ptr = hb_xgrab( 100 );
>
> In such version it's explicitly visible for users what such macros does
> and which lines will be reported by FM statistic module.
> And if you still prefer HB_TRACEFM() then you can simply define in your
> code:
> HB_TRACEFM( x ) HB_TR_SET( HB_TR_ALWAYS ); x
>
> In the code you created you are storing with each memory block also
> the code inside HB_TRACEFM() macro ( #x ) in the 264 bytes buffer
> attached to each memory block. For me it seems to be redundant. Having
> file name and line number is enough to check the exact code so it does
> not give any new functionality but increase the overhead created by
> FM statistic module reducing the speed and increasing total memory
> usage. I agree that final FM log looks nicer with such feature but
> personally I do not think that such reason is important enough. Anyhow
> this are only my personal feelings so it should be rather group
> decision. If other developers things that it's important to attach
> text with source code inside HB_TRACEFM() macro to each memory block
> allocated by FM statistic module to report such lines in fm.log file
> and agree to accept slowness and additional memory overhead because
> information about source file name and line number is not enough
> then we can add it.
>
>> Attache files ready for committed, I've taken care to preserve intact
>> the largest existing code as possible.
>> Please, you can review especially in MT mode. I've tried it with
>> success in a large multi-threaded application without conflict or
>> deadlock but maybe I missed something and I don't know force the
>> error.
>
> I see that you used TSD structure allocated on HVM stack to make it
> MT safe. But it creates one serious problem. It means that it's
> not possible to activate this code before HVM stack is created
> by application startup code and it's not possible to use hb_xgrab()
> by non HVM threads. I only guess that this trick with s_pInfoEx
> which makes it much more complicated then necessary is workaround
> for GPF at application startup caused by accessing TSD before HVM
> stack is initialized. It seems to work though it can be greatly
> simplified and of course the GPF in startup code and non HVM threads
> has to be fixed.
That pretty much sums up what I didn't like about the
imple
[Harbour] Binaries for Suse
Hi! URL to download of Harbour 2.0? Best regards. Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Przemek Q: SIX "FOR" clause Clipper/Harbour difference
The senior Clipper programmer here wanted me to ask someone this question. I couldn't think of a better person to ask than you! :) Question: - When a table's index file is re-opened (it was previously created), does it have to evaluate the FOR clause, or can it wait to do that only when a value in the table row changes? In SIX, it does not check the FOR expression when it opens an index file. In Harbour, when you open the index file it will evaluate the FOR expression, and if any variables or functions in that expression are not visible, the system will crash (undefined variable/function). eg. Index on iif(x=3,"a","b") tag "temp" of test.cdx When the index is opened (set index to...) if X is not visible, Harbour will crash. In Clipper, it will only crash if a row in the table changes value and the index needs to be updated. Unfortunately, my code has lots of specialized temporary indexes that are created and then used within a specific function. This does not present a problem until a timer event fires, which needs to close files to do "something". Upon reopening those file before RETURNing back the original function, the system crashes because the FOR in the index has variables out of scope. I can rewrite these but I will probably have to use Private variables and non-Static functions. Many thanks in advance -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
On Tue, 02 Feb 2010, Xavi wrote:
Hi,
> Thank you Przemek. It's not so easy because these solutions don't
> work with C++ new operator.
If you want to include memory allocated by C++ code to FM static
then it's necessary to overload new and delete operators and redirect
them to hb_xgrab()/hb_xfree(). hbmk2 has an option to enable such
overloading. Anyhow C preprocessor is too week to automatically insert
instruction which can safe __FILE__ and __LINE__ values so it cannot
be cleanly done. Using macros like HB_TRACEFM( x ) you send is not
solution too because in C++ code NEW/DELETE operators can be executed
indirectly. I.e.:
{
my_type x;
f( &x );
}
can activate code constructor and destructors which executes indirectly
some other code which can allocated new memory. To correctly set file
and line information in such code you will have to make sth like:
{
HB_TRACEFM( my_type x ); // this code is illegal in ANSI C mode !!!
HB_TRACEFM( f( &x ) );
HB_TRACEFM( ) // dummy call to set valid line and file info for
// destructors which also can allocate some memory
}
In fact for real C++ code using extensively constructors and destructors
you will have to enclose nearly _each_ line of code inside HB_TRACEFM()
so for me HB_TRACEFM() isn't reasonable solution, too.
Please also note that:
HB_TRACEFM( my_type x );
just like:
HB_TRACEFM( void * ptr = hb_xgrab( 100 ) );
generates in hidden way code which is not ANSI C compatible what creates
yet another problem.
Instead of using such HB_TRACEFM() macro I suggest to simply define
macro which will set file and line number for FM module, i.e.:
#define HB_TR_SET_CREATE(l) do { \
hb_tr_level_ = l; \
hb_tr_file_ = __FILE__; \
hb_tr_line_ = __LINE__; \
} while( 0 )
#if HB_TR_LEVEL >= HB_TR_DEBUG
#define HB_TR_SET_HB_TR_DEBUG() HB_TR_SET_CREATE(HB_TR_DEBUG)
#else
#define HB_TR_SET_HB_TR_DEBUG()
#endif
[...]
#if 1 /* always! */
#define HB_TR_SET_HB_TR_ALWAYS()HB_TR_SET_CREATE(HB_TR_ALWAYS)
#else
#define HB_TR_SET_HB_TR_ALWAYS()
#endif
#define HB_TR_SET(l) HB_TR_SET_##l()
so user can mark any place in his code before calling hb_xgrab()
or activating any other code which may allocates new memory by simple
adding HB_TR_SET( HB_TR_DEBUG ); i.e.
HB_TR_SET( HB_TR_DEBUG ); // code marker, store file and line info
ptr = hb_xgrab( 100 );
In such version it's explicitly visible for users what such macros does
and which lines will be reported by FM statistic module.
And if you still prefer HB_TRACEFM() then you can simply define in your
code:
HB_TRACEFM( x ) HB_TR_SET( HB_TR_ALWAYS ); x
In the code you created you are storing with each memory block also
the code inside HB_TRACEFM() macro ( #x ) in the 264 bytes buffer
attached to each memory block. For me it seems to be redundant. Having
file name and line number is enough to check the exact code so it does
not give any new functionality but increase the overhead created by
FM statistic module reducing the speed and increasing total memory
usage. I agree that final FM log looks nicer with such feature but
personally I do not think that such reason is important enough. Anyhow
this are only my personal feelings so it should be rather group
decision. If other developers things that it's important to attach
text with source code inside HB_TRACEFM() macro to each memory block
allocated by FM statistic module to report such lines in fm.log file
and agree to accept slowness and additional memory overhead because
information about source file name and line number is not enough
then we can add it.
> Attache files ready for committed, I've taken care to preserve intact
> the largest existing code as possible.
> Please, you can review especially in MT mode. I've tried it with
> success in a large multi-threaded application without conflict or
> deadlock but maybe I missed something and I don't know force the
> error.
I see that you used TSD structure allocated on HVM stack to make it
MT safe. But it creates one serious problem. It means that it's
not possible to activate this code before HVM stack is created
by application startup code and it's not possible to use hb_xgrab()
by non HVM threads. I only guess that this trick with s_pInfoEx
which makes it much more complicated then necessary is workaround
for GPF at application startup caused by accessing TSD before HVM
stack is initialized. It seems to work though it can be greatly
simplified and of course the GPF in startup code and non HVM threads
has to be fixed.
In general whole HB_TRACE() module should be fixed to be MT safe.
Unfortunately it can be cleanly done without any TSD/TLS variables
only using C99 macros :-(.
Anyhow it systematically begins to be bigger problems
Re: [Harbour] SF.net SVN: harbour-project:[13745] trunk/harbour
On Tue, Feb 2, 2010 at 9:46 PM, wrote: > * contrib/hbpgsql/postgres.c > ... > ; TODO: Fix sloppy parameter checking which only check number of > parameters instead of enforcing expected type. > ; Please test. Many thanks, I'll test it tomorrow. 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:[13747] trunk/harbour
Revision: 13747 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13747&view=rev Author: vszakats Date: 2010-02-02 21:24:33 + (Tue, 02 Feb 2010) Log Message: --- 2010-02-02 22:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbpgsql/postgres.c ! PQEXECPARAMS() fixed to not GPF when non-array is passed as 3rd parameter. ! PQESCAPEBYTEACONN() fixed to not GPF when non-string is passed as 2nd parameter. ! PQFNUMBER() fixed GPF (after prev commit) % Deleted hb_pcount() checks. This served no useful purpose. It's better to check for HB_IS*() is we want to enforce some parameters. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbpgsql/postgres.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:[13746] trunk/harbour
Revision: 13746 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13746&view=rev Author: vszakats Date: 2010-02-02 20:52:22 + (Tue, 02 Feb 2010) Log Message: --- 2010-02-02 21:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbpgsql/postgres.c * contrib/hbpgsql/tests/test.prg * Destructor PQCLOSETRACE() marked as deprecated, replaced in test app with NIL assignment. ! Fixes to FILE object type. ; All this is only relevant if built with NODLL flag. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbpgsql/postgres.c trunk/harbour/contrib/hbpgsql/tests/test.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
[Harbour] SF.net SVN: harbour-project:[13745] trunk/harbour
Revision: 13745 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13745&view=rev Author: vszakats Date: 2010-02-02 20:45:51 + (Tue, 02 Feb 2010) Log Message: --- 2010-02-02 21:44 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbpgsql/postgres.c + Added GC support for all remaining pointer types (result/cancel/FILE). + Added RTE when wrong pointer or wrong number of parameter is passed to functions. This means that behavior is now INCOMPATIBLE when wrong parameters are encountered in these functions. ; Destructor functions PQFREECANCEL(), PQCLOSE(), PQCLEAR() marked as 'deprecated'. These are not needed, it's enough to assign NIL to their holder variables on .prg level. % Cleanups along the way. ; TODO: Fix sloppy parameter checking which only check number of parameters instead of enforcing expected type. ; Please test. * contrib/hbpgsql/tests/async.prg * contrib/hbpgsql/tests/test.prg * contrib/hbpgsql/tests/cache.prg * contrib/hbpgsql/tests/stress.prg % Replaced deprecated destructor functions with ' := NIL'. * utils/hbmk2/hbmk2.prg * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbpgsql/postgres.c trunk/harbour/contrib/hbpgsql/tests/async.prg trunk/harbour/contrib/hbpgsql/tests/cache.prg trunk/harbour/contrib/hbpgsql/tests/stress.prg trunk/harbour/contrib/hbpgsql/tests/test.prg 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] Are there MT issues in contrib/hbpgsql?
On Tue, 02 Feb 2010, Lorenzo Fiorini wrote: > BTW did you see my msg "Help with segfaults with MT and hb_hrbload?" > I've created a test with pure prg code but I still get random errors. > Any suggestion? Use valgrind to locate the problem. Such random GPFs can be results of memory corruptions by some other errors, i.e. buffer overflows or using some uninitialized memory. Valgrind should precisely show where the problem is: valgrind --tool=memcheck --leak-check=yes --num-callers=16 -v \ ./myapp 2> myapp.log If you want to see information about source file names and line numbers then just like for GDB do not strip final binaries and compile Harbour code with -g GCC flag. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Are there MT issues in contrib/hbpgsql?
On Tue, Feb 2, 2010 at 7:25 PM, Viktor Szakáts wrote: > Ops, I've already started it. No problem, you can surely do it better. Many thanks. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
On Mon, 01 Feb 2010, Xavi wrote:
Hi,
> HB_TRACEFM(), with my next commit. I'm waiting for Przemek and others
> are ready. ;)
Can you send .diff file here so we can check what exactly this
modification does?
> >Is there a macro I can use to identify this sub-function? I could leave
> >it in the code wrapped conditional code for debug only.
> Yes if you have a C99 compiler, just have to redefine the macro in your code
> .-
> #ifdef HB_TRACEFM
> # undef HB_TRACEFM
> # define HB_TRACEFM( x ) hb_fm_xInfoEx( #x, __FILE__, __LINE__, __func__ );
> x
> #endif
We do not have hb_fm_xInfoEx() in our code so I guess it's part of
modifications you want to commit. __func__ is C99 macro. It makes
log more readable but __FILE__ + __LINE__ is enough to detect exact
place and function name if you have source code so it's not critical
information. For current unmodified code requested functionality
(without function name) can be reached by:
extern HB_EXPORT void * hb_xgrab_fm( ULONG ulSize,
const char * szFile, int iLine );
[...]
void * hb_xgrab_fm( ULONG ulSize, const char * szFile, int iLine )
{
hb_tr_file_ = szFile;
hb_tr_line_ = iLine;
return hb_xgrab( szFile );
}
#if HB_TR_LEVEL >= HB_TR_DEBUG
#define HB_XGRABFM( n )hb_xgrab_fm( n, __FILE__, __SIZE__ )
#else
#define HB_XGRABFM( n )hb_xgrab( n )
#endif
with most of C compilers the same effect can be reached using only
macros without hb_xgrab_fm() function, i.e.:
#if HB_TR_LEVEL >= HB_TR_DEBUG
#define HB_XGRABFM( n )( hb_tr_file_ = __FILE__, \
hb_tr_line_ = __LINE__, \
hb_xgrab( n ) )
#else
#define HB_XGRABFM( n )hb_xgrab( n )
#endif
If user wants does not want to set HB_TR_LEVEL=DEBUG then the
above macro can be extend to dynamically change and restore
debug level, i.e.:
#if HB_TR_LEVEL >= HB_TR_DEBUG
#define HB_XGRABFM( n ){ int iLevel = hb_tracelevel( HB_TR_DEBUG ); \
void * ptr; \
hb_tr_file_ = __FILE__; \
hb_tr_line_ = __LINE__; \
ptr = hb_xgrab( n ); \
hb_tracelevel( iLevel ); \
( void ) ptr; }
#else
#define HB_XGRABFM( n )hb_xgrab( n )
#endif
anyhow such version can be compiled only by few C compilers, i.e. by GCC.
To make it simpler we can change a little bit fm.c and HB_TRACE_STEALTH()
macro so user can use the first version independently to HB_TR_LEVEL setting.
BTW such modifications in HB_TRACE_STEALTH() macro should be done also to
fix yet another problem in current code so I'll commit them ASAP.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Are there MT issues in contrib/hbpgsql?
>> Add Harbour wrapper to function which returns thread safe status >> and check it. And of course check if you are using new separate >> concatenation in each thread in your own code. > > Ok, I'll check it. > >> BTW someone should update contrib/hbpgsql/postgres.c to use >> GC pointers for PGcancel* and PGresult* like for PGconn* and >> add RTE when wrong parameters are passed to functions. > > I'll try to do it. Ops, I've already started it. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Are there MT issues in contrib/hbpgsql?
2010/2/2 Przemysław Czerpak : > Add Harbour wrapper to function which returns thread safe status > and check it. And of course check if you are using new separate > concatenation in each thread in your own code. Ok, I'll check it. > BTW someone should update contrib/hbpgsql/postgres.c to use > GC pointers for PGcancel* and PGresult* like for PGconn* and > add RTE when wrong parameters are passed to functions. I'll try to do it. BTW did you see my msg "Help with segfaults with MT and hb_hrbload?" I've created a test with pure prg code but I still get random errors. Any suggestion? best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Are there MT issues in contrib/hbpgsql?
On Tue, 02 Feb 2010, Lorenzo Fiorini wrote: > Thanks for the answer. This is what I've found in > http://www.enterprisedb.com/documentation/libpq-concepts.html: [...] > Do you think I can found not thread-safe libpq in distros like Centos, > Fedora, Ubuntu? Add Harbour wrapper to function which returns thread safe status and check it. And of course check if you are using new separate concatenation in each thread in your own code. BTW someone should update contrib/hbpgsql/postgres.c to use GC pointers for PGcancel* and PGresult* like for PGconn* and add RTE when wrong parameters are passed to functions. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Are there MT issues in contrib/hbpgsql?
2010/2/2 Przemysław Czerpak : > Check if libpq is fully MT safe. Thanks for the answer. This is what I've found in http://www.enterprisedb.com/documentation/libpq-concepts.html: ... 29.4.16. Behavior in Threaded Programs libpq is reentrant and thread-safe if the configure command-line option --enable-thread-safety was used when the EnterpriseDB distribution was built. In addition, you might need to use additional compiler command-line options when you compile your application code. Refer to your system's documentation for information about how to build thread-enabled applications, or look in src/Makefile.global for PTHREAD_CFLAGS and PTHREAD_LIBS. This function allows the querying of libpq's thread-safe status: Returns 1 if the libpq is thread-safe and 0 if it is not. One thread restriction is that no two threads attempt to manipulate the same PGconn object at the same time. In particular, you cannot issue concurrent commands from different threads through the same connection object. (If you need to run concurrent commands, use multiple connections.) PGresult objects are read-only after creation, and so can be passed around freely between threads. The deprecated functions PQrequestCancel and PQoidStatus are not thread-safe and should not be used in multithread programs. PQrequestCancel can be replaced by PQcancel. PQoidStatus can be replaced by PQoidValue. If you are using Kerberos inside your application (in addition to inside libpq), you will need to do locking around Kerberos calls because Kerberos functions are not thread-safe. See function PQregisterThreadLock in the libpq source code for a way to do cooperative locking between libpq and your application. If you experience problems with threaded applications, run the program in src/tools/thread to see if your platform has thread-unsafe functions. This program is run by configure, but for binary distributions your library might not match the library used to build the binaries. ... Do you think I can found not thread-safe libpq in distros like Centos, Fedora, Ubuntu? 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:[13744] trunk/harbour
Revision: 13744 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13744&view=rev Author: druzus Date: 2010-02-02 16:59:07 + (Tue, 02 Feb 2010) Log Message: --- 2010-02-02 17:58 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/direct.c ! do not strip other attributes when "V" is set - it's neither DOS not Clipper compatible behavior Clipper passes attributes to OS and then OS decides about their interpretation, i.e. FreeDOS replicates hardcoded in our previous DIRECTORY() code behavior but MS-DOS doesn't. % small simplification * harbour/src/common/hbffind.c ! fixed emulation of DOS volum attribute in MS-Windows builds of hb_fsFindFirst()/hb_fsFindNext(). It also fixes problem in HBCT FILEATTR() function in MS-Windows builds. This is still not full DOS emulation. Exact emulation should automatically add trailing \ to given path, detect drive letter and resolve their current directories. If some windows users think it's important then they can extend this emulation. Now it can be done as local modifications only. Please test with real MS-Windows. ! fixed error code setting in UNICODE MS-Windows builds of hb_fsFindFirst()/hb_fsFindNext(). * harbour/contrib/hbct/files.c * removed old hack which is not longer necessary for current code. * harbour/include/hbapifs.h * small modifications to make HB_FNAME structure alignment independent * harbour/src/vm/hvm.c ! fixed GPF when WITH OBJECT reference is used inside codeblock evaluated outside WITH OBJECT / ENDWITH structure TODO: forbid using WITH OBJECT references in nested codeblocks Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/files.c trunk/harbour/include/hbapifs.h trunk/harbour/src/common/hbffind.c trunk/harbour/src/rtl/direct.c trunk/harbour/src/vm/hvm.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] DBF encryption
On Tue, 02 Feb 2010, Alex Strickland wrote: Hi, > >If you want to change password then you have to decrypt the table > >and then encrypt it again with new password. > What do you think of issuing a RTE if you try and encrypt an > encrypted database, it seems better than a silent fail? > Similarly, what do you think of a RTE when using APPEND FROM with > databases that are not encrypted/decrypted in synch? All such modifications will effect SIX3 compatibility. To touch it will have to repeat some tests with SIX3 and document differences and it will be time consuming process due to bugs in SIX3 library. I do not have time for it now, sorry. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: USE error ?
Hi, > Hi, > >> Related to this: My app doesn't need exclusive mode, >> but there are still a few typical places where it is >> used: pack and reindex (and structure change) operations. >> If POSIX doesn't support exclusive access, what is the >> recommended way to open a table for above operations >> if I want to avoid issues in multiuser scenarios? > > In POSIX systems EXCLUSIVE mode is emulated by Harbour so it > allow to sync different applications and threads if each of > them uses compatible emulation. > The fact that POSIX does not support EXCLUSIVE mode only means > that nothing stops other applications which do not respect our > emulation against opening the same files. This is also true for > file servers like SAMBA. If SAMBA does not use compatible > EXCLUSIVE mode emulation (and it really doesn't) then it means > that both native and remote MS-Windows application can open > the same file in EXCLUSIVE mode simultaneously. If application > needs EXCLUSIVE mode to synchronize some RDD operations between > native POSIX applications executed locally and some remote > applications then it should use for remote access HBNETIO. > It's not necessary to use HBNETIO for local access. Okay, situation is clear now, thanks a lot for clarifying. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Are there MT issues in contrib/hbpgsql?
On Mon, 01 Feb 2010, Lorenzo Fiorini wrote: Hi, > Continuing in my MT path this is what I get from code that work since years > ST: > double free or corruption (!prev): 0x0a05bd48 *** > === Backtrace: = > /lib/tls/i686/cmov/libc.so.6[0xb7a89604] > /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7a8b5b6] > /usr/lib/libpq.so.5(PQclear+0x30)[0xb7b88420] [...] > Where should I start to look? Check if libpq is fully MT safe. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: USE error ?
On Mon, 01 Feb 2010, Szak�ts Viktor wrote: Hi, > Related to this: My app doesn't need exclusive mode, > but there are still a few typical places where it is > used: pack and reindex (and structure change) operations. > If POSIX doesn't support exclusive access, what is the > recommended way to open a table for above operations > if I want to avoid issues in multiuser scenarios? In POSIX systems EXCLUSIVE mode is emulated by Harbour so it allow to sync different applications and threads if each of them uses compatible emulation. The fact that POSIX does not support EXCLUSIVE mode only means that nothing stops other applications which do not respect our emulation against opening the same files. This is also true for file servers like SAMBA. If SAMBA does not use compatible EXCLUSIVE mode emulation (and it really doesn't) then it means that both native and remote MS-Windows application can open the same file in EXCLUSIVE mode simultaneously. If application needs EXCLUSIVE mode to synchronize some RDD operations between native POSIX applications executed locally and some remote applications then it should use for remote access HBNETIO. It's not necessary to use HBNETIO for local access. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
To get the support (or to report bug) about your Ubuntu issue please refer to the main https://launchpad.net/ubuntu Ubuntu site, be free to ask any kind of question here: https://answers.launchpad.net/ubuntu Hth ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: USE error ?
On Mon, 01 Feb 2010, David Arturo Macias Corona wrote: Hi, > Something has changed for this case since Aug 2007 ? > "It mean that (in Linux) Harbour and xHarbour can not share dbf files ?" I created new code for MT mode which also can use BSD or POSIX locks for deny flags emulation so now it works between aliased work areas even in single process. This code were copied from Harbour repository to xHarbour CVS by: 2008-10-22 10:30 UTC+0100 Miguel Angel Marchuet even with my original ChangeLog notes but without even single word that these were my modifications :-( So this code is present in xHarbour. I haven't checked if it was ported correctly or not. Few times in last years my code from Harbour was copied without necessary updates to work correctly with xHarbour internal structures so you should ask about details xHarbour developers. > Your last message included below > I do not found some reference for this difference between > Harbour-xHarbour in doc\xhb-diff.txt Code is present but I do not have time to test current xHarbour CVS locate the bugs and document them. The are bugs I reported four or more years ago to xHarbour devel list and never fixed though some of them are even registered at xHarbour bug track so I think it's waste of time. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] New trouble with type from MS Sql
>-Original Message- >From: Horodyski Marek (PZUZ) >Sent: Tuesday, February 02, 2010 10:18 AM >To: Harbour Project Main Developer List. >Subject: RE: [Harbour] New trouble with type from MS Sql > >>-Original Message- >>From: Viktor Szakáts [mailto:harbour...@syenar.hu] >>Sent: Monday, February 01, 2010 6:32 PM ... >>> to support all range of bigint values. >> >>It's 64-bit signed integer. (confirmed from multiple sources) > >I do not know how to properly do so should this amendment. >Meanwhile, I have an error when closing the query. This information is now obsolete. Today I did not have a single error. It adds nothing - just resolved itself. In tables are still fields of BIGINT type. Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hb_idleSleep( ntimeOut ) & DST
Hi All, Will hb_idleSleep( ntimeOut ) wait for an extra hour if the clock is adjusted just in that moment with an hour back (like in DST)? Thanks Abe. -- View this message in context: http://n2.nabble.com/hb-idleSleep-ntimeOut-DST-tp4501573p4501573.html Sent from the harbour-devel 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] hb_QWith()/with object inside macro compiler
Hi, > We have two choices: > 1) detach WITH OBJECT variable lust like local variables > and add code which will resolve references in each : code. > It will cause some small speed overhead but it will work > 2) forbid using : in nested code blocks at compile time. > If we want to add support for macrocompiler then we can chose only > method one. > needs additional code to update lWithObject register at the beginning and > end of WITH OBJECT statement (additional speed overhead which can be > eliminated and reduces this feature to only single WITH OBJECT variable > and this is sth what I would like to eliminate in the future. This would be nice. > In xHarbour implementation WITH OBJECT is visible for macrocompiler so > semantically it works like with _tmp declared as PRIVATE instead of LOCAL > variable. > > As long as we operate only on local variables then we can easy extend > such functionality adding support for new variables and we can make > very extensive optimization at compile time calculating all HVM stack > offsets and eliminating lWithObject HVM stack register. If we add support > for accessing this value from macrocompiler then we lost such possibilities > so if you need such extenssion then you have to give me good reason to > implement it. > > BTW Personally I'd even prefer to replace current WITH OBJECT by new > syntax, i.e. > > WITH VAR [ := ] > [...] > ENDWITH > > because support for current > : > syntax breaks Clipper compatibility and it's necessary to introduce > hacks to PP code so some Clipper compatible code cannot be compiled by > Harbour and xHarbour. I.e. this code: > ... > will not work too. Just simply like IN, HAS and LIKE xHarbour extensions > also WITH OBJECT breaks valid Clipper syntax in PP but in this case we > adopted xHarbour syntax for code compatibility and I'm still not sure it > was good idea. I'd vote for the clean way. Namely option 2) and WITH VAR and leaving WITH OBJECT optional for compatibility. BTW 'WITH OBJECT' is very seldom used in current Harbour code, and one part of the reason is above ambiguity with it. It would be nice to see a small code example with 'WITH VAR', I'm not I fully oversee how it would replace current method in practice. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_QWith()/with object inside macro compiler
On Tue, 02 Feb 2010, Maurilio Longo wrote:
Hi,
> I'm trying to rebuild a project of mine with harbour (it was developed with
> xharbour) but I'm facing a problem, it seems that an object I'm accessing with
> a "with object xxx" does not work inside macro compiler.
> Example:
> with object MyObject
> &( "{|| x := :MyMethod() }" )
> end
> It gives a syntax error &
Yes, it is. It's intentional.
> This is code which has been working for years, so maybe I'm overlooking
> something, but before I start digging deeper I'd like to know better about
> this issue.
It works only with xHarbour. I can make it working with Harbour too
but in fact it will seriously limit farther extension.
To be precise I should even block current code which allows to use
such syntax in clodeblocks because it's possible to create GPF.
In next commit I'll add only protection for such GPF (it will work
like in xHarbour) and we can try to talk about the future of WITH OBJECT.
Here is the code which illustrates the problem:
proc main()
local cb
with object .F.
with object 0
cb := {|| :className }
? eval( cb )// NUMERIC
end
? eval( cb ) // LOGICAL
end
? eval( cb ) // GPF or NIL after incomming commit.
return
As you can see codeblock is created inside 'with object 0' statement but
can be used outside this statement when the given object does not longer
exist so it does not confirm WITH OBJECT specification and has to be fixed.
We have two choices:
1) detach WITH OBJECT variable lust like local variables
and add code which will resolve references in each : code.
It will cause some small speed overhead but it will work
2) forbid using : in nested code blocks at compile time.
If we want to add support for macrocompiler then we can chose only
method one.
But method one except some small speed overhead has yet another drawback.
It needs to keep current code which uses additional HVM stack register
(lWithObject) to store offset of WITH OBJECT value. Such implementation
needs additional code to update lWithObject register at the beginning and
end of WITH OBJECT statement (additional speed overhead which can be
eliminated and reduces this feature to only single WITH OBJECT variable
and this is sth what I would like to eliminate in the future.
WITH OBJECT statement make only one thing. Semantically it introduces
temporary variables. Instead of:
LOCAL _tmp
[...]
_tmp := errorNew()
_tmp:cargo := "ABC"
? _tmp:cargo
_tmp := NIL
you can write:
WITH OBJECT errorNew()
:cargo := "ABC"
? :cargo
ENDWITH
In xHarbour implementation WITH OBJECT is visible for macrocompiler so
semantically it works like with _tmp declared as PRIVATE instead of LOCAL
variable.
As long as we operate only on local variables then we can easy extend
such functionality adding support for new variables and we can make
very extensive optimization at compile time calculating all HVM stack
offsets and eliminating lWithObject HVM stack register. If we add support
for accessing this value from macrocompiler then we lost such possibilities
so if you need such extenssion then you have to give me good reason to
implement it.
BTW Personally I'd even prefer to replace current WITH OBJECT by new
syntax, i.e.
WITH VAR [ := ]
[...]
ENDWITH
because support for current
:
syntax breaks Clipper compatibility and it's necessary to introduce
hacks to PP code so some Clipper compatible code cannot be compiled by
Harbour and xHarbour. I.e. this code:
proc main
local xVar, get
@ 0, 0 SAY xVar PICTURE get:pict
return
cannot be compiled by xHarbour at all. It can be compiled by Harbour but
only due to hack which checks for leading spaces before ':' so this code:
proc main
local xVar, get
@ 0, 0 SAY xVar PICTURE get : pict
return
will not work too. Just simply like IN, HAS and LIKE xHarbour extensions
also WITH OBJECT breaks valid Clipper syntax in PP but in this case we
adopted xHarbour syntax for code compatibility and I'm still not sure it
was good idea.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] New trouble with type from MS Sql
>-Original Message- >From: Horodyski Marek (PZUZ) >Sent: Monday, February 01, 2010 6:46 PM >To: Harbour Project Main Developer List. >Subject: RE: [Harbour] New trouble with type from MS Sql > >>-Original Message- >>From: Mindaugas Kavaliauskas [mailto:dbto...@dbtopas.lt] ... >>> case SQL_TINYINT: >>> case SQL_SMALLINT: >>> case SQL_INTEGER: >>>pFieldInfo.uiType = HB_FT_INTEGER; >>>break; >> >>Try to add the fourth case sentence: >>case SQL_BIGINT: > >Now (after this change), when I close this select (anther is >quit without error), have I : > > >--- >- >Application Internal Error - c:\noweprod\exe\homar_cbki.exe >Terminated at: 2010.02.01 18:32:04 Nienaprawialny błąd nr >6005: Exception error: > >Exception Code:C005 >Exception Address:0046BF51 >EAX:7FBE000C EBX: ECX: EDX:7EF6000C >ESI:014A09C4 EDI: EBP:014A09C4 >CS:EIP:001B:0046BF51 SS:ESP:0023:0022F600 >DS:0023 ES:0023 FS:003B GS: >Flags:00010246 >CS:EIP: F6 04 18 02 74 EB 8B 04 9A 43 89 04 24 E8 FD EB >SS:ESP: 014A09C4 7E3A396F 014A09C4 0002 >014A09C4 0002 00467D4C 014A09C4 0123AA94 0001 0040C203 >0022F704 00852B0C 00852B0C 0067E76E > >C stack: >EIP: EBP: Frame: OldEBP, RetAddr, Params... > > >Modules: >0x0040 0x00463000 c:\noweprod\exe\homar_cbki.exe [...] > >Called from DBCLOSEALL(0) >Called from (b)KOMPILATOR(349) in kompilat.prg Called from >BOSS(143) in boss.prg Called from (b)KOMPILATOR(349) in >kompilat.prg Called from BOSS(143) in boss.prg Called from >KODKLAW(0) in KODKLAW.PRG Called from OPCJA(0) in OPCJA.PRG >Called from (b)KOMPILATOR(349) in kompilat.prg Called from >BOSS(143) in boss.prg Called from MAIN(269) in homar.prg >--- Strangely, today dbCloseAll(), already 2 times without error - and yesterday, every time. Query has hundreds of thousands records, and everything works ok. :) Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] New trouble with type from MS Sql
Hi, Marek, Horodyski Marek (PZUZ) wrote: It's 64-bit signed integer. (confirmed from multiple sources) I do not know how to properly do so should this amendment. Meanwhile, I have an error when closing the query. For sure code should be fixed to obtain large values if this is 64-bit int type, but I see no reason to GPF on area close. GPF should not be related to bigint. I guess different versions of harbour/rddsql code is mixed. Can you comment case SQL_BIGINT: and test if area closes with error? Or do not use bigint type in table and check area close. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to avoid terminal window using hbide/hbmk2 underwindows
Solved! Thank you ! Brgds Leandro -- From: "Viktor Szakáts" Sent: Tuesday, February 02, 2010 5:49 AM To: "Harbour Project Main Developer List." Subject: Re: [Harbour] How to avoid terminal window using hbide/hbmk2 underwindows It's enough to copy the solution from any existing win32 gui lib; the option needed is -gtgui (or gt=gtgui setting for .hbc files). Brgds, Viktor On 2010 Feb 2, at 02:03, Leandro Damasio wrote: Hello, I'm working on a new Win32 gui lib for Harbour and when I link an aplication using hbide (hbmk2) it calls a empty black terminal window behind my main window. How do I avoid it? Thanks Leandro ___ 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBF encryption
Przemysław Czerpak wrote: If you want to change password then you have to decrypt the table and then encrypt it again with new password. What do you think of issuing a RTE if you try and encrypt an encrypted database, it seems better than a silent fail? Similarly, what do you think of a RTE when using APPEND FROM with databases that are not encrypted/decrypted in synch? Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_QWith()/with object inside macro compiler
Hi,
here a little test sample, I've built it from the logic of my app, but it
should be enough.
--8<
#include "hbclass.ch"
class test
method New()
method Num()
endclass
method new() class test
return self
method num() class test
return 1
function main()
private oT := Test():New()
private x := 0
with object oT
&( "x := :Num()" )
end
? x
return
>8
Adding hb_QWith() before :Num() it works, xharbour does not require this and
it comes really handy, I'm using this with an interpreter to have a dynamic
web page where .prg code is mixed with html and can output code calling a
method of an object which abstracts the CGI interface like in
:cgiOut( "" )
or get an envvar with
myvar := :Server_Name
and so on.
Is it possible to have such capability inside harbour macro compiler?
Maurilio.
Maurilio Longo wrote:
> Hi,
>
> I'm trying to rebuild a project of mine with harbour (it was developed with
> xharbour) but I'm facing a problem, it seems that an object I'm accessing with
> a "with object xxx" does not work inside macro compiler.
>
> Example:
>
> with object MyObject
>
> &( "{|| x := :MyMethod() }" )
>
> end
>
> It gives a syntax error &
>
> This is code which has been working for years, so maybe I'm overlooking
> something, but before I start digging deeper I'd like to know better about
> this issue.
>
> Maurilio.
>
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] New trouble with type from MS Sql
>-Original Message-
>From: Viktor Szakáts [mailto:harbour...@syenar.hu]
>Sent: Monday, February 01, 2010 6:32 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] New trouble with type from MS Sql
>
>> Try to add the fourth case sentence:
>> case SQL_BIGINT:
>>
>> But I do not know how big is this "bigint" value. Please,
>try uncomment debug line:
>> HB_TRACE( HB_TR_ALWAYS, ("field: name=%s type=%d len=%d dec=%d
>> null=%d", pFieldInfo.atomName, iDataType, uiSize, iDec,
>iNull ) ); and report result for bigint filed type.
>>
>> Testing of "big" values (larger that +/- 2^32) is also
>required to make support for bigint complete. Perhaps we will
>need to adjust code:
>>
>> case HB_FT_INTEGER:
>> {
>> long int val = 0;
>> if( SQL_SUCCEEDED( res = SQLGetData( hStmt, ui,
>SQL_C_LONG, &val, sizeof( val ), &iLen ) ) )
>> {
>> pItem = hb_itemPutNLLen( NULL, val, pField->uiLen );
>> }
>> break;
>> }
>>
>> to support all range of bigint values.
>
>It's 64-bit signed integer. (confirmed from multiple sources)
I do not know how to properly do so should this amendment.
Meanwhile, I have an error when closing the query.
Regards,
Marek Horodyski
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to avoid terminal window using hbide/hbmk2 under windows
It's enough to copy the solution from any existing win32 gui lib; the option needed is -gtgui (or gt=gtgui setting for .hbc files). Brgds, Viktor On 2010 Feb 2, at 02:03, Leandro Damasio wrote: > Hello, > I'm working on a new Win32 gui lib for Harbour and when I link an aplication > using hbide (hbmk2) it calls a empty black terminal window behind my main > window. > How do I avoid it? > Thanks > Leandro > ___ > 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] Re: How to avoid terminal window using hbide/hbmk2 underwindows
On borland linker use -aa linker option. Leandro Damasio escribió en mensaje <23a659c78c92492dbb68d4e6e190a...@noteleo>... Hello, I'm working on a new Win32 gui lib for Harbour and when I link an aplication using hbide (hbmk2) it calls a empty black terminal window behind my main window. How do I avoid it? Thanks Leandro ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
