QLCommander v2.2.x

[Andrew]

What I did first, was introduce a call counter in your code (i.e. count recursive calls of CalcDirSize). With your original code and your set data space of 96k, it managed to reach like 380 calls before running out of data space.
Then I made the following changes to your code:

Code: Select all

REMark Line 8700 removed (b$ = MDHEADR$(newname$)
REMark Line 8800 removed (x = LONGINTEGER (b$(1 TO 4)))
8810 x = FLEN (\fname$) : REMark added, should do basically the same as the above

(I think that should do roughly the same as your code)
And the code could happily do 900 calls and more with the same data space size set as above (and ran through even my longest directory trees with no problem whatsoever).

Thank you Tobias - the counter is a great idea! Also the use of flen(\name$)!! How could I forget about flen? I am using it in other parts of my program!
WIth flen and dataspace 64k the test program happily does at least 1629 calls without any issues! (The largest win drive I have "only" has 1629 directories)

Next step, after Per updates the toolkit, is to check which is faster: MDHeader or flen

[pjw]

Well, thats it, then, I hope. Update on knoware.no.

Just the usual culprit: not properly tidying the stack. It must have been an ancient problem after all, as I thought I learnt that by now! I also fixed the code a bit: The header is read right onto the RI stack instead of going via the S*BASIC buffer.

I couldnt find any way to test on Level 1 drivers! On all the emulators I tried MDLEVEL returned 2 (even on AH ROM without TK2) Is this correctl or is there a problem with my code?

[pjw]

<>
Next step, after Per updates the toolkit, is to check which is faster: MDHeader or flen

There are much better ways to get the info you require than MDHEADR$. MDHEADR$ was never intended to be used that way..

If you used the method of accessing the directories as demonstrated in my DirCount routine, as shared above, then

LGET#ch\ ps + 0, leng: leng = leng - 64

is probably the fastest way. In fact, you have the whole file header right there and all the info you need can be fetched with simple GETs, BGETs, etc. But as I just found out: Turbo doesnt understand GET on strings, ie for the name. There you have to use GET$ or something.

[martyn_hill]

Nice one Per!

That darn RI Stack - I still get in trouble with it, even after studiously following Dilwyn's terrific and comprehensive article on the topic

I'll test your Level1/2 query later and update this thread.

[pjw]

Hiya Per!

I'm sure you've made Andrei a very happy fellow

Cant think how I missed this one.

Good grief, man, give yourself a break! Given the sheer volume of truly useful stuff you've made available to us over the years, I think a little slip is acceptable, now and again!

Thanks again for your great library of stuff and for taking the time and care to maintain it for us!

Thank you!

[pjw]

<>
I'll test your Level1/2 query later and update this thread.

That would be fantastic! It used to work, Im sure.

[martyn_hill]

Hi again Per

But as I just found out: Turbo doesnt understand GET on strings, ie for the name. There you have to use GET$ or something.

Just a point of clarification - later versions of Turbo DO support TK2's GET (with those pesky reference string params) - but:

a) ONLY on SMSQe and
b) If the appropriate directive is used "TURBO_ref" (no parameters itself)

e.g.

Code: Select all

100 TURBO_ref
110 TURBO_windo 3
120 TURBO_taskn "TestGET"
130 TURBO_objfil "win1_testGET_exe"
140 TURBO_repfil "dos2_testGET_txt"
150 REPeat loop
200   INPUT #0,"Enter folder-path:"!path$
210   IF path$="" THEN PAUSE 200: EXIT loop
220   fCh%=FOP_DIR(path$)
230   IF fCh%<0 THEN PAUSE 200: EXIT loop
240   GET #fCh%\14
250   GET #fCh%,fnam$
260   PRINT "GET returned:"!fnam$
265   CLOSE #fCh%
270 END REPeat loop
280 STOP

That said, ref params are not especially 'en-vogue' and, given the platform limitation, GET$ et-al are probably the better course...

[pjw]

Hi again Per

But as I just found out: Turbo doesnt understand GET on strings, ie for the name. There you have to use GET$ or something.

Just a point of clarification - later versions of Turbo DO support TK2's GET (with those pesky reference string params) - but:

a) ONLY on SMSQe and
b) If the appropriate directive is used "TURBO_ref" (no parameters itself)
<>

Ok, thanks for the tip. All I did was to take a perfectly normal piece of S*BASIC code (as in DirSizeQ_bas in the zip above) and try to compile it with Turbo. It compiled alright, but on running it the first problem started with: Line 122: Not found! And what is so special about line 122? Here is is:

120 odr$ = datad$: rem Keep original DATAD$
122 dir$ = odr$: sub$ = '': rem ????!!!!

After renaming stuff willy-nilly (as per DirSizeT_bas) it got past that little awkwardness, but the names came out blank, etc, etc. But I got there in the end.

Freddy V always used to say that SuperBASIC was not Turbo compatible. I have always thought it the other way round

[Andrew]

Freddy V always used to say that SuperBASIC was not Turbo compatible. I have always thought it the other way round

You are not the only one! I prefer QLiberator by far! No compatibility issues, produces shorter code and also has better error trapping: WHen Error, When variable, When Expression, Q_Err etc.
I decided to compile QLCommander with Turbo because
- Turbo it is said to be slightly faster
- the discussions about "Q_Liberator malaise" and Q60
- and last but not least, I had Martyns support on all Turbo quirks

[pjw]

<>
I decided to compile QLCommander with Turbo because
- Turbo it is said to be slightly faster

Anyone choosing to work with original QL hardware will have the patience to forego the 5-10% Turbo speed up

- the discussions about "Q_Liberator malaise" and Q60

As Ive demonstrated elsewhere, for those platforms where this matters, they should just run the SBASIC source code directly. The outcome is virtually identical qua speed, functionality, compactness, etc. And for those who so choose, their code can be obfuscated, producing a result not much worse than decompiled Turboed or Qlibbed stuff.

- and last but not least, I had Martyns support on all Turbo quirks

Yes, that must be invaluable Martyn is welcome to compile any of my programs, especially those that might conceivably benefit!

I have tried with some of them, but without much success. It took me an hour just to Turbo compile that simple 80 line DirSize program, above. Of course, had I been familiar with Turbo, and written programs from scratch with Turbo in mind it might not be too hard..

I dont mean to dis Turbo. I used it for many years, from SuperCharge and onwards. But it just like having a girlfriend who insists on everything being done her way, and always trying to "improve" you. And at the end of the day the sex is not that much better..