CaseCode hex or octal

[PhilLast]

I can't find any reference to it now but months ago it was almost agreed to change the case-codes from hex to octal to try to avoid the possibility of users' being confused by such as: #.abCDeFGHIjKLm-dec.aplf.

Octal includes only 01234567 so no confusion with names is possible.

I know it's me bringing up the subject and I don't mind doing it but have no particular desire to do so.

It's just that in the hope that acre's use might grow, sooner rather than later would be the time to make this change if at all.

It would require acre to put a temporary file entry in the project folder to flag which projects had been changed and it would preclude the possibility of opening a converted project in a previous version of acre unless case-coding had been turned off. There is justification that an inspection of existing case-codes finding no alphas could infer that octal was in use - statistically high but finite.

Can we put the idea to bed one way or the other? @e9gille @norberturkiewicz @PaulMansour @aplteam

[PaulMansour]

I've been meaning to bring this up as well because Link uses octal. As Morten said to me, the only reason Link even has case coding is to be compatible with Acre, they should have used hex. So here we are. In highsight, I would have preferred octal. Regardless, either Acre or Link needs to change.

[e9gille]

Yes, as with APLAN Dyalog agreed Link should implement it, but did their own flavor.

I forget now what you said Phil, but isn't Acre renaming files automatically if case code is enabled? If the content dictates the filename then it would only pose an issue with the char* files, right?

[PhilLast]

Acre does add or remove case-codes to or from all files and folders if you change the setting from CaseCode←'On' to CaseCode←'Off' or vice versa.

But that has nothing to do with the content or the file- or item-type and the only difference in the treatment of the .char* files is that they are not formatted using APLAN.

I assume from Paul's comment that given the benefits already mentioned and the need for a change somewhere it might as well be acre that changes.

In a possible future release of acre:

• On Opening a project acre sees that the CaseCode config parm is On.
  • If the files have no case-codes acre assumes the setting has just been changed, the files are renamed by adding octal case-codes and the config file is rewritten with CaseCode as Octal.
  • If the files do have case-codes they are assumed to be hexadecimal, the files are renamed with octal case-codes and the config parm is rewritten with CaseCode as Octal.
• On Opening a project acre sees that the CaseCode config parm is Off or Octal or missing.
  • Acre continues to behave normally.

[norberturkiewicz]

I will say that I don’t like the idea of renaming CAS at this point. Too many commits. I’m not opposed to adding an optional config property to set the encoding type. If omitted it would be octal.

Norbert

[PhilLast]

I don't think we should support more than one of hex and octal except during a transitional period when if the old were found acre would perform an automatic switch to the new and record the change in the project.

Copying source files from one project to another would become problematic.

In any case, changing branch could be a disaster if more than one branch existed prior to the change.

I think the only practical alternative is not to change.

[PaulMansour]

What's the confusion here?

.abCDeFGHIjKLm-dec.aplf.

The dash is not legal in a name, so if you see a dash you must know it is a case-code. No?

I think the only reason to go octal is that it looks a little less funny at the expense of a slightly longer code in some cases, no? And of course that Dyalog is using it. But the only reason they even have it is to be compatible with us.

I can ask them to change.

[PaulMansour]

Norbert, is your main objection the potential loss of history, or some space issue if Git does a rename on 10,000 files? I assume if it is a rename, the history is still there.

[PaulMansour]

Back in the old days, did we ever discuss system driven case-coding? That is, only if there are file name conflicts would acre add a case code, and only on subsequent duplicate names, not the first one. Thus on disk in a folder you might have:

gET.aplf
get-0.aplf
Get-1.aplf

Is this even possible?

[norberturkiewicz]

I believe the issue was fear third-party (I.e. github, gitlab..) services changing the casing on downloads.

[PaulMansour]

If I remember correctly, there are two issues case-coding solves: 1: duplicate but different cased item names potentially lost case info in file name due to case-insensitive operation system. I think the latter was dismissed by Adam as not really a big deal. Obviously system generated case coding only handles the former and not the latter.

[PaulMansour]

I believe the issue was fear third-party (I.e. github, gitlab..) services changing the casing on downloads

Yes, and while functions have the name in the file, folders (namespace don't, and losing case on folders would be a mess.

Dyalog obviously thinks this is not problem.

[PhilLast]

That is, only if there are file name conflicts would acre add a case code

Actually the very first edition of acre had case codes for change-files, as:

      {⍵,4 3⍕0.001×1000|2⊥⍵∊⎕A}'AbCdEfG'
AbCdEfG.085

and it added them to every item. It's not guaranteed but I got no duplicates in CAS that was about 7000 items at the time.

It was SALT that did it on an ad-hoc basis as your example above but SALT was (is?) single-user and it was not expected that anyone would be so silly as to copy files from one computer to another.

[e9gille]

CaseHash instead of CaseCode, I like it :)

[PhilLast]

Unresolved. Status quo pro tem. Closed.