Prog to find unused stuff in your source code..part 3

[Eddy Van Esch]

this is a continuation of thread: http://www.powerbasic.com/support/pb...ead.php?t=4084

------------------
[email protected]

[Peter Manders]

I missed this discussion while it was going on, but I would still like to post an idea for an alternative text parser.
I don't have the time to complete it, I took it from a specialized file parser I wrote once.
Maybe someone else can complete it, it should be blazing fast, no need for removing spaces, UCASE$() etc., just raw speed.

It's far from complete, won't compile. I'm posting this so you can get an idea how I think it should be done.

FUNCTION TextParser(hdPtr AS LONG, hdEnd AS LONG) AS LONG
LOCAL i AS LONG
'other locals

STATIC chPointersDone AS LONG
STATIC chDispatch() AS DWORD
STATIC chDispatcher AS DWORD

  IF ISFALSE(chPointersDone) THEN
    '
    DIM chDispatch(256) AS DWORD
    'Default responses:
    FOR i = 0 TO 255
      chDispatch(i) = CODEPTR(char_Default)
    NEXT i

    chDispatch(9               ) = CODEPTR(ch_Tab            )
    chDispatch(10              ) = CODEPTR(ch_Linefeed       )
    chDispatch(13              ) = CODEPTR(ch_Return         )
    chDispatch(32              ) = CODEPTR(ch_Space          )
    chDispatch(34              ) = CODEPTR(ch_Quote          )
    chDispatch(61              ) = CODEPTR(ch_Equal          )
    '
    FOR i = 48 TO 57
      chDispatch(i) = CODEPTR(ch_Digit)
    NEXT i
    FOR i = 65 TO 90
      chDispatch(i) = CODEPTR(ch_Letter)
    NEXT i
    'etc etc.
    chDispatcher = VARPTR(chDispatch(0))
    chPointersDone = %TRUE
  END IF

  'init all flags and variables here:
  QuoteMode = %FALSE

  ! mov eax, 0
ch_StartLoop:

    'eax is already cleared.
    ! mov ebx, hdPtr
    ! mov al, BYTE PTR [ebx]
    ! inc ebx
    ! mov hdPtr, ebx
    ! mov i, eax
    ! shl eax, 2
    ! mov ebx, chDispatcher
    ! add ebx, eax
    ! mov ebx, DWORD PTR [ebx]
    ! CALL ebx
    ! OR eax, eax
    ! jnz ch_ExitLoop
    ! mov ebx, hdPtr
    ! cmp ebx, hdEnd
    ! jb ch_StartLoop

ch_ExitLoop:
  ! cmp eax, %chFinished
  ! jne ch_Finish
  ! mov eax, 0
ch_Finish:
  ! mov i, eax
  FUNCTION = i
  EXIT FUNCTION

'------------------------------------------------------------------------------
ch_Default:
  IF QuoteMode THEN
    ! mov eax, 0
    ! ret
  ELSE
    ! mov eax, %chBadData
    ! ret
  END IF

'------------------------------------------------------------------------------
ch_Return:
  'reset line flags (this is just an example [img]http://www.powerbasic.com/support/forums/smile.gif[/img]
  QuoteMode = %FALSE
  ! mov eax, 0
  ! ret

'------------------------------------------------------------------------------
ch_Space:
ch_Tab:
  IF QuoteMode = %FALSE THEN
    'last word was completed, process word, reset word flags
    '
    '
  END IF
  ! mov eax, 0
  ! ret

'------------------------------------------------------------------------------
ch_Quote:

  QuoteMode = 1 - QuoteMode
  ! mov eax, 0
  ! ret
'------------------------------------------------------------------------------
'all other character processing goes here.


END FUNCTION

Peter.


------------------
[email protected]

[Guest]

I like the drag & drop checkit - for all the reasons Lance mentioned.

[Borje Hagsten]

Does anyone know max length of a Sub/Function/Variable name? Reason
for asking: The less space to allocate in TYPE array, the faster the
prog becomes. I have tested with using 100 byte len there and it makes
quite a difference to original 255, in large projects.

I guess not many uses more than 10-20 bytes in such names, but to play
it safe, what to use? For my own sake, even 30 is more than enough, but
for public use one must consider extreme naming - so if there's a limit,
it would be good to know..


------------------

[Lance Edmonds]

Physical lines can be up to 255 bytes long, so allowing for the trailing text such as "=0" or " _", the theoretical limit would be something like 253 characters.

I've never actually seen anyone use more than about 40-50 characters (or they get too long to be manageable!), to I'd ude 64, and place a BIG note at the top of the code about this restriction.

