Use correct file time for filesLoaded hash table keys

[d-torrance]

The keys were filenames after we called realpath, but the keys were file times from before we called it, so they may have been incorrect for symlinks.

For example, consider the following situation, where bar.m2 is a symlink to foo.m2:

Current behavior:

i1 : needs "~/tmp/foo.m2"

i2 : debug Core

i3 : filesLoaded#"/home/profzoom/tmp/foo.m2"

o3 = 1749055336

i4 : needs "~/tmp/bar.m2"

i5 : filesLoaded#"/home/profzoom/tmp/foo.m2"

o5 = 1749055341

foo.m2 wasn't updated, but the file time was!

Proposed behavior:

i2 : needs "~/tmp/foo.m2"

i3 : filesLoaded#"/home/profzoom/tmp/foo.m2"

o3 = 1749055336

i4 : needs "~/tmp/bar.m2"

i5 : filesLoaded#"/home/profzoom/tmp/foo.m2"

o5 = 1749055336

[d-torrance]

Ugh:

testing: ../../../../../Macaulay2/tests/normal/files.m2
stdio:1:5:(3): error: can't see file '/Macaulay2' : No such file or directory
Command exited with non-zero status 1

[mahrud]

I'm confused, why did this start breaking now?!

[d-torrance]

I think it's because we previously called fileTime before we loaded the file, but now we're calling it afterwards. In this case, we'd called changeDirectory during the test and the path was relative, so things got messed up.

[d-torrance]

I ended up simplifying this a bit so that we still get file time before we load the file, but call realpath then too.

[mahrud]

I'm confused about all the force pushes, and I have to repeatedly test the dropbox issue. If a single internal test is failing, why not just fix that?

[d-torrance]

Sorry about that. An earlier push did "fix" that test, but as I thought about it some more, I think that probably wasn't the right thing to do. The file that's being loaded could run arbitrary code, so who knows what kind of shenanigans could happen between when we load the file and then get its file time. So I think grabbing the file time before we load it as we've been doing is probably the right move.

So I force-pushed a new version, where we called realpath before we loaded the file, but in the process, we also updated the filepath variable. This changed the behavior of locate for the loaded file, causing another test to fail.

The most recent force push keeps the filepath variable the same -- we just call realpath as we're grabbing the file time. I'm pretty sure this should fix the symlink issue without breaking anything else lol...

[mahrud]

This changed the behavior of locate for the loaded file, causing another test to fail.

Was this behavior important? It seemed the difference between absolute vs relative path in a test string.

[mahrud]

Actually, I think the test that failed indicated another bug:

restart
testpkg = "./test.m2"
testpkg << ///newPackage("TestPackage")
export {"func"}; func = x -> x
beginDocumentation()
TEST "assert Equation(1 + 1, 2)"
/// << close
loadPackage("TestPackage", FileName => testpkg)
pkgtest = tests(0, "TestPackage")
locate pkgtest
changeDirectory ".."
locate pkgtest
code pkgtest

Output:

i6 : locate pkgtest

o6 = test.m2:4:5-4:32

o6 : FilePosition

i7 : changeDirectory ".."

o7 = /home/

i8 : locate pkgtest

o8 = test.m2:4:5-4:32

o8 : FilePosition

i9 : code pkgtest
stdio:13:4:(3): error: couldn't find file test.m2

Interestingly, locate func and code func seem to find the code even after changing the directory, probably because the code location stored in the symbol/function has already been converted to its real path, but the test location is still relative.

[d-torrance]

The cmake macOS build timed out, but it did pass the test that had been previously failing!

  -- running   check(339, "Core")              -- 1.70333s elapsed

I think this might finally be ready.

[mahrud]

I don't want to tempt fate, so I'll rerun it just in case then merge it.