Re: [Harbour] Trapping recurrsion

2008-07-04 Thread Szakáts Viktor
func test() test2() return nil func test2() test() return nil I replaced the errorint.c in source\rtl, deleted errorint.obj and hbrtl.lib and rebuilt Harbour. Well, my change targeted solely to log internal errors, of of those is internals errors in too deeply recursive error handler calls.

Re: [Harbour] Trapping recurrsion

2008-07-04 Thread Randy Portnoff
Hi Viktor, I am using: Harbour 1.0.0RC2 Intl. (Rev. 8928) My test is: func test() test2() return nil func test2() test() return nil I replaced the errorint.c in source\rtl, deleted errorint.obj and hbrtl.lib and rebuilt Harbour. Regards, Randy. At 11:59 AM 7/4/2008, you wrote: Hi Randy,

Re: [Harbour] Trapping recurrsion

2008-07-04 Thread Szakáts Viktor
Hi Randy, Please try with the latest SVN. For me this simple test program works: --- test.prg PROC Main() ErrorInHandler() // to force an internal error RETURN --- -> --- hb_out.log Application Internal Error - ... Terminated at: ... Unrecoverable error 9001: Error recovery failure Called

Re: [Harbour] Trapping recurrsion

2008-07-04 Thread Randy Portnoff
Hi Viktor, I tried the most recent errorint.c that you sent with the current Harbour build but it is not creating the log file. Regards, Randy. At 09:12 AM 7/3/2008, you wrote: Hi Randy, Since some week there is one common filename used. You can control this filename using Set( _SET_HBOUT

Re: [Harbour] Trapping recurrsion

2008-07-03 Thread Szakáts Viktor
Hi Randy, Since some week there is one common filename used. You can control this filename using Set( _SET_HBOUTLOG, ). You can also add custom information (one line) to all the log entries generated by Harbour using Set( _SET_HBOUTLOGINFO, Brgds, Viktor On 2008.07.03., at 15:09, Randy Po

Re: [Harbour] Trapping recurrsion

2008-07-03 Thread Randy Portnoff
Hi Viktor, Are the only error logs created by Harbour HB_EX.LOG and HB_OUT.LOG or are there others? IMO, I think only one filename should be used for _all_ logs and new errors should be appended to the existing log if it exists. Regards, Randy. At 02:45 PM 7/2/2008, you wrote: Hi Randy,

Re: [Harbour] Trapping recurrsion

2008-07-03 Thread Randy Portnoff
Thanks Viktor, but this does not build with my Harbour version - I will test it with the next release... At 02:45 PM 7/2/2008, you wrote: Hi Randy, Here is the internal error logging implemented. Copy the file to source/rtl/ and recompile. Brgds, Viktor On 2008.07.02., at 17:21, Randy

Re: [Harbour] Trapping recurrsion

2008-07-02 Thread Szakáts Viktor
Hi Randy, Here is the internal error logging implemented. Copy the file to source/rtl/ and recompile. Brgds, Viktor errorint.c Description: Binary data On 2008.07.02., at 17:21, Randy Portnoff wrote: Hi all, Similar to the way Harbour now traps GPF's (and logs some info in a text fil

Re: [Harbour] Trapping recurrsion

2008-07-02 Thread Szakáts Viktor
Hi Randy, This is a good idea, as I've already met such situation in real life, and it's really annoying to see the screen just "vanish" with no trace. Maybe the general answer to this, is that we may redirect all internal errors to a file, because internal errors are currently inherently lost i

[Harbour] Trapping recurrsion

2008-07-02 Thread Randy Portnoff
Hi all, Similar to the way Harbour now traps GPF's (and logs some info in a text file), can it also detect race conditions and log that as well? I am referring to situations where recursion occurs repeatedly which causes the app to just exit (ie. vanish). Ideally, a runtime error would be be