OTOH, the 'original' CheckIt is well and truely fast enough for a programmer (such as me!) to find useful, so why bother introducing a limit at all, just to squeeze a few 1/10th's of a sec off the processing time?! :P

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Michael Mattias]

I've never actually seen anyone use more than about 40-50 characters [for symbol names] ....place a BIG note at the top of the code about this restriction.

This will likely be considered a dopey idea, but, why not edit and report TYPE names > nnn characters?

Oh.. I forgot.. when programmers are users, they are not really users...

MCM




[This message has been edited by Michael Mattias (edited July 24, 2001).]

[Kev Peel]

Posted by Scott Slater:

Let me know if you find any bugs that I missed.

Scott,

A few probs:

CheckIt won't open source files with anything other than the 'bas' extension in lowercase, so it won't open '.BAS' or '.INC' files.
CheckIt reports some globals as ununsed when they are actually in use (it reports all globals as unused)

All in all though, a very useful program that gets a deserved place on my task bar!

Thanks & Regards,


------------------
Kev G Peel
KGP Software, Bridgwater, UK.
mailto:[email protected][email protected]</A> http://www.kgpsoftware.com

[Tom Hanlin]

Feel free to join in posting code, Michael. Or is it true that, when programmers are users,
they're not really programmers?

Confirmed that variables of the form "DIM xxx AS GLOBAL yyy" are incorrectly shown as unused.
I also noticed that "g_" was reported as an unused variable in one code set. While "g_" is
not a valid symbol name, the prefix "g_" is used in this code set to indicate a global symbol.

Nice utility!

------------------
Tom Hanlin
PowerBASIC Staff

[Scott Slater]

I'm still working on DIM xxx AS GLOBAL yyy but the lower case bug with
the file names got past me. I also added the ability to open .INC files
as well as fixed the lower case bug. I just posted an update to the web
site a minute ago. Thanks for the reports Kev, Tom. I'll see what I can
do about the DIM GLOBAL thing soon.

Scott


------------------

[Borje Hagsten]

Tom, I guess you mean like "g_xx"? As I understand it, underscores must
be preceeded with a space to become valid linewrap. For other use, it
must be placed inside variablenames and cannot be placed first/last (in names).

BTW, something is missing in the Drag/Drop handling. I think, if
DragAcceptFiles has been used to register a Window, one should
unregister this in for example the dialog's WM_DESTROY.

Also, in GetDroppedFiles procedure, it should end with DragFinish.
So, in MainCB:

     CASE %WM_DESTROY
        CALL DragAcceptFiles(CBHNDL, 0)

..and at bottom of GetDroppedFiles procedure:

    CALL DragFinish(hDrop)

