You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(30) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(133) |
Feb
(35) |
Mar
(89) |
Apr
(135) |
May
(198) |
Jun
(65) |
Jul
(54) |
Aug
(100) |
Sep
(210) |
Oct
(134) |
Nov
(53) |
Dec
(114) |
2003 |
Jan
(200) |
Feb
(208) |
Mar
(240) |
Apr
(261) |
May
(226) |
Jun
(443) |
Jul
(441) |
Aug
(388) |
Sep
(504) |
Oct
(473) |
Nov
(662) |
Dec
(769) |
2004 |
Jan
(801) |
Feb
(767) |
Mar
(929) |
Apr
(693) |
May
(637) |
Jun
(592) |
Jul
(466) |
Aug
(563) |
Sep
(374) |
Oct
(414) |
Nov
(409) |
Dec
(300) |
2005 |
Jan
(316) |
Feb
(460) |
Mar
(591) |
Apr
(629) |
May
(378) |
Jun
(297) |
Jul
(165) |
Aug
(332) |
Sep
(546) |
Oct
(955) |
Nov
(422) |
Dec
(280) |
2006 |
Jan
(291) |
Feb
(400) |
Mar
(313) |
Apr
(239) |
May
(81) |
Jun
(235) |
Jul
(200) |
Aug
(153) |
Sep
(145) |
Oct
(212) |
Nov
(164) |
Dec
(253) |
2007 |
Jan
(125) |
Feb
(211) |
Mar
(250) |
Apr
(289) |
May
(710) |
Jun
(142) |
Jul
(149) |
Aug
(168) |
Sep
(289) |
Oct
(196) |
Nov
(181) |
Dec
(285) |
2008 |
Jan
(187) |
Feb
(314) |
Mar
(456) |
Apr
(439) |
May
(255) |
Jun
(311) |
Jul
(108) |
Aug
(101) |
Sep
(56) |
Oct
(175) |
Nov
(239) |
Dec
(106) |
2009 |
Jan
(194) |
Feb
(134) |
Mar
(133) |
Apr
(138) |
May
(111) |
Jun
(68) |
Jul
(100) |
Aug
(110) |
Sep
(130) |
Oct
(84) |
Nov
(78) |
Dec
(51) |
2010 |
Jan
(53) |
Feb
(13) |
Mar
(30) |
Apr
(21) |
May
(31) |
Jun
(11) |
Jul
(30) |
Aug
(29) |
Sep
(23) |
Oct
(14) |
Nov
(21) |
Dec
(8) |
2011 |
Jan
(17) |
Feb
(171) |
Mar
(138) |
Apr
(25) |
May
(30) |
Jun
(26) |
Jul
(5) |
Aug
(6) |
Sep
(20) |
Oct
(19) |
Nov
(67) |
Dec
(2) |
2012 |
Jan
(4) |
Feb
(51) |
Mar
(11) |
Apr
(11) |
May
(7) |
Jun
(104) |
Jul
(171) |
Aug
(104) |
Sep
(77) |
Oct
(143) |
Nov
(74) |
Dec
(72) |
2013 |
Jan
(34) |
Feb
(17) |
Mar
(52) |
Apr
(11) |
May
(45) |
Jun
(17) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(7) |
2014 |
Jan
|
Feb
(17) |
Mar
(3) |
Apr
(6) |
May
(9) |
Jun
(2) |
Jul
(22) |
Aug
(5) |
Sep
|
Oct
(11) |
Nov
(14) |
Dec
(31) |
2015 |
Jan
(6) |
Feb
(34) |
Mar
(9) |
Apr
(2) |
May
(7) |
Jun
(10) |
Jul
(9) |
Aug
|
Sep
(6) |
Oct
(10) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
(16) |
Sep
(1) |
Oct
(38) |
Nov
(14) |
Dec
(19) |
2017 |
Jan
(16) |
Feb
(13) |
Mar
|
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
2018 |
Jan
(1) |
Feb
(6) |
Mar
(5) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ron P. <Ron@Profit-Master.com> - 2002-01-02 18:01:25
|
Luiz, > The attached small test will make this. If you compare the results of > tracelistasarray2.log(Witch produce the correct values for hbmake) with > traceatokens.log, you will see that some result are diferents.It > apear that > atokens get lost with some type os input string , ie: an simple ' > ' as input > produce an wrong array Actually the results are correct and intentional. We simply need to add a flag, if you don't want empty items. Remember, that parsers normally don't ignore empty tokens. For example: Ron,Pinkas ,Pinkas In both those, comma delimited lists, the *2nd* element will be Pinkas. Ron Pinkas Pinkas Again, in both those, space delimited lists, the *2nd* element will be Pinkas. That's because if the list starts with a separator, its as if the first element is empty. Also Ron,A,Pinkas ,,Pinkas In both lists, the *3rd* element is Pinkas. Similarly: Ron A Pinkas Pinkas Again in both lists, the *3rd* element is Pinkas. Because there are 2 separators before the Pinkas. The solution, is to add 3 optional parameters: lIgnoreEmptyFirst, lIgnoreEmptyLast, lIgnoreEmptyAll Let, me know what you think. Ron |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-02 17:30:18
|
> >Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland > >Error: Unresolved external '_HB_FUN_GETLIBS' referenced from > >C:\XHARBOUR\XHARBOUR\OBJ\B32\HBMAKE.OBJ > > it fixed now Thx Luiz. |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-02 10:15:22
|
Ron >Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland >Error: Unresolved external '_HB_FUN_GETLIBS' referenced from >C:\XHARBOUR\XHARBOUR\OBJ\B32\HBMAKE.OBJ it fixed now -- Regards Luiz Rafael Culik |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-02 09:41:23
|
* utils/hbmake/hbmake.prg * updated the date * utils/hbmake/hbmutils.prg * Sinc with harbour -- Regards Luiz Rafael Culik |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-02 04:56:27
|
Luiz, Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Error: Unresolved external '_HB_FUN_GETLIBS' referenced from C:\XHARBOUR\XHARBOUR\OBJ\B32\HBMAKE.OBJ Ron |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-02 04:47:07
|
2002-01-01 20:29 UTC+0100 Ron Pinkas <ro...@ro...> * xharbour/source/vm/fastitem.c * xharbour/source/vm/itemapi.c + Tracing info. * xharbour/source/vm/arrays.c * xharbour/source/vm/garbage.c ! Fixed few more GPFs to do with hb_arrayReleaseGarabage(). * xharbour/source/vm/estack.c * xharbour/source/vm/hvm.c ! Fixed initialization of top item in hb_stackInit() * xharbour/tests/inline_c.prg ! Fixed aTokens() parsing of last token with just one character. |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-02 00:23:20
|
Luiz, >This fix is very simple, just replace: > > > if( iOffset < pLine->item.asString.length - 1 ) > > >with > > > if( iOffset < pLine->item.asString.length ) > > > I´ve tryed this , and now i get an Bound Error: Array Access Luiz, this is what I was trying to highlight, when I talked about your error reports. Surely you understand, I can't have any idea what the problem might be, with the above info :-( Where do you get such error? Did you try to isolate it at all? Did you try to test aTokens() in a small sample? I'm confident you may perform better debugging, and post info that is much more meaningful than the above. Ron |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-01 21:30:47
|
Ron >Thx. The problem was when last (or only) token had only 1 character. >Th= is fix is very simple, just replace: > if( iOffset < pLine->item.asString.length - 1 ) >with > if( iOffset < pLine->item.asString.length ) I=B4ve tryed this , and now i get an Bound Error: Array Access -- Regards Luiz Rafael Culik |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-01 21:12:04
|
Dwayne >I understand, but my question is: is Harbour's API interface different >from the Clipper extend API? Is it more convenient, or more efficient, = >or easier to use? Or is there a more direct way of linking in C or >Assembl= er routines? Yes. Harbour API is an bit diferent from Clipper. Harbour add also some new api, that was not present on clipper. most API functions are fastern then the clipper equivalent. also all harbour api=B4s are prefixed by an hb ie : Clipper _parc() api becomens in harbour hb_parc() -- Regards Luiz Rafael Culik |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-01 21:08:13
|
Luiz, > I find the problem using the atokens function. > I´ve testes tracelog() function with the return value of > listasarray2() and > atokens() function > > Below the logs > ... Thx. The problem was when last (or only) token had only 1 character. This fix is very simple, just replace: if( iOffset < pLine->item.asString.length - 1 ) with if( iOffset < pLine->item.asString.length ) Ron |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-01 20:19:32
|
Ron I find the problem using the atokens function. I=B4ve testes tracelog() function with the return value of listasarray2()= and atokens() function Below the logs With listasArray2() [SETBUILD] ( 538) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(BCB)\BIN\$(LINKER) @&&!<<< [SETBUILD] ( 548) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 3 Items }<<< >>>$(BCB)\BIN\$(LINKER) <<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 2 Items }<<< >>>$(LFLAGS) +<<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 2 Items }<<< >>>$(ALLOBJ), +<<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 2 Items }<<< >>>$(PROJECT),, +<<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 2 Items }<<< >>>$(ALLLIB), +<<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 2 Items }<<< >>>$(DEFFILE), +<<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(ALLRES)<<< [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 1 Items }<<< >>>!<<< [COMPFILES] ( 613) Called from: MAIN( 193) >>>{ Array of 4 Items }<<< >>>$(CFILES) $(OBJFILES) $(RESDEPEN) $(DEFFILE)<<< with atokens() [SETBUILD] ( 558) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(BCB)\BIN\$(LINKER) @&&!<<< [SETBUILD] ( 568) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 3 Items }<<< >>>$(BCB)\BIN\$(LINKER) <<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(LFLAGS) +<<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(ALLOBJ), +<<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(PROJECT),, +<<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(ALLLIB), +<<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(DEFFILE), +<<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 1 Items }<<< >>>$(ALLRES)<<< [SETBUILD] ( 582) Called from: PARSEMAKFI( 369) MAIN( 188) >>>{ Array of 0 Items }<<< >>>!<<< [COMPFILES] ( 633) Called from: MAIN( 193) >>>{ Array of 5 Items }<<< >>> $(CFILES) $(OBJFILES) $(RESDEPEN) $(DEFFILE)<<< Please notice the result on both version but the most important one is the last two on both logs. The motive that hbmake works with listasarray and dont work with atokens = is the follow [SETBUILD] ( 562) Called from: PARSEMAKFI( 351) MAIN( 188) >>>{ Array of 1 Items }<<< >>>!<<< Atokens dont produce this array, with this, it cannot set the properly commands to compiler Can you check the atokens function -- Regards Luiz Rafael Culik |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-01 19:11:54
|
Please take a look to next code, functions array1(),array2(),array3() use 8MB but array4() use more than 134 MB !!! :(. Is there a bug for release memory with AADD and recursive process ? Many thanks in advance Regards Jorge Mason here the code : //-------------------------------------------------------------------------- ------------------------------------------------------- /* Name : arrays.prg Description : Testing Arrays Function with Large Data CopyRight : Jorge Mason Salinas Date : Dec 25 2001 Url : www.htcsoft.cl Email : jm...@ht... */ #include "inkey.ch" FUNCTION Main() Array1() Array2() Array3() Array4() RETURN nil FUNCTION Array1() LOCAL n LOCAL aArray := {} // Testing without AADD() ? "Build ARRAY without AADD()" nSeconds = SECONDS() aArray = ARRAY(20000) FOR n = 1 TO 20000 aArray[n] = ARRAY(10) NEXT ? "Finished 20000 elements added without AADD() -> see memory usage in program manager < 8MB" INKEY(0) RETURN NIL FUNCTION Array2() LOCAL n LOCAL aArray := {} // Testing with AADD() aArray = {} ? "Build ARRAY with AADD()" FOR n = 1 TO 20000 AADD(aArray,ARRAY(10)) NEXT ? "Finished 20000 elements added with AADD() -> see memory usage in program manager < 8MB" INKEY(0) RETURN NIL FUNCTION Array3() LOCAL n LOCAL aArray := {} // Testing with function AADD() aArray = {} MEMORY(-1) ? "Build ARRAY with function and AADD()" FOR n = 1 TO 20000 AADD(aArray,myarray()) NEXT ? "Finished 20000 elements added with function and AADD() -> see memory usage in program manager < 8MB" INKEY(0) RETURN NIL FUNCTION myArray(nElements) LOCAL array := {} AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) AADD(array,NIL) RETURN array FUNCTION Array4() LOCAL aArray := {} // Testing with function recursive function() ? "Build ARRAY with function and AADD()" WHILE LEN(aArray) < 20000 AADD(aArray,MyRecursive(10)) END ? "Finished 20000 elements added with function and AADD() -> see memory usage in program manager > 134 MB" INKEY(0) RETURN NIL FUNCTION MyRecursive(nLen) LOCAL uArray LOCAL n FOR n = 1 TO nLen uArray := {} AADD(uArray,MyRecursive(0)) NEXT RETURN uArray //-------------------------------------------------------------------------- ------------------------------------------------------- |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-01 18:53:50
|
Luiz, > > > Do you think that the problem can be that the string returned by > > > replacemacros are now processed > > > > No, it doesn't matter, how you produce the string to process. > But this is > so > > easy to debug, just put a TraceLog() for the values in the array, after > the > > call to aTokens(). > Where can i find the tracelog function. Here it is: //--------------------------------------------------------------// INIT PROCEDURE TraceInit() local FileHandle FileHandle := FCreate( 'Trace.Log' ) FClose(FileHandle) RETURN //--------------------------------------------------------------// Function TraceLog( p1, p2, p3, p4, p5, p6, p7, p8, p9 ) local FileHandle, ProcName, Counter := 1, aEntries aEntries := { p1, p2, p3, p4, p5, p6, p7, p8, p9 } FileHandle := FOpen( 'Trace.Log', 1 ) FSeek( FileHandle, 0, 2 ) FWrite( FileHandle, '[' + ProcName(1) + '] (' + Str( Procline(1), 5 ) + ') Called from: ' + CRLF ) do while ! ( ( ProcName := ProcName( ++Counter ) ) == '' ) FWrite( FileHandle, space(30) + ProcName + '(' + str( Procline( Counter ), 5 ) + ')' + CRLF ) enddo for Counter := 1 to PCount() if aEntries[Counter] == NIL aEntries[Counter] := 'NIL' endif FWrite(FileHandle, '>>>' + xToStr( aEntries[Counter] ) + '<<<' + CRLF ) next FWrite(FileHandle, CRLF) FClose(FileHandle) return .T. //--------------------------------------------------------------// FUNCTION xToStr( xExp ) LOCAL cType IF xExp == NIL RETURN 'NIL' ENDIF cType := ValType( xExp ) DO CASE CASE cType = 'C' RETURN xExp CASE cType = 'D' RETURN dToc( xExp ) CASE cType = 'L' RETURN IIF( xExp, '.T.', '.F.' ) CASE cType = 'N' RETURN Str( xExp ) CASE cType = 'M' RETURN xExp CASE cType = 'A' RETURN "{ Array of " + LTrim( Str( Len( xExp ) ) ) + " Items }" CASE cType = 'B' RETURN '{|| Block }' CASE cType = 'O' RETURN "{ Object }" OTHERWISE RETURN "Type: " + cType ENDCASE RETURN "" //--------------------------------------------------------------// > Thanks , for you too, as one of my wishes for 2002 has come true, an Girl > Friend Congrats, hope you two have lot's of fun. Ron |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-01 18:36:43
|
Dwaine > Aside from the Clipper compatible low-level interface, does Harbour have any enhancements that make 32-bit C or Assembly routines link to a Harbour routine more efficiently? Using Harbour extend API. -- Regards Luiz Rafael Culik |
From: Luiz R. C. G. <cu...@sl...> - 2002-01-01 17:40:12
|
Ron > Luiz, > > > I has tryed the atokens() function with hbmake. > > i=B4ve just replaced all listasarray2() calls with the atokens() call. > > > > And I just found that then hbmake dont work. > > Do you think that can be an problem with the function > > I don't think so. The Function is very simple, and also very easy to te= st. I know, is even fastern then listasarray > > Most calls to atokens function is a:=3Datokens(replacemacros(atemp[2]= )," ") > > Do you think that the problem can be that the string returned by > > replacemacros are now processed > > No, it doesn't matter, how you produce the string to process. But this = is so > easy to debug, just put a TraceLog() for the values in the array, after the > call to aTokens(). Where can i find the tracelog function. > BTW Luiz, I know Antonio suggested that you use better formating for yo= ur > code, and I know you said you were in a Hurry, I must tell you my frien= d, > that is so much easier to deal with a properly formatted code. I think = it > must become like a second nature. Most of my written code is properly formated. I know that an good formate= d code make easy to find bugs or enhace an function.The code you refering t= hat Antonio said that was not properly formated was an maindllp.c. If you look on the code now, you will see that is properly formated. > For example even if it was just for an email sample I would write the above > as: > > aWords :=3D aTokens( ReplaceMacros( aTemp[2] ) ) // Note ' ' is the default > separator. > > Also it seems that you tend to post messages about errors, without providing > full info, even when it is very easy to isolate, like in this case. About the error.Most of my errors report i post with an code that show th= e error. On the other side, I recieve many error report on the harbourbr li= st , most of then with out an code that demostrate the error.So I redirect t= hen to the harbour list translated, and ask the poster on the Brasilian list = to provide an small piece of code that produce that error,and most of then d= ont send the code. > I hope you know, that I consider you a dear friend, I decided to say it > because I'm your friend, not to criticize, but instead to help us all b= e > more productive. > > > And before I forget, I wish to you and your family an Great 2002 Thanks , for you too, as one of my wishes for 2002 has come true, an Girl Friend -- Regards Luiz Rafael Culik |
From: Ron P. <Ron@Profit-Master.com> - 2002-01-01 01:53:12
|
Luiz, > I has tryed the atokens() function with hbmake. > i´ve just replaced all listasarray2() calls with the atokens() call. > > And I just found that then hbmake dont work. > Do you think that can be an problem with the function I don't think so. The Function is very simple, and also very easy to test. > Most calls to atokens function is a:=atokens(replacemacros(atemp[2])," ") > Do you think that the problem can be that the string returned by > replacemacros are now processed No, it doesn't matter, how you produce the string to process. But this is so easy to debug, just put a TraceLog() for the values in the array, after the call to aTokens(). BTW Luiz, I know Antonio suggested that you use better formating for your code, and I know you said you were in a Hurry, I must tell you my friend, that is so much easier to deal with a properly formatted code. I think it must become like a second nature. For example even if it was just for an email sample I would write the above as: aWords := aTokens( ReplaceMacros( aTemp[2] ) ) // Note ' ' is the default separator. Also it seems that you tend to post messages about errors, without providing full info, even when it is very easy to isolate, like in this case. I hope you know, that I consider you a dear friend, I decided to say it because I'm your friend, not to criticize, but instead to help us all be more productive. > And before I forget, I wish to you and your family an Great 2002 Same wishes to you and all my "eFriends", and all your loved ones. May the next year bring more peace and less war. > and one more thing. > Remember that errors i´ve reported to you when using -w3 or -w4 switch.Are > they fixed now Great. Ron |
From: Luiz R. C. G. <cu...@sl...> - 2001-12-31 23:52:40
|
Jean > it's 0 oclock here in belgium, We still have 2hours and 20 minutes for 2002 > Happy New year 2002 I wish the same to all people of this list |
From: Luiz R. C. G. <cu...@sl...> - 2001-12-31 23:09:37
|
Ron I has tryed the atokens() function with hbmake. i=B4ve just replaced all listasarray2() calls with the atokens() call. And I just found that then hbmake dont work. Do you think that can be an problem with the function Most calls to atokens function is a:=3Datokens(replacemacros(atemp[2])," = ") Do you think that the problem can be that the string returned by replacemacros are now processed And before I forget, I wish to you and your family an Great 2002 and one more thing. Remember that errors i=B4ve reported to you when using -w3 or -w4 switch.= Are they fixed now -- Regards Luiz Rafael Culik |
From: JF L. <jf...@my...> - 2001-12-31 23:04:23
|
it's 0 oclock here in belgium, Happy New year 2002 Best regards, J. Lefebvre, Bruxelles, Belgium |
From: Ron P. <Ron@Profit-Master.com> - 2001-12-31 21:56:20
|
Luiz, > > > Btw, has you get my email with the filesys enhacements > > > > Yes, I received, but I am not familiar with the issue at all. I will let > you > > complete it the way you find correct. > > Ok. Btw At least hb_FileHandlesStartup() should be called on the app > startup. > Where we could place. this function call In hvm.c where all the other init calls are, just before the RDD I think. Let me know when you are ready (must be tested thoroughly), I can add the call. Ron |
From: Luiz R. C. G. <cu...@sl...> - 2001-12-31 10:23:50
|
Andi > RP> This is simply to give Clipper > RP> compatibility, where, what ever is the link order, the first proced= ure of > RP> the first linked module will become the startup procedure (after IN= IT > RP> procedures). > > A *must* ? I seem to not agree. Only *one* should have been designated > startup - the main module. This shall in no way bother Clipper > compatibility - even enhance it because we could put the main module > wwherever we want, be it in the first, middle or last linking order. Sorry , but I have to agree with Ron. Clipper uses for startup the follow AN main function if present. The first symbol on the first object file linked, Ie Let=B4s say the firs= t function is foo, this will become the main proc -- Regards Luiz Rafael Culik |
From: Andi J. <and...@ha...> - 2001-12-31 06:36:32
|
Ron, RP> > I was confused too at the beginning. Now I ask you the opposite way : RP> > "why HB_FS_FIRST should be needed (hence embeded in C source) while RP> > actually it of no use at all ?" RP> RP> It is used, each compiled module *must* have a designated startup, *incase* RP> this module is the first linked module. This is simply to give Clipper RP> compatibility, where, what ever is the link order, the first procedure of RP> the first linked module will become the startup procedure (after INIT RP> procedures). A *must* ? I seem to not agree. Only *one* should have been designated startup - the main module. This shall in no way bother Clipper compatibility - even enhance it because we could put the main module wwherever we want, be it in the first, middle or last linking order. RP> The HB_FS_FIRST is attributed *once* in each module, so that the VM knows RP> which is the startup procedure, *if* this module is the first linked module. By deleting HB_FS_FIRST from all module _BUT_ the main one, VM will also know what to be executed no matter where it lies in the stack array. RP> > If we review how the VM ( hvm.c ) RP> > initializes start symbol, then we can draw a conclusion that Harbour RP> > only need _one_ module with HB_FS_FIRST and it should be the main RP> > function. The situation was _every_ module has HB_FS_FIRST - a "waste", RP> > is it not ? RP> RP> Not really, because: RP> RP> 1. This is a *MASK* attribute, which means it takes *no* extra space. It RP> lives in the *same* byte used for HB_FS_INITEXIT etc. Of course I did not mean it literally. By being a "waste" I mean as follows: Rather than : LOCAL X := 10 - 2 Why not say : LOCAL X := 8 RP> 2. There is no other way to get the Clipper compatibility, unless changing RP> sort order of the Symbol Table, which is far more complex. RP> RP> > This condition created difficulties particularly when we RP> > work with Harbour DLL. The VM symbol processing routine cannot yet RP> > detect from where the symbols was derived. It cannot yet tell us what RP> > symbols are from EXE and what symbols are from DLL. The VM will RP> > initialize start symbol it it finds a module with HB_FS_PUBLIC and RP> > HB_FS_FIRST. They are a lot of them. Now with -gc3 we "kill" all those RP> > HB_FS_FIRST attribute from very libraries ( and DLL ) and only create RP> > one in the application object files. The VM then detect those from the RP> > linked object. RP> RP> Ok, that explains it. I didn't yet look at the issue, but I trust that you RP> already did. RP> RP> I would then suggest to rename it something like -gcDLL. This will also RP> allow easy generation of other differences, that might be needed for DLL RP> targeted compilation. For example I plan to allow syntax: RP> RP> EXPORT MyHarbourFunction( Param1 AS LONG, Param2 AS STRING ) AS INT [ALIAS RP> "MyExportedCaseSensitiveFunction"] Very nice. With the present CVS tree Harbour is rather not flexible to generate a proper wrapper. It's OK with Borland but I noted some problem with more strict compiler such as MSVC. RP> This will automatically generate the proper required wrapper, dealing with RP> all the parameter preparations, and return value handling, etc (but only RP> relevant for DLLs). RP> RP> > Anyhow, this -gc3 has _NO_ obvious benefit if one works with static RP> > libraries. It is only very useful when we work with DLL. RP> RP> See above ;-) -- Andi Jahja <and...@ha...> <URL: http://harbour-id.net> |
From: Ron P. <Ron@Profit-Master.com> - 2001-12-31 01:08:54
|
Andi, > I was confused too at the beginning. Now I ask you the opposite way : > "why HB_FS_FIRST should be needed (hence embeded in C source) while > actually it of no use at all ?" It is used, each compiled module *must* have a designated startup, *incase* this module is the first linked module. This is simply to give Clipper compatibility, where, what ever is the link order, the first procedure of the first linked module will become the startup procedure (after INIT procedures). The HB_FS_FIRST is attributed *once* in each module, so that the VM knows which is the startup procedure, *if* this module is the first linked module. > If we review how the VM ( hvm.c ) > initializes start symbol, then we can draw a conclusion that Harbour > only need _one_ module with HB_FS_FIRST and it should be the main > function. The situation was _every_ module has HB_FS_FIRST - a "waste", > is it not ? Not really, because: 1. This is a *MASK* attribute, which means it takes *no* extra space. It lives in the *same* byte used for HB_FS_INITEXIT etc. 2. There is no other way to get the Clipper compatibility, unless changing sort order of the Symbol Table, which is far more complex. > This condition created difficulties particularly when we > work with Harbour DLL. The VM symbol processing routine cannot yet > detect from where the symbols was derived. It cannot yet tell us what > symbols are from EXE and what symbols are from DLL. The VM will > initialize start symbol it it finds a module with HB_FS_PUBLIC and > HB_FS_FIRST. They are a lot of them. Now with -gc3 we "kill" all those > HB_FS_FIRST attribute from very libraries ( and DLL ) and only create > one in the application object files. The VM then detect those from the > linked object. Ok, that explains it. I didn't yet look at the issue, but I trust that you already did. I would then suggest to rename it something like -gcDLL. This will also allow easy generation of other differences, that might be needed for DLL targeted compilation. For example I plan to allow syntax: EXPORT MyHarbourFunction( Param1 AS LONG, Param2 AS STRING ) AS INT [ALIAS "MyExportedCaseSensitiveFunction"] This will automatically generate the proper required wrapper, dealing with all the parameter preparations, and return value handling, etc (but only relevant for DLLs). > Anyhow, this -gc3 has _NO_ obvious benefit if one works with static > libraries. It is only very useful when we work with DLL. See above ;-) > ... Ron |
From: Andi J. <and...@ha...> - 2001-12-31 00:19:03
|
Ron, RP> Sorry, I did read [some] of the info on the Harbour list, but I could not RP> understand the purpose of this option. Can you please explain why would it RP> be needed? RP> I mean, the HB_FS_FIRST is just a *mask* attribute, in the *Symbol Table*, RP> it is not affecting the code generation of the function itself. I was confused too at the beginning. Now I ask you the opposite way : "why HB_FS_FIRST should be needed (hence embeded in C source) while actually it of no use at all ?" If we review how the VM ( hvm.c ) initializes start symbol, then we can draw a conclusion that Harbour only need _one_ module with HB_FS_FIRST and it should be the main function. The situation was _every_ module has HB_FS_FIRST - a "waste", is it not ? This condition created difficulties particularly when we work with Harbour DLL. The VM symbol processing routine cannot yet detect from where the symbols was derived. It cannot yet tell us what symbols are from EXE and what symbols are from DLL. The VM will initialize start symbol it it finds a module with HB_FS_PUBLIC and HB_FS_FIRST. They are a lot of them. Now with -gc3 we "kill" all those HB_FS_FIRST attribute from very libraries ( and DLL ) and only create one in the application object files. The VM then detect those from the linked object. Anyhow, this -gc3 has _NO_ obvious benefit if one works with static libraries. It is only very useful when we work with DLL. RP> I guess I'm trying to understand why would it help in the DLL issue, or any RP> other issue. You bet. It is a DLL issue. Doing it windows way may cause incompatilitities with other compilers because of specific windows API function such as GetModuleFileName() etc. which might not exist in other compilers. Doing it at the C-source might help the code be use by other compilers. RP> I understand it could be used to make sure that a certain module does never RP> include a startup module, but why? Everybody links the intended main module RP> first anyway, right? But why every module has to be a startup ? I think, _no_ module _except_ the main one which should be a start-up. This issue is very much related to Clipper compalibility which allows any name as start function. If we would rather use a name constant such as "MAIN" then this issue would never raise because VM will first detect it without analysing where it came from. ( EXE or DLL ). The following snippet might be the culprit: if( ( ! s_pSymStart ) && ( hSymScope & HB_FS_FIRT && ! ( hSymScope & HB_FS_INITEXIT ) ) ) s_pSymStart = pModuleSymbols + ui; /* first public defined symbol to start execution */ This cannot work in DLL configuration unless we kill all HB_FS_FIRST in the DLL. ( Unless we agree to start-up name constant "MAIN" ) -- Andi Jahja <and...@ha...> <URL: http://harbour-id.net> |
From: Ron P. <Ron@Profit-Master.com> - 2001-12-30 23:33:44
|
Andi, Sorry, I did read [some] of the info on the Harbour list, but I could not understand the purpose of this option. Can you please explain why would it be needed? I mean, the HB_FS_FIRST is just a *mask* attribute, in the *Symbol Table*, it is not affecting the code generation of the function itself. I guess I'm trying to understand why would it help in the DLL issue, or any other issue. I understand it could be used to make sure that a certain module does never include a startup module, but why? Everybody links the intended main module first anyway, right? What am I missing? Ron |