tofro wrote: Sun Jan 19, 2025 7:57 pm
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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*] 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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*] 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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*] 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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*] 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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*] 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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*]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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
[*] 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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
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.
tofro wrote: Sun Jan 19, 2025 7:57 pm
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.