Announcement

Collapse
No announcement yet.

Max number of statements 'tween line numbers?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Donald Darden
    replied
    I noted something in your initial code that I wanted to comment on.
    With PowerBasic, there are two ways to identify line lables:

    (1) Use a standalong line number, such as 12345, which optionally
    can be followed by a colon (

    (2) Use a suitable name, similar to a variable name, but follow
    it with a colon ( and allow no statement on that line.

    In general, there are three techniques for renumbering or renaming
    lines in a BASIC source file for use in PowerBasic:

    (1) Renumber every line, possibly with an incremental step, such
    as 10, or 20, in case you want to add new statements in between,
    This assumes that line numbers will be used or assigned in
    sequece, from low to high, over the course of the program.

    (2) Renumber only referenced lines, such as those that are
    targeted with GOTO or GOSUB, and eliminating line numbers that
    are not really needed to compile the program. This reduces the
    size of the source code, show you where join points occur in
    the code from other areas in the program, but reduces the value
    of ERL if an error occurs and you are trying to trap for it.

    (3) Rename line numbers making them names, such as taking 12345
    and renaming it "L12345:", so as to get rid of line numbers in
    the old BASIC style (BASICA, GWBASIC, and others). Again, if a
    line number is not actually used, it is removed.

    Typically, programs that do this for you might be called a
    Renumber, Labler, ReLable, or one of the services provided by
    a Format, ReFormat, or Convert program.

    Another thing that a Format, Reformat, or Convert program might
    do would to break up very dense lines where multiple statements
    appear separated by colons. This may appear to make the program
    much larger, but it also means you now have room to either add
    new line numbers for every statement (for more specific trapping)
    or you now have space per line for adding more comments to your
    source. Neither change will make the resulting compiled program
    any arger. And another advantage of a Format, ReFormat, or
    Convert program is that it can standardize the source, apply
    rules of capitalization, indentation, and other benefits.

    I want to make sure that you know that the name "Format" is also
    shared by a utility for reformatting disk drives, and we do not
    want you formatting disk drives by accident. But it is one of
    the names sometimes employed for modifying source code files.

    I seem to recall a converter utility called QB2PB, which did a
    pretty good job converting QBASIC and QuickBASIC ASCII source
    files to PB/DOS. It could also handle GWBASIC and BASICA
    source files and convert them over. There were some problems
    with graphic statements because QBASIC and QuickBASIC use a
    different graphical coordinate system than adopted by PowerBasic.

    The thing about PowerBasic is that it can be configured to use
    Conventional Memory, Expanded Memory, and Extended Memory, so
    that you had far less reason to be concerned with the 640 kb
    limits of DOS.

    Of course you also have the option to convert over to PB/CC in
    place of PB/DOS. PB/CC has evolved quite a bit from the earlier
    versions of BASIC, which means a lot more built-in functionality,
    but it is not so far from them that it also makes it too hard to
    adapt the source code.

    Towards this end, lets take a look at another piece of your code:

    Code:
    7920 ' - Select Hour wanted
    7930 GOSUB 9440:IF TZ THEN GOSUB 10220
    7940 PRINT KK$;:IF TZ THEN GOSUB 10310
    7950 LINE INPUT Y2$:IF Y2$="E" OR Y2$="e" THEN 8080
    7960 IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
    7970 IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN 7980 ELSE 7930
    7980 ' - Wk hr
    7990 IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
    8000 Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
    8010 HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
    8020 IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
    8030 GOTO 8050
    8040 HT=HT+12:Y2$=RIGHT$(STR$(HT),2)+":00PM"
    How about instead:
    Code:
     ' - Select Hour wanted
     7920 GOSUB 9440
     7930 IF TZ THEN GOSUB 10220
          PRINT KK$;
          IF TZ THEN GOSUB 10310
          LINE INPUT Y2$
          IF Y2$="E" OR Y2$="e" THEN 8080
          IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
          IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN
            GOTO 7980
          ELSE
            GOTO 7930
          END IF
    7980 ' - Wk hr
          IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
          Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
          HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
          IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
          GOTO 8050
    8040 HT=HT+12
         Y2$=RIGHT$(STR$(HT),2)+":00PM"
    8050
    When you do this, you begin to see that the line numbers can be
    made into lables, and the lables can have meaning. The GOSUB
    and [some implied] GOTO commands can jump to labels that are
    named to have some meaning in context, such as AM: and PM:.
    Fact is, some GOSUB commands can be replaced with SUBs or
    FUNCTIONs that are named for the tasks that they perform.

    What you had to do with BASICA, GWBASIC, QBASIC, and QuickBASIC
    were what you had to do at the time, but techniques and methods
    can be refined over time. With earlier BASICS, you sometimes
    could only perform one statement or multiple statements with
    colon separators on a single line - there were no multi-line
    IF structures with ELSEIF, ELSE, and END IF to help you. And
    for structure, you did not have SELECT CASE, CASE, CASE ELSE, and
    END SELECT, what you had was ON GOTO or ON GOSUB to contend with.

    Things are so much better now that it is worth adapting. As to
    adapting your code to use the new functionality, that is your
    call. You can usually still use it as originally written, or you
    may find value in at least a partial rewrite.

    ------------------
    Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

    Leave a comment:


  • Michael Mattias
    replied
    Just a thought... is it possible you are referencing a line number in a different code segment (not a different module, just one line referencing another line with one or more intervening $SEGMENT directives?

    I never really thought about it before, and since I never had a problem with it I assume the compliler either picks this up or doesn't care, but as long as the question is from Mars you may as well consider a suggestion from Jupiter.


    Leave a comment:


  • Mike Luther
    replied
    You are totally correct Michael ..

    I 'may' have posted here on at least two occasions that worrying
    about which particular compiler functions you use to test/compare/jump
    is unlikely to produce as much performance improvement as a careful
    look at your own code design.

    I'm not trying to show you up or anything; I'm just using this as an
    example of what happens when you modify code many times over the
    years (no code lives as long as yours has without lots of modifications)
    and then wonder where your blazing speed went.
    And your critique absolutely has to be valid for a lot more of my
    code than what I posted above. Sadly. And, no, you are not trying to
    show me up or anything. Plus what you posted here, I hope, will help
    a lot more folks than me to think carefully about what you have said
    not only about this, but in a heck of a lot of other comments you've
    made in the forums Michael. You are a major contributor here and have
    been, in my eyescape, and the time to do that doesn't come free either.

    Thank you.


    Not only are you correct, I've got what it takes to document what you
    say from the work here to actually show people how right you are and
    why what you say is so important.

    The above code chunk actually supports what you are saying in your
    critique of my work far more than you expected, sigh. The calendar
    module was 'taken' from parts of the broadcast station log programming
    codework, originally 'extracted' for concept 'can we do this?' as my
    current records show, in 1991.

    One of my utilities I wrote originally in Basic for my Heathkit Z120
    looks for string data in any collection of files for a file name slice
    overlay description match in a given file path. I looked for the
    following text in this case, "RIGHT$(Y2$,". Admittedly I'm lax in that
    from the files here I can't go back prior to 1985 in that we have
    operating system issues for the work that was originally done in eight
    inch floppies, the Heathkit Z120 and H89 boxes that *ARE* still there
    for proof. But this'll show exactly how right you are Michael, grin.

    From a WordStar file with the following internal trace date in the
    128 bytes from the control header at the top of every WS format
    file, grin:

      02-15-85
    From that 1985 file we find the following code where it was pulled
    from the 1976-era broadcast station operations code that started in
    BASIC at radio station WTAW in College Station, Texas. Incidentally,
    there are very few "W" broadcast stations west of the Mississippi
    river in the USA instead of KORA etc. The original Aggieland student
    EE Department crew got the call letters from the FCC for "Watch The
    Aggies Win". And the their first broadcasts were indeed of football
    games here in CS.

    I can go back to 286CPU code in CPM if we need to but this'll do
    as to show how right you are! From that February 1985 file:

    Code:
    7920 ' - Select Hour wanted
    7930 GOSUB 9440:IF TZ THEN GOSUB 10220
    7940 PRINT KK$;:IF TZ THEN GOSUB 10310
    7950 LINE INPUT Y2$:IF Y2$="E" OR Y2$="e" THEN 8080
    7960 IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
    7970 IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN 7980 ELSE 7930
    7980 ' - Wk hr
    7990 IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
    8000 Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
    8010 HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
    8020 IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
    8030 GOTO 8050
    8040 HT=HT+12:Y2$=RIGHT$(STR$(HT),2)+":00PM"
    8050 IF HT=24 THEN MID$(Y2$,6,2)="AM":HT=0:GOTO 8080
    8060 IF HT=12 AND RIGHT$(Y2$,2)="AM" OR HT=12 AND RIGHT$(Y2$,2)="am" THEN HT=0
    8070 L=INT(VAL(MID$(Y2$,4,2))):LL=L:IF L<1 OR L>60 THEN L=0
    8080 GOSUB 9970:RETURN
    At another time you made a very important point in working with me
    here that one really needs to keep accurate revisions files and old
    source information so you can document all the changes. I try. BTW,
    one day when I get the time, Will Honea showed me how to re-configure
    the OS/2 floppy diskette driver loader parameters so I can actually
    tie one of those eight inch floppy or an older 5-1/4" floppy diskette
    with the Heathkit DOS format to the current OS/2 operating system!
    We could go all the way back to just after CP/M for this quest here if
    we want. But thistle dew .. I think, to show the color of the blossom.

    Marvelous this OS/2 operating system. Not only do we have USB and all
    but we go back all the way to just after CP/M on the same box!

    GDRFC!

    What this whole thread now shows though is an even more important look
    at project techniques, 'wrongs' and 'rights' that most would never
    see. We program as people; each of us are different. We each see
    our world bounded by our own limitations, which all of us have. As
    an MBA in corporate planning from Texas A&M, strongly looking with
    eyes that see text data and realizing that all professional management
    is really the same, I've sought to containerize that concept.

    For over 40 years now.. And I'm getting closer and closer each year.

    Yes, the art is in the deal and numbers control it. But it is still
    the TEXT and the variable length string data that are the mechanisms of
    payment for whatever. As I can see over all this.

    And yes, string data. an array of characters if you 'see' it that way,
    grin, is best compared and directed through integer math pointers!
    A truely competent 'reader' only should read a line once. The step
    to representing that text and what it means in the fastest possible
    recall of it, can't be efficently applied to the text words to describe
    what you view, if you have to read the line over and over again before
    you act on that data each time. You may get paid by the text, but
    you'd better be able to index it by integer pointers if you ever
    want to make a profit.

    My problem is the template that encapsulates all this is so huge as
    for what I really see. So many vectors; so little time. You have
    to simultaneously, in real-time, keep key data from leaking out of
    the control template before you have been really hurt by what's been
    'wrongly' taken from your pie. And yes you are right again.

    You have to periodically review the whole project and try to even
    re-design it and completely look at things differently as the
    focus on the canvas changes. Yet, Michael, on that special night
    when you catch a glimpse of the whole picture, the moon only is
    there for maybe ten minutes over the whole horizon .. which has
    all the other details in it you must remember?

    And it is a hundred years until that precise picture comes back
    again for you to see? You won't live that long, so you begin
    to work at capturing the beauty. You must.

    My problem is precisely as you say. If I were a better reader, I'd
    realize in my programming that I'd be better able to point to the
    solutions with mathematics, than I now do as I see things. Yes,
    the code above shows I have made real progress since 1985 at making
    things more maintainable and clear. But there is a long way to go
    down this management trail of stary night events, Michael.

    Your point is very well taken. You are correct. At the same time
    the overview is still massively before me. There is still art in
    the deal which I see which has to be on the canvas as a working
    calendar module before I can go back and touch up the canvas.

    It's like looking at a painting and seeing the real overview, knowing
    what might be done, but still not finished with the painting to be
    able to handle the details.

    I was in the room at a Holiday Inn in Baxter, Iowa, when a young guy
    named Charlie McLain, on New Year's Eve in the 60's said, "Folks,
    here's a song we're thinking of recording I like to try on you.
    See what you think about it," And then, for the first time, in
    public, he sang, "Stary stary night ... Amber fields .."

    Two years ago, Vincent Van Gough's painting "Stary Night" was on
    exhibit at the Houston Museum of Fine Art. You bet I went to see
    it. And I GUARANTEE you that you ain't seen what Vincent wanted
    you to see until you've looked at the original. For the admission
    money they were right in step with technology. You got a personal
    hand held. You punched in the integer number of the painting in
    this massive exhibit of fine art and a custom audio track talked
    to you about the painting at which you were looking.

    Yap, yap .. all the technical details about Vincent's trip to the
    monastery and so on. As you would expect, there was a large crowd
    in front of that painting, including a tour clump of extra-paid-for
    folk led by one of the exhibition planners. I wasn't in that group,
    just happened to be there then. The guide asked, "Any questions?"

    Ny overview broadcasting engineering management personality got the
    best of me. I asked him, "If you've gone to all the beautiful work
    to put this wonderful modern audio track together for the show,
    and this painting, why didn't you background this track with
    the music for Stary Stary Night from McClain's Vincent?"

    Answer, "Gee, I never thought of that!"

    Gee, Michael, you've just done exactly the same thing to me, and
    you are so correct. All I can tell you is that it's awfully hard
    to see the details on the canvas for the real nuances in the scene,
    when you have to go over and over the work 'cuz the hairs fall out
    of the brush every time you go to add an impression swipe at the
    canvas.

    But the brush issue is only another of the same sort of things that
    *ALL* of us face when we try to really put out work which is on the
    edge of what can be done with the technology resources. That at
    the same time economics focus all of us on what we can and cannot
    afford to add to our pallet and application tools.

    I really do understand why sometimes we have to work with things the
    way they are. But realizing that even not knowing if some otherwise
    unseen limit in the tools we have, might cure things, if I just knew
    it, makes me ask. Even IBM, as big as it is, has a phrase, "Customer
    has a workaround." Even they are important.

    It takes a lot more than any of us have as individuals. or even big
    corporations sometimes. to define what really can be done in any
    creative work. And believe me, what you offered is important to me.
    I'll try, when I can get the thing working, again, this time, on the
    canvas, to see what highlights can be placed on it to make it better.

    Thanks again for your time. I guarantee you that the time you have
    spent here, along with that of many others, has made my screen
    look brighter, handle more data, and move faster than I ever could
    have done by myself.

    Meanwhile.

    Does anyone here have any idea what the statement limit might
    be between two consecutive numeric line lables in PB 3.5?

    Inquiring mind wants to know.





    ------------------
    Mike Luther
    [email protected]

    Leave a comment:


  • Michael Mattias
    replied
    >Thoughts?

    Not directly on topic, but you asked....


    Code:
    SUB AP37894 (DTMEORG$, Y2$, GFF%, HT%, L%, LL%) PUBLIC '        CVRTTIME:
    37899   Y2$ = DTMEORG$ '                        Set to convert selected time
               IF VAL(Y2$) < 0 OR VAL(Y2$) > 2359 THEN
                  GOTO APDCV1 '                     Units per hour
               END IF
               IF LEN(Y2$) < 3 OR LEN(Y2$) > 6 OR INSTR(Y2$, ":") > 0 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF LEN(Y2$) > 4 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF VAL(Y2$) < 1159 THEN '            Fix it up
                  Y2$ = Y2$ + "AM"
               ELSE
                  Y2$ = Y2$ + "PM"
               END IF
               ' next test is totally useless becuase above always
               ' makes the last character an upper case M
               IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
                  GOTO APDCV2
               END IF
    APDCV1:
             GFF% = 1 '                             Set bad time flag
             EXIT SUB
    
    APDCV2:
         etc..
    You know, Mike, in your other post you query about the difference in performance between SELECT CASE and IF..ELSEIF blocks.

    If this is typical code you are looking at, you are whistling past the graveyard. The code here is exceptionally redundant and uses the string engine far more than it needs to.

    If I haven't missed something here, you are editing a time. The rule is the length of string must be exactly three or four characters, because you test for LEN<3, LEN>6 and LEN>4) and all failed tests "GOTO APDCV1" (which sets GFF% = 1 and EXITs); must not contrain a colon (although I would think it must be numeric, period); the HHMM must be in range ; and if the time passes the edits, a formatted "AM/PM" time is output.

    You are testing LEN and VAL of the string multiple times... even when the string will fail a later edit.

    I suggest we might try something like:
    Code:
      Y2$ = DTMEORG$ '                Set to convert selected time
      LY2% = LEN(Y2$)               ' take length only once so we can do integer compares
          SELECT CASE LY2% 
            CASE 3%, 4%             ' the only valid lengths
               VY2% = VAL (Y2$)     ' only need to test VAL if length is in range, right?
                                    ' so take it only once instead of twice
               IF VY2% < 0 OR VY2% > 2359 THEN
                  GOTO APDCV1                   ' out of valid range
               END IF
              ' string is now known to be correct length and its VAL is in range
              ' so what could have screwed this up? Perhaps a colon chararter?
               IF INSTR (Y2$, ":") THEN
                  GOTO  APDCV1
               END IF
              ' so fix up the string (doing the integer compare instead of taking VAL again)
               IF VY2% < 1159 THEN 
                  Y2$ = Y2$ + "AM"
               ELSE
                  Y2$ = Y2$ + "PM"
               END IF
               ' --------------------------------------------------------------------
               ' This test from original code is totally useless because above always makes
               ' the last character of Y2$ an upper case "M", so the test is ALWAYS true;
               ' so get rid of it and just GOTO the "passed edits and formatted" label
               ' (this must have been some kind of 'emergency edit' which got left in)      
               ' IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
               ' --------------------------------------------------------------------
               GOTO APDCV2
    
           CASE ELSE            ' just exit to error point, invalid length
              GOTO APDCV1
    
       END SELECT               ' of length

    I 'may' have posted here on at least two occasions that worrying about which particular compiler functions you use to test/compare/jump is unlikely to produce as much performance improvement as a careful look at your own code design.

    I'm not trying to show you up or anything; I'm just using this as an example of what happens when you modify code many times over the years (no code lives as long as yours has without lots of modifications) and then wonder where your blazing speed went.

    MCM

    Leave a comment:


  • Mike Luther
    started a topic Max number of statements 'tween line numbers?

    Max number of statements 'tween line numbers?

    I wonder?

    No matter how carefully you decide you'll allocate actual line
    numbers in PB 3.5 for program use in error handling mostly, there
    comes a time...

    A time with 25,000 lines per program including CALLS, libraries,
    Units, whatever - that it is necessary to make statements between
    contiguous physical numeric line labels in the code. At least that
    has happened here.

    OK. So what? Well, you can use the ":" mark to delimit statements
    in the source code with many of them on one line.

    OK .. you can also, in the quest to make code more understandable
    and easier to maintain, simply move to what I've done totally and
    go to one line per statement.

    But .. I'm curious. Is there a maximum number of physical statements
    either coded with ":" separators on one line, or into single none
    labeled pure one statement per line uses you can make between two
    physical adjacent number sequence numeric line labels in PB 3.5.

    **********************************

    Reason I'm curious is that once again I just spent another seven hours
    here chasing the mysterious SYS3170 error in very large executables in
    OS/2 DOS-VDM's in huge PB executables. This error is:

    [C:\]help sys3170

    SYS3170: A program in this session encountered a problem and
    cannot continue.

    EXPLANATION: The process was ended because the program generated
    an unhandled fatal user (non-system) exception through DosRaiseException.

    ACTION: If you purchased this program, contact the supplier of the
    program. If you are the developer of this program, refer to the
    information in the register.

    ************************************

    There is no way to debug these large programs here with PBD as there
    simply isn't enough memory to even operate them, even with 675K of
    free memory at the raw command prompt line. Thus I wind up hand
    inserting little break point traps line after line one at a time
    until I can find the exact place where the trap takes place.

    Here, once again, hours later I'm faced with the 'solution' which is
    a simple numeric line lable in the source of 37899 in the below. If
    I don't add a line lable to it we get the SYS3170 .. or SYS3176
    is possible too. With the following, absolute stable runtime:

    Code:
    SUB AP37894 (DTMEORG$, Y2$, GFF%, HT%, L%, LL%) PUBLIC '        CVRTTIME:
    37899   Y2$ = DTMEORG$ '                        Set to convert selected time
               IF VAL(Y2$) < 0 OR VAL(Y2$) > 2359 THEN
                  GOTO APDCV1 '                     Units per hour
               END IF
               IF LEN(Y2$) < 3 OR LEN(Y2$) > 6 OR INSTR(Y2$, ":") > 0 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF LEN(Y2$) > 4 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF VAL(Y2$) < 1159 THEN '            Fix it up
                  Y2$ = Y2$ + "AM"
               ELSE
                  Y2$ = Y2$ + "PM"
               END IF
               IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
                  GOTO APDCV2
               END IF
    APDCV1:
             GFF% = 1 '                             Set bad time flag
             EXIT SUB
    
    APDCV2:
         etc..
    Now I already know from long BITTER experience I can't put any actual
    operational code directly adjacent to a non-numeric line lable as
    is shown above. But that's another story..
    Remove that 37899 numeric line lable and the whole DOS-VDM session
    comes crashing down. It's the first time in all these years it has
    popped to my attention that could this be related to the total number
    of statements between two adjacent numeric line lables? There is a
    lable above it statements back of 37899 and, in this case, a numeric
    line lable for error trap reporting purposes of 37902.


    Thoughts?



    ------------------
    Mike Luther
    [email protected]
Working...
X