LB Booster - Odd Behaviour

LB Booster

IDE and Compiler

Compiler (Moderator: Richard Russell)

Odd Behaviour

« Previous Topic | Next Topic »

Pages: 1

Author

Topic: Odd Behaviour (Read 748 times)

CryptoMan
New Member

member is offline

Gender:

Posts: 46

Odd Behaviour
« Thread started on: Aug 19^th, 2016, 7:04pm »

I was trying to debug this SUB

Code:

'=================================================================================================================
 SUB ParseTLV X$ 
'=================================================================================================================
    #s.te, "*PARSE TLV 1*"
    LOCAL.DEBUG=1
    CALL ZeroTAGS
	#s.te, "*PARSE TLV 2*"
    i=0
    TLV$=X$
    [CONT]
    i=i+1
    TAG$=LEFT$(TLV$,2):IF TAG$="5F" OR  TAG$="9F" THEN TAG$=LEFT$(TLV$,4): PTR=5 ELSE PTR=3:TAG$=TAG$+"  "
    LGT$=MID$(TLV$,PTR,2):PTR=PTR+2
    VLU$=MID$(TLV$,PTR,HEXDEC(LGT$)*2):PTR=PTR+2*HEXDEC(LGT$)
    CALL AddTAG i,TAG$,HexDec(LGT$),PackIso$(VLU$)
	#s.te, "*PARSE TLV 3*"
    TLV$=MID$(TLV$,PTR)
    p=FindTag( PackIso$(TAG$) )
	#s.te, "*PARSE TLV 4*"
    IF LOCAL.DEBUG THEN print #s.te,SPACE$(35);TAG$;" ";LGT$;" ";VLU$;" ";emvTAGS$(p,4)
    IF LEN(TLV$) THEN [CONT]
    i=i+1
    CALL AddTAG i,"9F35",1,PackIso$("22")
    i=i+1
    CALL AddTAG i,"9F45",2,PackIso$("DAC1")
	LOCAL.DEBUG=0
END SUB

But this DIM was missing which was supposed to be in another INCLUDE file for GLOBAL and DIM declarations.

Code:

DIM    emvSFI$(10,10),emvTAGS$(200,4),emvTEMPS$(20,2),TAGSinCard$(200),TAGLenCard(200),TAGValue$(200 ),CandidateList$(20),Candidate$(20)

I was getting NOT IN FN or something like that error but I was not yet at this page. So, I was putting my cookie crumbs to find where it was blowing up.

Instead of #s.te, "PARSE TLV 1*", I put a NOTICE and magically my code started running.

Then I was curious because it was parsing properly and listing the tags from the list as it is supposed to do and I made some cosmetic edits like adding SPACE$(35) for nice indentation and it was still working.

But, IF LOCAL.DEBUG THEN print #s.te,SPACE$(35);TAG$;" ";LGT$;" ";VLU$;" ";emvTAGS$(p,4) wasn't coming out because it was not previously populated, so I put an ">" instead of " " to see it more clearly and after this point my code stopped working
like it was supposed to not work because CALL ZeroTAGS must have blown up before because the arrays were not dimensioned.

Code:

SUB ZeroTAGS
'=================================================================================================================
FOR i=1 TO 200
    TAGSinCard$(i)=""
    TAGLenCard(i)=0
    TAGValue$(i)=""
NEXT
END SUB

After this I realized my DIMs were missing.

But, now the question is, how did it worked when it worked when it was not supposed to work?

Include is a nice feature but some improvement is needed because it is not telling us on which line of Include an error happens.

Another thing is if you write a wrong file name, it just continues without any warnings just as a simple comment. Then you wonder when your code blows when that function or sub inside that function is called and missing.

It will be good if INCLUDE is case insensitive, either INCLUDE or Include or include means the same thing like other BASIC keywords.

It will be also nice if LBB displays somewhere on the IDE when it starts processing an INCLUDE file and line numbers. For example by changing the title of the dialog box from "Boosting your program" to something line "Now, including INC/FOO.BAS 126 / 890...."

