Bug in EXTRAS in SMSQ/E?

Anything QL Software or Programming Related.
Post Reply
User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Bug in EXTRAS in SMSQ/E?

Post by programandala.net »

I've just realised the EXTRAS command doesn't work as expected in a daughter SBASIC job in SMSQ/E (QPC2). It lists the keywords of the commands I've typed in.

For example: I open a new interpreter with the SBASIC command. I type "DIR ram1_:PRINT 0", then "BEEP 1,0" and finally "EXTRAS"... The keywords in the list are DIR, PRINT, BEEP and EXTRAS!

I think it didn't happen with SMSQ and my QXL years ago, but I'm not sure. Anyway it makes no sense. It seems a bug. The QPC manual says nothing special about EXTRAS.


Marcos Cruz (programandala.net)
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Bug in EXTRAS in SMSQ/E?

Post by RWAP »

This the default behaviour - I quote the SBASIC / SuperBASIC Reference Manual on this:
Within an SBASIC ( on SMS ) , EXTRAS only lists those keywords used in that SBASIC to date - this is because the whole name table is not copied when an SBASIC is started up, allowing different SBASICs to use the same name for different things.


User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Re: Bug in EXTRAS in SMSQ/E?

Post by programandala.net »

RWAP wrote:This the default behaviour - I quote the SBASIC / SuperBASIC Reference Manual on this:
Within an SBASIC ( on SMS ) , EXTRAS only lists those keywords used in that SBASIC to date - this is because the whole name table is not copied when an SBASIC is started up, allowing different SBASICs to use the same name for different things.
Thank you! There's no mention about that in the manuals bundled with QPC2 (I searched all the PDFs for EXTRAS before posting), and I don't have the Reference Manual.

But I don't understand two issues (because of my ignorance of the inner working of the interpreter):

1) I guess "The whole name table is not copied when an SBASIC is started up, allowing different SBASICs to use the same name for different things" means I could load an extension within a daughter SBASIC, with the same name but different behaviour than other extension already loaded in other running SBASIC, even the main one. Is it right? And an extension loaded into a daughter SBASIC is not avalaible in other SBASIC jobs. So every SBASIC keeps its own name table. But the standard commands are avalaible anyway in all SBASIC jobs, and the extensions loaded into the main SBASIC job are avalaible in the daughter SBASICs too. What's the problem about listing the avalaible keywords in the daughter SBASICs?

2) What's the point of listing the used keywords? Is it an irrelevant side effect or does it have any goal?

I find out this "non-bug" while checking a simple procedure I wrote to print EXTRAS into a ram file and check if some keywords are avalaible (In such cases I use the EXISTS extension, by Phil Borman, but In a special case I needed to check if EXISTS actually exists!). Everything worked fine in the main SBASIC job, but not in the daughters...


Marcos Cruz (programandala.net)
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Bug in EXTRAS in SMSQ/E?

Post by tofro »

Marcos,
this won't help much in your specific case, but for the sake of completeness:
Minerva copies the complete set of EXTRAS into daughter basic jobs. (I.e. EXTRAS shows identical output in job 0 and daughter basics.)
I'm not sure what happens should you try to override one specific S*Basic extension by another one in a daughter basic. The manual implies it should work.

And, in an attempt to find some reasoning for the (admittedly weird) behaviour:
I can quite well understand that there is is a (needs to be a...) job specific name table. A merge of all S*Basic Name entries would not only give a problem when overloading extensions in daughter basics, but also when a daughter basic ends (how should the OS know what names can be purged from the - then joint - name table?). So the algorithm seems to be: If you encounter a name, look into the job private name table. If you can't find it there, try to copy if from job 0.

EXTRAS should probably do the same - First list names from the daughter basic's NT, then do the same from job 0. And I guess it's just a side effect (or an omission in neglect of S*Basic jobs from the requirements.)

Cheers
tofro


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Bug in EXTRAS in SMSQ/E?

Post by RWAP »

Yes, toFro's interpretation is correct.

EXTRAS will first of all list definitions within the local SBASIC name table, and then looks to the main one - this has the effect that only used extensions are visible UNLESS you link a new toolkit into an SBASIC daughter job (ie. they get patched into the local SBASIC name table) - EXTRAS when used from within that SBASIC should then list all of those extensions as available.

Outside of that SBASIC, EXTRAS will not find the extensions.

This can be useful for coding new versions of existing SuperBASIC keywords for future development of SMSQ/e :-)


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Bug in EXTRAS in SMSQ/E?

Post by RWAP »

As for the reference manual - it can be purchased on sellmyretro.com -
http://www.sellmyretro.com/offer/detail ... on_CD-1397


User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Re: Bug in EXTRAS in SMSQ/E?

Post by programandala.net »

I tried VOCAB, a much improved version of EXTRAS, part of the DIY Tookit written by Simon N. Goodwin, and the same "problem" happens.


Marcos Cruz (programandala.net)
Post Reply