COLON algorithm

[Derek_Stewart]

Hi

Sorry to be a kill joy, but why do you not know where the program is loading from?

I generally load the program S*Basic, executable or data file via Fileinfo2 and the storage device is known in the loading string, which details the device driver.

Maybe I look at things in a more simplistic way.

[Popopo]

Hi

Sorry to be a kill joy, but why do.uou not know eherethd program is loading from?

I generally load the program S*Basic, executable or data file via Fileinfo2 and the storage device is known in the loading string, which details the device driver.

Maybe I look at things in a more simplistic way.

Hi Derek.
No idea what is eherethd.
All fine if you are a kill joy, I would prefer time ago you would answer the basic question from me and many users about how to know from which source a program is launch.
But you didn't. Did you?
So now here is a way, pretty easy way.

What would be nice from you (if you don't mind) is to tell me if that Fileinfo2 is compatible with any ROM or requires specific one (version or type), but... barely (probably I am wrong) we are talking about different things.
What I have done, is a way to put it into your cartridge or floppy, insert it wherever you want, run it and the soft design now can run from it completely. Another user can use your disk or mdv... insert it in another place and run it the same without change or answer any previous question or line of code. That is particularly useful when the main code need to call and open files from the same device and doesn't know which one is its source.

Can you do the same with that sentence? if so, show me how?

[Derek_Stewart]

sorry about the spelling mistakes, I have correct them.

But maybe you do not use Toolkit 2, PTH, Turbo Toolkit.

Turbo Toolkit has a DEFAULT_DEVICE command, runs on all Roms.

The programming effort is tremendous and very well done, I complement you on your programming skills.

How do you integrate this into the operating system.

[Popopo]

sorry about the spelling mistakes, I have correct them.

But maybe you do not use Toolkit 2, PTH, Turbo Toolkit.

Turbo Toolkit has a DEFAULT_DEVICE command, runs on all Roms.

The programming effort is tremendous and very well done, I complement you on your programming skills.

How do you integrate this into the operating system.

Thank you Derek,
Default device is that, the referenced unit from where from this time compilation on, only the soft will work. If I understood you right.

I appreciate your help.
Let me do some little changes and I will describe more details.
But the nice of the point is... you don't need to implement in the OS anything. It doesn't matter at all.

Imagine you have this compiler with the defined variable or constant you have show me DEFAULT_DEVICE.
But instead it, you use a sys var or user var named unit$. So you have not more a direct link to a place, but the link reference will aim to the value of unit$.
Clear by now?
Ok, so what left is to add this value to the var. Since it is a variable defined in BASIC, so QDOS (Am I right?) you have this var in RAM and you can read from your code.

Now you set from QDOS or your basic loader the var as MDV8. OK?
And compile it and distribuite it, selling it, or sharing it... whatever.

I got my copy from you, because I love what you have done and I want my copy.
But I have not 8 Microdrives, not hardware virtualization (ie vMAP, whatever), so... I would like to enjoy your software from MDV1, how to do it?
I set the unit$ = MDV1
Then start your program. Since your program now is going to read the value of this var, it nows aim to my MDV1 instead the original used for you MDV8. That's all.

And it doesn't matter your ROM version for loading it, or ROM type, or device... doesn't matter. All references are relative to the var unit$. Wherever in the RAM is would be stored.

That is the point.

The thing that left is the exception manager.
If I want to do it automatically (that it would find itself, it means my MDV1), it is fine, but perhaps Arthur that also loved your software have gotten his copy and want to run it from Floppy1, since the autorsearching algorithm explore MDV1 and Arthur has not MDV1 inserted but FLP1, the program will try to open and fail, the catch of the exception and ignore it in order to proceed with the next device in the list of searching is very important. Otherwise Arthur or anyone must set from basic or into BOOT file the line unit$ = FLP1 .

Now I am going to change some things in the basic code to allows parameters and make it flexible.
What I need because my lack of experience is the management of the messages when a unit is not present or the TOKEN file is not present. Probably it may be trivial, but my lack of experience...
Also I am going to change the MERGE for another better MRUN. Just need to test if the control of the execution pointer is lost or remains. And solve it if it is lost.

Edit: In order to make it clear, I know compilers needs to have references settled before compile (in 90% of cases). uni$ is a example, you can read with a pointer in a direction a byte. The byte represent a number and the number represent a unit. From basic the user poke in that direction the number referenced. (ie. 00000001 for MDV1), actually the code of the demo could at the end with a If-else function recognize the unit and poke the equivalent of that RAM address where your program and everyone is going to read the value), even farther, they could be parametrized by the programmer when give the software in his BOOT or BASIC or compiled loader.

There are many ways to implement the algorithm. This one is a demo of the concept witch a good part is to find itself in order to know from where is loaded holding its own ID (token).

[tofro]

Your program has, unfortunately, a number of flaws (No intent to discourage you from going on, though):

