$$external problem

[Giorgio Garabello]

It's the first time I try to create a function using the $$ external Qliberator directive.

I copied the following sample program from the manual:

50 REMark $$ external
60 DEFine Function FRA (x)
70 RETurn x-INT (x)
80 END DEFine

I compiled it and then loaded it into memory using the LRESPR command.

When I try to run it

PRINT FRA (3)
hangs on the RETURN statement with the following error: "non-numeric string", then it crashes?

I'm doing the tests on QPC2 ...

Some idea?

[Derek_Stewart]

Hi,

Try line 50 without the space between $$ external

That is:

Code: Select all

50 REMark $$external

[EmmBee]

Hi Georgio,

You need to do your tests on a real QL or Q-emuLator, and you will get the expected answers.

Unfortunately, these QLIB externals will not currently work with QPC2.
What happens is that x gets the value of an empty string,
and INT expects a numeric value, so this causes the error,
but the function would not return anyway.

EmmBee

[Giorgio Garabello]

these QLIB externals will not currently work with QPC2

Damn!

Are there any alternative ways to create extensions?

[pjw]

these QLIB externals will not currently work with QPC2

Damn!

Are there any alternative ways to create extensions?

Yes, in assembler But why do you have to do this? It is no faster that incorporating the S*BASIC code in your (compiled) program. You could have a library of such toolkits and just paste them into your code as needed (as I do) or use Wolfgang's SBASIC linker..

[Peter]

You need to do your tests on a real QL or Q-emuLator, and you will get the expected answers.
Unfortunately, these QLIB externals will not currently work with QPC2.

What is the technical reason for this?

[Giorgio Garabello]

these QLIB externals will not currently work with QPC2

Damn!

Are there any alternative ways to create extensions?

Yes, in assembler But why do you have to do this? It is no faster that incorporating the S*BASIC code in your (compiled) program. You could have a library of such toolkits and just paste them into your code as needed (as I do) or use Wolfgang's SBASIC linker..

Assembler?....argh! (i'm ignorant)

I wanted to create a species of "API" to facilitate the work of other programmers ....

[EmmBee]

You need to do your tests on a real QL or Q-emuLator, and you will get the expected answers.
Unfortunately, these QLIB externals will not currently work with QPC2.

What is the technical reason for this?

The trouble is apparently caused by QPC2 not recognizing it has been called from the Interpreter's #0.
The code will work if called from another compiled SBASIC Qliberator job, I've just tried this.
So, these QLIB externals do actually work with QPC2, but they currently cannot be used in Interpreted SBASIC.

EmmBee

[RWAP]

I wanted to create a species of "API" to facilitate the work of other programmers ....

Why not just leave the functions as SuperBASIC for people to incorporate within their own programs.
They could be coupled with the QL Library Manager by Ergon Development - http://www.dilwyn.me.uk/program/index.html

[Giorgio Garabello]

I wanted to create a species of "API" to facilitate the work of other programmers ....

Why not just leave the functions as SuperBASIC for people to incorporate within their own programs.
They could be coupled with the QL Library Manager by Ergon Development - http://www.dilwyn.me.uk/program/index.html

In my case it is an extension / command that acts in insertion on a Blackphonix system file ..
I want to make sure everyone can take advantage of the service but that no one can enter data that is formally wrong.
I believe that alternatively I used an executable program.

Of course it would be interesting to solve the problem of extensions!

Giorgio