Also, it will be nice if it can sense an update is made in an include file and re-compilation is made. I add arbitrary blank lines to main to force compilation but sometimes I forget and get puzzled why something I changed still not working. However, I can live with this.

My question is, how did the code run on ZeroTAGS with 200 element arrays worked and it didn't complain for emvTAGS$(p,4) ?

« Last Edit: Aug 19^th, 2016, 9:17pm by Richard Russell »

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: Odd Behaviour
« Reply #1 on: Aug 19^th, 2016, 9:15pm »

on Aug 19^th, 2016, 7:04pm, CryptoMan wrote:

Include is a nice feature but some improvement is needed because it is not telling us on which line of Include an error happens.

INCLUDE is intended to be used with libraries: code modules that are already thoroughly tested. You shouldn't attempt to INCLUDE a file that might have errors, for the reasons you say. Of course one can never be 100% sure that a library is bug-free, so there's a possibility of a failure that cannot easily be traced, but that should be rare.

Quote:

Another thing is if you write a wrong file name, it just continues without any warnings just as a simple comment.

That's by design. Otherwise LBB would fail to run a Liberty BASIC program that (by chance) has a comment line that happens to start with the word include.

Quote:

Also, it will be nice if it can sense an update is made in an include file and re-compilation is made.

That's related to my first point: INCLUDE is intended for use with libraries that are complete and stable. Changing the contents of an included file whilst one is developing the 'parent' program is not expected.

Quote:

My question is, how did the code run on ZeroTAGS with 200 element arrays worked and it didn't complain for emvTAGS$(p,4) ?

In Liberty BASIC it is not necessary to declare an array with DIM if it has 10 or fewer elements, so if p was less than 11 you would not expect an error to be reported.

Richard.

Logged

CryptoMan
New Member

member is offline

Gender:

Posts: 46

Re: Odd Behaviour
« Reply #2 on: Aug 20^th, 2016, 08:49am »

You can see that SUB ZeroTAGS is trying to go up to 200 elements. Ofcourse, I know you don't need the DIM up to 10.

The odd behaviour is how did it call ZeroTAGS and didn't blow up and code worked huh

That's the second statement on top of SUB ParseTLV.

And, this is the critical question.

* * *

Other things are WISHLIST related to 'include for which I have the following remarks.

'include filename.ext obviously understood that it should pass without problems on LB because it will look like comment.

So, why not 'INCLUDE filename.ext or 'Include filename.ext should have a different effect on LB?

Upper case INCLUDE makes it more visible especially when comments are in pale colours.

Furthermore, who cares if LB will blow up or not with 'include ?

Once, you carried out your code pieces into include files, would there be slightest chance that LB to compile without errors and work?

I think an include'lized version is effectivelly a LBB source file which is only fit for LBB and there is nothing can be achieved by hiding it under a comment. I can not think of any use case.

In fact, a proper <include filename.ext> syntax is more logical and it will be good to cause a compilation error on LB, rather than insidiously seeping through the compilation. It is a better to sense an unsuitable code at the beginning rather than hiding and later surfacing at runtime.

* * * * *

Yes, we know libraries, true and tested code, etc but remember that we are trying to port and clean up LB code into LBB with the objective of better organization and managebility. During this clean up process, we are moving code pieces into different include files function by function, sub by sub. Sometimes, we want to relocate certain subs
and functions in different include files.

Thinking about MAKE files where we defined the dependencies on
.c files, .h files, .o files, .lib files, whatever needed to be recompiled and linked was made automatically by MAKE. Yes, I know this is not C compiler, but ofcourse something can be done to sense a change in the includes and cause a recompile if this INCLUDE feature to be more useful and avoid some mistakes. When you work for hours and tired, you may miss that the recompilation wasn't made.

* * * * * *

With regard to comment lines from LB with a chance include as the
first line relates to another issue. If you accidentally write a wrong filename with our intended includes, it simply ignores it and continues without any warnings or errors. This is also possible cause for later runtime errors.

So, <include stdio.h> could be a better option.

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: Odd Behaviour
« Reply #3 on: Aug 20^th, 2016, 09:44am »

on Aug 20^th, 2016, 08:49am, CryptoMan wrote:

The odd behaviour is how did it call ZeroTAGS and didn't blow up and code worked???

Here is a test:

Code:

CALL ZeroTAGS
END

SUB ZeroTAGS
'=================================================================================================================
FOR i=1 TO 200
    TAGSinCard$(i)=""
    TAGLenCard(i)=0
    TAGValue$(i)=""
NEXT
END SUB

That reports 'Bad subscript at line 7' as would be expected. If your program did not report an error I would suspect the presence of an ON ERROR GOTO statement.

Quote:

Furthermore, who cares if LB will blow up or not with 'include ?

I do! An important use of 'include is to support the new functions in LB 4.5.0 - after$(), afterlast$(), httpget$() etc. The way LBB supports those functions is by means of the supplied lb45func.bas library:

Code:

'include lb45func.bas

This only provides a compatible solution (i.e. one that results in the program working in both LB 4.5.0 and LBB) because LB 4.5.0 treats the 'include directive as a comment and ignores it. If, as you propose, the include directive were to cause LB to "blow up" the new functions could not be supported this way.

Quote:

I can not think of any use case.

Well, the fact that you cannot think of a use case doesn't mean there isn't one - and an extremely important one.

Quote:

In fact, a proper <include filename.ext> syntax is more logical

You do like stating your opinion as if it is fact! Other people may disagree with you, but still have a valid point of view.

Quote:

If you accidentally write a wrong filename with our intended includes, it simply ignores it and continues without any warnings or errors.

It's true that an error may only be reported at run-time, rather than at compile-time, but in LBB many errors are only detected at run-time anyway (it's a weakness of most interpreted languages, including LB 4).

Richard.

Logged

CryptoMan
New Member

member is offline

Gender:

Posts: 46

Re: Odd Behaviour
« Reply #4 on: Aug 20^th, 2016, 1:35pm »

Thanks for your explanations.

True. There was an ON ERROR GOTO at the main program

Code:

 ON ERROR GOTO [ERROR.HANDLER4]
 FILE.NAME$="BATCH/OFLINE.TXT"
 OPEN FILE.NAME$ FOR INPUT AS #1
 LINE INPUT #1,X$
 CLOSE #1

but this was inside a SUB and there was no local label [ERROR.HANDLER4] in that SUB. What happens in that case? Does it try to jump to the main block?

Because, I saw it functioning, and then after some simple changes like ">" instead of " ", it stopped working. If error handler was making it work earlier, it should have continued making it work.

Please test and see the conditions below.

Code:

ON ERROR GOTO [HANDLER]


PRINT "BEFORE PARSE"
CALL ParseTLV
PRINT "AFTER PARSE"


END

[HANDLER]
  PRINT "Error "; Err$; " "; " code "; Err
  PRINT ""
  DIM TAGSinCard$(200),TAGLenCard(200),TAGValue$(200)
  RESUME
END


END

SUB ParseTLV
    PRINT "PARSE TLV"
    CALL ZeroTAGS
    PRINT "CONTINUE PARSE"
    PRINT "IT CAN NOT RETURN TO MAIN LOOP"
END SUB


SUB ZeroTAGS
PRINT "ZeroTAGS"
FOR i=1 TO 200
    PRINT "ZT ";i
    TAGSinCard$(i)="Z"
    IF Err PRINT "AFTER ERROR 1"
    TAGLenCard(i)=0
    IF Err PRINT "AFTER ERROR 2"
    TAGValue$(i)=""
    IF Err PRINT "AFTER ERROR 3"
NEXT

PRINT "END ZERO LOOP"
FOR i=1 TO 200
    PRINT USING("###",i);" ";TAGSinCard$(i);" ";
    IF NOT(i MOD 10) THEN PRINT
NEXT

NOTICE "WAIT"

END SUB

An error is caused in a SUB and there is no local label and it makes a long jump to main and succesfully sets the dimensions and recovers the error condition and resumes to the point of error and from the later listing we see that it succesfully assingns "Z" to index 11, completes the loop and SUB ZeroTAGS returns back to SUB ParseTLV which can go all way to END SUB but from that point it can not return to the main.

Also,if you remove DIM statement by commenting out, the program stops with an error and doesn't continue looping.