• It doesn't support subdirectories - You're searching for the _TOKEN file to merge with in the root directories only
• The user needs to maintain a file named _TOKEN in addition to your program file. If he makes any error in doing this (like forgetting to delete it when he moves the program somewhere else), your algorithm breaks, unfortunately
• If you have more than one copy of your program (and thus more than one identical _TOKEN file) laying around, your algorithm only finds the first occurrence of that file, which is not necessarily the one which is running
• If the file was loaded through TK2's data default or prog default and the files hidden in a subdirectory, you won't necessarily find it
• If the drive list to search contains a device the user doesn't have (like "fdk_", for example) this will unfortunate break the program with an error. If he has a the program on a device that's not in the list, your algorithm won't find it. That means the user unfortunately still needs to adapt your program to work in his specific system. If he needs to do that, he could, with the same effort, just as well hard-code the path in the program to the same effect
• If your algorithm would be generally adopted, everyone would have a lot of _TOKEN files floating around on their media, which would significantly increase search time (Here I guess CTOKEN is the check you have the proper file belonging to the program)
• If someone accidentally creates a file named _TOKEN, your algorithm will fail. File names "reserved for me only" are not a good idea

First of all, I would propose to get rid of the _TOKEN file altogether - Instead of searching for that, you can just as well search for the program file name. If you still want to use the CTOKEN variable, put it in the first line that you read (not MERGE) from your program and compare, then. And my personal opinion is that in 2025, you can safely assume everyone has TK2. If he doesn't, well his problem. Your program could only improve if you do that as well.

BTW: I myself consider the problem you are trying to solve practically unsolvable in "standard SuperBASIC" without relying on special PEEKS into BASIC variables or accepting such flaws as mentioned above.

[Popopo]

Your program has, unfortunately, a number of flaws (No intent to discourage you from going on, though):

You are not the program actually doesn't matter, it is a poor implementation of the algorithm that is what matters.

[*] It doesn't support subdirectories - You're searching for the _TOKEN file to merge with in the root directories only

By now you are right. But there is a partial truth that I don't dare too answer completely till I confirm it my suspects.
Firstly think about it as a way to know where the main program is sourced. You don't have a BOOT file into a subdirectory of every Microdrive or may I think floppy?
Thinking about massive storage you are right but can be "fixed" in some ways. Firstly you want to know where is the rest of your program. The main problem is when you have installed a software that only runs from a localization that you have not in your system or you wish to run from another place. Not the code!!! but the algorithm to know from where I am, and thus to know where are the rest of my files.

[*] The user needs to maintain a file named _TOKEN in addition to your program file. If he makes any error in doing this (like forgetting to delete it when he moves the program somewhere else), your algorithm breaks, unfortunately

No need actually, again, you paid too much attention in the demo code, instead the algorithm, what restrains you from use another name? in few minutes I will modify it to allows parameters to change the name of the file that store the TOKEN. The token is necessary as BOOT file for booting from a MDV, or an executable that is mandatory to have to run the software, a library... why not this file too? I guess you want something completely transparent for device and system. Thus nobody figured it out before. Assuming it is not possible natively due to the OS to know from where a software was called, this is a way to solve it.

[*] If you have more than one copy of your program (and thus more than one identical _TOKEN file) laying around, your algorithm only finds the first occurrence of that file, which is not necessarily the one which is running

Tell me, why should I want to have 4 abacus loaded in my Microdrives?
How could I tell which one is each of them? Sames applies on this example and focus. You are looking for a pefect solutions that didn't exist. But this allows you to have different versions and with different IDs even now you could tell which one is your favorite ABACUS version without the need of running it. Just reading the TOKEN.

[*] If the file was loaded through TK2's data default or prog default and the files hidden in a subdirectory, you won't necessarily find it

Why should I hide it? Does anybody hide BOOT file? or the main program that ran an APP? You can do it anyway. I think it is possible to find the boot in a directory in a way as I use to install Windows 3.11 software or MSDos software in my floppies or hard disk. But since I have not one for QL, it is just a supposition. In any case, there is always a way. It is the cost in time of exploring due to access time or whaetver what must be considering. but again... this is an argument for massive storage case.

[*] If the drive list to search contains a device the user doesn't have (like "fdk_", for example) this will unfortunate break the program with an error. If he has a the program on a device that's not in the list, your algorithm won't find it. That means the user unfortunately still needs to adapt your program to work in his specific system. If he needs to do that, he could, with the same effort, just as well hard-code the path in the program to the same effect

You are right about breaking. That is why I am trying to finish an implementation to catch exceptions from access files or devices and manage to return an err code that the algorithm needs to skip it and process with the next device in the list. Again... the implementation doesn't matter in the demo. It is the algorithm what matters. the user won't need to do nothing. Let's imagine that the demo code doesn't work as expected now and never. But programmers use the reference variable or a direction in the RAM to read the unit from where it is running. The user only need to run the algorithm with a parameter that convert the referenced unit of his wish into a byte that the program will read to ID the place where to access for reading files that need (database, graphical editor, game to store whatever). Still this is useful since you don't need to rely on a specification of a driver when compilation time.

