QLiberator v3.42

[EmmBee]

It would be interesting to see, if QLib with the runtimes do a similar thing than SBASIC.

Let's put it to the test. We'll give them both the same program and see how they get on.

Code: Select all

160 CLS
170 first
180 second "hello"
190 PAUSE 100
200 STOP
210 :
220 DEFine PROCedure first
230 LOCal x
240   FOR x = 1 TO 10 : PRINT ! x !
250   PRINT
260 END DEFine
270 :
280 DEFine PROCedure second(x)
290   PRINT x
300   first
310 END DEFine

First, running this under the Interpreter in QPC2 ..
It prints out a row of ten numbers, says "hello", then prints another set of ten numbers.

Now Compiling with QLiberater and running ..
It prints out a row of ten numbers, says "hello", then unexpectedly stops with a FOR type error.

As a matter of interest, if we compile this with Turbo ..
It prints out a row of ten numbers, fails to say "hello", then stops with an error in expression.

It would seem that SMSQ/E wins the day.

EmmBee

[duncan]

I can see why the compiled programs ought to fail.

The procedure "second" is passed a variable x which is actually a string - hence the likely problem with Turbo and for QLIB when "second" is called x has been defined as a LOCal for "first". Why not define the variable passed to second as x$ and see if it works.

Cheers

[RalfR]

In the case of QLib: Yes, it works, when "second" is changed to "x$". Which is also more correct for my opinion.

Seems to be a special behaviour of SMSQ/E when a variable is undefined.

And I think Turbo always awaits DIMed variables.

[EmmBee]

Yes, you're right, using x$ in "second" instead of "x" makes it work correctly.

With Turbo, all variables of the same name will only ever have one type, in this case, a float.
Since we cannot assign the string "hello" to a float, this explains the error in expression.

QLiberater, on the other hand, acts just like the Interpreter, in which case procedure parameters will take their type from the incoming actual parameters.
In this case, the x in "second" is a genuine string type. That fact should explain why QLiberater is able to say "hello" to us.
The reason why QLib fails with a FOR loop error is because QLiberater bans any FOR loop ids coming through the parameter mechanism. Why? ..
I believe the reason is to ensure all FOR loop ids only ever have one type.

Cheers, EmmBee

[duncan]

smsq/e can be forgiving about variable types but the compilers are not usually. Turbo strings do need to be dimensioned. By default if my recollection is correct they are dimensioned to 100 characters but this may not apply to strings passed as variables. Perhaps x$ might need to be explicity dimensioned before being passed for Turbo.

Cheers

[EmmBee]

I attach my latest dissembly of the patched Qlib_run (and all the other user-side toolkits that came with Qlib 3.36). Ive been using the resulting binaries for a while now without issue (not that that guaranatees there arent any..)

As I mentioned in my previous communication with you and other interested parties, I made some suggestions to re-arrange the furniture a bit. Since no further objections were forthcoming, those changes are included here. See the enclosed readme_txt file for details.

Any constructive feedback is welcome, as is any further analysis of these toolkits.
Qlib342b.zip

I notice that in Qlib342run_asm the comments appear to be truncated at lines 4152 to 4255. Perhaps they were already like that!

The general overall idea is to bring together all that's needed to use the Qlib system.
This seems to be a good idea, and it's also good to promote SMSQ/E, which gives the best user experience for users who want to write their own code.

SMSQ/E forever !

EmmBee

[pjw]

<>
I notice that in Qlib342run_asm the comments appear to be truncated at lines 4152 to 4255. Perhaps they were already like that!

Not truncated, just not expanded. It takes a bit of donkey work and I didnt feel like making the effort until the functional bit is working properly.

The general overall idea is to bring together all that's needed to use the Qlib system.
This seems to be a good idea, and it's also good to promote SMSQ/E, which gives the best user experience for users who want to write their own code.

Agreed!

SMSQ/E forever !

That slogan has rather sad connotations for me. Used by former QL luminaries who have now, sadly, defected to the dark side..

[RalfR]

SMSQ/E forever !

That slogan has rather sad connotations for me. Used by former QL luminaries who have now, sadly, defected to the dark side..

Wish, I could understand this.

[BSJR]

First, running this under the Interpreter in QPC2 ..
It prints out a row of ten numbers, says "hello", then prints another set of ten numbers.

Now Compiling with QLiberater and running ..
It prints out a row of ten numbers, says "hello", then unexpectedly stops with a FOR type error.

It would seem that SMSQ/E wins the day.

One would hope that if it's valid for SMSQ/E it should be valid for Qlib too.
As the second 'first' proc is called from inside the 'second' proc, the x - now a string - is also kept and thus fails at FOR.
Maybe even SMSQ/E is too forgiving here. Checking all these different x uses does complicate parsing.

Changing the main program to below does not change the intended output but avoids the x confusion.
160 CLS
170 first
180 second "hello"
190 first
200 PAUSE 100
210 STOP

BSJR

[BSJR]

I have not yet used any of the Qlib 3.37+ versions but reading the Readme file up to 3.42 no mention is made of the $$asmb= limits and I cannot remember if it has been addressed before.
Only 8 code files can be added this way at compile time. Is it possible to extend this limit in 3.43?

BSJR