In my error handler there was nothing for dimension fixing and it happily looped around 200 times.

*******
In what I reported as odd behaviour was that in my error handler there was no remedial dimensioning,etc but it was proceeding past [CONT] and properly parsing the string correctly and was printing TAG LENGTH VALUE except displaying the name of the tag as expected because it was not populated so FindTAG was finding position 0 and displaying blank string.

However, I saw it working albeit writing a little bit on the left, so I added SPACE$(35) to make cosmetic correction.

Then I came to investigate why tag name was not being retrieved and I simply changed a " " to ">" and it stopped working.

At that point I realized my mistake about DIM.

How did it work mysteriously?

Could WMLIBERTY.DLL cause this in the main loop used for WINSOCK handling?

Logged

CryptoMan
New Member

member is offline

Gender:

Posts: 46

Re: Odd Behaviour
« Reply #5 on: Aug 20^th, 2016, 1:48pm »

Why do I get an error at array index 1 in the following code?

Code:

PRINT "BEFORE PARSE"
CALL ParseTLV
PRINT "AFTER PARSE"
END
 

SUB ParseTLV
    PRINT "PARSE TLV"
    CALL ZeroTAGS
    PRINT "CONTINUE PARSE"
    PRINT "IT CAN NOT RETURN TO MAIN LOOP"
END SUB


SUB ZeroTAGS
'ON ERROR GOTO [HANDLER]
PRINT "ZeroTAGS"
FOR i=1 TO 10
    PRINT " ZT ";i;
    TAGSinCard$(i)="Z"
    IF Err PRINT "AFTER ERROR 1"
    TAGLenCard(i)=0
    IF Err PRINT "AFTER ERROR 2"
    TAGValue$(i)=""
    IF Err PRINT "AFTER ERROR 3"
NEXT

PRINT "END ZERO LOOP"
FOR i=1 TO 10
    PRINT USING("###",i);" ";TAGSinCard$(i);" ";
    IF NOT(i MOD 10) THEN PRINT
NEXT

GOTO [wait]

[HANDLER]
  PRINT "Error "; Err$; " "; " code "; Err
  PRINT ""
  DIM TAGSinCard$(200),TAGLenCard(200),TAGValue$(200)
  Err=0
  RESUME


[wait]
NOTICE "WAIT"

END SUB

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: Odd Behaviour
« Reply #6 on: Aug 20^th, 2016, 2:20pm »

on Aug 20^th, 2016, 1:35pm, CryptoMan wrote:

but this was inside a SUB and there was no local label [ERROR.HANDLER4] in that SUB. What happens in that case? Does it try to jump to the main block?

Yes, in that case it will automatically exit the SUB and jump to your error handler in the main block. This should work even if an error occurs within a deeply-nested SUB: LBB should automatically 'unwind the stack' until it reaches a point where the error handler is 'in scope'.

Quote:

Please test and see the conditions below.

RESUME cannot work if your error handler is in a different scope from that in which the error occurs. As I explain above, when the error happens the stack is automatically unwound until it reaches the scope containing the ON ERROR; at that point there is no way that it can 'get back to' the original scope in which the error occurred.

This is explicitly documented in the Compatibility section of the LBB help: "RESUME must be used within the scope of the SUB or FUNCTION (if any) in which the error occurred". It may be different from how LB4 behaves, but it's standard in other languages.

ON ERROR GOTO is an archaic construct prone to all sorts of problems (hardly surprising because GOTO is involved!). Consider using Structured Exception Handling (SEH) which is implemented in LBB by means of the try, catch, end try and throw statements.

on Aug 20^th, 2016, 1:48pm, CryptoMan wrote:

Why do I get an error at array index 1 in the following code?

It's because when LBB compiles your program it sees that you have a DIM statement for that array. It has no way of knowing that, in fact, the DIM is never executed at run-time so it doesn't fall back to the 'every array is assumed to be dimensioned with subscript 10' default.

It's (once again) called out explicitly in the LBB Help docs: "If you receive the error message 'Bad use of array' check that your program doesn't attempt to access an array before it is DIMensioned".

You might find it helpful to read through the LBB Help file.