BTW2: why accept multiple files? Usually we have one main file and
a bunch of includes. What happens if we drop main + includes? I
think a program like this needs to make sure the file carries a
COMPILE statement, this making it main source file, otherwise no
point in searching for all globals, etc. (include files don't know
who's their parent). To rely on extension, BAS, is not okay. I use
many included sub-dialogs in the form of .BAS files..

I'm working on another approach. Looks promising so far but must
test more, because there's so many different aspects to consider.
Will post result when it's more ready.


------------------


[This message has been edited by Borje Hagsten (edited July 24, 2001).]

[Borje Hagsten]

Took a look at the command$ procedure in this project. Changed a few
things and added LFN support. The GetAttr part was wrong. Cannot compare
directly - must do it bitwise, since a folder can have other variations
than plain 16. Haven't looked at latest files, maybe already changed..

Not sure of the LFN part here. What if a user sends a mix of long and
short file names - with long ones in double-quotes and the others without?
How does Win2K treat command$? Does it automatically embed files in DQ's,
or is this always up to the user to do?

'************************************************************************
' GetCommandFiles - Function Loads File/Folder names into the global arrays
'************************************************************************
FUNCTION GetCommandFiles( BYVAL CmdStr AS STRING, Fi() AS STRING, Fo() AS STRING ) AS LONG  'Returns the number of files in the string
    LOCAL TempStr AS STRING, i AS LONG, j AS LONG, k AS LONG, Count AS LONG, pStr AS STRING
 
    IF INSTR(CmdStr, $DQ) THEN
       pStr = $DQ
    ELSE
       pStr = " "
    END IF
 
    Count = PARSECOUNT(CmdStr, pStr)
    REDIM Fi(Count)             ' Make room in the global array
    REDIM Fo(Count)             ' Make room in the global array
 
    DO
        INCR k
        TempStr = TRIM$(PARSE$(CmdStr, pStr, k))
        IF LEN(TempStr) = 0 THEN EXIT DO
        IF (GETATTR(TempStr) AND 16) THEN ' check if it's a dir
            INCR i
            Fo(i) = TempStr   ' directorys
        ELSE
            INCR j
            Fi(j) = TempStr ' Files
        END IF
    LOOP
 
    REDIM PRESERVE Fi(j)        ' Make array the correct size
    REDIM PRESERVE Fo(i)        ' Make array the correct size
    FUNCTION = Count
END FUNCTION

------------------


[This message has been edited by Borje Hagsten (edited July 24, 2001).]

[Tom Hanlin]

Yep, I mean variables like g_hWnd. No, a line continuation underscore doesn't
necessarily follow a space. An underscore is a line continuation character if
it can't be part of a symbol name. So, it may come directly after something
like a left paren, equals sign, etc. as well as after a space.

Windows has no conventions when it comes to passing filespecs on the command
line. They may be quoted or they may not. In a case where you expect that
more than one filespec may be passed, a good approach is to look for the first
non-space character. If it's a quote, pull everything up to the next quote as
a single filespec. If it's not a quote, pull everything up to the first space.
Repeat until you've processed the whole command line.


------------------
Tom Hanlin
PowerBASIC Staff

[Borje Hagsten]

Thanks for the explanation, Tom.

Will have a closer look at COMMAND$ handling later on. In the meanwhile,
I have just uploaded PBCODEC.ZIP to my site. It is my version of this
prog. Interface is same, but it only accepts single dropped files. Also,
changed some in the report code so it's easier to copy line numbers.
Lots of code is rewritten, "my way", so to speak..

Parsing is done correctly in all include files and it even handles DIM
xx AS GLOBAL. Pretty fast too. Have tested on my own projects and all
is ok, so far. Have more ideas for it, but this is first working copy.
The zip file contains both pbcodec.bas and pbcodec.exe, and can be
downloaded from: http://www.tolken99.com/pb/pbcodec.zip


------------------

[Wayne Diamond]

Borje,
I just ran pbcodec.bas with pbcodec.exe, it found nothing that was un-used, but down the bottom there are no references.. ?

********************************************************************************
--- TOTAL REFERENCE COUNTS ---
(format is: Reference count, Name)

INCLUDES:
 D:\PBDLL\WINAPI\WIN32API.INC
 D:\PBDLL\WINAPI\COMDLG32.INC

It correctly found my include files


------------------

[Wayne Diamond]

btw, do these programs ignore comments and strings?
for example, these may be throw-offs...

 Dim RealFunction
 'Dim CommentedFunction
 MyStr$ = "Dim StringFunction"

"RealFunction" and "MyStr$" are the only things that should be looked at, just something to be cautious of
im amazed how fast this has progressed, its sensational being able to analyse PB code like this. Drinks all round! (i heard that Bob was shouting?)


------------------

[Kev Peel]

How about including it with the PB/xx distribution? Since some customers may not visit this forum or even have internet access?

Regards,

------------------
Kev G Peel
KGP Software, Bridgwater, UK.
mailto:[email protected][email protected]</A> http://www.kgpsoftware.com

[Borje Hagsten]

Pbcodec blanks out all text within string quotes and removes uncomments,
etc. Silly bug in last file, because I used a bunch of listboxes while
developing and in the process of removing all those, I made some stupid
mistakes. Sorry, but new file just uploaded, one that works and scans
all files this time..


------------------

[Borje Hagsten]

Lots of PB users never visit here. Maybe not so easy for PB INC. to include
utilities like these in their main distribution. Means support, etc. Think
they have their hands full with the compiler/ide. To bring these tools up
to "professional" state, means a lot more work needs to be done.
We usually stop when it works. A huge difference when it comes to
distribution.

My own experience is that when the coding is ready, one is half-way through
the project. The comes documentation, installation procedures, ide polishing,
etc. Not sure PB inc. would be willing to pay for such things. I know I once
tried to contact them about their standing "job-offer", and gave them a few
ideas of things I could do, like rewriting POFFS so they could include it on
their installation CD, etc, but didn't even get an answer. Guess they have
their hands full with other things right now (a little bird has whispered
that next version is just around the door..


------------------

[Borje Hagsten]

New upload to http://www.tolken99.com/pb/pbcodec.zip

Did some minor adjustments, plus changed report a bit to have aligned
columns, etc. Report looks much better now, IMHO..


------------------

[Borje Hagsten]

Added minimize button to dialog, date and time to report and infobk
color to label on dialog. New file just uploaded..

------------------
and again - found silly bug in the handling of DIM AS GLOBAL, that made
the program include other things in search. Now fixed and seems to work
like it should..

[This message has been edited by Borje Hagsten (edited July 25, 2001).]