[*]If your algorithm would be generally adopted, everyone would have a lot of _TOKEN files floating around on their media, which would significantly increase search time (Here I guess CTOKEN is the check you have the proper file belonging to the program)

How many users are going to put in all their devices a disk and a microdrive at once? do you see?
At any case let's imagine the worse case and 20% users do it. OK, how many units has the QL? 8 MDvs if I am not wrong, how many floppies? how many massive storage?
Even farther... how many users has a massive storage?
Even more... how much software is developed nowadays that requires hard disk?
The reality is that this simple thing, is more a benefits for all users (even when they are not going to use it) than a problem for a part of the community.

[*] If someone accidentally creates a file named _TOKEN, your algorithm will fail. File names "reserved for me only" are not a good idea

That is why it can be parametrized... and again... are you going to create a program to call it BOOT and store it into a Microdrive where you have already an program that requires BOOT file to run?
I am agree about not to use reserved names, that is why it can be parametrized. Again... don't look at the code, it is a demo. Think about the algorithm and the functionality that it gives.
Perhaps I am wrong, but what I feel reading some comments is a resistance to adopt new things if it is not full compatible with what existed from 30 years ago. And adapt to every single possibility and case. That is not the purpose at all of any of my works. I pursuit to benefits the most part of people that I can.

First of all, I would propose to get rid of the _TOKEN file altogether - Instead of searching for that, you can just as well search for the program file name. If you still want to use the CTOKEN variable, put it in the first line that you read (not MERGE) from your program and compare, then. And my personal opinion is that in 2025, you can safely assume everyone has TK2. If he doesn't, well his problem. Your program could only improve if you do that as well.

I didn't get this point. The token is a concept as you know. Who said the token must be a file with a number inside? Did I? if I did, my mistake. You can search for anything that identify your disk, your microdrive, your directory. But a IMO a better way is to use a standard one that everyone knows what means and contains. But it is ups to the programmer or person who use the algorithm or the demo code for his purpose.

BTW: I myself consider the problem you are trying to solve practically unsolvable in "standard SuperBASIC" without relying on special PEEKS into BASIC variables or accepting such flaws as mentioned above.

About it, same than above. You are thinking about how I have implemented the algorithm for the demo, I have not enough acknowledge about Basic vars. Peek solves some parts? great, tell me how to use it. I have reading docs but it is so wide that I cannot absorb all of it at once, nor in a week or a year. Help is welcome.

First answer to your post.

Yes, you are right, it was a not the best demo. Some of those points, are going to be solved in the demo soon (tonight I hope)
I have add some new lines to my last comment that are related with some of your points.

About many tokens... it is only a file. one line of text. Not too much to deal when we think about 1 cartridge or floppy with its own TOKEN file (which name is going to be defined by the user by parameter).
About hardisks yes, I don't like too much to have in each directory a token for APP, but this is another context and also there is a point of view that solves it. Same than BOOT file doesn't bother users to have one in their Microdrives images or cartridges.

The main is that now I show a way to allows your code to run from any unit, and it can find itself and give the parameters to your APP to use them inner other file references inside it when you need to access to the source to read a file. it doesn't rely on ROMs type/version, or other tools releasing RAM resources to run the code or store data.

The exception is the clue, how to catch it. And it can be outsourced to a C code program or ASM that try to open a device and return a code in case of err. As QDOS does when I type "dir noexistunit_" it doesn't freeze but get an error message, so why not a pretty small program of few KB that does this job before free the used ram?

I very thank you for your comments because helps me to learn more and also to solve what I have forgotten to add.

Later I will edit this comment in order to answer properly point by point.

[SM7I]

@popopo

Does this exist in C ?

[Popopo]

@popopo

Does this exist in C ?

It is an algorithm so can be implemented in any language for anyone. Since I understand that the idea is not always clear about how to use it, I guess it is better if I do a functional and stable version.
About a implementation of it into C, no idea if someone is going to do it.
I could compiled it, but firstly I want to change it a little to do it more flexible.

A pure C version I could implement it, but not soon because lot of tasks to do in other projects.
I am interesting to do it since also I Want to program software for QL in C. That could be a easy way to start.

Why do you need it in C?

[bwinkel67]

So this question is not directed at the BASIC code here but just a general one. I'm surprised this hadn't ever been addressed by any of those Sinclair QL World Simon Goodwin DIY code bits, or by the many add-on toolkits that someone wrote. Really LRUN, EXEC, and EXEC_W ought to set some system variable that could be checked (similar to ver$, maybe called dev$) to see which device a program was loaded or executed from, otherwise it's easy enough to add a one-liner: INPUT #0, "Device? ";dev$

[Derek_Stewart]

Hi,

Sounds like you are doing great work.

Personally, I will stick to using Toolkit 2 data and program defaults and PTH for path searching.

You could have a search path of MDV1 to MDV8, so do not really need to know the location of the program. But this is a personally opinion on how I set a QL environment.

I the flexibilty, of being able customise the way the system is setup otherwise we end with a Windows, Linux or MAC system.

I only use Minerva or SMSQ/E anything else does allow multitasking Basic.