NameCheck

Anything QL Software or Programming Related.
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: NameCheck

Post by dilwyn »

Thanks Steve.

Won't be attempting to parse _bas files, but may try to parse _sav files. Don't think I can reliably parse an untokenised _bas file.

The intention is that when compiled it works on a program loaded into memory, so you can use it as you develop and run a program. As it's not compiled yet, run it in an SBASIC daughter job (type SBASIC, then load namecheck_bas - it then works against job 0 basic.)

As I can't reproduce the error you describe, could you let me have a copy of the basic program you were using, or perhaps print out the values of the variables in the line at which the error occurs (to help me work out what's happening)? Obviously the binary chop search routine is having a problem with something. This is the problem with lifting routines like this from my older programs where they may not be used in quite the same way. Values such as m,mid%,number% and search$. Have you done any changes to the namessc_txt file, for example?

Bit of a setback. There was a Windoze 10 update last night which has trashed a few things as QPC2 was open overnight, as Windoze updates do, so some time will be wasted sorting things out this morning. QXL.WIN was backed up so shouldn't be more than wasted time. Must learn not to leave QPC2 open on Tuesday nights at the mercy of M$ :cry:


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: NameCheck

Post by dilwyn »

Ah, found the bug, don't bother Steve.
The problem is with the string that BASIC_NAME$ extracts from the name table for an unset name, such as an unquoted filename in the program (i.e. garbage when your error occurs).
Can work around it by range-checking the search strings until I resolve the main issue with reading the name table entries.
Further investigation needed, as results seem different on QDOS to SBASIC.


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: NameCheck

Post by stevepoole »

Hi Dilwyn,

Glad to see you found the bug. I was stumped by it, after trying many fixes !

I have tried mergeing a very long _bas file at the end of namecheck_bas, and, except for the line 750 bug, your program seems to check all the extra names OK !

That means no need for turbo'd or daughter'd code ? ( As your program is the only one needing to be loaded into Basic, before mergeing ) ....

I look forward to reading the ensueing developments.

Steve.
_______________________________________________


EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: NameCheck

Post by EmmBee »

Hi Dilwyn,

I am getting the same error as Steve.
My guess is that we don't have your very latest program.
There is no "REPORT_ERROR", no "FOUND" and no "choice" names in namecheck03, but these names show up in your .jpg file.

EmmBee


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: NameCheck

Post by dilwyn »

stevepoole wrote:Hi Dilwyn,

Glad to see you found the bug. I was stumped by it, after trying many fixes !

I have tried mergeing a very long _bas file at the end of namecheck_bas, and, except for the line 750 bug, your program seems to check all the extra names OK !

That means no need for turbo'd or daughter'd code ? ( As your program is the only one needing to be loaded into Basic, before mergeing ) ....

I look forward to reading the ensueing developments.

Steve.
_______________________________________________
It hadn't occurred to me to merge NameCheck with your own program. In that case, it might need a line number range check to exclude results from NameCheck itself? Although NameCheck is a bit long to do that for every program.

The line 750 error occurs because of trying to compare the long garbage string which BASIC_NAME$ returns (still not sure why) and gets compared against shorter strings in the search routine. Still working on why that happens. In my case it goes wrong at name table entry 1047, but later entries are correct. May be due to an arithmetic error with the pointers, or not rounding up odd length strings resulting in name lengths being read from an odd or incorrect address perhaps. No doubt it'll turn out to be a silly mistake and I'll be kicking myself when I find it.
EmmBee wrote:I am getting the same error as Steve.
My guess is that we don't have your very latest program.
There is no "REPORT_ERROR", no "FOUND" and no "choice" names in namecheck03, but these names show up in your .jpg file.
All our setups vary - different names in the name table etc.
I guess you are running NameCheck on itself in that case, I wasn't. My sample screen showed it running in a second SBASIC against my Basic Reporter program which was in Job 0, hence the differing names.

Successfully restored my qxl.win after last night's W10 update, PC seems OK now.


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: NameCheck

Post by stevepoole »

Hi Dilwyn,

The bug stems from the variable 'longest%' being defined twice :

2090 longest%=0
2190 DIM array$(number%-1, longest%)
2240 longest%=0

The fix I have used is to allow a longer array-string, 2190 DIM array$(number%-1, Longest% *2)
Times 2 may be too much, so I will have to investigate further.

But the program runs OK now,( even with a 62ko basic program merged on to the end )....

Steve.


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: NameCheck

Post by dilwyn »

While that will help you get past the problem temporarily, it doesn't fix the fact that garbage (sometimes long strings)is being picked up from the nametable. Randomly, you may find it exceeds even that.

Had a chance to look at why this is happening. Of course it's as simple as BASIC moves about and details in the nametable change as it runs.

Even using the Turbo Toolkit functions to access BASIC structures may see things change between commands. So while a program is trying to examine itself, things can move and cause chaos.

It works a lot more reliably if you run NameCheck in a daughter SBASIC or compiled, rather than merging it with your own program (so that job 0 BASIC is still and doing nothing while NameCheck runs), until I can build in some length safeguards for the search routine, as most of the rest of the code survives this, if a bit clumsily.

Changing the subject: Quite a storm happening here now, we usually lose electricity during high winds like this so...fingers crossed for tonight.


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: NameCheck

Post by stevepoole »

Hi Dilwyn,

After re-starting QPC2, I can now get your version of the program to work (on my _bas file) as a Sbasic daughter job.

As of yet, Your Turbo'd program will not execute at all (on my _bas file), so I am still investigating....

I have tested the modified version with several long MERGED _bas files, and found no problems as of yet.

This program should prove to be very useful for ensuring platform compatibility !

Many thanks again for your effort. A great job.

Steve.


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: NameCheck

Post by dilwyn »

Great, thanks Steve.

The version you have probably won't compile without a great deal of changes. I've done a lot of work on the program today, so here's the latest _bas and compiled _task for you to tinker with.

Still a bit flaky and prone to stopping unexpectedly, but making progress.
namecheck04.zip


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: NameCheck

Post by stevepoole »

Hi Dilwyn,

Both your 'version 04' task and daughter Sbasic programs run fine on my system. (QPC2).

Tested using very complex _bas files !

What more do we need ?

Best Wishes,

Steve.
______________________


Post Reply