Richard.

« Last Edit: Aug 20^th, 2016, 2:45pm by Richard Russell »

Logged

CryptoMan
New Member

member is offline

Gender:

Posts: 46

Re: Odd Behaviour
« Reply #7 on: Aug 21^st, 2016, 4:25pm »

Thanks for pointing me towards SEE.

I missed that subject and I will learn how to use it.

I have been strugling all last week and all this weekend trying to understand the logic and errors.

One issue I am having is the following. If I make a mistake and give a wrong [label], LBB does not stop and give an error pop up saying:
"Unresolved [label], execution stopped on Line XXXX" but rather wanders off to infinity and only resolution is Task Manager Kill button and at this stage I observe a CPU usage of around 30%. In normal flow this is less than 1%. Maybe it is trying to find that label beyond the limits of program code space or something you can better explain.

Another puzzling thing is Not in function at Line 0 error which is very puzzling. It succesfully compiles but then at run stage this error comes. Evidently for something like this GLOBAL p,q,r, ,x,y,z
a mistake I made when I was weeding out my code where I removed a redundant global variable and forgot to remove the comma. Instead of stopping the compilation and pointing out to line this is happening.

Maybe a two pass compilation with the first pass with stronger syntax and error checking and more clearly reporting errors and if this stage is clear than going about what is now doing could be better. As it is now, it is not very forgiving. No mercy for mistakes. And, it is really costing a lot of time trying to understand what is going on.

This is why I was looking for the old XREF software I remember from the early days of Basic listing all variables and on which lines this variable is used. Obviously one can write such a software himself but being lazy and lots of code to convert to LBB, I was wondering if somebody already knows such a tool. I noticed Notepad++ has a nice feature highlighting the variable all over the source code - not always but most of the times. That helps during this conversion.

OK. I must go back to my conversion and clean up work.

Logged

tsh73
Full Member

member is offline

Gender:

Posts: 210

Re: Odd Behaviour
« Reply #8 on: Aug 21^st, 2016, 5:06pm »

Quote:

This is why I was looking for the old XREF software I remember from the early days of Basic listing all variables and on which lines this variable is used. Obviously one can write such a software himself but being lazy and lots of code to convert to LBB, I was wondering if somebody already knows such a tool

Have you tried program from reply#4 of your question on LB forum?

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: Odd Behaviour
« Reply #9 on: Aug 21^st, 2016, 5:16pm »

on Aug 21^st, 2016, 4:25pm, CryptoMan wrote:

If I make a mistake and give a wrong [label], LBB does not stop and give an error

As always, I wish you would give an example! Normally LBB will report an error; try this code:

Code:

    goto [non.existent.label]
    end

This reports (at run-time) "No such line at line 1". So if you are not receiving this error message I need to see a (preferably simple) self-contained program that demonstrates the issue.

Quote:

Evidently for something like this GLOBAL p,q,r, ,x,y,z

I agree that the error message you receive in this case is less than informative! If you look at the BBC BASIC code generated it's clear why it is happening, but ideally LBB ought to report something more obvious. I'll see if there's a simple (and safe) change I could make.

Quote:

As it is now, it is not very forgiving. No mercy for mistakes.

I've explained before why the error reporting is poor. It's because LBB was originally envisaged as a tool that you would use to 'boost' a program that had already been developed and tested in LB 4, therefore the expectation was that the program would not have any syntax errors. Now LBB has developed into more of a stand-alone IDE, in which you can write programs from scratch, ideally the error reporting should be better than it is.

Quote:

I was wondering if somebody already knows such a tool.

There's LBReader by Jim Brossman (mknarr) which lists all the variables, arrays etc. used in a program. See this thread at the LB Community forum.

Richard.

Logged

tsh73
Full Member

member is offline

Gender:

Posts: 210

Re: Odd Behaviour
« Reply #10 on: Aug 21^st, 2016, 6:25pm »

LBReader by Jim Brossman (mknarr)
lists stuff and counts how much times it used
XREF - A LB Cross Referencer by terciops
lists lines where stuff is used.

Logged

Pages: 1


« Previous Topic \| Next Topic »