The Sinclair QL Forum

RIP Sir Clive Sinclair 1940 - 2021
https://theqlforum.com/

My "from PACKAGE import *" (Python) simulation project (reflection)

https://theqlforum.com/viewtopic.php?t=5227

Page 7 of 9

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Wed Jun 04, 2025 8:52 am
by Derek_Stewart
Hi,

With regards, to numberless boot programmes, I asked Laurence Reeves at a Quanta Workshop I organised in 1993, in Whitley Bay, Newcastle Upon Tyne, about numberless programmes, he seemed non-committal and seemed to like the idea, but maybe the control structures would have problems.

I stopped using this in SMSQ/E, where various experts said it was a bug fix, sorry I forget who, too many years ago.

I am interested in this Simulation Project, and it is refreshing to talk to professional people like Peter, who can programme computers correctly, I mean criticism.

Not a STOP statement, maybe PAUSE 10e100

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Wed Jun 04, 2025 10:17 am
by tofro
Me, personally, I see numberless BOOT programs (or numberless S*BASIC programs in general) more of an oversight sold as a "feature" (in Jan Jones' book) after the fact. But that's just an opinion fed by the hint that no original QL manual ever mentioned numberless BASIC files, and the first mention came up with the TK2 "DO" command (which used to have its own quirks in versions before 2.50). With numberless programs used with anything else but (a working) DO you can also run into all sorts of problems like files left open and be no longer editable,....

On the other hand, I have no problem if someone wants to use this quirk for something not possible otherwise - As long as it is made sure that all files are properly closed on all QDOS versions, which would be quite a feat. (As BOOT programs are, for most users, a "private thing" not distributed broadly, I'm not too fundamentalistic about that. But if you want to build a program feature based on them that could become widely distributed, you'll likely not do yourself a favour - You'll very probably produce a "works on my machine" program.)

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Wed Jun 04, 2025 3:55 pm
by polka
Hum ! I did not want to show MY boot program, only to use a typical boot program as an example to show how a little "Add_Line_Numbers" FuNction could together with all the power of MERGE, MRUN etc. let develop SuperBasic programs as an assemblage of unnumbered modules that are numbered and eventually managed only with SuperBasic IF ... ENDIF ( or other...) constructs, automatically on the fly when the program is loaded, and that no other special tools would be absolutely needed than those provided by BBQL SuperBasic + TK2.

The benefit being that everything is SuperBasic and thus remains individually small, readable and easily editable.

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Wed Jun 04, 2025 10:31 pm
by ql_freak
Finally I have found time to correct my reflection_cde toolkit :-)

Much thanks goes to Per Witte, who found and corrected a lot of bugs and provided a SuperBASIC test program. With the versions which were downloadable here until now, this program will fail (or even crash?) with out of memory.

Warning: It is under development, the only functions currently working are:

REF_GETLNLO% Returns the lowest line number of currently loaded SuperBASIC program.
REF_GETLNFREE% Returns the first "free" (lowest not yet used) line number (REF_GETLNHI%+1) of currently loaded SuperBASIC program
REF_GETLNHI% Returns highest line number of currently loaded SuperBASIC program (for Derek, I don't know why it should be useful, is the same as REF_GETLNFREE%-1)

Please note, except for merging REF_GETLNFREE% can be used to end your program with GO TO REF_GETLNFREE%

DO _N_O_T_ use the other function (REF_L%), it will not work and may (will?) crash your machine.

You also should not use the one PROCedure, albeit it does nothing, except slow down (most probably not notable) your program, it does currently nothing. I'm working on REF_L%. When I have finished, I will publish the source.

Included is also the current version of the executable rn program (it should be reentrant and if EJC documentation is correct even ROMable as it is compiled with EJC), which renumbers text files with or without line numbers (even mixed), but _N_O_T_ included GO TO and GO SUB statements(!). Look at examples from me in this thread, how you can combine this with REF_GETLNFREE% to merge any SuperBASIC (without GO TO or/and GO SUB statements!) program or command line file with your program, without the need to renumber the merged or your program. I will publish the source code of rn shortly (must refactor it before it can be published).

This may be useful for BBQLs with just Microdrive mass storage, as your stored programs must not include all the stuff needed at runtime, but can MERGE common routines when it runs (see examples from me in this thread).

tstreflect_bas is the test program from Per for reflection_cde (you should rename reflection0v1v0_cde to reflection_cde and use the original filename only for backups (so that you must not look inside the _cde file to find the version number).

rnTestFile01_bas (it is not a valid BASIC program!) is for testing the rn program with e.g.:

ex'rn';'10000 5 <WIN1_tmp_rnTestFile01_bas >WIN1_tmp_DELETE_ME'

Re: My "from PACKAGE import *" (Python) simulation project

Posted: Thu Jun 05, 2025 12:05 am
by ql_freak
Derek_Stewart wrote: Tue Jun 03, 2025 11:47 am I would prefer all S*BASIC programmes to numberless, and all programming could structured.
From what I have seen (determined) when developping reflection_cde SuperBASIC does NOT (not even in its tokenized form!) require line numbers. When I have finished reflection_cde (one PROC and one FuNc are still missing, before the 1.0 [or better 0.99] version), I will try to poke a tokenized numberless program into the BASIC-area, adjust the BASIC and System variables and try to run it.

Even if the interpreter will not run it or even the QL will crash:

It should be very easy to extend the interpreter so that it can run BASIC programs without line numbers (albeit ED would most probably not work with those programs and must also be extended, this could be a bit more complicated). The line numbers are really only required for GO TO, GO SUB, ... If you don't use it, it's absolutely not required. E.g. Python has no GO TO and more worse, it has no possibility to exit from an inner loop out of an outer loop (no problem in SuperBASIC, every loop has a name so you could use exit LOOPNAME (which is a kind of GO TO).

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Mon Jun 16, 2025 1:17 am
by ql_freak
2025-06-15 Sun (cottage/home):

Problem (REF_L%) get parameter via a3 (NOT CA.GTSTR!)

Technical Guide says A3 points to the first parameter (my function
is using just the first parameter, all others are ignored). So I get
the first parameter with:

move.w 0(a6,a3.l),d5

into register D5 (this seems to work).

Then I make a test if parameter is preceeded by hash (#); I will perhaps
later allow an hash for an extension, so for now it's forbidden.

Now I test for if parameter is a string (type $0201 aka ntString).

Yes it is :‑)

Then there is my problem. Technical Guide says:

A3 points to the entry of the Name Table entry of the first parameter. The
Name Table entry is 8 bytes, first word is the type of the parameter. That's
ok, it is $0201 :-), second word is the pointer to the name in the Name List.
This pointer is -1 if there is no name for the parameter in the Name List,
this is also okay (it's FFFF which is -1 in decimal). Technical guide says
the last long word of the name table entry is the offset of the value in the
SuperBASIC Variables Value Area (BV.VVBAS). Offset means it's not a direct
pointer to the value, but the offset into BV.VVBAS from start of BV.VVBAS (which
you IMHO should always get with 28(a6); BTW: If not explicitly noted all values
are of course in hex.

So I think you should get the value of the parameter (a pointer to a string
in my case) with the code between:

;BEGIN Supervisor Mode
and
;END Supervisor Mode

into register a0.

(IMHO the code would run in 99.9% without the switch into SV-Mode, but if
a new job will be started, SuperBASIC (A6) may move, so I be careful.)

Unfortunately it does not work. What's my fault?

NOTE: I do NOT want to use CA.GTSTR to fetch the parameter via the RI-Stack!
In my machine code function I just need the value of the parameter (a normal
QDOS-string) to compare it with another QDOS-string. So I want to avoid
CA.GTSTR (which requires to adjust the RI-Stack and some other things). The
string is there (pointed to via A3 into the Name Table), why should I put it
on the RI-Stack (which must be reset before returning to the caller).


Here is the assembler code (not assemblable[!], the labels, definitions like
equ are missing):

Code: Select all

;Example (not working) for getting string value of a parameter which is
;NOT fetched with the vector CA.GTSTR:
        cmpa.l   a3,a5          ;Are there any parameters?
        beq      errBadParameter ;No
        move.w   0(a6,a3.l),d5  ;Load type info of parameter
        btst     #bcHash,d5     ;Parameter preceeded by hash?
        bne.s    errBadParameter ;Yes
        cmp.w    #ntString,d5   ;Parameter is string? (We mustn't
        bne.s    errBadParameter ; currently care about separator
                                 ; as hash not allowed and it's
                                 ; the first parameter)

        move.l   ntValPtr(a6,a3.l),d7 ;d7=offset of string para. in VVA
;BEGIN Supervisor Mode:
         trap    #0              ;Switch into Supervisor Mode
         move.l  BV_VVBAS(a6),a4 ;Get base of variables values area
         move.l  8(a4,d7.l),a0   ;a0 should now point (absolute!) to
                                 ;string parameter in VVA
         sub.l   a6,a0           ;make a0 ptr relative to a6

         andi.w  #endSV,sr       ;Clear Supervisor Flag
;END Supervisor Mode
         move.w  0(a6,a0.l),d5   ;d5 should now hold length of string
;
; What am I doing wrong?
; (After LRESPRing this _cde file the following statement outputs 0
; (I think it should output the length of the string, i.e. 1 for the
; example below):
;
; PRINT REF_L%('x')

;preliminary for debugging, we always return 32767 (i. e. stop prog)
        move.l   #32767,d4      ;DEBUG: Return max. allowed line no.

;Following are debugging statements only, to get value in d5:
        ;and.w   #wRmHash,d5  ;Just for testing, remove eventual hash
        move.w   d5,d4        ;Just for testing, what's in d5?

        move.w    BV_CHRIX,a0   ;We need space on RI stack
        moveq     #2,d0         ;2 bytes required for line number
        move.l    BV_RIP(a6),a1 ;Per: Only QDOS needs this move
        jsr       (a0)
;Per Witte (thank you): We must correct the stack pointer with:
        subq.l    #2,BV_RIP(a6) ;This i where the real stack top is so
                                ;here's where we need to take the space
        move.l    BV_RIP(a6),a1 ;Restore RI stack pointer
        move.w    d4,0(a6,a1.l) ;Push line no. (short int) ...
        moveq     #QINT,d4      ;... set return type (integer [short])
        moveq     #0,d0         ;No error
        rts                     ;Return to SuperBASIC

errBadParameter
        moveq   #ERR_BP,d0
        rts

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Sat Jun 28, 2025 2:28 am
by ql_freak
I'm still working on one function I want to add to my Reflection Toolkit, before publishing the source code (it's more difficult, than I have expected). But if you want to try reflection, there are a lot of reflection functions in SuperToolkit II, especially in section 16 of the manual:

PARTYP(name)
PARUSE(name)
PARNAM$(number) : REMark number is the position of the parameter, e.g. for "myProc abc, def" PARNAM$(2) will (should?) return "def"
PARSTR$(name, number)

In DIY Toolkit there are additional machine code extension to find e.g. if a parameter is preceded by a hash.

Here a simple example:

Code: Select all

100 REMark SuperToolkit II Reflection
110 REMark e.g. for parameter examination:
120 :
130 DEFine FuNction decValue(num$)
140   REMark Return decimal value of num$
150   REMark if num$ is a string and it's
160   REMark preceeded by '$' num$ is an
170   REMark hexadecimal number
180   IF PARTYP(num$)=2 OR PARTYP(num$)=3:RETurn num$
190   IF num$(1)='$':RETurn HEX(num$(2TO)):ELSE RETurn num$
200 END DEFine
210 :
220 REMark Test:
230 PRINT decValue(3)
240 PRINT decValue(2.5)
250 PRINT decValue('10')
260 PRINT decValue('$10')
Output:
3
2.5
10
16

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Tue Jul 08, 2025 11:05 pm
by ql_freak
I have now for the first time tried reflection0v1v0_cde (version 0.1.0 from the last zip file I have uploaded in this thread) with QPC2 5.20.

It is working if it is LRESPRed in my boot program into the Resident Procedure Area (i.e. no jobs running when LRESPRed), also in MultiBASIC jobs. Even Pers SuperBASIC test program (also in the archive) runs OK.

But if LRESPRed from a MultiBASIC it doesn't run (except REF_GETLNLO%) and even worse, after an REF_GETLNHI% (output is 0) and/or REF_GETLNFREE% (output is also 0) and then a simple DIR command, QPC2 crashes fully (not even SYSMON is howling).

I have also detected that if you start a MultiBASIC from the EXEC menu or with the SBASIC command and you type EXTRAS only those commands are listed which have been already be executed in this MultiBASIC.

In sQLux (and I think also in UQLX) with Minerva all this is working perfectly.

It seems SBASIC is not really compatible to SuperBASIC. There was the problem with formal parameter names (see this thread) and now this malaise :-(

When I will find time, I will test reflection0v1v0_cde with an JS and JM ROM.

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Wed Jul 09, 2025 11:43 am
by janbredenbeek
ql_freak wrote: Tue Jul 08, 2025 11:05 pm I have also detected that if you start a MultiBASIC from the EXEC menu or with the SBASIC command and you type EXTRAS only those commands are listed which have been already be executed in this MultiBASIC.

In sQLux (and I think also in UQLX) with Minerva all this is working perfectly.
This is normal for SBASIC. It only loads new names into the name table which are actually being used in the child job, and then they inherit their properties from their ancestors in the main SBASIC.

As for your extension not working, it's generally not recommended to load extensions in SBASIC child jobs, especially not when they contain system extensions such as device drivers and interrupt servers. They will be destroyed when you quit the child job but the system will still have hooks to them in system tables etc., which may crash the machine. It's better to load them in the main SBASIC.

Re: My "from PACKAGE import *" (Python) simulation project (reflection)

Posted: Wed Jul 09, 2025 2:47 pm
by pjw
janbredenbeek wrote: Wed Jul 09, 2025 11:43 am <>
As for your extension not working, it's generally not recommended to load extensions in SBASIC child jobs, especially not when they contain system extensions such as device drivers and interrupt servers. They will be destroyed when you quit the child job but the system will still have hooks to them in system tables etc., which may crash the machine. It's better to load them in the main SBASIC.
To be more precise: It is quite normal to load toolkit commands into SBASIC daughter jobs (and, I presume, the same goes for MBASICs) They go away once the SBASIC daughter job terminates. This works similarly to including toolkits with Qlib- or Turbo- compiled programs.

As Jan rightly points out, systems extensions, ie toolkits that are designed to extend whole system capabilities must only be loaded into the main interpreter for the reasons he mentions. Such toolkits are, for example, ptr_gen, wman and hot_rext; certain timer toolkits, TK2 (there may be subsets that are ok to load), ENV_bin, etc. Some systems extensions have facilities to detach themselves from systems tables etc on removal of the job that owns them (mk79 demonstrated one such technique here a while back); I surmise easyptr may be one such.
All times are UTC+01:00
Page 7 of 9

Powered by phpBB® Forum Software © phpBB Limited