auto-file-extension problems.

[Dunbaratu]

(This refers not to the version on develop, but the version in erendrake's fork that will soon become the develop version.)

The use case scenario:

This is the thing I tried doing, as I figure it's the main purpose of the ML files and the filenames:

I have my old ascend script that I've used for ages (I really need to make it smarter some day). It consists of 5 separate scripts.

Use case: On the launchpad before launch, compile the 5 programs and copy just the compiled versions to the local volume of the craft, and then try running it from the local volume.

My copying was done with this:

//KOS
print "Compiling code on archive first.".
SWITCH TO 0.
PRINT "loadascend".   COMPILE loadascend.   COPY loadascend TO 1.
PRINT "unloadascend". COMPILE unloadascend. COPY unloadascend TO 1.
PRINT "consts".       COMPILE consts.       COPY consts TO 1.
PRINT "stager".       COMPILE stager.       COPY stager TO 1.
PRINT "ascend".       COMPILE ascend.       COPY ascend TO 1.
SWITCH TO 1.
LIST.

Here are the problems that this scenario discovered:

Double-appending file extensions if compiling again.

If you have a filename zzz and try compiling it twice in a row, you get this:

COMPILE zzz.
COMPILE zzz.
LIST.
zzz.ks
zzz.ksm
zzz.ksm.ksm  // <-------- oops!

Copy command picking wrong file.

When I wanted to copy the compiled version over, I couldn't because given a choice between copying the KSM or the KS file, COPY chose to copy the KS file even when it's older.

---

It occurs to me that the general problem is that which is the right file extension to pick depends entirely on the context of the command it's being used in. The decision can't be made at the level of just the file getting operation because it doesn't know why it's being gotten. For example, I suspect that the reason for the file zzz.ksm.ksm is that when compiling, the compiler saw that the existing KSM file was newer than the KS file and it picked the KSM file to start from on the principle that it's newer and therefore should be picked. (I haven't looked at the content of the zzz.ksm.ksm file to see what weird result it had).

I think I may have a skeleton of an idea for a solution to that problem. The methods that obtain or save a file in Volume.cs, like GetByName() for example, could be given optional extra arguments like so:

    ProgramFile file = vol.GetByName(
            filename,
            { Volume.KERBOSCRIPT_EXTENSION, VOLUME.KOS_MACHINELANGUAGE_EXTENSION},
            VolumeFileOrdering.NEWEST );

The above example might be how the RUN command gets the program it wants to run. The second argument is "this is the list of legal extensions for this command. To be considered it must be one of these". The third argument is "this is the ordering rule to use to disambiguate which of the set of legal files to pick if there's more than one."

To give an example of how it would be used in other contexts, the COMPILE command would have slightly different rules for its source file and it might say this:

    ProgramFile sourceFile = vol.GetByName( filename, { Volume.KERBOSCRIPT_EXTENSION} );

That would say there is only one legal type of extension in the list, everything else is disallowed, and therefore there's no need for a VolumeFileOrdering rule, so that optional argument was left out.

In this way it's the command trying to get the file who is deciding what the sane rule is for what it's trying to do, and you can go through all the commands that operate on files and make whatever rules you want for each one.

[Dunbaratu]

One thing that could help fix the copy problem (when I say COPY myfile TO 1. did I mean myfile.ks, myfile.ksm, or both?) Is to allow the COMPILE command to pick a destination location in the first place, like so:

COMPILE myfile to 1

Meaning volume 1, not a filename called '1'. The compile command can figure out which is meant (filename or volume) by whether the file starts with a number, which up until now no filenames could do because they must be identifiers.

That would keep the input and output in two places for now. For getting 0.15 out and kicking the ugly problems down the road, I'd be happy with just that fix alone. It would allow the use case to work for today and we can tell people that smarter filename stuff comes later.

The ugly problem that compiling causes is that you have to COPY the result to the craft when you're done, and unlike all the other commands, COPY can't tell what your intent is and it doesn't know which one you wanted to copy.

[erendrake]

@Dunbaratu what happens if you have renamed a volume and want to copy it to the name?

[Dunbaratu]

Now that we're doing a u-turn and changing the file extension solution, the volume suggestion above is moot. It was to solve a problem that won't exist anymore.