INT 21.58 order confusing

[ecm-pushbx]

With my bleeding edge IntList, 21.5802/.5803 is shown before 21.5800/.5801. Not sure how that happened.

INT 21 - DOS 5+ - GET OR SET UMB LINK STATE (AH=58h/AL=02h,03h)
INT 21 - DOS 2.11+ - GET OR SET MEMORY ALLOCATION STRATEGY (AH=58h/AL=00h,01h)

[shidel]

It is likely caused by these new "smart sorting" features. I had a similar issue recently in FPC when using the built in sort for TStringList. I needed to add a callout to a custom sort to fix it. It is even worse with the file viewer I use in macOS. In some directories, I cannot even find things with that program because of how it wants to sort the files. Any more for working on The List, I usually just open terminal, go to the proper directory and type something like bbedit *\ SET\ MEM*

If you look at those two files the "smart sorter" is likely seeing:

STRING NUMBER - STRING NUMBER+ - ....

And 5 is less than 211, so it would go first.

It is just being helpful.

:-)

[shidel]

Okay, I just had to share the crazy order shown by the program Path Finder on my Mac.

FYI, it is sorted alphabetically and INT 2D, INT 2F and others appear before this screen shot.

[ecm-pushbx]

I don't think the order in which makelist pastes the files is related to Path Finder?? Also, how do we fix this?

[ecm-pushbx]

Is this because of the matching unique IDs?

[shidel]

makelist sorts strictly by ID(+Category)(+duplicates) using a simple ASCII string comparison using a Red/Black Binary Tree.

It is not the ID. I just verified by creating a singe INTERRUP.LST file using the current data.

Line # 62979 - D-2158 - INT 21 - DOS 2.11+ - GET OR SET MEMORY ALLOCATION STRATEGY
Line # 63040 - D-2158 - INT 21 - DOS 5+ - GET OR SET UMB LINK STATE

They are in order in the LST file. But, with identical IDs there is no guarantee of that order.

I could have it perform it's sorting a little differently. It gets a little more complex. But with a little effort, it could sort those entries by adding another tree which sorts by using something like:

ID + CATEGORY + TITLE + (Duplicates)

[shidel]

Actually, as I think about it, I will discard the CATEGORY when sorting.

I will likely add the new sorting method to makelist tomorrow.

This should also prevent items with duplicate IDs from wandering about in The List because of changes in the filesystem and recursive directory scanning. That could occur at present by placing items with duplicate IDs into different sub-directories. Thereby changing when that item is processed and found to be a duplicate.

I will use strictly "Unique ID + Entry Title" for sorting. If it encounters an item where both of these are identical, it will throw an error and abort when using the --cicd option. I think this will be a good add. After all, while two IDs may be identical, those items should not have the same title. Otherwise, why are they not the same entry.

[ecm-pushbx]

I will use strictly "Unique ID + Entry Title" for sorting. If it encounters an item where both of these are identical, it will throw an error and abort when using the --cicd option. I think this will be a good add. After all, while two IDs may be identical, those items should not have the same title. Otherwise, why are they not the same entry.

It goes back to the unique id not being sufficiently unique I take it. So there's my suggestion to add a sort-order-affecting trail to the unique id. This could be discarded in the final .LST file, just read by makelist to determine the order. In this case a strict byte-by-byte comparison of the titles (DOS 2.11 vs DOS 5) would result in the expected order, but I don't think we should depend on this coincidence.

[ecm-pushbx]

That trail could be just a more fully specified unique ID. Eg, Unique ID: 2158-sort-as-215800. So makelist sorts like 215800 but only takes 2158 to generate the heading line of the actual .LST entry. Voi la, compatible output but with the correct order enforced by the sort-as ID trailer.

[shidel]

Looks fine to me. New parsers like yours and the coming html convertor can be away of that -sort-as- tail and either use or ignore it. However, it should not be present in the LST file when using the --legacy option. Should be easy enough to implement.

[ecm-pushbx]

Looks fine to me. New parsers like yours and the coming html convertor can be away of that -sort-as- tail and either use or ignore it. However, it should not be present in the LST file when using the --legacy option. Should be easy enough to implement.

It isn't present in .LST output files as of now, even without the --legacy option. I only use the sort-as-ID for sorting the tree, the list-as-ID is unchanged from before (ie 2158 for both entries).

(My parser doesn't operate on the source files, only on the compiled list file.)

[shidel]

It isn't present in .LST output files as of now, even without the --legacy option. I only use the sort-as-ID for sorting the tree, the list-as-ID is unchanged from before (ie 2158 for both entries).

(My parser doesn't operate on the source files, only on the compiled list file.)

Ah, you are correct. I was looking at it. But, forgot to build the new version before looking at the new output. So, I was seeing some -sort-as- items added to the section headers. Once, I recompiled the binary, those vanished like magic. :-)

Same here, the HTML generator will work from the compiled list. But, it will do its own sorting and organizing.